PWABuilder VS localfirstweb.dev

For a PWA to be listed in app stores, it must be wrapped within additional software. This wrapper tends to be less robust and not as finely tuned as mainstream browsers, a fact that even PWABuilder acknowledges.

Not to trivialize anyone's discovery; always happy to have more people on this bandwagon!

But I have to say, PWAs (progressive web apps) might blow Jim's mind here.

https://docs.pwabuilder.com/#/home/pwa-intro

excerpt (emphasis added): "Service workers are how progressive web apps work offline: service workers can _cache essential resources and handle requests when the network is down_. Every request to and from a PWA goes through the service worker, and there are a ton of different strategies for how to cache and fetch necessary resources."

There is some way for iOS, and some iOS apps work on M1, so maybe. Although Apple has been removing PWA style apps from App Store, so better check newest requirements somewhere at docs.

https://www.pwabuilder.com

https://docs.pwabuilder.com/#/builder/app-store

Depending on how you ship these polyfills, you may even open up a security risk for them. There is a reason there are best practices such as progressive enhancement and local first. Is this always possible? Probably not, but does that mean we throw out the baby with the bathwater? I do not believe that is a good approach.

For those wondering what this is about (like I was). This is from their website:

So, you want to build an app that has its data co-located with its UI? That works offline? That synchronizes between clients? And that lets its users own their data?

Welcome to the world of local-first web development.

https://localfirstweb.dev/

That's awesome you've already considered of a similar design to Triplit. Re: storage, Triplit can basically bind to any storage capable of providing ordered key values so we have bindings for SQLite but in the browser you're best of doing either in-memory or IndexedDB (both of which are built-in), examples here: https://www.triplit.dev/docs/client-database/storage.

Regarding similar projects there are a few you can find on https://localfirstweb.dev/ but Triplit stands out in a few ways:

This is sometimes called "LoFi" development these days and there's a Discord where people discuss it:

https://localfirstweb.dev/

Despite the name it's not really a web exclusive community.

Actually the web isn't a great way to do this, there's alternate stacks that maybe can work better. The Android stack has been rewritten in recent years by Google and parts are now usable on desktop and iOS. Someone posted this to the Kotlin slack earlier today which is how they implement local-first using the Kotlin stack:

https://medium.com/@mike_21858/auto-generating-an-http-serve...

The idea is that you can use Kotlin for both server, Android and also a desktop client, and with KMP you're also able to use it on iOS for the backend (UI is still in Swift). So you can share your domain model across all devices and the underlying sync protocols and logic can be auto generated using a compiler plugin. The underlying DB is SQLite wrapped using a library from Google called Room which makes SQLite a bit easier to use.

I’ve been working on apps for limited connectivity environments such as Afghanistan and rural Rwanda for many years. I think we have to make offline-first a lot easier than it is now. Our own app Ustad Mobile has more than 60 tables in the database. Writing manual logic to run all of those offline would 1) exceed the resources we have and 2) be prone to human error.

This article introduces Door: our open-source way to automate the generation of an offline-first data layer using Kotlin Multiplatform and Kotlin Symbol Processing (KSP). Door is still a work-in-progress and not ready for production use in other apps yet, but we think it’s a game-changer for offline-first development. Feedback on the concept and API is welcome. Door can automatically generate HTTP server endpoints and an offline first client based on a Room database.

Deploying such an app on Android is obvious, for iOS you need to learn about Kotlin/Multiplatform but obviously SQLite can run on iOS just fine and Kotlin can interop with Objective-C/Swift. For desktop, deployment is easy if you use Conveyor, which the Ustad guys are planning to do, as it supports Kotlin desktop apps out of the box. You do need to buy signing certificates (or distribute via the app stores) but that's a one time cost.

The main issue here is if you're wedded to the web. Probably stuff can be done with WASM but it's not going to be as natural as just using the tech on the JVM.

This is a growing area of focus in some web communities, and it's called local-first. Verdant is a full local-first framework, including upgrading to multi-device sync and multiplayer with a server when you're ready. I wrote a bit on it elsewhere, and there's an emerging community around local-first more broadly. Check it out!

WASM and Web Workers- unless carefully used - won't magically make your UI snappy.

There are three reasons (for the vast majority of apps) that a UI feels sluggish:

1. The network! Requesting data from a server is slow, by far the slowest aspect of any app. As a start, prefetch and cache, use a CDN, try edge platforms that move data and compute closer to the user. However, if you can explore Local First (http://localfirstweb.dev), for a web app it is the way we should be looking to build in future.

2. They are doing work on the UI thread that takes longer than 16ms. This is where Web Workers are perfect, the DX around them isn't perfect, as another comment suggested Comlink helps, but there is a lot of opportunity here to build abstractions that help devs.

3. Excessive animations that delay user interaction - there is so much bad UX where animations have been added that only make things slower. Good animations have a purpose, showing where something came from or is going, and never get in the way.

Finally, we are well into diminishing returns with front end frameworks optimising the way they do templating and update the DOM. The key thing there now is DX, that is how you pick a framework, benchmarks are almost always useless.

The real "edge" is the users device, I'm 100% sold on the concept of "local first". There is a great community building around this: https://localfirstweb.dev/

This is very much what the local first movement is about: https://localfirstweb.dev/

Give users control of their data, moving away from large backend infrastructure, and providing better value to the user. With the bonus of having a more enjoyable development environment and an excited community.