Hacker News new | ask | show | jobs
by faangguyindia 7 days ago
Most of my apps are now simply HTMX + Go + SQLite.

I've found it's enough for most projects.

One of my sites is image heavy and serves 10 TB of traffic per month. For this, I use the following setup:

1. S3 (I wanted reliable data storage) 2. In front of it, I have Cloudflare (with Tiered Cache enabled, which makes POPs prefer pulling from Cloudflare rather than the origin). I've set rules to cache everything on both the browser and Cloudflare for 1 year, ignore origin cache policies, ignore query strings, etc., and I simply use immutable objects that require revisioning. 3. BunnyCDN in front

Cloudflare will not let you run an image heavy site on its own, so I use this approach to massively cut the bills. Their policy says you cannot use it primarily for images; it must be used for HTML, CSS, JavaScript, and other site content.

And if you run only S3, the bills will be huge.

But yes, lately I’ve been building mobile apps. PWAs are limited; the OS can evict IndexedDB storage, so I cannot offer people reliable data storage in the app without sign up or involving a backend.

What can I do? So I was forced to switch to Flutter on Android, but I ran into another pain point: app updates sometimes spend a lot of time "under review," which is frustrating. For the same app, I maintain a web app that is very quick to update by comparison.

I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.

I like how quickly you can update PWA app.

18 comments

> I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.

There is! You just have to time travel all the way back to 2009 when webOS was launched by Palm. Time travel is the easy part, you then also need to somehow prevent Palms demise and webOS fading into obscurity as a smartphone OS.

If 2009 is too far back you can try your luck in 2012 with Firefox OS.

Joking aside, people and companies have given it a go. But a combination of bad timing and various other events never made that reality happen in our timeline.

Maybe I'm missing something but aren't PWAs pretty dead-simple on both iOS and Android? Maybe it's the "reliable storage" part that's the gap?
The amount of effort that goes into keeping Termux barely functional, has a lot to do with Android and the platform making it harder and harder, to access a dev environment on a phone.

Running `npm install` on Android isn't so easy.

(Caveat: The new Android Terminal that only works on a handful of models.)

I thought I read that one or both of them removed or heavily restricted PWA support to funnel more apps to their 30%-taking app store.
No that's not correct, they both support PWAs with a large feature set. I built and have been maintaining a client's PWA (an internal tool for their employees) for over 10 years now.

Not my site, but someone on HN (can't remember who) built it: https://pwascore.com

iOS was PWA-only to begin with, but at the same time, OS X didn't support them at all. It was a messy time, but has since changed. [0]

[0] https://github.com/mdn/content/issues/32969

Alternatively, you could try to keep HP from killing the TouchPad
You can still buy KaiOS phones, I have one.
Sure, but they aren't exactly widespread or even close to mainstream.
Go is so awesome for server apps. I should have discovered it much sooner. It somehow sits in the exact optimal point having no bullshit overhead like C, yet also getting out of your way so you can focus on the business logic like Java (not Rust).

It's not great for every task - in particular the lack of abstraction-building capabilities - but it's great for business-logic-heavy server apps. It feels like it's specialized for that and not trying to be a jack of all trades.

>One of my sites is image heavy and serves 10 TB of traffic per month

I can't imagine this kind of traffic without acting as a CDN, advertising broker, pornographer, or part of a massive ecommerce site. I have to wonder, what are you doing that generates 10TB of traffic per month?

Lots of legitimate businesses that deal in maintenance have ridiculous amounts of image data.

I have a civil engineering firm as a client, they take video & photo’s of roads they help project manage the maintenance on.

Small towns of 10000 can have ridiculously big road networks in Australia. And you take a photo every 10m, likely more but you only care about every 10m. It adds up, quick.

I’m only now investigating a web version of the app I wrote them because I think origin file system will work for them but I would never consider serving their 200TB+ of their imagery as a website.

10TB is nothing these days. All Hetzner virtual servers in Europe have 20TB/month traffic included (excess less than $2/TB) and all their dedicated servers have unlimited fair use (which is probably about 200TB/month averaged over many months).
Are you me? I've been on a tear building stuff with HTMX + Go + SQLite. It's like the trifecta of boring technology that jives with me. Stuff gets deployed to a colo server using a generic bash script.

I created a couple libraries to abstract the SQL and HTMX/web/OAuth bits; my apps are now very similar and easy to copy features between.

https://github.com/cattlecloud/webtools

https://github.com/cattlecloud/litesql

> Cloudflare will not let you run an image heavy site on its own

Cloudflare R2 object storage is S3-compatible, offers free egress, and does not share their CDN product's fair use policy against image-heavy use. Storage is 65% the per-GB cost of S3.

yes, you are right i didn't see their update: https://blog.cloudflare.com/updated-tos/
> I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.

Because there isn't a 30% walled garden you can create with that.

Since you're using HTMX, I have to ask: do you have any tips or idioms for composing complex forms and UI without things getting out of hand? I love the approach, but I'm having a bad time figuring out where the ideal balance is between too few or too many HTMX-replaced areas in a page. Thanks.
My #1 advice is not creating separate server endpoints for every HTMX fragment, unless you are 1000% sure that endpoint will be used in multiple different pages.

Working on a "simple html page" that is actually 5 different independent "subpages" (routes, views, templates) in the backend is awful. The UX was improved, but the DX was sacrificed.

I recommend having a single view function for each page/SPA and do sub-routing within that function to handle page fragments. In other words, use a GET/path/Header parameter that indicates which fragment is currently needed, defaulting to the full document as normal. Just make sure you are considering request logging and client-side caching in your solution.

This makes it very easy to add/remove async content from the page, since you are just editing the one view function/template and you can easily reason about the entire page as one logical unit.

It also means you don't need to duplicate security logic or other middlewares for the page, since it can be implemented once at the start of your multi-faceted view function.

Generally you don't even need to do the sub-routing in the handler. You can just render the entire page and have `hx-select` attributes pluck out the part that you want.
That is a good solution for reusing content across pages, but most of my HTMX usage is for fetching data that would otherwise delay first page load significantly, or for seamless interactivity. Very different use cases.
This is huge, thank you.
> Cloudflare will not let you run an image heavy site on its own, so I use this approach to massively cut the bills. Their policy says you cannot use it primarily for images; it must be used for HTML, CSS, JavaScript, and other site content.

Pages has a 20k-100k limit on static files, but if they just guide you to R2 to offload it, which is still Cloudflare.

Did you mean the CDN? In which case, I'm not seeing that in the terms. [0] Though, I would have expected they'd have a similar thing. R2 resources don't generally count towards your cache limits.

[0] https://www.cloudflare.com/service-specific-terms-applicatio...

Looks like "Section 2.8 to give Cloudflare the means to preserve the original intent of the CDN: limiting use of the CDN to webpages." is gone.

https://blog.cloudflare.com/updated-tos/

interesting, it seems now i can host stuff directly on r2 and put CF in front and serve images, video and other files!

> Most of my apps are now simply HTMX + Go + SQLite.

Very cool!

> But yes, lately I’ve been building mobile apps. ... What can I do?

I am currently building HTMXNative.

Together with Objective-Smalltalk, which has linguistic support for REST built-in.

The idea is that you create your model in a natural way and then thinly wrap it to deliver wherever.

> Most of my apps are now simply HTMX + Go + SQLite.

Would like to hear about your Go stack for building htmx apps.

I've learned about several frameworks that are system language + web frontend. The general approach is, ship a small binary compiled for the specific platform, and use the platform's native browser (and whatever html frontend tech you like) for frontend. The whole binary can be 1mb or less.

There's a couple of Rust libraries like this; right now I'm building an app in Tauri+Svelte.

It looks like Wails might be a similar framework in Golang.

On the mobile point, there is https://github.com/instawork/hyperview

Your Go server can have endpoints that render XML instead of HTML and basically get the same server-driven experience of your HTMX site. Fully skips the need for the app review process since you're not updating the actual client app code to make UI changes.

> I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.

There WAS. Firefox OS phone! HTML+CS+JS apps! But Mozilla kicked it to the graveyard even though it was very popular in third world nations. I guess it was not $$$$$ enough for the Mozilla CEO of that era.

Can't vouch for it's effectiveness, but Hotwire Native might meet the needs for mobile paired with plain HTML. Despite the name, it doesn't seem that using Hotwire for the web UI is necessary to use Hotwire Native. I could be wrong about that though.

https://native.hotwired.dev/

Hotwire doesn't work anywhere you can't guarantee a high-quality low-latency connection. Every UI interaction in Hotwire includes that round trip.
That's pretty much true of HTMX too (which is what GP mentions using). I mention Hotwire Native (different from plain Hotwire) because it makes it easy to wrap a web app as a mobile app. Then you can replace performance critical parts with native views, but keep everything else working through the web app portion. This is easier to maintain, albeit with the downside that everything requires network round trips. Depending on you use case, that may be an acceptable tradeoff.
Where do you store the SQLite database files? What is your strategy for partitioning your data into SQLite files? One per user or…?
> Where do you store the SQLite database files?

What? On the server, where else would you put it?

You only have one server?

Then that approach will work. If you need to scale beyond that, you need some way to route the request to the server with the right data. And what if a request needs data that was stored on two different servers?

Those are the kinds of questions I had in mind.

Developing webapps only for iPhone was Jobs original strategy. Only changed when developers complained.
have you considered Capacitor? it works pretty well for cross platform web development