10 ms·

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

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?

raelmiu 2y ago
Love this. What are computers for? Local first could be the file format that allows us to use devices without cloud services. Back to file first, vendors of software apps, pay for software once (or one year of updates or whatever). It's s new horizon.
- rollcat 2y ago
  I would still prefer to have my stuff synced between devices. Files are OK for data that doesn't change much (your music/photo/book library) - Syncthing works great there. CRDTs allow for conflict-free edits where raw files start falling short (calendars, TODOs, etc). I'd love to see something like Syncthing for CRDTs, so that local-first can take the next logical step forward and go cloud-free.
  - WorldMaker 2y ago
    The other day I was riffing on ideas on what if Browsers had a third Storage called `roamingStorage`. Keep it the simple, stupid key/value store interface of localStorage and sessionStorage, but allow it to roam between your devices (like classic Windows %RoamingAppData% on a network/domain configured for it). It doesn't even "need" a full sync engine like CRDTs at the browser level, if it did something as simple and dumb as basic MVCC "last write wins, but you can pull previous versions" you can easily build CRDT library support on top of it. The hardest trick to that would be securing it, in particular how you define an application boundary so that the same application has the same roamingStorage but bad actor applications can't spoof your app and exfiltrate data from it. My riffing hasn't found an easy/simple/dumb solution for that (if you want offline apps you maybe can't just rely on website URL as localStorage mostly does today, and that's maybe before you get into confusion about multiple users in the same browser instance using the app), but I assume it's a solvable problem if there was interest in it at the browser level.
    - satvikpendem 2y ago
      Local first access control via cryptography: https://www.inkandswitch.com/beehive/notebook/ https://www.inkandswitch.com/beehive/notebook/
    - rollcat 2y ago
      Look up CloudKit[1], many of these questions have been answered for Apple-native apps, but perhaps it's not obvious how to translate that to the web-world, or how to keep the object storage decentralised (but self-hosted shouldn't be a problem). I'm also firmly in the native app camp. And again, Apple did this right. The web interface to iCloud works great from both Firefox and Chromium, even on OpenBSD, even with E2EE enabled (you have to authorise the session from an Apple device you own, but that's actually a great way to protect it and I don't mind the extra step). It's probably harder to answer those questions if you can't build the solution around a device with a secure element. But there's a lot of food for thought here. [1]: https://developer.apple.com/documentation/cloudkit/ https://developer.apple.com/documentation/cloudkit/
      - 2y ago
JodieBenitez 2y ago
> shoehorning 40 years of UI development and products into them seems like a mistake. It wouldn't be such a mistake if it was done well. For all the bells and whistles web UIs have, they still lack a lot of what we had on the desktop 30 years ago, like good keyboard shortcuts, support for tab in forms, good mask inputs, and so on.
invalidator 2y ago
> 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. That's basically the JVM, isn't it? It's interesting to think how some of the reasons it sucked for desktop apps (performance, native UI) are also true of Electron. Maybe our expectations are just lower now.
- dmwilcox 2y ago
  I got super interested in Clojure and the java UI frameworks a year ago. But the languages on top of languages scared me. I wanted something simpler, so now I'm writing x86-16 and making bitmapped fonts and things. Probably not a good idea for anyone with a timeline but it's been educational
  - invalidator 2y ago
    > Probably not a good idea for anyone with a timeline It's not completely crazy. Software was developed by much smaller teams and got out the door quickly in that era.

raelmiu 2y ago

Love this. What are computers for? Local first could be the file format that allows us to use devices without cloud services. Back to file first, vendors of software apps, pay for software once (or one year of updates or whatever). It's s new horizon.

rollcat 2y ago
I would still prefer to have my stuff synced between devices. Files are OK for data that doesn't change much (your music/photo/book library) - Syncthing works great there. CRDTs allow for conflict-free edits where raw files start falling short (calendars, TODOs, etc). I'd love to see something like Syncthing for CRDTs, so that local-first can take the next logical step forward and go cloud-free.
- WorldMaker 2y ago
  The other day I was riffing on ideas on what if Browsers had a third Storage called `roamingStorage`. Keep it the simple, stupid key/value store interface of localStorage and sessionStorage, but allow it to roam between your devices (like classic Windows %RoamingAppData% on a network/domain configured for it). It doesn't even "need" a full sync engine like CRDTs at the browser level, if it did something as simple and dumb as basic MVCC "last write wins, but you can pull previous versions" you can easily build CRDT library support on top of it. The hardest trick to that would be securing it, in particular how you define an application boundary so that the same application has the same roamingStorage but bad actor applications can't spoof your app and exfiltrate data from it. My riffing hasn't found an easy/simple/dumb solution for that (if you want offline apps you maybe can't just rely on website URL as localStorage mostly does today, and that's maybe before you get into confusion about multiple users in the same browser instance using the app), but I assume it's a solvable problem if there was interest in it at the browser level.
  - satvikpendem 2y ago
    Local first access control via cryptography: https://www.inkandswitch.com/beehive/notebook/ https://www.inkandswitch.com/beehive/notebook/
  - rollcat 2y ago
    Look up CloudKit[1], many of these questions have been answered for Apple-native apps, but perhaps it's not obvious how to translate that to the web-world, or how to keep the object storage decentralised (but self-hosted shouldn't be a problem). I'm also firmly in the native app camp. And again, Apple did this right. The web interface to iCloud works great from both Firefox and Chromium, even on OpenBSD, even with E2EE enabled (you have to authorise the session from an Apple device you own, but that's actually a great way to protect it and I don't mind the extra step). It's probably harder to answer those questions if you can't build the solution around a device with a secure element. But there's a lot of food for thought here. [1]: https://developer.apple.com/documentation/cloudkit/ https://developer.apple.com/documentation/cloudkit/
    - 2y ago

JodieBenitez 2y ago

> shoehorning 40 years of UI development and products into them seems like a mistake. It wouldn't be such a mistake if it was done well. For all the bells and whistles web UIs have, they still lack a lot of what we had on the desktop 30 years ago, like good keyboard shortcuts, support for tab in forms, good mask inputs, and so on.

invalidator 2y ago

> 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. That's basically the JVM, isn't it? It's interesting to think how some of the reasons it sucked for desktop apps (performance, native UI) are also true of Electron. Maybe our expectations are just lower now.

dmwilcox 2y ago
I got super interested in Clojure and the java UI frameworks a year ago. But the languages on top of languages scared me. I wanted something simpler, so now I'm writing x86-16 and making bitmapped fonts and things. Probably not a good idea for anyone with a timeline but it's been educational
- invalidator 2y ago
  > Probably not a good idea for anyone with a timeline It's not completely crazy. Software was developed by much smaller teams and got out the door quickly in that era.