3 ms·
Hearing the name, I first thought this was about reducing complexity and removing unnecessary dependencies on cloud services. But it seems rather about adding y
by xg15 3y ago
Hearing the name, I first thought this was about reducing complexity and removing unnecessary dependencies on cloud services. But it seems rather about adding yet another layer of complexity: You still have to track the state on the server, but now you want to also track it on the client.
- bbor 3y agoI'm curious what kind of app doesn't already require tracking state on the client...? Very confused about your objection, but probably just because of inexperience on my part. It seems to me that basically every web app I can think of (e.g. Facebook, Figma, ChatGPT, Spotify, Discord) revolves around the server and client sharing some responsibility for tracking and updating the state. If your objection is that we should just have state as a DB table on a server and just sync it to the client as needed, then that's basically what this is -- just with a client DB instead of a client Redux store/bespoke javascript mess/etc.
- klabb3 3y agoThere’s a big risk that it moves in that direction, indeed. But that depends on what kind of tech gains traction. Imo, a great local-first app has a rich client and a dumb server that serves simple functions like relaying, backing up and auth. The main challenge is social. Once you have true local first, lots of apps have no plausible excuse to store all your private data in plain text. I can already see the disappointed faces of the VCs and other bean counters when they understand this. But for good or bad, that also means that there will be very little money behind these efforts.