[verisimilidude]

Ah yes, let's ask people on spotty connections to download a (likely) megabytes-large JavaScript bundle. What could go wrong?

Most of my users have old phones and bad connections. I've tried this JS-heavy bundle-first approach. It doesn't work.

The solution is way simpler than local-first. Just shrink every page and interaction. Fewer requests, little JavaScript (if any at all), low latency. Use static pages when possible. Even the oldest phones on the most remote connections can usually deal with a sub-50kb page all-in. It feels like people forget how simple web interactions can be.

I'm sure local-first can be great for highly interactive tools like Figma. But the grandparent is right. Most sites don't need anything close to that level of complexity.

[LAC-Tech]

I feel like you're conflating a few different things here.

Small pages and interactions are good, sure, but I don't really see a tension between this and local first. My homepage is static HTML (minus google analytics) and it works offline.

The multi-mb JS bundle is also a red herring. The only multi-mb JS bundle I ever worked with did not work offline at all. Feel this is orthogonal.

Also connectivity for people is usually something that changes with time. You have it in the farmhouse, but not out in the field. You have it at the office, but not on the road. So downloading stuff when you have connectivity and still being able to read/write what you don't is the real aim of the game here.

[verisimilidude]

If you're using browser APIs to do lean local interactions, then good for you. Gold star. Fully approved. That's not what I've been seeing recently from the people around me who are most excited about this stuff.

And you're right about how connectivity changes over time. But how many people are on their bikes when applying for unemployment insurance? I just don't think most business apps benefit from this level of offline support. There are of course use cases for this! But it's not the common case.

[LAC-Tech]

I think we're in broad agreement.

And you're right, if it's OK to not be able to read or write during a network partition - then you don't need this. But I would encourage everyone out there to figure it out first as bolting it on after the fact is a real challenge.

[rapnie]

You are making an assumption on megabytes-large JS bundles. Also, how well do lean and mean pages load when you lose internet connection?

[verisimilidude]

Not much of an assumption. Many local-first solutions work from a big wad of JS. I've seen use of WASM to include things like SQLite. It's not pretty.

My point is that if you're in danger of losing your internet connection, you're not going to be able to reliably get that initial JS bundle anyway.

[rapnie]

Yes, but "local-first" and "Big JS" aren't related. Sure you can build any monstrosity and make it local-first. And my local-first software can be a Tauri app, installed-once, or any kind of local software for that matter.