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.
> 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.
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.
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.
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
>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?
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.
> 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.
> 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.
> 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...
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.
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).
Where do you store the SQLite database files? What is your strategy for partitioning your data into SQLite files? One per user or…?
Developing webapps only for iPhone was Jobs original strategy. Only changed when developers complained.
> Most of my apps are now simply HTMX + Go + SQLite.
Would like to hear about your Go stack for building htmx apps.