I wrote a static web page and accidentally started a community (2023)

I love the localfirst idea but I don't love web browsers. They're the platform everyone has to have but shoehorning 40 years of UI development and products into them seems like a mistake.

I can see why local UI development fell out of favor, but it is still better (faster, established tooling, computers already have it so you don't have to download it). I can't help but feel like a lighter weight VM (versus electron) is what we actually want. Or at least what _I_ want, something like UXN but just a little more fully featured.

I'm writing some personal stuff for DOS now with the idea that every platform has an established DOS emulator and the development environment is decent. Don't get me wrong this is probably totally crazy and a dead end but it's fun for now. But a universally available emulator of a bare bones simple machine could solve many computing problems at once so the idea is tempting. To use DOS as that emulator is maybe crazy but it's widely available and self-hosting. But to make networked applications advancing the state of emulators like DOSBox would be critical.

Actually local first, maybe the way forward is first to take a step back. What were we trying to accomplish again? What are computers for?

From something I wrote in 2021 [0] and based on my experience working on a "browser-based OS" in 2013:

    What we need is to have a device-transparent way to see our *data*. We got so used to the idea that web applications let us work from "dumb terminals" that we failed to realize that *there is no such thing as a dumb terminal anymore*. With multi-core smartphones, many of them with 4, 8, 12, 16GB of RAM; it's not too hard to notice that the actual bottlenecks in mobile devices are battery life and (intermittent and still relatively expensive) network connectivity. These are problems that can be solved by appropriate data synchronization, not by removing the data from the edge. 

    One of the early jokes about web2.0 was that to have a successful company you should take an Unix utility and turn it into a web app. This generation of open source developers are reacting to this by looking at successful companies and building "self-hosted" versions of these web apps. What they didn't seem to realize is that **we don't need them**. The utlities and the applications still work just fine, we just need to manage the data and how to sync between our mobile/edge devices and our main data storage. 

    If you are an open source developer and you are thinking of creating a web app, do us all a favor and ask yourself first: do I need to create yet-another silo or can I solve this with Syncthing?

[0]: https://raphael.lullis.net/thinking-heads-are-not-in-the-clo...

This ties in nicely with the bookmarking discussion about Pinboard. I particularly like the following quote from this article:

> Now, of course, there are many advantages to this shift: collaboration, backups, multi-device access, and so on. But it’s a trade! In exchange, we’ve lost the ability to work offline, user experience and performance, and indeed true dominion over our own data.

I’ve decided that the advantages of storing my bookmarks locally far outweigh the chance that I'll want to access them from a different device or collaborate with someone else on them. Yes, it means I've created something of a 'silo', but I'm starting to think that's not a bad thing.

Another aspect of local-first I'm exploring is trying to combine it with the ability to make the backend sync server available for local self-hosting as well.

In our case we're building a local-first multiplayer "IDE for tasks and notes" [1] where the syncing or "cloud" component adds features like real-time collaboration, permission controls and so on.

Local-first ensures the principles mentioned in the article like guaranteed access to your data and no spinners. But that's just the _data_ part. To really add longevity to software, I think it would be cool if it would also be possible to guarantee the _service_ part also remains available. In our set up we'll allow users to "eject" at any time by saving a .zip of all their data and simply downloading a single executable (like "server.exe" or "server.bin"). The idea is you can then easily switch to the self-hosting backend hosted on your computer or a server if you want (or reverse the process and go back to the cloud version).

[1] https://thymer.com/

I created https://sql-workbench.com a while ago, mainly to let people analyze data that's available via http sources, or on their local machines, w/o having to install anything.

A recent project is https://shrink.video, which is using the WASM version of ffmpeg to shrink or convert video in the user's browser itself, for privacy and similar reasons mentioned before.

I’m working on a kanji learning app (shodoku.app) which some might say fulfills this ‘local first’ philosophy. Currently it is hosted on GitHub pages and relies on static assets (such as dictionary files, stroke order SVGs, etc.) which requires a web connection to fetch. However when I make this a PWA (which I’ll do very soon) these will all be stored in the browser cache, effectively making it work offline.

I store the user data (progress, etc.) in an indexedDB in the user’s browser and I have to say:

> No spinners: your work at your fingertips

is not true at all. indexedDB can be frustratingly slow on some devices. It also has a frustratingly bad DX (even if you use a wrapper library like idb or dexie) due to limitations of the database design, which forces you into making bad database designs which further slows things down for the user (as well as increases the total storage consumption on the user’s device).

I also wished browsers offered a standard way to sync data between each other, even though you can share your firefox tabs between your phone and computer, you can‘t get the data from indexedDB on the same site between your computer and phone. Instead you have to either use a server or download and drop the data between the two clients.

indexedDB feels like a broken promise of local first user experience which browser vendors (and web standard committees) have given up on.

I was introduced to Local First while watching this conference by Martin Kleppmann (the author of Designing Data-Intensive Applications book): https://martin.kleppmann.com/2023/06/29/goto-amsterdam.html. It's worth watching!

This gives me hope that we can get native apps back again, and collaborative work through them without the browser or a central authority

Love this. I had always referred to this concept with the rallying cry: "'offline' is not an error"

> But I was equally surprised by how little this was being discussed, or (as far as I could tell) practiced in the real world. While there seemed to be endless threads on Twitter about server-side React (to get the UI generation closer to the data), no-one was talking about the opposite: moving the data to be closer to the UI, and onto the client!

This, I've wondered for a while. There is plenty of talk about server side rendering, which I don't think is useful for many apps out there. SSR is quite wasteful of the resources on the client side that can be made useful. And, I've seen many apps being developed with "use cliënt" littered all over, and that begs to wonder why do you even want SSR in your app.

You should know that the website localfirstweb.dev shows as blacklisted on avast and avg viruses. It doesn't like a site reference called strut.io. claiming it is a card stealer.

Very cool. Coincidentally I just made a basic calculator with stored variables (https://calc.li/) with this philosophy in mind, though I didn't know there was a bigger movement around the idea! Mostly, I didn't want to bother with a backend or even cookies, so I just store everything in localStorage (which is criminally under-used IMHO).

Love the idea and the community aspect!

The issue with local first web dev in my experience is two fold:

1. It's super hard. The problem of syncing data is super hard to solve and there is little support from modern tooling. Mostly because it differs vastly on how you should handle it from app to app.

2. Very few that live in the west or people who pay for software are offline in longer stretches. There is simply very little to no requests for making apps work offline. I would argue to opposite that it probably is mostly bad business because you will get stuck on technical details due to #1 being so hard to solve. Even people who say they will use the app offline are never offline in my experience (from working on a real app that worked offline).

I work on an app that has clear offline benefits, although, pretty much no one will use it offline in practice and where I live, people have 5G access nowadays even at places that used to be offline, aka trains, tunnels etc. Even so, I plan to make my app offline supported but only after I have success with it.

Hey browser makers, please allow file:// URLS to actually be able to load other files in the same directory without giving a CORS error. You can't even run a JS file from the same directory! That's what's really killing "local first".

A couple podcast episodes featuring the author (mostly regarding his TinyBase project):

- https://www.devtools.fm/episode/67

- https://www.localfirst.fm/12

There really must be something less bloated for local static pages. Embedded SQLite and react just for a few nested table queries? Come on, js has maps and hashtables. React for displaying generated content? My DOM inserter is half a page, and loads instantly

Related idea to local-first: https://stephango.com/file-over-app

I don't understand, offline-capable software is now being pitched as something profound and genius? There was software before the widespread Internet access.

I built and offline friendly app, was not offline first, but it was my first PWA, the idea was that a pilot could have our web page open at high altitudes, potentially with bad service, and they could still interact with anything, once back online, it would push any changes they made. I implemented it with vanilla JS.

The only annoying part was detecting when the browser was back online, I used some hacky solution since there was no native API for it for any browser at the time, but it worked.

> You see, connectivity is generally good on a boat - wifi, cell coverage, and satellite options abound - so we survive. But when it isn’t good, it really isn’t good. And then suddenly, it dawns on you just how much of your life is beholden to the cloud. Your documents don’t load. Your photos don’t sync. Your messages don’t send. Without necessarily consciously realizing it, we have all moved most of our online existence to other people’s computers!

Welcome to the world a huge chunk of the population lives in. It drives me crazy how quick people were to jump onto cloud computing without ever asking the question "how well does it work when my Internet connection sucks?"

Well, it's always amusing how they discover that applications can run locally without depending on someone else's servers and maybe without pulling unverified code from 50 random repos.

Next they'll discover native applications! Innovation!

Maybe after that they'll even discover that you can give a shit about the user's battery/power consumption and ram consumption again!

Seems need pointer and example. What is this mobile at your fingertips tip local but share …

lokijs and nedb were better candidates for local db's but sadly both are unmaintained.

I never made anything fancy, but I never made anything for the web that I can't run locally. If I can't just sync the changed files to the web server and overwrite the DB (which for my use cases takes seconds), I'm not interested. If it needs to be in the domain root, I'm not interested. A bunch of files using relative paths and a config that checks for running on localhost and points to the local DB or the production one, respectively. That's it (okay plus the domain and a few other things so cookies etc. work, but describing it would take longer than making it), that's all I want out of the web kthxbai. I'm basically stuck in 2000 and I love it.