One of the things that's exciting to me about local-first web development is how it bridges the gap between a full-blown native app and full-blown web service.
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.
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.
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 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.
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 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.
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.
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.
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 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.
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.
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).
>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.
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.
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?".
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.
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.
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 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.
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.
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?
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)
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.
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.
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.
What are rich creative tools? Do you mean something like Figma or Photoshop? Or are there other tools in that category, like tools for creative writing?
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.
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.
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 :(
[+] [-] dasil003|3 years ago|reply
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.
[+] [-] chii|3 years ago|reply
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.
[+] [-] darklion|3 years ago|reply
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.
[+] [-] krab|3 years ago|reply
[+] [-] hardcopy|3 years ago|reply
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.
[+] [-] inportb|3 years ago|reply
PouchDB does have rather expensive adapters that use memory or LocalStorage. Almost twice the size as the base package (minified).
[+] [-] jbjorge|3 years ago|reply
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())
[+] [-] xyzzy4747|3 years ago|reply
[+] [-] locustous|3 years ago|reply
I'm really surprised more companies don't pick this stack.
[+] [-] vouwfietsman|3 years ago|reply
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.
[+] [-] realPubkey|3 years ago|reply
[1] https://rxdb.info/offline-first.html
[+] [-] sekao|3 years ago|reply
[+] [-] darau1|3 years ago|reply
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.
[+] [-] franky47|3 years ago|reply
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.
[+] [-] wellpast|3 years ago|reply
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).
[+] [-] Falkon1313|3 years ago|reply
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.
[+] [-] ghiculescu|3 years ago|reply
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.
[+] [-] LAC-Tech|3 years ago|reply
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?".
[+] [-] yonz|3 years ago|reply
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.
[+] [-] clairity|3 years ago|reply
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.
[+] [-] oblib|3 years ago|reply
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.
[+] [-] iamwil|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] EGreg|3 years ago|reply
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...
[+] [-] yonz|3 years ago|reply
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.
[+] [-] RcouF1uZ4gsC|3 years ago|reply
The Sun and later Google vision is the network is the computer. For better or worse, the Sun/Google vision is ascendent now.
[+] [-] wellpast|3 years ago|reply
[+] [-] canadiantim|3 years ago|reply
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!
[+] [-] javaunsafe2019|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] gfodor|3 years ago|reply
https://gfodor.medium.com/rebooting-the-web-in-3d-with-websp...
[+] [-] yonz|3 years ago|reply
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.
[+] [-] iainmerrick|3 years ago|reply
[+] [-] jamesgpearce|3 years ago|reply
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!
[+] [-] Falkon1313|3 years ago|reply
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?
[+] [-] college_physics|3 years ago|reply
[+] [-] yonz|3 years ago|reply
We have an amazing lineup prepared for you, including @pvh you can find the details here: https://twitter.com/founderYonz/status/1628846898898501632?t...
[+] [-] sergioisidoro|3 years ago|reply
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.
[+] [-] yonz|3 years ago|reply
These two links have the same zip code: https://www.sqlite.org/np1queryprob.html https://engineering.fb.com/2020/03/02/data-infrastructure/me...
[+] [-] realPubkey|3 years ago|reply
[+] [-] wellpast|3 years ago|reply
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.
[+] [-] lupire|3 years ago|reply
[+] [-] iamwil|3 years ago|reply
[+] [-] Existenceblinks|3 years ago|reply
[+] [-] yonz|3 years ago|reply
[+] [-] hobobaggins|3 years ago|reply
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.
[+] [-] iamwil|3 years ago|reply
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.
[+] [-] l8again|3 years ago|reply
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.
[+] [-] garfieldnate|3 years ago|reply