Local-First Web Development(localfirstweb.dev)
localfirstweb.dev
Local-First Web Development
https://localfirstweb.dev
177 comments
> ramp .. into full SaaS
I think the local first ideology can enable an alternative way to sell B2B, from the bottom up.
Sell to the users directly, at a cheap price and prevent the issues that stems from enterprise sales. This usually only works for small to medium sized businesses, and very rarely large businesses. However, due to the cheap price, the budget for this software that runs locally could be kept on the discretionary account of even large-ish businesses.
Then, if the quality and value of the software is demonstrated, it should grow organically as users recommend it to other people around them.
Over time, the need for enterprise features would arise - such as Single Sign On, and directory integration, sharing of data, etc. Up the charge for these to make up for the loss of revenue early on from early cheap sales.
I think the local first ideology can enable an alternative way to sell B2B, from the bottom up.
Sell to the users directly, at a cheap price and prevent the issues that stems from enterprise sales. This usually only works for small to medium sized businesses, and very rarely large businesses. However, due to the cheap price, the budget for this software that runs locally could be kept on the discretionary account of even large-ish businesses.
Then, if the quality and value of the software is demonstrated, it should grow organically as users recommend it to other people around them.
Over time, the need for enterprise features would arise - such as Single Sign On, and directory integration, sharing of data, etc. Up the charge for these to make up for the loss of revenue early on from early cheap sales.
This isn't a particularly new idea - and it does work! Github, Basecamp, Slack, Qualtrics, Notion, Monday, JIRA, and others all followed this approach. Local-first might reduce the startup costs somewhat, though.
> nasty cross-platform tradeoffs
You mean like web apps partially or completing ignoring platform-specific appearances, conventions, or behaviors?
Let’s not pretend that native apps are the only ones that struggle to work correctly cross-platform. While core logic may be portable in web app, frequently web UIs are happy to make a one-size-fits-all interface. While that may be acceptable in a web page, it is neglectful and insulting in a web app that wants to be treated as a peer of native apps.
You mean like web apps partially or completing ignoring platform-specific appearances, conventions, or behaviors?
Let’s not pretend that native apps are the only ones that struggle to work correctly cross-platform. While core logic may be portable in web app, frequently web UIs are happy to make a one-size-fits-all interface. While that may be acceptable in a web page, it is neglectful and insulting in a web app that wants to be treated as a peer of native apps.
Not sure where I implied that web magically solves all cross-platform problems. In fact I went out of my way to underline the gaps using phrases like "worse is better" and "accepting that reality".
So while I was never opposed to your sentiment, I find this to be a strange statement:
> While that may be acceptable in a web page, it is neglectful and insulting in a web app that wants to be treated as a peer of native apps.
This frames native apps as a gold standard, which obviously is a bar that web apps can never reach. There are foundational tradeoffs here that can never be worked around. You might as well demand that all native platforms implement a common API to ease cross platform development.
The reality is that supporting multiple platforms with their native conventions and idioms is a very large undertaking that fewer and fewer developers are willing to do. You can choose to label that neglectful and insulting, but I doubt it will overcome the incentives and market forces that are inexorably pushing in a different direction. I too lament the loss of a rich native app ecosystem. But on the other hand, I'm pretty thankful the web disrupted Microsoft just as their consolidation of desktop computing was nearly complete. You win some, you lose some, but if you want to shape the future, you must clear-eyed and forward-looking.
So while I was never opposed to your sentiment, I find this to be a strange statement:
> While that may be acceptable in a web page, it is neglectful and insulting in a web app that wants to be treated as a peer of native apps.
This frames native apps as a gold standard, which obviously is a bar that web apps can never reach. There are foundational tradeoffs here that can never be worked around. You might as well demand that all native platforms implement a common API to ease cross platform development.
The reality is that supporting multiple platforms with their native conventions and idioms is a very large undertaking that fewer and fewer developers are willing to do. You can choose to label that neglectful and insulting, but I doubt it will overcome the incentives and market forces that are inexorably pushing in a different direction. I too lament the loss of a rich native app ecosystem. But on the other hand, I'm pretty thankful the web disrupted Microsoft just as their consolidation of desktop computing was nearly complete. You win some, you lose some, but if you want to shape the future, you must clear-eyed and forward-looking.
>You can choose to label that neglectful and insulting, but I doubt it will overcome the incentives and market forces that are inexorably pushing in a different direction.
I don't think it's just about incentives and market forces. There is an inevitable trade-off between implementing the features that people want and working on ever deeper platform integration. This trade-off exists and will always exist irrespective of financial considerations.
Some people (not you) make it sound as if putting more work into platform integration is somehow a more noble goal than building other features, and if it wasn't for those greedy, cost cutting capitalists the natural steady state of all software would be some sort of "native" ideal.
I disagree with that. As a user I don't want developers to put time into every single thing that platform providers invent in order to make their own platform more unique, however useless or even detrimental that differentiation may be for me. Platform providers don't want to be replaceable pipes because that would hurt their margins.
In many cases one size really does fit all my needs when it comes to infrastructure. In a minority of cases I do need really deep platform integration. Both goals have their legitimate place in software engineering even before considering any profit motives and financial constraints.
I don't think it's just about incentives and market forces. There is an inevitable trade-off between implementing the features that people want and working on ever deeper platform integration. This trade-off exists and will always exist irrespective of financial considerations.
Some people (not you) make it sound as if putting more work into platform integration is somehow a more noble goal than building other features, and if it wasn't for those greedy, cost cutting capitalists the natural steady state of all software would be some sort of "native" ideal.
I disagree with that. As a user I don't want developers to put time into every single thing that platform providers invent in order to make their own platform more unique, however useless or even detrimental that differentiation may be for me. Platform providers don't want to be replaceable pipes because that would hurt their margins.
In many cases one size really does fit all my needs when it comes to infrastructure. In a minority of cases I do need really deep platform integration. Both goals have their legitimate place in software engineering even before considering any profit motives and financial constraints.
Great point, and well stated.
In many ways the web is the last great open-protocol success, and the only one I can think of push its way all the way up the presentation layer. Kind of miraculous when you think about it.
In many ways the web is the last great open-protocol success, and the only one I can think of push its way all the way up the presentation layer. Kind of miraculous when you think about it.
Why should the SDK be install-less? IMHO it's enough if the app makes it into the Windows store, Apple store and any Linux format.
I've been really happy with CouchDB + PouchDB at https://financier.io
You can do unique things like offer a trial period without syncing (database wholly in browser), which allows for ridiculously quick onboarding. And then when the user signs up for a paid plan, you just hook up CouchDB and the data syncs right on over.
The sync mechanism works so damn well. It's really cool how easy it is to implement a Google Docs-like sync mechanism with conflict resolution baked in.
You can do unique things like offer a trial period without syncing (database wholly in browser), which allows for ridiculously quick onboarding. And then when the user signs up for a paid plan, you just hook up CouchDB and the data syncs right on over.
The sync mechanism works so damn well. It's really cool how easy it is to implement a Google Docs-like sync mechanism with conflict resolution baked in.
It works so damn well until it finds itself in a Firefox private window :)
PouchDB does have rather expensive adapters that use memory or LocalStorage. Almost twice the size as the base package (minified).
PouchDB does have rather expensive adapters that use memory or LocalStorage. Almost twice the size as the base package (minified).
I used the stack on a side project. Wrote an adapter for websocket sync and a wrapper for Vue that allowed streaming queries.
I really liked it, but the typical pattern of one-db-per-user with internal replication on the server was a bit difficult plan/orchestrate for shared data. I'm patiently waiting for the couchdb PR for document level access control.
These days I use supabase with row level security and a Vue-wrapper that can cache queries locally and update the result as the network request finishes. Works as good as pouch + couch (but naturally comes up short for queries that rely on Date.now())
I really liked it, but the typical pattern of one-db-per-user with internal replication on the server was a bit difficult plan/orchestrate for shared data. I'm patiently waiting for the couchdb PR for document level access control.
These days I use supabase with row level security and a Vue-wrapper that can cache queries locally and update the result as the network request finishes. Works as good as pouch + couch (but naturally comes up short for queries that rely on Date.now())
I also love CouchDB/PouchDB, but it’s quite clunky to configure the security settings on a per user basis, and many times I want to additionally transform the data before bringing it to the client. I also don’t like to be locked into directly blasting a database with requests (sometimes it’s better to use caching). So for those reasons I keep it behind an API layer.
I use this model as well. It is a hidden gem for quickly building an awesome local first web app.
I'm really surprised more companies don't pick this stack.
I'm really surprised more companies don't pick this stack.
Isn't the direction we're taking with networking and connectivity kind of making this irrelevant? I always feel like local-first is a good idea but I am actually never without internet connection, and building a truly local-first anything is significantly more complicated than the alternative of "always online" for most domains, even if you use various helper libs. A lot of the pages talk about privacy reasons as well, but I don't get that either, if you want privacy then you want encryption, not local-first development.
Finally, in the end what you want to do with your work is to share it, meaning that "doing" your work is for a large part "sharing" your work, which is fundamentally not local-first.
Maybe I am the odd one out here.
Finally, in the end what you want to do with your work is to share it, meaning that "doing" your work is for a large part "sharing" your work, which is fundamentally not local-first.
Maybe I am the odd one out here.
It is not about being offline. It is more about running queries locally which makes them fast enough that you do not even need a loading spinner [1].
Imagine your whatsapp client would have to do a http request on each UI interaction.
[1] https://rxdb.info/offline-first.html
[1] https://rxdb.info/offline-first.html
The thing I'm missing in this discussion is that there's very few people out there making whatsapp or figma. The vast majority of software development is perfectly served by submitting forms, as mind-numbingly boring as that sounds I think its true.
I feel like the primary challenge of the field of software development is actually to guard simplicity. Local-first becoming a standard is not unlike SPA becoming the standard: it hurts simplicity and digs the hole we are in deeper still.
To help with this, I think any new technology proposed should advertise when it should NOT be used. In this case, I think, this disclaimer should probably say: "most of the time, for most applications, this should not be used".
I feel like the primary challenge of the field of software development is actually to guard simplicity. Local-first becoming a standard is not unlike SPA becoming the standard: it hurts simplicity and digs the hole we are in deeper still.
To help with this, I think any new technology proposed should advertise when it should NOT be used. In this case, I think, this disclaimer should probably say: "most of the time, for most applications, this should not be used".
That sounds exactly like offline capabilities?
Think about longevity. Whether I'm writing, drawing, making music, or anything else important to my life, will I still be able to view/edit that data in 20 years? Granted, even with offline-friendly software I may need to port it to new platforms and make sure I back up the data, but at least I have a chance. The data I still have from 20 years ago is far more precious to me than I thought it would be back then. Data that can only be accessed through an external party is ephemeral and it will inevitably disappear one day.
You are right to talk about the data first and foremost. 20 year old software is very rarely useful (yes there are exceptions) but the data is often just as valuable as before or even more so.
That is why I much prefer a web app that lets me download my data in an open and well documented format to a desktop app that locks my data into some obscure proprietary format or even into a particular device.
That is why I much prefer a web app that lets me download my data in an open and well documented format to a desktop app that locks my data into some obscure proprietary format or even into a particular device.
[deleted]
> I am actually never without internet connection
You are part of a very small minority. The fact is, the majority of the world can't always be online, and so can't be properly served by always-online applications.
You are part of a very small minority. The fact is, the majority of the world can't always be online, and so can't be properly served by always-online applications.
For me, getting on a train in the UK is enough to break almost every app. I’m “technically” connected but signal can be spotty at times, with massive latency spikes and packet drops, and any kind of interaction that depends on the network will stall, which is incredibly frustrating.
Every time I’m in that situation (or get on a plane), I’m reminded of the value of local-first software.
Every time I’m in that situation (or get on a plane), I’m reminded of the value of local-first software.
Similar experience in Germany – even inside metropolitan areas inhabited by millions.
Saying that offline, local-first apps aren't relevant because "almost everyone is always online" rings similar to saying accessibility isn't relevant because almost everyone can use their eyes.
As for sharing, that's very much application dependent: personal data could benefit from being shared across a user's device, but not with third parties.
As for sharing, that's very much application dependent: personal data could benefit from being shared across a user's device, but not with third parties.
> Saying that offline, local-first apps aren't relevant because "almost everyone is always online" rings similar to saying accessibility isn't relevant because almost everyone can use their eyes.
It’s true, and that “almost” is smaller than you think! There’s a concept called temporary disability which shifts the meaning of “disability” from “some permanent crippling condition” to “unable to do X thing in a given moment”.[1]
For example, one place I regularly go without reliable Internet is… the subway! There’s no signal between stations, so if I need access to something I have to make sure it’s downloaded first.
My grocery store also has a basement with no cell reception. Imagine if the notes app with my grocery list required an Internet connection!
[1] https://mas.to/@carnage4life/109840772570956275
It’s true, and that “almost” is smaller than you think! There’s a concept called temporary disability which shifts the meaning of “disability” from “some permanent crippling condition” to “unable to do X thing in a given moment”.[1]
For example, one place I regularly go without reliable Internet is… the subway! There’s no signal between stations, so if I need access to something I have to make sure it’s downloaded first.
My grocery store also has a basement with no cell reception. Imagine if the notes app with my grocery list required an Internet connection!
[1] https://mas.to/@carnage4life/109840772570956275
Local-first goes beyond privacy and offline, but nevertheless I think it serves those goals better in fairly obvious ways.
I'm a programmer and artist that works with various non local-first tools (ranging from project management/task collaboration, diagramming, programming--iterating and generating code, etc) and the thing I want more than anything is the fast, tightly integrated experience you get from desktop apps. (The web tech stack is all oriented around consumer-first and not producer-first.)
We need a streamlined tech stack for desktop-first applications. Which probably involves a p2p (*ish) connection and sharing mechanism (nostr looks interesting for this), CRDTs or other patterns, and -- why is this so friggin hard -- tools, frameworks and libraries for cross-platform desktop apps (and don't say you can't retain OS-specific touchpoints when doing this).
I'm a programmer and artist that works with various non local-first tools (ranging from project management/task collaboration, diagramming, programming--iterating and generating code, etc) and the thing I want more than anything is the fast, tightly integrated experience you get from desktop apps. (The web tech stack is all oriented around consumer-first and not producer-first.)
We need a streamlined tech stack for desktop-first applications. Which probably involves a p2p (*ish) connection and sharing mechanism (nostr looks interesting for this), CRDTs or other patterns, and -- why is this so friggin hard -- tools, frameworks and libraries for cross-platform desktop apps (and don't say you can't retain OS-specific touchpoints when doing this).
Why would you need CRDT for this traditional OT, this always turns into some weird political debate about decentralisations.
The complexity has not necessarily something to do with consensus algo, where CRDT are not best in class, but what if your creative app is using some compute shader for some visual effect? This is not possible without WebGPU, and then still someone has to do the work of porting all of this.
The complexity has not necessarily something to do with consensus algo, where CRDT are not best in class, but what if your creative app is using some compute shader for some visual effect? This is not possible without WebGPU, and then still someone has to do the work of porting all of this.
Why is not wanting every action one takes on the web getting collected, analyzed and sold considered a "weird political debate"?
100% agree. I want a web where using web apps is private by default. Been working on an attempt to move towards this: https://peergos.org/posts/a-better-web
What kind of tight integrated experience are you imagining? Is it integration with 3rd party API services? Or with other desktop apps on the same local computer? Or something else?
>building a truly local-first anything is significantly more complicated than the alternative of "always online"
Wow. That is so incredibly wrong. People have been building local-first software twice as long as the internet has even been publicly accessible at all.
The tools to build local native apps, the UI for them, and the libraries that they can use, are all still decades ahead of the web-first tools.
I say this as someone who has spent the last 15 years building web apps. We haven't even reached parity with 1995-era desktop apps yet. We're only barely beginning to approach that level of usability and functionality now. And with radically more complexity to do so. (And worse performance.)
Building native desktop software without having any dependence on being online all the time and dependence on having high bandwidth and dependence on a good signal is worlds simpler than developing software that depends on all that extra stuff. All that stuff that is out of your control.
Wow. That is so incredibly wrong. People have been building local-first software twice as long as the internet has even been publicly accessible at all.
The tools to build local native apps, the UI for them, and the libraries that they can use, are all still decades ahead of the web-first tools.
I say this as someone who has spent the last 15 years building web apps. We haven't even reached parity with 1995-era desktop apps yet. We're only barely beginning to approach that level of usability and functionality now. And with radically more complexity to do so. (And worse performance.)
Building native desktop software without having any dependence on being online all the time and dependence on having high bandwidth and dependence on a good signal is worlds simpler than developing software that depends on all that extra stuff. All that stuff that is out of your control.
It is more complicated. If you can accept an always online / always connected model then you can guarantee more things because there is only one source of truth (the server). The reason to care about local first is that even today, it’s hard to guarantee a server will always be connected and that model has some privacy and scalability challenges.
I'm without internet connection multiple times a week on average because mobile networks are far from flawless (I live in that very rural place where you'd expect to not have regular connectivity called London). I don't necessarily care so much about "true" local first as 1) something where at least some care has been taken to ensure it can keep working while offline, 2) with respect to privacy, I halfway agree with you, but bigger than privacy to me is portability, for example if it turns out I can't trust the current provider. But defaulting to not shipping my data to a server somewhere is a good way of increasing trust. That said, I want encryption too.
With waves of climate change disasters sweeping at an increasing rate across the world, and resulting wars being almost inevitable in the next few decades, you are unlikely to have always-on internet for the entirety of your life. My region (first world, in a wealthy nation) has had its infrastructure (roads and comms alike) largely destroyed twice in the last year or so. As we're rich, it gets built back, but that takes time. I've been stung enough from weeks'-long outages and periods of isolation to never again completely rely on an internet connection. I do use software that requires a connection, but not for anything critical.
> building a truly local-first anything is significantly more complicated than the alternative of "always online" for most domains
It is more complicated. It works best when the user has a distinct data bucket that is exclusively theirs. A note taking app. Personal finance. But they may have multiple devices so syncing is desirable.
This use case is reasonably common and turns out to be relatively simple to do.
If you have shared data between users. If you have a significant amount of data that just requires being online to interact with the system. Then it has pretty minimal benefits over just centralizing the data and it should be avoided to minimize complexity.
It is more complicated. It works best when the user has a distinct data bucket that is exclusively theirs. A note taking app. Personal finance. But they may have multiple devices so syncing is desirable.
This use case is reasonably common and turns out to be relatively simple to do.
If you have shared data between users. If you have a significant amount of data that just requires being online to interact with the system. Then it has pretty minimal benefits over just centralizing the data and it should be avoided to minimize complexity.
>But they may have multiple devices so syncing is desirable.
USB cables or thumbdrives make that a snap, and you don't have to rely on some flaky third-party system or a network connection. It's all 100% under your control 100% of the time.
Really, social interactive shared things are the only things where it ever makes sense to be online-first. For everything else, native is way better in every possible way. Speed, security, ability to still access it in the future, etc.
It's good to have online backups in case your house burns down. But that's still second-tier to having local backups.
USB cables or thumbdrives make that a snap, and you don't have to rely on some flaky third-party system or a network connection. It's all 100% under your control 100% of the time.
Really, social interactive shared things are the only things where it ever makes sense to be online-first. For everything else, native is way better in every possible way. Speed, security, ability to still access it in the future, etc.
It's good to have online backups in case your house burns down. But that's still second-tier to having local backups.
I would hate and never use an utility app that requires me to constantly physically connect my devices in order to keep data in sync.
I agree with this sentiment. Our networks are only getting faster.
Keeping 100% of the application state in exactly one place can eliminate entire universes of problems.
If you are building an app that doesn't actually need to talk to outside things, then sure. Go 100% client-side.
The dragon is having 1 foot in each swimming pool. 50/50 state spread evenly across client & server.
Keeping 100% of the application state in exactly one place can eliminate entire universes of problems.
If you are building an app that doesn't actually need to talk to outside things, then sure. Go 100% client-side.
The dragon is having 1 foot in each swimming pool. 50/50 state spread evenly across client & server.
It does, but I think we no longer live in that kind of environment. Distributed is the norm, and trying to shoehorn it into a mental model where everything is all in the same place adds a kind of accidental complexity to our underlying stack for simplicity at the very top.
As an aside, with the future as a (potential) interplanetary species, networks can't beat the speed of light, so we'll have to figure this out then!
As an aside, with the future as a (potential) interplanetary species, networks can't beat the speed of light, so we'll have to figure this out then!
How about having the state 100% on server AND on client? No dragons, no problems.
Keeping them in sync is the dragon
How do you prevent sync issues?
One local DB/store for each app. Who is the correct sync?
Or is it first in first out?
One local DB/store for each app. Who is the correct sync?
Or is it first in first out?
CRDTs is how sync issues become non-issues. The “correct sync” is deterministically determined by the CRDT conflict resolution algorithm. There can be multiple DBs/stores per app or per user or per whatever makes sense. One big global DB/store broken down to millions of DBs/stores.
CRDT is the dragon slayer
It's the sword that we needed! But it doesn't take us all the way. There are semantic conflicts that are difficult for CRDTs to solve alone.
What are the semantic conflicts you mean here?
As far as I can tell, CRDTs are the correct solution for syncing state between parties.
As far as I can tell, CRDTs are the correct solution for syncing state between parties.
Merge conflicts that must be resolved by the user (i.e. when there is no logical way to determine the priority of two offline changes) are still an application specific problem, even with CRDTs. You can build structures that allow storing conflict resolutions in CRDTs, but getting them right is still like half the problem to solve.
I have lack of imagination to think what kind of conflicts those would be, would you have examples?
In my experience there’s always a logical way to solve conflicts. And CRDTs can have any kind of conflict resolution algorithm, so it’s customizable per application. “Storing conflict resolutions”, eg. “a merge operation”, is not needed and unnecessarily complicates any CRDT.
In my experience there’s always a logical way to solve conflicts. And CRDTs can have any kind of conflict resolution algorithm, so it’s customizable per application. “Storing conflict resolutions”, eg. “a merge operation”, is not needed and unnecessarily complicates any CRDT.
Yes, sometimes it is hard to come up with the merge strategy that preserves user intent. I think the big one is rich text, where Peritext[0] looks like a good direction.
[0]: https://www.inkandswitch.com/peritext/
[0]: https://www.inkandswitch.com/peritext/
This is the correct answer :)
Then you get to deal with conflict resolution, which is a rare dragon that is kind of confusing and sometimes has to ask the user which state they'd like to keep.
Been involved in projects like software adoption in remote aid posts in Papua New Guinea that don't even have roads, and Agtech apps in deep rural Australia.
Even with Starlink there will still be places that stuff needs to work offline.
Even with Starlink there will still be places that stuff needs to work offline.
It’s not only about being able to operate disconnected for long periods it’s also about handling network partitions and being able to achieve consensus without a single source node.
If you travel, you'll constantly experience no or degraded internet access. Airports, trains, hotel Wi-Fi, rural areas, etc.
It heavily influenced how I work and which tools I use.
It heavily influenced how I work and which tools I use.
Many people are not online all the time.
Many people don’t want to share all of their data and would like to keep some local.
Many people don’t want to share all of their data and would like to keep some local.
There’s way too many options on this site. It’s intimidating! How should I know which DB to use? I just wanna build stuff.
For local-first to succeed as a concept, it would gain a lot from having a Rails equivalent that people can get started on. If that exists, promote just that and hide all the other options.
For local-first to succeed as a concept, it would gain a lot from having a Rails equivalent that people can get started on. If that exists, promote just that and hide all the other options.
There’s way too many options on this site. It’s intimidating! How should I know which DB to use? I just wanna build stuff.
Multi-master systems - which you have if the same data is being written to by multiple devices - are complicated, and there's no one size fits all solution. The different approaches all have different trade offs.
A good place to start might be "what do I think should happen when two bits of data that were updated independently are merged?".
Multi-master systems - which you have if the same data is being written to by multiple devices - are complicated, and there's no one size fits all solution. The different approaches all have different trade offs.
A good place to start might be "what do I think should happen when two bits of data that were updated independently are merged?".
I get your argument, cargo really gave Rust a leg up.
Unfortunately we are far from having a go to platform. The community page's primary objective is to get the word out and connect local first builders.
Unfortunately we are far from having a go to platform. The community page's primary objective is to get the word out and connect local first builders.
They said Rails, not Rust. Like Django for Python.
I guess the answer is that JS/TS has never had a stack comparable to those py/rb behemoths.
I guess the answer is that JS/TS has never had a stack comparable to those py/rb behemoths.
why doesn't rails have a local-first equivalent? it's something i'd love to see, as many apps can benefit.
back in the day, we built a real-time sports stats app on top of rails and firebase (before it was gobbled up by google) that provided some affordances in that regard, but truly offline first--saving locally, then syncing when online--would be a great rails use case.
back in the day, we built a real-time sports stats app on top of rails and firebase (before it was gobbled up by google) that provided some affordances in that regard, but truly offline first--saving locally, then syncing when online--would be a great rails use case.
I'm surprised they list PouchDB but not CouchDB for local first software.
PouchDB is fine for trivial local first apps, but not for anything that's critical.
CouchDB, on the other hand, is a very robust app that can be used by multiple local-first apps and those apps can access and share that data, and back it up on a separate local and/or remote CouchDB.
PouchDB and CouchDB used together are a pretty sweet and solid platform to build a Cloud and/or local first on app on.
PouchDB is fine for trivial local first apps, but not for anything that's critical.
CouchDB, on the other hand, is a very robust app that can be used by multiple local-first apps and those apps can access and share that data, and back it up on a separate local and/or remote CouchDB.
PouchDB and CouchDB used together are a pretty sweet and solid platform to build a Cloud and/or local first on app on.
probably because you can't run CouchDB on the browser. You do need it as something for PouchDB to talk to, however.
[deleted]
Okay two things.
1) I gave a talk about doing local-first web development that web developers should watch or read at least: https://qbix.com/blog/2020/01/02/the-case-for-building-clien...
2) I recently learned about AbsurdSQL! It's absurdly amazing for this! https://hackaday.com/2021/08/24/sqlite-on-the-web-absurd-sql...
1) I gave a talk about doing local-first web development that web developers should watch or read at least: https://qbix.com/blog/2020/01/02/the-case-for-building-clien...
2) I recently learned about AbsurdSQL! It's absurdly amazing for this! https://hackaday.com/2021/08/24/sqlite-on-the-web-absurd-sql...
Would love to have you share your learnings with the community.
This is the first time I'm hearing about QBIX. Feel free to send a PR with a short description to be considered for the page.
This is the first time I'm hearing about QBIX. Feel free to send a PR with a short description to be considered for the page.
Sure, would be very happy to. Send it where?
I am going to message you on Keybase.
What is interesting is that local first applications were the Microsoft vision in the 1990s with a Windows computer acting as your home hub and syncing over the internet.
The Sun and later Google vision is the network is the computer. For better or worse, the Sun/Google vision is ascendent now.
The Sun and later Google vision is the network is the computer. For better or worse, the Sun/Google vision is ascendent now.
But will there be a local-first Renaissance with desktop apps returning to focus? (Not sure - unlikely? - but, man, as a creative, I really hope so.)
Building desktop apps remains a chore. A lot of crossplatform frameworks are promising (Electron, Flutter, etc) but ask any developer building series enterprise applications in those tools how fun it is and they will tell you it is not encouraging.
What are the main challenges when building cross platform desktop apps today?
Constant ecosystem changes make it difficult to maintain strict low-level and high-level API boundaries and drivers across platforms. To get non-trivial projects done with high quality you need very experienced engineers who are comfortable dropping into low-level code as well as fork or build in-house versions of common libraries and tools that don't quite get the job done for your use-case.
Also there's a lot of hobby projects that are great and push boundaries but they're also often the only option for a given toolchain/language/framework. So its a very frustrating exercise to invest in a tool only to realize its half-baked (which is fair for a hobby project!) and you need to reverse course and rebuild or extend it yourself - even for simple things.
Also there's a lot of hobby projects that are great and push boundaries but they're also often the only option for a given toolchain/language/framework. So its a very frustrating exercise to invest in a tool only to realize its half-baked (which is fair for a hobby project!) and you need to reverse course and rebuild or extend it yourself - even for simple things.
How come? I don’t understand how the creative part figures into a desktop app focus?
I’m guessing it’s because you like the responsiveness of desktop apps for tools in the creative space like photoshop? Or is it something else?
I’m guessing it’s because you like the responsiveness of desktop apps for tools in the creative space like photoshop? Or is it something else?
Great list!
Has anyone tried ElectricSQL? Looks amazing.
The ability to effectively use multi-tenant SQLite but aggregate shared data into a postgres database is amazing. And they help you with migrations etc. This is exactly the ideal setup I've been looking for!
Has anyone tried ElectricSQL? Looks amazing.
The ability to effectively use multi-tenant SQLite but aggregate shared data into a postgres database is amazing. And they help you with migrations etc. This is exactly the ideal setup I've been looking for!
Wow, and I’m here and thinking who needs this, what problems are solved here by adding that complexity and don’t see any real benefit from the producer side perspective and that’s where the costs are.
Using a multi-tenant SQLite setup helps ensure user data is separated into their own databases and won't be inadvertently queried by other users. Users can then choose to share the data they want to either via peer-to-peer or by aggregating to a postgres database.
But the main benefit to me would be that user data will be more private and protected and configurable.
This gives someone much more fine-grained control over their data and how their data is stored. I think it ultimately makes the attack vector space smaller for any client data.
But the main benefit to me would be that user data will be more private and protected and configurable.
This gives someone much more fine-grained control over their data and how their data is stored. I think it ultimately makes the attack vector space smaller for any client data.
Me as a service provider I would just want to keep the data seperated at my backend. I guess Ill need it anyways for some usecases. And after that why should I bother adding complexity to ship that data to the client side?
Right, but then you’re not building a local-first app. of course the tools that are useful for building a local-first app won’t be that relevant to you if that’s not what you’re doing!
[deleted]
I built a thing called webspaces for 3D html worlds based on these principles.
https://gfodor.medium.com/rebooting-the-web-in-3d-with-websp...
https://gfodor.medium.com/rebooting-the-web-in-3d-with-websp...
Yonz here, one of the people helping connect local-first builders on https://lfw.dev/
Lots of comments here, and r/programming are missing the point of local-first. Without local-first, there is no reasonable way to fix the fragmented and siloed nature of data in today's products. Local-first systems rely on data living in user space (vs. product silo), creating an avenue for reusable, portable, and composable data.
Let's take movie streaming to break this down.
1. Composability: Our viewing history is siloed in Netflix, Disney, Apple TV, and Prime Video. You could access better recommendations if these platforms merged your viewing history.
2. Re-usability: Say you signup for Hulu. Since the collaborative filtering model doesn't have any information on you, it takes a while for you to get good recommendations. Even worse still, this prevents new startups from being able to compete.
3. Portability: Web2 companies have almost perfected lock-in models, and this is primarily because you can't move your data. Most people learned the hard way trying to mastodon.
/> Local-first at a high level tackles these by moving data storage to user space (not offline but local-first). Yielding newfound capabilities for:
- ML trained on all your movie-watching history
- Single source of truth for your relationships as opposed to your connections on Twitter, LinkedIn, Instagram, etc., and their specific handles. If you want to partition by platform, you can still do it.
- User-owned private keys and historical data create exciting opportunities to skip signups and re-use historical data with new applications.
- Death to spinners!
Quick responses to some of the common themes,
- Conflict-free sync is hard, but it is not complexity for the sake of complexity; with in-device/p2p conflict resolution, you can finally have a world free of spinners.
- This is not native app development where your app state is a warm cache for BE source of truth.
- Yes, it creates a world where you can use apps offline, which is always a good thing.
- No, its not a service or a stack. It is more of an ideology and can't guarantee people won't abuse it.
Lots of comments here, and r/programming are missing the point of local-first. Without local-first, there is no reasonable way to fix the fragmented and siloed nature of data in today's products. Local-first systems rely on data living in user space (vs. product silo), creating an avenue for reusable, portable, and composable data.
Let's take movie streaming to break this down.
1. Composability: Our viewing history is siloed in Netflix, Disney, Apple TV, and Prime Video. You could access better recommendations if these platforms merged your viewing history.
2. Re-usability: Say you signup for Hulu. Since the collaborative filtering model doesn't have any information on you, it takes a while for you to get good recommendations. Even worse still, this prevents new startups from being able to compete.
3. Portability: Web2 companies have almost perfected lock-in models, and this is primarily because you can't move your data. Most people learned the hard way trying to mastodon.
/> Local-first at a high level tackles these by moving data storage to user space (not offline but local-first). Yielding newfound capabilities for:
- ML trained on all your movie-watching history
- Single source of truth for your relationships as opposed to your connections on Twitter, LinkedIn, Instagram, etc., and their specific handles. If you want to partition by platform, you can still do it.
- User-owned private keys and historical data create exciting opportunities to skip signups and re-use historical data with new applications.
- Death to spinners!
Quick responses to some of the common themes,
- Conflict-free sync is hard, but it is not complexity for the sake of complexity; with in-device/p2p conflict resolution, you can finally have a world free of spinners.
- This is not native app development where your app state is a warm cache for BE source of truth.
- Yes, it creates a world where you can use apps offline, which is always a good thing.
- No, its not a service or a stack. It is more of an ideology and can't guarantee people won't abuse it.
The “examples” section just has a framework, a tutorial and a demo app. What are some actual examples of this in the wild?
One of the authors here. Just catching up on the awesome feedback in this thread - thanks!
I just thought this was a fun list of links to put together (like it's 1994!) and TBH I was not expecting quite this degree of positive reception.
Happy to answer any questions!
I just thought this was a fun list of links to put together (like it's 1994!) and TBH I was not expecting quite this degree of positive reception.
Happy to answer any questions!
Question 1: Could you summarize or maybe add a page about it? There's just two lines of text and then a bunch of links. I really can't tell what you're getting at.
The obvious answer to all the questions would be to just create normal software and people can upload/share their files if they want to. That's pretty much how all software works except for SAAS web stuff. I assume you're getting at something different, but it isn't at all clear what it is.
Local/native software has been around for many decades. Long before web software; long before the web itself even existed. What is different about this idea?
Is it some way to make web UIs actually as functional as native applications? Some format to make data from web apps as usable as data from normal applications?
The obvious answer to all the questions would be to just create normal software and people can upload/share their files if they want to. That's pretty much how all software works except for SAAS web stuff. I assume you're getting at something different, but it isn't at all clear what it is.
Local/native software has been around for many decades. Long before web software; long before the web itself even existed. What is different about this idea?
Is it some way to make web UIs actually as functional as native applications? Some format to make data from web apps as usable as data from normal applications?
Thanks! Yep, I think we need an about page, and maybe a few pull quotes from the articles. The first article from Ink & Switch is the canonical source of the name and the idea.
I think a lot of web consumer products (and dare I say SaaS too) are these days _not_ on your own computer like they were in the 90's or early 2000s. This isn't a call to return to those days, but it is a reminder that there have been trade offs in moving our productive lives entirely to other people's computers - both in terms of technical performance, but also conceptual ownership and the like. Can we rebalance a little?
So yes, the idea is exactly _not_ new. But a lot of products are built today without considering this tried-and-tested architecture as an option. This site & list of tools is just a friendly reminder that yes, there is another way.
I think a lot of web consumer products (and dare I say SaaS too) are these days _not_ on your own computer like they were in the 90's or early 2000s. This isn't a call to return to those days, but it is a reminder that there have been trade offs in moving our productive lives entirely to other people's computers - both in terms of technical performance, but also conceptual ownership and the like. Can we rebalance a little?
So yes, the idea is exactly _not_ new. But a lot of products are built today without considering this tried-and-tested architecture as an option. This site & list of tools is just a friendly reminder that yes, there is another way.
It feels like the web becomes exciting again. A bit confusing with all the orthogonal directions but very much alive and promising
Amazing to see this community coming together. We are having the first #LFW meetup @ 4PM ET Feb 28,2023 on our discord stage. Come join us https://lfw.dev/ (https://localfirstweb.dev)
We have an amazing lineup prepared for you, including @pvh you can find the details here: https://twitter.com/founderYonz/status/1628846898898501632?t...
We have an amazing lineup prepared for you, including @pvh you can find the details here: https://twitter.com/founderYonz/status/1628846898898501632?t...
I am learning MobX State tree, and using the references to objects in a tree, with normalisation (ensuring you don't have duplicates in the tree, etc). It's impossible not to think that state management is getting closer and closer to client databases for more complex apps.
I'm really hoping WebAssembly will finally bridge the backend and the frontend data structures seamlessly, because right now we are getting to the point of keeping 2 separate data schemas, which is a huge waste of effort.
I'm really hoping WebAssembly will finally bridge the backend and the frontend data structures seamlessly, because right now we are getting to the point of keeping 2 separate data schemas, which is a huge waste of effort.
Being able to have storage and network transparent business logic is something that I get really excited about. In my mind I want a GraphQL interface (ORMis) for a database that acts like a wire protocol.
These two links have the same zip code: https://www.sqlite.org/np1queryprob.html https://engineering.fb.com/2020/03/02/data-infrastructure/me...
These two links have the same zip code: https://www.sqlite.org/np1queryprob.html https://engineering.fb.com/2020/03/02/data-infrastructure/me...
Using RxDB as state management there is much you get for free like sharing the state between multiple browser tabs and reusing a singe replication socket even when the user has opened 1000ths of tabs.
Where does "Web" come in here? All of the links are for local-first principles, CRDTs.
One of the reasons I love the local-first movement is that it puts desktop back into the center of things. I want fast, rich creative tools integrated with my OS but I want synchronization and collaboration. This is what local-first aims for, was my understanding.
Ideally "Web" (ie browser tech) steps aside for first-class desktop producer/creative-focused apps.
One of the reasons I love the local-first movement is that it puts desktop back into the center of things. I want fast, rich creative tools integrated with my OS but I want synchronization and collaboration. This is what local-first aims for, was my understanding.
Ideally "Web" (ie browser tech) steps aside for first-class desktop producer/creative-focused apps.
Is there any popular commercial apps based on these? Most of projects I have seen using these tech are developers' side projects.
Not that many, we need more builders. https://www.inkandswitch.com/ has a few and ofc checkout the apps to try section on the site.
The key bullets are listed at the top:
1. data co-located with its UI
2. works offline
3. synchronizes between clients
4. lets its users own their data
So, except for #3, exactly like classic desktop apps that store data in local files. (#3 used to be called "peer-to-peer networking").
The modern equivalent of classic desktop apps (not that they've gone away) are mobile app stores. Mobile apps are installed and run locally on a phone, even though a key part in their business model is that most frequently sync back data to their server-side.
What's technically different between these and "local-first"? Nothing.
In #4, there's only an implied contract (not even explicit) that the local-first will be not doing "bad" things (like connecting server-side and then sending data there without user permission.) There's no technical limitation that keeps the app from doing that, though.
In other words, "local-first" seems to be a somewhat meaningless buzzword or critique about a business model, not a technical design.
1. data co-located with its UI
2. works offline
3. synchronizes between clients
4. lets its users own their data
So, except for #3, exactly like classic desktop apps that store data in local files. (#3 used to be called "peer-to-peer networking").
The modern equivalent of classic desktop apps (not that they've gone away) are mobile app stores. Mobile apps are installed and run locally on a phone, even though a key part in their business model is that most frequently sync back data to their server-side.
What's technically different between these and "local-first"? Nothing.
In #4, there's only an implied contract (not even explicit) that the local-first will be not doing "bad" things (like connecting server-side and then sending data there without user permission.) There's no technical limitation that keeps the app from doing that, though.
In other words, "local-first" seems to be a somewhat meaningless buzzword or critique about a business model, not a technical design.
When comparing desktop apps to web apps, we often forget that web apps came to dominate because they have a massive advantage when it comes to distribution.
It's much easier to go to a URL than to download and install software, not to mention the process of maintaining the upgrade versions. With web apps, there are no dialog boxes that interrupt you when you're firing up the app to get stuff done.
So while it's not mentioned in the local-first software manifesto, I'd add that we'd want to retain the property of easy distribution of web apps, and it's not just sync between clients.
It's much easier to go to a URL than to download and install software, not to mention the process of maintaining the upgrade versions. With web apps, there are no dialog boxes that interrupt you when you're firing up the app to get stuff done.
So while it's not mentioned in the local-first software manifesto, I'd add that we'd want to retain the property of easy distribution of web apps, and it's not just sync between clients.
This isn't about desktop vs web apps. Plenty of desktop apps (or mobile apps) use a centrally located database server side.
So, #3 (synchronize between clients) is about merging data using CRDTs in a distributed manner without requiring a centrally located database.
A better way to think about it is Google Docs (as a desktop app or web app really doesn't matter), and it offers real-time collaboration on a single doc between users without using a centrally located database.
A better way to think about it is Google Docs (as a desktop app or web app really doesn't matter), and it offers real-time collaboration on a single doc between users without using a centrally located database.
I'm curious why Solid/Pods are not mentioned; there was a lot of press and excitement around its launch, backed by Tim Berners-Lee, and it seemed to be exactly the pro-user technology we needed to take computing in service of humanity to the next step. No news on that project since 2021 :(
Fossil Source Code Management (fossil-scm.org/) ticks all these boxes. It's amazing in every way except the ones most relevant to this thread: it's not for web development! (Except as a means of version control for your web-dev project. And managing tickets, and discussion and other project management things.)
The reason I bring it up is that in spite of this apparent misfit-to-topic is that it's a superb exemplar of what a local-first application can operate like. It does not sacrifice network presence and utility. I wish for more projects to work like Fossil does, only tackling different problem domains. (My personal vote is for blog or CMS.)
The reason I bring it up is that in spite of this apparent misfit-to-topic is that it's a superb exemplar of what a local-first application can operate like. It does not sacrifice network presence and utility. I wish for more projects to work like Fossil does, only tackling different problem domains. (My personal vote is for blog or CMS.)
This is something which I need, ALMOST!!
It will be great if someone here guides me on how I can solve this below problem.
I am part of a Enterprise company which installs a bunch of managed security softwares in employees' laptops. A couple of these security softwares can/must be used in BYODs as well, to connect to the company network.
I would like to build a application such that, whenever a employee finds that something is not working right on their laptop, they should be able to fire it up on their browser and it will access logs from these security software and does troubleshooting/debugging locally on the machine and provides the results and remediation steps to the person. This will tremendously save time instead of contacting IT team and waiting for their help.
For this usecase, I have some limitations.
1) I want to be able to solve for both managed laptops and BYODs (both Mac and Windows). So I cannot push this as a desktop application using MDM solution.
I want this to be a web-app as I can control the version of the application that they are running. So a local-first web app seems perfect in that sense.
2) I want to be able to access local file system where the logs of these security software are located. I am not a developer, but rather a infra guy, but based on what I know, a web-app cannot access the file system without user actually doing a file picker. But in this case, it is too much friction for non-technical users, especially since I want to build this solution for multiple security software which is dependent on multiple file location.
3) Moreover, I don't want to unnnecessarily reveal too much information of location of the log files for the security softwares. But if it is a local-first "web-app" and the user has to be pick the file using a dialog box, I cannot do it without revealing the location.
4) For "some" use cases, I want to be able to "securely" send meta data to a centralized server for more complex troubleshooting scenarios or to log a ticket, for example.
Sorry for the long question. May I know if anyone have any solutions for this scenario?
It will be great if someone here guides me on how I can solve this below problem.
I am part of a Enterprise company which installs a bunch of managed security softwares in employees' laptops. A couple of these security softwares can/must be used in BYODs as well, to connect to the company network.
I would like to build a application such that, whenever a employee finds that something is not working right on their laptop, they should be able to fire it up on their browser and it will access logs from these security software and does troubleshooting/debugging locally on the machine and provides the results and remediation steps to the person. This will tremendously save time instead of contacting IT team and waiting for their help.
For this usecase, I have some limitations.
1) I want to be able to solve for both managed laptops and BYODs (both Mac and Windows). So I cannot push this as a desktop application using MDM solution.
I want this to be a web-app as I can control the version of the application that they are running. So a local-first web app seems perfect in that sense.
2) I want to be able to access local file system where the logs of these security software are located. I am not a developer, but rather a infra guy, but based on what I know, a web-app cannot access the file system without user actually doing a file picker. But in this case, it is too much friction for non-technical users, especially since I want to build this solution for multiple security software which is dependent on multiple file location.
3) Moreover, I don't want to unnnecessarily reveal too much information of location of the log files for the security softwares. But if it is a local-first "web-app" and the user has to be pick the file using a dialog box, I cannot do it without revealing the location.
4) For "some" use cases, I want to be able to "securely" send meta data to a centralized server for more complex troubleshooting scenarios or to log a ticket, for example.
Sorry for the long question. May I know if anyone have any solutions for this scenario?
Hmm, I would think browser sandboxing is going to make that hard. If you have local admin rights, you might be able to make a shell script to grep through the logfiles and generate an html page as its output, which you could open in the browser? I would imagine your IT / SecOps folks would not be excited about that data being sent off the device.
I would imagine your IT / SecOps folks would not be excited about that data being sent off the device.
This is a concern, but not as much as you would think, because we are going to limit what we are going to send back to the server. Also, we have a dedicated team that will do a audit of the security/privacy implications because any company application goes live.
I am not a developer, but infact part of IT security team. And this is the reason, why I had not gone ahead with any development, despite having this idea for more than a year, because I don't have a proper solution.
* blacksmith_tb 10 minutes ago | parent | context | on: Local-First Web Development
Hmm, I would think browser sandboxing is going to make that hard. If you have local admin rights, you might be able to make a shell script to grep through the logfiles and generate an html page as its output, which you could open in the browser? I would imagine your IT / SecOps folks would not be excited about that data being sent off the device.*
There are two problems to it, which I see. I want my usecase to be solved for managed as well as BYOD devices. And these BYOD devices are managed by the IT teams of different partners we work with. And they have their own security softwares and restrictions. Firstly, we cannot convince them to install a desktop application in their company managed machine. Secondly, a desktop application has a high probability of getting blocked compared to a web-app.
Also, a web-app is in general a better user experience when compared to a desktop app, in this scenario. Because it is easier for the user to launch and use.
I know I am asking for too much. But I have not lost hope that somewhere out there, there might be a solution.
I am open to ideas.
This is a concern, but not as much as you would think, because we are going to limit what we are going to send back to the server. Also, we have a dedicated team that will do a audit of the security/privacy implications because any company application goes live.
I am not a developer, but infact part of IT security team. And this is the reason, why I had not gone ahead with any development, despite having this idea for more than a year, because I don't have a proper solution.
* blacksmith_tb 10 minutes ago | parent | context | on: Local-First Web Development
Hmm, I would think browser sandboxing is going to make that hard. If you have local admin rights, you might be able to make a shell script to grep through the logfiles and generate an html page as its output, which you could open in the browser? I would imagine your IT / SecOps folks would not be excited about that data being sent off the device.*
There are two problems to it, which I see. I want my usecase to be solved for managed as well as BYOD devices. And these BYOD devices are managed by the IT teams of different partners we work with. And they have their own security softwares and restrictions. Firstly, we cannot convince them to install a desktop application in their company managed machine. Secondly, a desktop application has a high probability of getting blocked compared to a web-app.
Also, a web-app is in general a better user experience when compared to a desktop app, in this scenario. Because it is easier for the user to launch and use.
I know I am asking for too much. But I have not lost hope that somewhere out there, there might be a solution.
I am open to ideas.
[deleted]
> Also, a web-app is in general a better user experience when compared to a desktop app, in this scenario. Because it is easier for the user to launch and use.
Embed an icon to your software, pin to taskbar or the system tray. User clicks icon -> large, non-minimizable popup window appears, gets users attention -> 'generate report?' -> Yes or No button.
Much better than having the user type some URL. They'll remember the icon but not the URL. Two mouse clicks, no keyboard needed.
Embed an icon to your software, pin to taskbar or the system tray. User clicks icon -> large, non-minimizable popup window appears, gets users attention -> 'generate report?' -> Yes or No button.
Much better than having the user type some URL. They'll remember the icon but not the URL. Two mouse clicks, no keyboard needed.
This looks to be curation, but one of the things on there in a prominent position isn't the best choice IMO. RxDB is what I might call an Empty-Core project, where you can't do simple stuff without the paid plugins.
Not true. Most RxDB users use the dexie.js storage which is for free: https://rxdb.info/rx-storage-dexie.html
Also you should compare it to the alternatives like firestore or AWS datastore which are not even open source partially and cannot even be used with a self-hosted server.
Is this So-Mo-Lo or no, is it Lo-So-Mo?
(S.V. reference)
(S.V. reference)
there are many options if you do not care how conflicts are resolved and last win or some unknown but deterministic change wins is ok, but if you care to write bullet proof app specific conflict resolution without any data loss there is no real alternative to pouchdb + couchdb (except reimplementing something similar manually)
also worth noting is that offline first is about way more than just working offline, yes full offline scenarios are more and more rare, but offline first apps provide reliable and instant interactivity where any user action is has a latancy of 1 to 10 ms max and no data is lost. and works as well on crappy mobile as on a high speed landline.
also worth noting is that offline first is about way more than just working offline, yes full offline scenarios are more and more rare, but offline first apps provide reliable and instant interactivity where any user action is has a latancy of 1 to 10 ms max and no data is lost. and works as well on crappy mobile as on a high speed landline.
[deleted]
Crashing Brave browser on iOS.
I didn’t even think it’s possible for a site to take down a browser completely. Nice work!
Give me 5 minutes with my abysmal Angular skills.
A site can't take down a browser. A browser can take itself down if it doesn't like a site.
Author here. This has got to be one of the simplest web pages on the planet :/
Logged with Brave support and as issue on the site’s repo.
Logged with Brave support and as issue on the site’s repo.
Works fine on Firefox iOS
+1
Just wild! checkout the source code the page isn't doing much: https://github.com/localfirstweb/localfirstweb.dev
[deleted]
@martinkl (Martin Kleppmann, primary author of the Automerge CRDT _and_ Designing Data-Intensive Applications) suspiciously absent from the Folks to Follow section.
That is a good point, we will have it updated tomorrow.
It wasn't deliberate omission but more that he is essentially the person who kicked it off and the first link is the ink and switch local-first article
It wasn't deliberate omission but more that he is essentially the person who kicked it off and the first link is the ink and switch local-first article
imo the ecosystem is weak for a local-first apps.
I'm dreaming about e2e encrypted local-first database that would be easy ti plug in and store encrypted on the server. From the tooling perspective, WASM seems a good choice for most likely embracing through Rust.
Absolutely need something here This keeps coming up everywhere. Down below in this HN thread, r/programming LFW comments and the discord chat.
Database as a storage and sync layer makes a lot of sense but it's hard to pull of the encryption and device provisioning at that abstraction layer.
Database as a storage and sync layer makes a lot of sense but it's hard to pull of the encryption and device provisioning at that abstraction layer.
that’s a surprisingly short list of Apps to Try. i am a fan of the promise of local first, but one doubt in my mind is always that the Notions of the world dont embrace it. if the UX was so desirable then why havent they been replaced by something local first?
A lot of the alternatives (including the one I am working on) embrace different parts of this in their UX. Just Notion is the dominant at the moment.
How would you use Notion in a local-first context?
FYI This crashes Brave iOS. Odd it doesn’t crash Safari iOS given they’re the same engine.
The web has moved to client rendering. But we still host the data on the server! Why?
The web has always been client-rendered UI. Markup is data. What's changed is the practice of pushing JSON instead to client-render to markup which the client then renders as UI. Whether this is an improvement is highly situational and probably somewhat subjective.
What hasn't changed is that data management is often easier to let someone else think about, and that routing data between different client apps is often most easily and efficiently done with a single centralized intermediary.
What hasn't changed is that data management is often easier to let someone else think about, and that routing data between different client apps is often most easily and efficiently done with a single centralized intermediary.
Funny you mention that! The web has shifted towards server rendering (again).
Anyways, it depends on use case. It's not entirely an either or situation. Like Obsidian, the note app as an example (even though it doesn't have a web app version officially). It runs great locally, you manage all of that yourself the way you want. However, they also have a subscription to manage syncing for you, in which your data is hosted on their servers for multi device use.
Anyways, it depends on use case. It's not entirely an either or situation. Like Obsidian, the note app as an example (even though it doesn't have a web app version officially). It runs great locally, you manage all of that yourself the way you want. However, they also have a subscription to manage syncing for you, in which your data is hosted on their servers for multi device use.
For most users, delegating data management and application updates to a 3rd party is worth paying for.
[deleted]
how do you make your website load almost instantly? please tell me.
https://rxdb.info/offline-first.html has a good write up on this.
I'm also trying to dig up this local-first GitHub client that a hacker built and demoed on YouTube
I'm also trying to dig up this local-first GitHub client that a hacker built and demoed on YouTube
I'm sure a lot of the technologies on the list (like Yjs!) are well-designed and reliable, but I would not touch GUN with a ten foot pole. The code is absolutely inscrutable (what does any of this do? https://github.com/amark/gun/blob/master/lib/axe.js), the creator has failed to sufficiently explain any of the underlying mechanisms without complete hand-waving (what on earth is a "hypothetical amnesia machine" that supposedly underpins all of GUN? The creator has literally never given any kind of coherent explanation of it) -- it's just pure snake oil.
[deleted]
Loading this site causes Brave browser on iOS to hard crash. Impressive.
Given that every iOS browser uses the same engine under the hood, this sounds like a Brave problem. Safari and Chrome are fine.
Author here. I’ll try and fix this. I have a suspicion it’s the CSS glow behind the logo since everything else is the most stupid basic HTML you could imagine.
Nope, I'm not sure it's that. Brave crashes on tinybase.org pages without the glow. I wonder if it's the SVG favicon?
Woww, is this still happening? its literally a barebones jekyll page https://github.com/localfirstweb/localfirstweb.dev
Not sure what we can fix, does https://lfw.dev also crash (redir to localfirstweb)
Not sure what we can fix, does https://lfw.dev also crash (redir to localfirstweb)
Can confirm. Was looking forward to reading this and then BAM. Exit
Yep. Guess I’ll just read the comments.
[deleted]
Ironic using discord for such a project.
Maybe try matrix?
Neither of those thing are local-first, e.g. you can't search or compose messages while offline. Then again chat apps hold little interest when offline.
Nah, IRC and XMPP MUC
Both are beaten by matrix now.
In what way? Not in mature stable clients or in system resources for hosting a server. There’s issues around the centralization of Matrix.org and I've seen many cases where folks spun up then spun down a Matrix server 'cause it costs too much to run. In the case of Disroot, the closed their server to open an XMPP server instead.
https://disroot.org/de/blog/matrix-closure
https://disroot.org/de/blog/matrix-closure
you’re running on 2018 vintage data. plus there is no centralisation on matrix.org (beyond it being the biggest server), as has been pretty obvious in the situations where matrix.org has gone offline.
It amuses me how this is positioned like it's something new and radical :-).
Yes I know! I gave a talk about this, and it made me nostalgic in a way. https://tripleodeon.com/2022/11/closing-the-gap-between-your...
[deleted]
Many things where it would take me 10 minutes to look up a library or API thing I don't know from memory. From today:
* Write me a Python Fabric script to control an SSH session in the following ways: ...
* "What does torchaudio.load do if num_frames exceeds the end of the file"?
* "What's a typical conn_max_age in django for conn_max_age and why?"
* "One-liner to create django secret key and use flyctl secrets set"
* "Fix this toml:"
* etc.
It's also amazing rubber duck debugging. https://en.wikipedia.org/wiki/Rubber_duck_debugging
* Write me a Python Fabric script to control an SSH session in the following ways: ...
* "What does torchaudio.load do if num_frames exceeds the end of the file"?
* "What's a typical conn_max_age in django for conn_max_age and why?"
* "One-liner to create django secret key and use flyctl secrets set"
* "Fix this toml:"
* etc.
It's also amazing rubber duck debugging. https://en.wikipedia.org/wiki/Rubber_duck_debugging
Native apps have high install friction and a lot of nasty cross-platform tradeoffs. Even though there's always a cohort here (rightly) commenting on how much of a step backwards the web is for GUI app development, one has to admit that we are past the time where a truly cross-platform, install-less native app SDK can be created and cross the chasm to universal adoption. Web tech is what we have, worse is better, yada yada.
Accepting that reality, one of the implications of the web and cloud-storage is that the server component tends to be heavy. While it's convenient for users to have their data centralized in the cloud for consistency and access on multiple devices, this does incur some significant overhead in terms of account managment, authentication, and database hosting.
The thing that I find really cool about local-first web development is that it reopens the door for hobbyist and micro-ISV apps that can served cheaply as static files, where the customer pays for the compute and stores the data. There are lots of potential micro-apps, which don't require network effects or large data storage, that could be built this way and avoid incurring significant ops overhead for the developer. Obviously it runs counter to user expectations today, but I think a lot people might also appreciate useful apps that don't have $5/month subscription as table stakes just to keep the lights on. Also, it doesn't have to be a binary proposition, there could be accounts/sync functionality optional. Most of all, as a developer, it's exciting to have the ability to try out an idea, with optionality to ramp it up into a full SaaS, or scale it down without an abrupt rug-pull on the early adopters.