list-positions-demos VS localfirstweb.dev

* Typescript schemas and type hinting in queries in return types

For more advanced CRDT stuff, the creator of the Fugue List CRDT, created [a Triplit-powered collaborative text editor](https://github.com/mweidner037/list-demos/blob/master/tripli...) using Quill and his [List Positions](https://github.com/mweidner037/list-positions) library that we plan to have tighter integrations with.

The kind of scenario screams a local-first applications and solutions, and it's the reason why the Internet was created in the first place [1][2]. People have been duped by the misleading no software of Salesforce's advert slogan that goes against the very foundation and the spirit of the Internet. For most of its life and duration starting back in 1969, the Mbps is the anomaly not the norm and the its first killer application of email messaging (arguably the still best Internet application) is a local-first [3]. Ironically the culprit application that the author was lamenting in the article is a messaging app.

[1] Local-first software: You own your data, in spite of the cloud:

https://www.inkandswitch.com/local-first/

[2] Local-first Software:

https://localfirstweb.dev/

[3] Leonard Kleinrock: Mr. Internet:

https://www.latimes.com/opinion/la-oe-morrison-use24-2009oct...

Website: A good starter site with many follow-up topics - Local First Web

Local-first (https://localfirstweb.dev) is a term that's not really well understood. Even though I have read on CRDTs etc. before, my first thought when I read local-first was that this is a web app that could work without network connection. I think we need a better term for web apps that sync to the cloud in a different fashion.

- Regulatory Challenges: In the places where this is most needed, the country's laws are going to make it difficult for this app. I suspect you need to make this public and put that risk, unfortunately, on the side of the user. But some aspects that could help are using local first data (https://localfirstweb.dev/) where possible and decentralised data storage when it's not.

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!