Local-First Web Development

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.

wellpast3• 3 years ago

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.)

tmpz222• 3 years ago

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.

iamwil8• 3 years ago

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?

sergioisidoro• 3 years ago

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.

realPubkey2• 3 years ago

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.

yonz13• 3 years ago

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...

jacooper2• 3 years ago

Ironic using discord for such a project. Maybe try matrix?

toastal2• 3 years ago

Nah, IRC and XMPP MUC

jacooper2• 3 years ago

Both are beaten by matrix now.

remram4• 3 years ago

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.

mlajtos3• 3 years ago

Chat apps like Discord hold valuable content and having it offline searchable would be really nice. Also, replying offline.

vouwfietsman2• 3 years ago

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.

realPubkey2• 3 years ago

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

dmak• 3 years ago

That sounds exactly like offline capabilities?

vouwfietsman2• 3 years ago

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".

wellpast3• 3 years ago

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).

KrugerDunnings• 3 years ago

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.

iamwil8• 3 years ago

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?

bob1029• 3 years ago

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.

hem7776• 3 years ago

How about having the state 100% on server AND on client? No dragons, no problems.

iamwil8• 3 years ago

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!

franky47• 3 years ago

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.

jakelazaroff• 3 years ago

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

sekao• 3 years ago

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.

fauigerzigerk2• 3 years ago

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.

mkraft• 3 years ago

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.

darau1• 3 years ago

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.

pocketarc• 3 years ago

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.

vidarh• 3 years ago

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.

locustous2• 3 years ago

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.

Falkon13133• 3 years ago

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.

crispinb• 3 years ago

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.

LAC-Tech2• 3 years ago

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.

nicbou• 3 years ago

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.

Falkon13133• 3 years ago

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.

pharmakom• 3 years ago

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.

ssss11• 3 years ago

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.

wellpast3• 3 years ago

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.

lupire2• 3 years ago

For the new generation, the Internet is the Web. HTTP is part of the standard stack like IP, even if you don't need or use hypertext.

iamwil8• 3 years ago

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?

rs999gti2• 3 years ago

So what is this? Shipping SQL lite or something similar with all web projects, with an async process for eventual sync with HQ data and systems?

remram4• 3 years ago

SQL lite

You mean SQLite?

To answer your question, this is not a technical product, it is a call for action and a collection of resources.

NickBusey• 3 years ago

Loading this site causes Brave browser on iOS to hard crash. Impressive.

kept3k• 3 years ago

Can confirm. Was looking forward to reading this and then BAM. Exit

christophilus• 3 years ago

Yep. Guess I’ll just read the comments.

Etheryte• 3 years ago

Given that every iOS browser uses the same engine under the hood, this sounds like a Brave problem. Safari and Chrome are fine.

yonz13• 3 years ago

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)

makingstuffs• 3 years ago

Yeah it does also crash

jamesgpearce6• 3 years ago

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.

jamesgpearce6• 3 years ago

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?

ghiculescu• 3 years ago

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.

clairity• 3 years ago

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.

yonz13• 3 years ago

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.

yunohn• 3 years ago

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.

LAC-Tech2• 3 years ago

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?".

canadiantim3• 3 years ago

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!

javaunsafe2019• 3 years ago

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.

canadiantim3• 3 years ago

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.

hobobaggins• 3 years ago

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.

iamwil8• 3 years ago

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.

l8again• 3 years ago

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.

oblib• 3 years ago

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.

iamwil8• 3 years ago

probably because you can't run CouchDB on the browser. You do need it as something for PouchDB to talk to, however.

hardcopy• 3 years ago

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.

locustous2• 3 years ago

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.

inportb• 3 years ago

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).

jbjorge• 3 years ago

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())

xyzzy4747• 3 years ago

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.

dasil0033• 3 years ago

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.

krab• 3 years ago

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.

chii• 3 years ago

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.

Centigonal• 3 years ago

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.

darklion• 3 years ago

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.

dasil0033• 3 years ago

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.

yonz13• 3 years ago

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.

anonym29• 3 years ago

Is this So-Mo-Lo or no, is it Lo-So-Mo?

(S.V. reference)

jFriedensreich• 3 years ago

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.

vore• 3 years ago

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.

gfodor• 3 years ago

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...

bravura• 3 years ago

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

iainmerrick• 3 years ago

The “examples” section just has a framework, a tutorial and a demo app. What are some actual examples of this in the wild?

EGreg2• 3 years ago

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...

yonz13• 3 years ago

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.

EGreg2• 3 years ago

Sure, would be very happy to. Send it where? I am going to message you on Keybase.

rkagerer• 3 years ago

It amuses me how this is positioned like it's something new and radical :-).

jamesgpearce6• 3 years ago

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...

college_physics• 3 years ago

It feels like the web becomes exciting again. A bit confusing with all the orthogonal directions but very much alive and promising

benatkin• 3 years ago

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.

code-is-code• 3 years ago

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.

z3t4• 3 years ago

The web has moved to client rendering. But we still host the data on the server! Why?

r3trohack3r• 3 years ago

For most users, delegating data management and application updates to a 3rd party is worth paying for.

waboremo• 3 years ago

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.

wwweston• 3 years ago

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.

forestrat2• 3 years ago

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?

blacksmith_tb• 3 years ago

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.

forestrat2• 3 years ago

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

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.

swyx• 3 years ago

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?

canadiantim3• 3 years ago

How would you use Notion in a local-first context?

tin7in• 3 years ago

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.

maphew• 3 years ago

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.)

jamesgpearce6• 3 years ago

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!

Falkon13133• 3 years ago

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?

jamesgpearce6• 3 years ago

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.

vnjp• 3 years ago

how do you make your website load almost instantly? please tell me.

yonz13• 3 years ago

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

elvin_d• 3 years ago

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.

yonz13• 3 years ago

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.

mbo• 3 years ago

@martinkl (Martin Kleppmann, primary author of the Automerge CRDT _and_ Designing Data-Intensive Applications) suspiciously absent from the Folks to Follow section.

yonz13• 3 years ago

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

Existenceblinks• 3 years ago

Is there any popular commercial apps based on these? Most of projects I have seen using these tech are developers' side projects.

yonz13• 3 years ago

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.

shireboy• 3 years ago

FYI This crashes Brave iOS. Odd it doesn’t crash Safari iOS given they’re the same engine.

garfieldnate• 3 years ago

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 :(

yonz13• 3 years ago

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...

Local-First Web Development

Related Stories