7 ms·

Linear sent me down a local-first rabbit hole

467 points by jcusch 1y ago

ivape 1y ago
[flagged]
- jcusch 1y ago
  An ad for what? I'm not associated with any of the projects mentioned.
  - ivape 1y ago
    An ad for Linear.
    - defrost 1y ago
      If it's an ad for Linear why is so much text spent on Electric SQL, Zero, and Jazz?
      - ivape 1y ago
        [flagged]
        mrkeen 1y ago
        In that worldview, it's unthinkable that you'd come and warn us about ads out of the goodness of your own heart. Who paid you for these comments? Atlassian?
        mattsahr 1y ago
        That's an interesting question. I will open a Jira ticket to schedule a meeting with the Product Team, and they will assign you several stories with acceptance criteria written by AI.
        ramon156 1y ago
        Do elaborate, u made me curious
- dewey 1y ago
  It’s a developer writing about a tool they like. If you’d call word of mouth an “ad” the I guess it’s one.
  - ivape 1y ago
    Why do you think marketing is not sophisticated? Here I’ll offer my services. I’ll pretend to do a technical deep dive of your app for X amount. No one will know, I’ll just act super interested. When the fuck did anyone ever go “omg this web app so impressive”, never, ever, never, ever.
    - dewey 1y ago
      It’s a choice to always see the worst in everything. Many blog post submissions here are someone diving into something they like, hardware, software, tool etc. and it’s just because people like to share.
      - Fnoord 1y ago
        Yep, but LLMs being used as aid in writing blog posts is a relatively new phenomenon. I'm on the fence. IMO ivape provides a hypothesis, but brings it as fact. That isn't a good starting point for a discussion (though a common mistake), but that doesn't prove they are wrong either. Btw, I believe the HN guidelines encourage you to take the positive angle, at least for comments. As for the topic at hand local-first means he end up with a cache; either in memory or on disk. If you got the RAM and NVMe you might as well use it for performance. Back in the days not much could be cached, but your connection was often too lousy or not 24/7. So you ended up with software distribution via 3.5 inch floppies or CDROM. Larger distributions used gigantic disk cache either centralized (Usenet) or distributed (BitTorrent). But the 'you might as well use it' issue is it introduces sloppiness. If you develop with huge constraints you are disciplined into deterrence to start, failing, or succeeding efficiently. We hary ever hear about all the deterrence and failing.
    - theglenn88_ 1y ago
      [flagged]
- deleted 1y ago
  [deleted]
- yard2010 1y ago
  Best kind of ad to the best kind of service (I'm not affiliated, this is not an ad) - an organic one. The enshitification that Jira went through is by itself an ad for Linear.
Gravityloss 1y ago
Some problem on the site. Too much traffic? Secure Connection Failed An error occurred during a connection to bytemash.net. PR_END_OF_FILE_ERROR Error code: PR_END_OF_FILE_ERROR
- jcusch 1y ago
  It looks like I was missing a www subdomain CNAME for the underlying github pages site. I think it's fixed now.
  - Gravityloss 1y ago
    I still see the same error
    - Gravityloss 1y ago
      Ok, it works, problem was probably on my end.
deleted 1y ago
[deleted]
mbaranturkmen 1y ago
How is this approach better than using react-query to persist storage which periodically sync the local storage and the server storage? Perhaps I am missing something.
- petralithic 1y ago
  That approach is precisely what the new TanStack DB does, which if you don't know already has the same creator as React Query. The former extends the latter's principles to syncing, via ElectricSQL, both organizations have a partnership with each other.
- 0xblinq 1y ago
  Yes, you’re missing a lot of things. Like how to update that data when you are offline and have everything sync around when others have made updates to the same data in the meanwhile. Among many other concerns and use cases.
petralithic 1y ago
ElectricSQL and TanStack DB are great, but I wonder why they focus so much on local first for the web over other platforms, as in, I see mobile being the primary local first use case since you may not always have internet. In contrast, typically if you're using a web browser to any capacity, you'll have internet. Also the former technologies are local first in theory but without conflict resolution they can break down easily. This has been from my experience making mobile apps that need to be local first, which led me to using CRDTs for that use case.
- jitl 1y ago
  Because building local first with web technologies is like infinity harder than building local first with native app toolkits. Native app is installed and available offline by default. Website needs a bunch of weird shenanigans to use AppManifest or ServiceWorker which is more like a bunch of parts you can maybe use to build available offline. Native apps can just… make files, read and write from files with whatever 30 year old C code, and the files will be there on your storage. Web you have to fuck around with IndexedDB (total pain in the ass), localStorage (completely insufficient for any serious scale, will drop concurrent writes), or OriginPrivateFileSystem. User needs to visit regularly (at least once a month?) or Apple will erase all the local browser state. You can use JavaScript or hit C code with a wrench until it builds for WASM w/ Emscripten, and even then struggle to make sync C deal with waiting on async web APIs. Apple has offered CoreData + CloudKit since 2015, a completed first party solution for local apps that sync, no backend required. I’m not a Google enthusiast, maybe Firebase is their equivalent? Idk.
  - agos 1y ago
    and if you didn't like or cared to learn CoreData? just jam a sqlite db in your application and read from it, it's just C. This was already working before Angular or even Backbone
  - mike_hearn 1y ago
    Well .... that's all true, until you want to deploy. Historically deploying desktop apps has been a pain in the ass. App stores barely help. That's why devs put up with the web's problems. Ad: unless you use Conveyor, my company's product, which makes it as easy as shipping a web app (nearly): https://hydraulic.dev/ https://hydraulic.dev/ You are expected to bring your own runtime. It can ship anything but has integrated support for Electron and JVM apps, Flutter works too although Flutter Desktop is a bit weak.
incorrecthorse 1y ago
> For the uninitiated, Linear is a project management tool that feels impossibly fast. Click an issue, it opens instantly. Update a status and watch in a second browser, it updates almost as fast as the source. No loading states, no page refreshes - just instant, interactions. How garbage the web has become for a low-latency click action being qualified as "impossibly fast". This is ridiculous.
- jitl 1y ago
  A web request to a data center even with a very fast backend server will struggle to beat 8ms (120hz display) or even 16ms (60hz display), the budget for next frame painting a navigation. You need to have the data local to the device and ideally already in memory to hit 8ms navigation.
  - ahofmann 1y ago
    This is not the point, or other numbers matter more, then yours. In 2005 we wrote entire games for browsers without any frontend framework (jQuery wasn't invented yet) and managed to generate responses in under 80 ms in PHP. Most users had their first bytes in 200 ms and it felt instant to them, because browsers are incredibly fast, when treated right. So the Internet was indeed much faster then, as opposed to now. Just look at GitHub. They used to be fast. Now they rewrite their frontend in react and it feels sluggish and slow.
    - Zanfa 1y ago
      > Now they rewrite their frontend in react and it feels sluggish and slow. And decided to drop legacy features such as <a> tags and broke browser navigation in their new code viewer. Right click on a file to open in a new tab doesn’t work.
    - DanielHB 1y ago
      Unless you are running some really complicated globally distributed backend your roundtrip will always be higher than 80ms for all users outside your immediate geographical area. And the techniques to "fix" this usually only mitigate the problem in read-scenarios. The techniques Linear uses are not so much about backend performance and can be applicable for any client-server setup really. Not a JS/web specific problem.
mkarliner 1y ago
Meteor was/is a very similar technology. And I did some fairly major projects with it.
- mentalgear 1y ago
  Meteor was amazing, I don't understand why it never got sustainable traction.
  - dustingetz 1y ago
    non-relational, document oriented pubsub architecture based on MongoDB, good for not much more than chat apps. For toy apps (in 2012-2016) – use firebase (also for chat apps), for crud-spectrum and enterprise apps - use sql. And then React happened and consumed the entire spectrum of frontend architectures, bringing us to GraphQL, which didn't, but the hype wave left little oxygen remaining for anything else. (Even if it had, still Meteor was not better.)
    - vlasky 1y ago
      I'm the defacto maintainer of the Meteor MySQL integration. Since 2015, I've been involved in the design and maintenance of six different Meteor webapps for real-time geospatial applications built for B2B and B2C. Given this, I reject your assertion that Meteor is limited to MongoDB and "toy apps".
      - deleted 1y ago
        [deleted]
      - deleted 1y ago
        [deleted]
  - h4ch1 1y ago
    Seems like meteor is still actively developed and is Framework agnostic! https://github.com/meteor/meteor https://github.com/meteor/meteor
  - 1y ago
terencege 1y ago
I'm also building a local first editor and rolling my own CRDTs. There are enormous challenges to make it work. For example the storage size issue mentioned in the blog, I end up using with yjs' approach which only increase the clock for upsertion, and for deletion remove the content and only remain deleted item ids which can be efficiently compressed since most ids are continuous.
- jddj 1y ago
  In case you missed it and it's relevant, there was an automerge v3 announcement posted the other day here which claimed some nice compression numbers as well
  - terencege 1y ago
    As far as I know, automerge is using DAG history log and garbage collecting by comparing the version clock heads of 2 clients. That is different than yjs. I have not followed their compression approach in v3 yet, will check if having time.
mentalgear 1y ago
Local-First & Sync-Engines are the future. Here's a great filterable datatable overview of the local-first framework landscape: https://www.localfirst.fm/landscape https://www.localfirst.fm/landscape My favorite so far is Triplit.dev (which can also be combined with TanStack DB); 2 more I like to explore are PowerSync and NextGraph. Also, the recent LocalFirst Conf has some great videos, currently watching the NextGraph one (https://www.youtube.com/watch?v=gaadDmZWIzE https://www.youtube.com/watch?v=gaadDmZWIzE).
- virgil_disgr4ce 1y ago
  Thank you for this, I'm going to have to check out Triplit. Have you tried InstantDB? It's the one I've been most interested in trying but haven't yet.
- rogerkirkness 1y ago
  Reminds me of Meteor back in the day.
  - 8n4vidtmkvmk 1y ago
    Whatever happened to meteor? They made it sound so great. What I didn't like was the tight coupling to mongodb.
    - explorigin 1y ago
      For me it was the lack of confirmation with the backend. When it was the next big thing, it sent changes to the backend without waiting for a response. This made the interface crazy fast but I just couldn't take the risk of the FE being out-of-sync with the backend. I hope they grew out of that model but I never took it serious for that one reason.
      - rogerkirkness 1y ago
        Yeah I built my first startup on Meteor, and the prototype for my second one, but there was so many weird state bugs after it got more complicated that we had to eventually switch back to normal patterns to scale it.
Cassandra99 1y ago
I developed an open-source task management software based on CRDT with a local-first approach. The motivation was that I primarily manage personal tasks without needing collaboration features, and tools like Linear are overly complex for my use case. This architecture offers several advantages: 1. Data is stored locally, resulting in extremely fast software response times 2. Supports convenient full database export and import 3. Server-side logic is lightweight, requiring minimal performance overhead and development complexity, with all business logic implemented on the client 4. Simplified feature development, requiring only local logic operations There are also some limitations: 1. Only suitable for text data storage; object storage services are recommended for images and large files 2. Synchronization-related code requires extra caution in development, as bugs could have serious consequences 3. Implementing collaborative features with end-to-end encryption is relatively complex The technical architecture is designed as follows: 1. Built on the Loro CRDT open-source library, allowing me to focus on business logic development 2. Data processing flow: User operations trigger CRDT model updates, which export JSON state to update the UI. Simultaneously, data is written to the local database and synchronized with the server. 3. The local storage layer is abstracted through three unified interfaces (list, save, read), using platform-appropriate storage solutions: IndexedDB for browsers, file system for Electron desktop, and Capacitor Filesystem for iOS and Android. 4. Implemented end-to-end encryption and incremental synchronization. Before syncing, the system calculates differences based on server and client versions, encrypts data using AES before uploading. The server maintains a base version with its content and incremental patches between versions. When accumulated patches reach a certain size, the system uploads an encrypted full database as the new base version, keeping subsequent patches lightweight. If you're interested in this project, please visit https://github.com/hamsterbase/tasks https://github.com/hamsterbase/tasks
- b_e_n_t_o_n 1y ago
  very cool!
preaching5271 1y ago
Automerge + Keyhive is the future https://www.inkandswitch.com/project/keyhive/ https://www.inkandswitch.com/project/keyhive/
minikomi 1y ago
My kingdom for a team organised by org mode files through a got repo
yanis_t 1y ago
I don't get it. You still have to sync the state one way or another, network latency is still there.
- Aldipower 1y ago
  Me neither. Considered we are talking about collaborative network applications, you are loosing the single-source-of-thruth (the server database) with the local first approach. And it just adds so much more complexity. Also, as your app grows, you probably end up to implement the business logic twice. On the server and locally. I really do not get it.
  - jitl 1y ago
    You can use the same business logic code on both the client and server. With the Linear approach, the server remains the source of truth.
    - foldr 1y ago
      It’s difficult to ensure that it’s always the same logic when client and server software versions can get out of sync. You can try to force the client to reload whenever the server redeploys, but realistically you’ll probably end up dealing with cases where the client and server logic diverge.
      - jitl 1y ago
        i mean that's life with client computers, you make stuff backwards compatible and you avoid making it too brittle.
        foldr 1y ago
        It's not an insurmountable problem, but it's a problem that you don't have if you execute your business logic only on the server.
- croes 1y ago
blixt 1y ago
I've been very impressed by Jazz -- it enables great DX (you're mostly writing sync, imperative code) and great UX (everything feels instant, you can work offline, etc). Main problems I have are related to distribution and longevity -- as the article mentions, it only grows in data (which is not a big deal if most clients don't have to see that), and another thing I think is more important is that it's lacking good solutions for public indexes that change very often (you can in theory have a public readable list of ids). However, I recently spoke with Anselm, who said these things have solutions in the works. All in all local-first benefits often come with a lot of costs that are not critical to most use cases (such as the need for much more state). But if Jazz figures out the main weaknesses it has compared to traditional central server solutions, it's basically a very good replacement for something like Firebase's Firestore in just about every regard.
- ChadNauseam 1y ago
  Yeah, Jazz is amazing. The DX is unmatched. My issue when I used it was, they mainly supported passkey-based encryption, which was poorly implemented on windows. That made it kind of a non-starter for me, although I'm sure they'll support traditional auth methods soon. But I love that it's end-to-end encrypted and it's super fun to use.
madisvain 1y ago
Local first is amazing. I have been building a local first application for Invoicing since 2020 called Upcount https://www.upcount.app/ https://www.upcount.app/. First I used PouchDB which is also awesome https://pouchdb.com/ https://pouchdb.com/ but now switched to SQLite and Turso https://turso.tech/ https://turso.tech/ which seems to fit my needs much better.
b_e_n_t_o_n 1y ago
Local first is super interesting and absolutely needed - I think most of the bugs I run into with web apps have to do with sync, exacerbated by poor internet connectivity. The local properties don't interest me as much as request ordering and explicit transactions. You aren't guaranteed that requests resolve in order, and thus can result in a lot of inconsistencies. These local-first sync abstractions are a bit like bringing a bazooka to a water gun fight - it would be interesting to see some halfway approaches to this problem.
croes 1y ago
But how is conflicting data handled? For instance one closes an something and another aborts the same thing.
qweiopqweiop 1y ago
It's starting to feel to me that a lot of tech is just converging on other platforms solutions. This for example sounds incredibly similar to how a mobile app works (on the surface). Of course it goes the other way too, with mobile tech taking declarative UIs from the Web.
10us 1y ago
Man why arent couchdb / pouchdb not listed? Still works like a charm!
- jFriedensreich 1y ago
  "Works like a charm" / "not listed" does not really do it justice, its much worse. All of the mentioned "solutions" will inevitably lose data on conflicts one way or another and i am not aware of anything from that school of thought, that has full control over conflict resolution as couchdb / pouchdb does. Apparently vibe coding crdt folks do not value data safety over some more developer ergonomics. It is an tradeoff to make for your own hobby projects if you are honest about it but i don't understand how this is just completely ignored in every single one of these posts.
antgiant 1y ago
I’ve been working on a small browser app that is local first and have been trying to figure out how to pair it with static hosting. It feels like this should be possible but so far the tooling all seems stuck in the mindset of having a server somewhere. My use case is scoring live events that may or may not have Internet connection. So normal usage is a single person but sometimes it would be nice to allow for multi person scoring without relying on centralized infrastructure.
- swsieber 1y ago
  Honestly, having used InstantDB (one of the providers listed in their post), I think it'd be a pretty nice fit. I've been writing a budget app for my wife and I and I've made it 100% free with 3rd party hosting: * InstantDB free tier allows 1 dev. That's the remote sync. * Netlify for the static hosting * Free private gitlab ci/cd for running some email notification polling, basically a poor mans hosted cron.
  - antgiant 1y ago
    I may end up doing that, but I really wish there was a true p2p option that doesn’t have me relying on someone not rug pulling their free tier sync server.
    - swsieber 1y ago
      Yeah... true p2p is pretty hard though, to the point that even stuff like WebRTC requires external servers to setup the data sync portion. It would be nice to develop something that worked at that layer though. IIUC, InstantDB is open source with a docker container you can run yourself, but at this point it's designed to run in a more cloud-like environment than I'd like. Last time I checked there was at least one open PR to make it easier to run in a different environment, but I haven't check in recently.
      - antgiant 1y ago
        I spent some more time hunting due to this conversation and I’m hopeful that yjs + y-WebRTC + PeerJS will solve this. I also see that there are a few libraries that enable QR codes to replace PeerJS as a truly offline WebRTC initialization with true p2p connectivity. Looks quite promising
mizzao 1y ago
Is this technical architecture so different from Meteor back in the day? Just curious for those who have a deeper understanding.
sturza 1y ago
Local-first buys you instant UX by moving state to the client, and then makes everything else a little harder
- captainregex 1y ago
  this is such a clean and articulate way of putting it. The discussion around here the last few days about local and the role it is going to play has been phenomenal and really genuine
- CharlieDigital 1y ago
  > instant UX I do not get the hype. At all. "Local first" and "instant UX" are the least of my concerns when it comes to project management. "Easy to find things" and "good visibility" are far more important. Such a weird thing to index on. I might interact with the project management tool a few times a day. If I'm so frequently accessing it as an IC or an EM that "instant UX" becomes a selling point, then I'm doing something wrong with my day.
  - virgil_disgr4ce 1y ago
    UI performance is "a weird thing to index on"?
    - CharlieDigital 1y ago
      Yes? If that's the primary selling point for a project manager versus being just a really damn good project manager with good visibility? I've never used a project manager and thought to myself "I want to switch because this is too slow". Even Jira. But I have thought to myself "It's too difficult to build a good workflow with this tool" or "It's too much work to surface good visibility". This is not a first-person shooter. I don't care if it's 8ms vs 50ms or even 200ms; I want a product that indexes on being really great at visibility. It's like indexing your buying decision for a minivan on whether it can do the quarter mile at 110MPH @ 12 seconds. Sure, I need enough power and acceleration, but just about any minivan on the market is going to do an acceptable and safe speed and if I'm shopping for a minivan, its 1/4 mile time is very low on the list. It's a minivan; how often am I drag racing in it? The buyer of the minivan has a purpose for buying the minivan (safety, comfort, space, cost, fuel economy, etc.) and trap speed is probably not one of them. It's a task manager. Repeat that and see how silly it sounds to sweat a few ms interaction speed for a thing you should be touching only a few times a day max. I'm buying the tool that has the best visibility and requires the least amount of interaction from me to get the information I need.
tommoor 1y ago
If you want to work on Linear's sync infrastructure or product – we're hiring. The day-to-day DX is incredible.
- theappsecguy 1y ago
  You should put pay bands on job listings to save everyone time and sanity.
- marmalar 1y ago
  I'm curious what the WLB is like?
CafeRacer 1y ago
We're using dexie+rxjs. A killer combination. Described here https://blog-doe.pages.dev/p/my-front-end-state-management-approach/ https://blog-doe.pages.dev/p/my-front-end-state-management-a... I've already made improvements to that approach. decoupling of backend and front end actually feels like you're reducing complexity.
- floydnoel 1y ago
  Are you using the cloud sync with Dexie? I built an app on it but it seems to have a hard time switching from local to cloud mode and vice versa. I’m not sure they ever thought people would want to but why bother making cloud set up calls for users that didn’t want it.
  - CafeRacer 1y ago
    Nope, locally. Roughly I'm doing something like that https://gist.github.com/vladmiller/0be83755e65cf5bd942ffba22be3ad35 https://gist.github.com/vladmiller/0be83755e65cf5bd942ffba22... Example is a bit bad, but roughly shows how we're using. I have built a custom sync API that accepts in the body a list of <object_id>:<short_hash> and returns a kind of json-list in a format <id>:<hash>:<json_object>\n <id>:<hash>:<json_object>\n API compares what client knows vs. current state and only returns the objects that were updated/created and separately objects that were removed. Not ideal for large collections (but then again why did I store 50mb of historical data on the client in the first place? :D)
sergioisidoro 1y ago
I really like electric approach and it has been on my radar for a long time, because it just leaves the writing complexity to you and the API. Most of the solutions with 2 way sync I see work great in simple rest and hobby "Todo app" projects. Start adding permissions and evolving business logic, migrations, growing product and such, and I can't see how they can hold up for very long. Electric gives you the sync for reads with their "views", but all writes still happen normally through your existing api / rest / rpc. That also makes it a really nice tool to adopt in existing projects.
rylan-talerico 1y ago
I'm a big fan of local-first. InstantDB has productized it – worth looking into if you're interested in taking a local-first approach.
jeremy_k 1y ago
Not a lot of mention for the collaboration aspect that local first / sync engines enabled. I've been building a project using Zero that is meant to replace a Google Sheet a friend of mine uses for his business. He routinely gets on a Google Meet with a client, they both open the Sheet and then go through the data. Before the emergence of tools like Zero I wouldn't have ever considered attempting to recreate the experience of a Google Sheet in a web app. I've previously built many live updating UIs using web sockets but managing that incoming data and applying it to the right area in the UI is not trivial. Take that and multiply it by 1000 cells in a Sheet (which is the wrong approach anyway, but it's what I knew how to build) and I can only imagine the mess of code. Now with Zero, I write a query to select the data and a mutator to change the data and everything syncs to anyone viewing the page. It is a pleasure to work with and I enjoy building the application rather than sweating dealing with applying incoming hyper specific data changes.
thruflo 1y ago
> Electric’s approach is compelling given it works with existing Postgres databases. However, one gap remains to fill, how to handle mutations? Just to note that, with TanStack DB, Electric now has first class support for local writes / write-path sync using transactional optimistic mutations: https://electric-sql.com/blog/2025/07/29/local-first-sync-with-tanstack-db#transaction-mutations https://electric-sql.com/blog/2025/07/29/local-first-sync-wi...
nicoritschel 1y ago
I've been down this rabbit hole as well. Many of the sync projects seem great at first glance (and are very impressive technically) but perhaps a bit idealistic. Reactive queries are fantastic from a dx perspective, but any of the "real" databases running in the browser like sqlite or pglite store database pages in IndexedDB as there are some data longevity issues with OPFS (IIRC Safari aggressively purges this with a week of inactivity). Maybe the solution is just storing caches in the users' home directory with the filesystem api, like a native application. Long story short, if requirements aren't strictly real time collaborative and online-enabled, I've found rolling something yourself more in the vein of a "fat client" works pretty well too for a nice performance boost. I generally prefer using IndexedDB directly— well via Dexie, which has reactive query support.
bob1029 1y ago
I'm all-in on SSR. The client shouldn't have any state other than the session token, current URL and DOM. Networks and servers will only get faster. Speed of light is constant, but we aren't even using its full capabilities right now. Hollow core fiber promises upward of 30% reduction in latency for everyone using the internet. There are RF-based solutions that provide some of this promise today. Even ignoring a wild RTT of 500ms, a SSR page rendered in 16ms would feel relatively instantaneous next to any of the mainstream web properties online today if delivered on that connection. I propose that there is little justification to take longer than a 60hz frame to render a client's HTML response on the server. A Zen5 core can serialize something like 30-40 megabytes of JSON in this timeframe. From the server's perspective, this is all just a really fancy UTF-8 string. You should be measuring this stuff in microseconds, not milliseconds. The transport delay being "high" is not a good excuse to get lazy with CPU time. Using SQLite is the easiest way I've found to get out of millisecond jail. Any hosted SQL provider is like a ball & chain when you want to get under 1ms. There are even browser standards that can mitigate some of the navigation delay concerns: https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API https://developer.mozilla.org/en-US/docs/Web/API/Speculation...
- packetlost 1y ago
  Latency is additive, so all that copper coax that and mux/demux in between a sizeable chunk of Americans and the rest of the internet means you're looking at a minimum roundtrip latency of 30ms if server is in the same city. Most users are also on Wi-Fi which adds and additional mux/demux + rebroadcast step that adds even more. And most people do not have the latest CPU. Not to mention mobile users over LTE. Sorry, but this is 100% a case of privileged developers thinking their compute infrastruction situation generalizes: it doesn't and it is a mistake to take shortcuts that assume as such.
  - markasoftware 1y ago
    uh have you ever tried pinging a server in your same city? It's usually substantially <30ms. I'm currently staying at a really shitty hotel that has 5mbps wifi, not to mention I'm surrounded by other rooms, and I can still ping 8.8.8.8 in 20ms. From my home internet, which is /not/ fiber, it's 10ms.
aboodman 1y ago
> Using Zero is another option, it has many similarities to Electric, while also directly supporting mutations. The core differentiator of Zero is actually query-driven sync. We apparently need to make this more clear. You build your app out of queries. You don't have to decide or configure what to sync up front. You can sync as much, or as little as you want, just by deciding which queries to run. If Zero does not have the data that it needs on the client, queries automatically fall back to the server. Then that data is synced, and available for next query. This ends up being really useful for: - Any reasonably sized app. You can't sync all data to client. - Fast startup. Most apps have publicly visible views that they want to load fast. - Permissions. Zero doesn't require you to express your permissions in some separate system, you just use queries. So the experience of using Zero is actually much closer to a reactive db, something like Convex or RethinkDB (). Except that it uses standard Postgres, and you also get the instant interactions of a sync engine.
- deleted 1y ago
  [deleted]
JusticeJuice 1y ago
I remember being literally 12 when google docs was launched, which featured real-time sync, and a collaborative cursor. I remember thinking that this is how all web experience will be in the future, at the time 'cloud computing' was the buzzword - I (incorrectly) thought realtime collaboration was the very definition of cloud computing. And then it just... never happened. 20 years went by, and most web products are still CRUD experiences, such as this site included. The funny thing is it feels like it's been on the verge of becoming mainstream for all this time. When meteor.js got popular I was really excited, and then with react surely it was gonna happen - but even now, it's still not the default choice for new software. I'm still really excited to see it happen, and I do think it will happen eventually - it's just trickier than it looks, and it's tricky to make the tooling so cheap that it's worth it in all situations.
- levmiseri 1y ago
  I feel the same way. The initial magic of real-timeness felt like a glimpse into a future that... where is it? I'm still excited about the prospects of it — shameless plug: actually building a tool with one-of-a-kind messaging experience that's truly real-time in the Google docs collaboration way (no compose box, no send button): https://kraa.io/hackernews https://kraa.io/hackernews
  - nwienert 1y ago
    Agreed, I did a talk about exactly this earlier this year: https://www.youtube.com/watch?v=RjV3Dm5giko https://www.youtube.com/watch?v=RjV3Dm5giko
    - JusticeJuice 1y ago
      Interesting talk. I think it's just a matter of making tooling where it's so easy, cheap, and simple enough that doing realtime doesn't introduce any extra time cost to a business compared to CRUD.
  - JusticeJuice 1y ago
    That's a really cool project! The realtime message aspect reminds me a bit of https://honk.me/ https://honk.me/, but for like, docs.
_aobj 1y ago
Check out "Distributed Quantum Computing across an optical network link" by D.Main. Et Al. 2024. As it seems that the goals of Linear, are closely aligned with distributed Quantum Computing. Having decided I need a distributed Website with quantum entanglement. For my Web shop to sell "Federation Crypto currency" I find this post very instructive, towards that goal. " It is possible to use so little javascript and css that it makes more sense to inline it. SSR enables this " Does this imply compile time goals of browser are potentially compatible with a Distributed Quantum Computing Website? a local-first approach
nchmy 1y ago
Local first is fantastic. But something that I can't figure out is why the OG of local first, RxDB, never gets any love. As far as I can tell, it's VASTLY more capable than all of these new options. It has full-text search, all sorts of query optimizations, different storage backends in both the browser and server, and more.
- fredguth 1y ago
  RxDB is the OG? I thought it was PouchDB.
  - nchmy 1y ago
    Fair enough, rxdb was originally built on pouchdb, but now doesn't support it anymore since that project has a lot of issues. https://rxdb.info/rx-storage-pouchdb.html https://rxdb.info/rx-storage-pouchdb.html My point/question still stands though - rxdb seems to be vastly more capable than all of the new tools that get all the attention. Very peculiar
    - jFriedensreich 1y ago
      rxdb has a toxic license and tried to do too much in too many different ways and does things like have open source components that are just working worse and are slower. its something that a lot of people were appalled by including me. they also changed so much it was hard to keep track of how things actually worked. pouchdb is definitiely the OG local first database, and it inspired rxdb and was the core of it for a long time. it has definitely flaws mainly the developer ergonomics and not very up to date and non homogenic ecosystem. my feeling is non of these issues were the reaason rxdb parted ways, they could just have decided to > contribute < by fixing them and improving, but that would not have allowed them to create moat that they can enforce users switching to pro feautures with.

467 points by jcusch 1y ago

ivape 1y ago

[flagged]

jcusch 1y ago
An ad for what? I'm not associated with any of the projects mentioned.
- ivape 1y ago
  An ad for Linear.
  - defrost 1y ago
    If it's an ad for Linear why is so much text spent on Electric SQL, Zero, and Jazz?
    - ivape 1y ago
      [flagged]
      - mrkeen 1y ago
        In that worldview, it's unthinkable that you'd come and warn us about ads out of the goodness of your own heart. Who paid you for these comments? Atlassian?
        mattsahr 1y ago
        That's an interesting question. I will open a Jira ticket to schedule a meeting with the Product Team, and they will assign you several stories with acceptance criteria written by AI.
      - ramon156 1y ago
        Do elaborate, u made me curious
dewey 1y ago
It’s a developer writing about a tool they like. If you’d call word of mouth an “ad” the I guess it’s one.
- ivape 1y ago
  Why do you think marketing is not sophisticated? Here I’ll offer my services. I’ll pretend to do a technical deep dive of your app for X amount. No one will know, I’ll just act super interested. When the fuck did anyone ever go “omg this web app so impressive”, never, ever, never, ever.
  - dewey 1y ago
    It’s a choice to always see the worst in everything. Many blog post submissions here are someone diving into something they like, hardware, software, tool etc. and it’s just because people like to share.
    - Fnoord 1y ago
      Yep, but LLMs being used as aid in writing blog posts is a relatively new phenomenon. I'm on the fence. IMO ivape provides a hypothesis, but brings it as fact. That isn't a good starting point for a discussion (though a common mistake), but that doesn't prove they are wrong either. Btw, I believe the HN guidelines encourage you to take the positive angle, at least for comments. As for the topic at hand local-first means he end up with a cache; either in memory or on disk. If you got the RAM and NVMe you might as well use it for performance. Back in the days not much could be cached, but your connection was often too lousy or not 24/7. So you ended up with software distribution via 3.5 inch floppies or CDROM. Larger distributions used gigantic disk cache either centralized (Usenet) or distributed (BitTorrent). But the 'you might as well use it' issue is it introduces sloppiness. If you develop with huge constraints you are disciplined into deterrence to start, failing, or succeeding efficiently. We hary ever hear about all the deterrence and failing.
  - theglenn88_ 1y ago
    [flagged]
deleted 1y ago
[deleted]
yard2010 1y ago
Best kind of ad to the best kind of service (I'm not affiliated, this is not an ad) - an organic one. The enshitification that Jira went through is by itself an ad for Linear.

Gravityloss 1y ago

Some problem on the site. Too much traffic? Secure Connection Failed An error occurred during a connection to bytemash.net. PR_END_OF_FILE_ERROR Error code: PR_END_OF_FILE_ERROR

jcusch 1y ago
It looks like I was missing a www subdomain CNAME for the underlying github pages site. I think it's fixed now.
- Gravityloss 1y ago
  I still see the same error
  - Gravityloss 1y ago
    Ok, it works, problem was probably on my end.

deleted 1y ago

[deleted]

mbaranturkmen 1y ago

How is this approach better than using react-query to persist storage which periodically sync the local storage and the server storage? Perhaps I am missing something.

petralithic 1y ago
That approach is precisely what the new TanStack DB does, which if you don't know already has the same creator as React Query. The former extends the latter's principles to syncing, via ElectricSQL, both organizations have a partnership with each other.
0xblinq 1y ago
Yes, you’re missing a lot of things. Like how to update that data when you are offline and have everything sync around when others have made updates to the same data in the meanwhile. Among many other concerns and use cases.

petralithic 1y ago

ElectricSQL and TanStack DB are great, but I wonder why they focus so much on local first for the web over other platforms, as in, I see mobile being the primary local first use case since you may not always have internet. In contrast, typically if you're using a web browser to any capacity, you'll have internet. Also the former technologies are local first in theory but without conflict resolution they can break down easily. This has been from my experience making mobile apps that need to be local first, which led me to using CRDTs for that use case.

jitl 1y ago
Because building local first with web technologies is like infinity harder than building local first with native app toolkits. Native app is installed and available offline by default. Website needs a bunch of weird shenanigans to use AppManifest or ServiceWorker which is more like a bunch of parts you can maybe use to build available offline. Native apps can just… make files, read and write from files with whatever 30 year old C code, and the files will be there on your storage. Web you have to fuck around with IndexedDB (total pain in the ass), localStorage (completely insufficient for any serious scale, will drop concurrent writes), or OriginPrivateFileSystem. User needs to visit regularly (at least once a month?) or Apple will erase all the local browser state. You can use JavaScript or hit C code with a wrench until it builds for WASM w/ Emscripten, and even then struggle to make sync C deal with waiting on async web APIs. Apple has offered CoreData + CloudKit since 2015, a completed first party solution for local apps that sync, no backend required. I’m not a Google enthusiast, maybe Firebase is their equivalent? Idk.
- agos 1y ago
  and if you didn't like or cared to learn CoreData? just jam a sqlite db in your application and read from it, it's just C. This was already working before Angular or even Backbone
- mike_hearn 1y ago
  Well .... that's all true, until you want to deploy. Historically deploying desktop apps has been a pain in the ass. App stores barely help. That's why devs put up with the web's problems. Ad: unless you use Conveyor, my company's product, which makes it as easy as shipping a web app (nearly): https://hydraulic.dev/ https://hydraulic.dev/ You are expected to bring your own runtime. It can ship anything but has integrated support for Electron and JVM apps, Flutter works too although Flutter Desktop is a bit weak.

incorrecthorse 1y ago

> For the uninitiated, Linear is a project management tool that feels impossibly fast. Click an issue, it opens instantly. Update a status and watch in a second browser, it updates almost as fast as the source. No loading states, no page refreshes - just instant, interactions. How garbage the web has become for a low-latency click action being qualified as "impossibly fast". This is ridiculous.

jitl 1y ago
A web request to a data center even with a very fast backend server will struggle to beat 8ms (120hz display) or even 16ms (60hz display), the budget for next frame painting a navigation. You need to have the data local to the device and ideally already in memory to hit 8ms navigation.
- ahofmann 1y ago
  This is not the point, or other numbers matter more, then yours. In 2005 we wrote entire games for browsers without any frontend framework (jQuery wasn't invented yet) and managed to generate responses in under 80 ms in PHP. Most users had their first bytes in 200 ms and it felt instant to them, because browsers are incredibly fast, when treated right. So the Internet was indeed much faster then, as opposed to now. Just look at GitHub. They used to be fast. Now they rewrite their frontend in react and it feels sluggish and slow.
  - Zanfa 1y ago
    > Now they rewrite their frontend in react and it feels sluggish and slow. And decided to drop legacy features such as <a> tags and broke browser navigation in their new code viewer. Right click on a file to open in a new tab doesn’t work.
  - DanielHB 1y ago
    Unless you are running some really complicated globally distributed backend your roundtrip will always be higher than 80ms for all users outside your immediate geographical area. And the techniques to "fix" this usually only mitigate the problem in read-scenarios. The techniques Linear uses are not so much about backend performance and can be applicable for any client-server setup really. Not a JS/web specific problem.

mkarliner 1y ago

Meteor was/is a very similar technology. And I did some fairly major projects with it.

mentalgear 1y ago
Meteor was amazing, I don't understand why it never got sustainable traction.
- dustingetz 1y ago
  non-relational, document oriented pubsub architecture based on MongoDB, good for not much more than chat apps. For toy apps (in 2012-2016) – use firebase (also for chat apps), for crud-spectrum and enterprise apps - use sql. And then React happened and consumed the entire spectrum of frontend architectures, bringing us to GraphQL, which didn't, but the hype wave left little oxygen remaining for anything else. (Even if it had, still Meteor was not better.)
  - vlasky 1y ago
    I'm the defacto maintainer of the Meteor MySQL integration. Since 2015, I've been involved in the design and maintenance of six different Meteor webapps for real-time geospatial applications built for B2B and B2C. Given this, I reject your assertion that Meteor is limited to MongoDB and "toy apps".
    - deleted 1y ago
      [deleted]
    - deleted 1y ago
      [deleted]
- h4ch1 1y ago
  Seems like meteor is still actively developed and is Framework agnostic! https://github.com/meteor/meteor https://github.com/meteor/meteor
- 1y ago

terencege 1y ago

I'm also building a local first editor and rolling my own CRDTs. There are enormous challenges to make it work. For example the storage size issue mentioned in the blog, I end up using with yjs' approach which only increase the clock for upsertion, and for deletion remove the content and only remain deleted item ids which can be efficiently compressed since most ids are continuous.

jddj 1y ago
In case you missed it and it's relevant, there was an automerge v3 announcement posted the other day here which claimed some nice compression numbers as well
- terencege 1y ago
  As far as I know, automerge is using DAG history log and garbage collecting by comparing the version clock heads of 2 clients. That is different than yjs. I have not followed their compression approach in v3 yet, will check if having time.

mentalgear 1y ago

Local-First & Sync-Engines are the future. Here's a great filterable datatable overview of the local-first framework landscape: https://www.localfirst.fm/landscape https://www.localfirst.fm/landscape My favorite so far is Triplit.dev (which can also be combined with TanStack DB); 2 more I like to explore are PowerSync and NextGraph. Also, the recent LocalFirst Conf has some great videos, currently watching the NextGraph one (https://www.youtube.com/watch?v=gaadDmZWIzE https://www.youtube.com/watch?v=gaadDmZWIzE).

virgil_disgr4ce 1y ago
Thank you for this, I'm going to have to check out Triplit. Have you tried InstantDB? It's the one I've been most interested in trying but haven't yet.
rogerkirkness 1y ago
Reminds me of Meteor back in the day.
- 8n4vidtmkvmk 1y ago
  Whatever happened to meteor? They made it sound so great. What I didn't like was the tight coupling to mongodb.
  - explorigin 1y ago
    For me it was the lack of confirmation with the backend. When it was the next big thing, it sent changes to the backend without waiting for a response. This made the interface crazy fast but I just couldn't take the risk of the FE being out-of-sync with the backend. I hope they grew out of that model but I never took it serious for that one reason.
    - rogerkirkness 1y ago
      Yeah I built my first startup on Meteor, and the prototype for my second one, but there was so many weird state bugs after it got more complicated that we had to eventually switch back to normal patterns to scale it.

Cassandra99 1y ago

I developed an open-source task management software based on CRDT with a local-first approach. The motivation was that I primarily manage personal tasks without needing collaboration features, and tools like Linear are overly complex for my use case. This architecture offers several advantages: 1. Data is stored locally, resulting in extremely fast software response times 2. Supports convenient full database export and import 3. Server-side logic is lightweight, requiring minimal performance overhead and development complexity, with all business logic implemented on the client 4. Simplified feature development, requiring only local logic operations There are also some limitations: 1. Only suitable for text data storage; object storage services are recommended for images and large files 2. Synchronization-related code requires extra caution in development, as bugs could have serious consequences 3. Implementing collaborative features with end-to-end encryption is relatively complex The technical architecture is designed as follows: 1. Built on the Loro CRDT open-source library, allowing me to focus on business logic development 2. Data processing flow: User operations trigger CRDT model updates, which export JSON state to update the UI. Simultaneously, data is written to the local database and synchronized with the server. 3. The local storage layer is abstracted through three unified interfaces (list, save, read), using platform-appropriate storage solutions: IndexedDB for browsers, file system for Electron desktop, and Capacitor Filesystem for iOS and Android. 4. Implemented end-to-end encryption and incremental synchronization. Before syncing, the system calculates differences based on server and client versions, encrypts data using AES before uploading. The server maintains a base version with its content and incremental patches between versions. When accumulated patches reach a certain size, the system uploads an encrypted full database as the new base version, keeping subsequent patches lightweight. If you're interested in this project, please visit https://github.com/hamsterbase/tasks https://github.com/hamsterbase/tasks

b_e_n_t_o_n 1y ago
very cool!

preaching5271 1y ago

Automerge + Keyhive is the future https://www.inkandswitch.com/project/keyhive/ https://www.inkandswitch.com/project/keyhive/

minikomi 1y ago

My kingdom for a team organised by org mode files through a got repo

yanis_t 1y ago

I don't get it. You still have to sync the state one way or another, network latency is still there.

Aldipower 1y ago
Me neither. Considered we are talking about collaborative network applications, you are loosing the single-source-of-thruth (the server database) with the local first approach. And it just adds so much more complexity. Also, as your app grows, you probably end up to implement the business logic twice. On the server and locally. I really do not get it.
- jitl 1y ago
  You can use the same business logic code on both the client and server. With the Linear approach, the server remains the source of truth.
  - foldr 1y ago
    It’s difficult to ensure that it’s always the same logic when client and server software versions can get out of sync. You can try to force the client to reload whenever the server redeploys, but realistically you’ll probably end up dealing with cases where the client and server logic diverge.
    - jitl 1y ago
      i mean that's life with client computers, you make stuff backwards compatible and you avoid making it too brittle.
      - foldr 1y ago
        It's not an insurmountable problem, but it's a problem that you don't have if you execute your business logic only on the server.
croes 1y ago

blixt 1y ago

I've been very impressed by Jazz -- it enables great DX (you're mostly writing sync, imperative code) and great UX (everything feels instant, you can work offline, etc). Main problems I have are related to distribution and longevity -- as the article mentions, it only grows in data (which is not a big deal if most clients don't have to see that), and another thing I think is more important is that it's lacking good solutions for public indexes that change very often (you can in theory have a public readable list of ids). However, I recently spoke with Anselm, who said these things have solutions in the works. All in all local-first benefits often come with a lot of costs that are not critical to most use cases (such as the need for much more state). But if Jazz figures out the main weaknesses it has compared to traditional central server solutions, it's basically a very good replacement for something like Firebase's Firestore in just about every regard.

ChadNauseam 1y ago
Yeah, Jazz is amazing. The DX is unmatched. My issue when I used it was, they mainly supported passkey-based encryption, which was poorly implemented on windows. That made it kind of a non-starter for me, although I'm sure they'll support traditional auth methods soon. But I love that it's end-to-end encrypted and it's super fun to use.

madisvain 1y ago

Local first is amazing. I have been building a local first application for Invoicing since 2020 called Upcount https://www.upcount.app/ https://www.upcount.app/. First I used PouchDB which is also awesome https://pouchdb.com/ https://pouchdb.com/ but now switched to SQLite and Turso https://turso.tech/ https://turso.tech/ which seems to fit my needs much better.

b_e_n_t_o_n 1y ago

Local first is super interesting and absolutely needed - I think most of the bugs I run into with web apps have to do with sync, exacerbated by poor internet connectivity. The local properties don't interest me as much as request ordering and explicit transactions. You aren't guaranteed that requests resolve in order, and thus can result in a lot of inconsistencies. These local-first sync abstractions are a bit like bringing a bazooka to a water gun fight - it would be interesting to see some halfway approaches to this problem.

croes 1y ago

But how is conflicting data handled? For instance one closes an something and another aborts the same thing.

qweiopqweiop 1y ago

It's starting to feel to me that a lot of tech is just converging on other platforms solutions. This for example sounds incredibly similar to how a mobile app works (on the surface). Of course it goes the other way too, with mobile tech taking declarative UIs from the Web.

10us 1y ago

Man why arent couchdb / pouchdb not listed? Still works like a charm!

jFriedensreich 1y ago
"Works like a charm" / "not listed" does not really do it justice, its much worse. All of the mentioned "solutions" will inevitably lose data on conflicts one way or another and i am not aware of anything from that school of thought, that has full control over conflict resolution as couchdb / pouchdb does. Apparently vibe coding crdt folks do not value data safety over some more developer ergonomics. It is an tradeoff to make for your own hobby projects if you are honest about it but i don't understand how this is just completely ignored in every single one of these posts.

antgiant 1y ago

I’ve been working on a small browser app that is local first and have been trying to figure out how to pair it with static hosting. It feels like this should be possible but so far the tooling all seems stuck in the mindset of having a server somewhere. My use case is scoring live events that may or may not have Internet connection. So normal usage is a single person but sometimes it would be nice to allow for multi person scoring without relying on centralized infrastructure.

swsieber 1y ago
Honestly, having used InstantDB (one of the providers listed in their post), I think it'd be a pretty nice fit. I've been writing a budget app for my wife and I and I've made it 100% free with 3rd party hosting: * InstantDB free tier allows 1 dev. That's the remote sync. * Netlify for the static hosting * Free private gitlab ci/cd for running some email notification polling, basically a poor mans hosted cron.
- antgiant 1y ago
  I may end up doing that, but I really wish there was a true p2p option that doesn’t have me relying on someone not rug pulling their free tier sync server.
  - swsieber 1y ago
    Yeah... true p2p is pretty hard though, to the point that even stuff like WebRTC requires external servers to setup the data sync portion. It would be nice to develop something that worked at that layer though. IIUC, InstantDB is open source with a docker container you can run yourself, but at this point it's designed to run in a more cloud-like environment than I'd like. Last time I checked there was at least one open PR to make it easier to run in a different environment, but I haven't check in recently.
    - antgiant 1y ago
      I spent some more time hunting due to this conversation and I’m hopeful that yjs + y-WebRTC + PeerJS will solve this. I also see that there are a few libraries that enable QR codes to replace PeerJS as a truly offline WebRTC initialization with true p2p connectivity. Looks quite promising

mizzao 1y ago

Is this technical architecture so different from Meteor back in the day? Just curious for those who have a deeper understanding.

sturza 1y ago

Local-first buys you instant UX by moving state to the client, and then makes everything else a little harder

captainregex 1y ago
this is such a clean and articulate way of putting it. The discussion around here the last few days about local and the role it is going to play has been phenomenal and really genuine
CharlieDigital 1y ago
> instant UX I do not get the hype. At all. "Local first" and "instant UX" are the least of my concerns when it comes to project management. "Easy to find things" and "good visibility" are far more important. Such a weird thing to index on. I might interact with the project management tool a few times a day. If I'm so frequently accessing it as an IC or an EM that "instant UX" becomes a selling point, then I'm doing something wrong with my day.
- virgil_disgr4ce 1y ago
  UI performance is "a weird thing to index on"?
  - CharlieDigital 1y ago
    Yes? If that's the primary selling point for a project manager versus being just a really damn good project manager with good visibility? I've never used a project manager and thought to myself "I want to switch because this is too slow". Even Jira. But I have thought to myself "It's too difficult to build a good workflow with this tool" or "It's too much work to surface good visibility". This is not a first-person shooter. I don't care if it's 8ms vs 50ms or even 200ms; I want a product that indexes on being really great at visibility. It's like indexing your buying decision for a minivan on whether it can do the quarter mile at 110MPH @ 12 seconds. Sure, I need enough power and acceleration, but just about any minivan on the market is going to do an acceptable and safe speed and if I'm shopping for a minivan, its 1/4 mile time is very low on the list. It's a minivan; how often am I drag racing in it? The buyer of the minivan has a purpose for buying the minivan (safety, comfort, space, cost, fuel economy, etc.) and trap speed is probably not one of them. It's a task manager. Repeat that and see how silly it sounds to sweat a few ms interaction speed for a thing you should be touching only a few times a day max. I'm buying the tool that has the best visibility and requires the least amount of interaction from me to get the information I need.

tommoor 1y ago

If you want to work on Linear's sync infrastructure or product – we're hiring. The day-to-day DX is incredible.

theappsecguy 1y ago
You should put pay bands on job listings to save everyone time and sanity.
marmalar 1y ago
I'm curious what the WLB is like?

CafeRacer 1y ago

We're using dexie+rxjs. A killer combination. Described here https://blog-doe.pages.dev/p/my-front-end-state-management-approach/ https://blog-doe.pages.dev/p/my-front-end-state-management-a... I've already made improvements to that approach. decoupling of backend and front end actually feels like you're reducing complexity.

floydnoel 1y ago
Are you using the cloud sync with Dexie? I built an app on it but it seems to have a hard time switching from local to cloud mode and vice versa. I’m not sure they ever thought people would want to but why bother making cloud set up calls for users that didn’t want it.
- CafeRacer 1y ago
  Nope, locally. Roughly I'm doing something like that https://gist.github.com/vladmiller/0be83755e65cf5bd942ffba22be3ad35 https://gist.github.com/vladmiller/0be83755e65cf5bd942ffba22... Example is a bit bad, but roughly shows how we're using. I have built a custom sync API that accepts in the body a list of <object_id>:<short_hash> and returns a kind of json-list in a format <id>:<hash>:<json_object>\n <id>:<hash>:<json_object>\n API compares what client knows vs. current state and only returns the objects that were updated/created and separately objects that were removed. Not ideal for large collections (but then again why did I store 50mb of historical data on the client in the first place? :D)

sergioisidoro 1y ago

I really like electric approach and it has been on my radar for a long time, because it just leaves the writing complexity to you and the API. Most of the solutions with 2 way sync I see work great in simple rest and hobby "Todo app" projects. Start adding permissions and evolving business logic, migrations, growing product and such, and I can't see how they can hold up for very long. Electric gives you the sync for reads with their "views", but all writes still happen normally through your existing api / rest / rpc. That also makes it a really nice tool to adopt in existing projects.

rylan-talerico 1y ago

I'm a big fan of local-first. InstantDB has productized it – worth looking into if you're interested in taking a local-first approach.

jeremy_k 1y ago

Not a lot of mention for the collaboration aspect that local first / sync engines enabled. I've been building a project using Zero that is meant to replace a Google Sheet a friend of mine uses for his business. He routinely gets on a Google Meet with a client, they both open the Sheet and then go through the data. Before the emergence of tools like Zero I wouldn't have ever considered attempting to recreate the experience of a Google Sheet in a web app. I've previously built many live updating UIs using web sockets but managing that incoming data and applying it to the right area in the UI is not trivial. Take that and multiply it by 1000 cells in a Sheet (which is the wrong approach anyway, but it's what I knew how to build) and I can only imagine the mess of code. Now with Zero, I write a query to select the data and a mutator to change the data and everything syncs to anyone viewing the page. It is a pleasure to work with and I enjoy building the application rather than sweating dealing with applying incoming hyper specific data changes.

thruflo 1y ago

> Electric’s approach is compelling given it works with existing Postgres databases. However, one gap remains to fill, how to handle mutations? Just to note that, with TanStack DB, Electric now has first class support for local writes / write-path sync using transactional optimistic mutations: https://electric-sql.com/blog/2025/07/29/local-first-sync-with-tanstack-db#transaction-mutations https://electric-sql.com/blog/2025/07/29/local-first-sync-wi...

nicoritschel 1y ago

I've been down this rabbit hole as well. Many of the sync projects seem great at first glance (and are very impressive technically) but perhaps a bit idealistic. Reactive queries are fantastic from a dx perspective, but any of the "real" databases running in the browser like sqlite or pglite store database pages in IndexedDB as there are some data longevity issues with OPFS (IIRC Safari aggressively purges this with a week of inactivity). Maybe the solution is just storing caches in the users' home directory with the filesystem api, like a native application. Long story short, if requirements aren't strictly real time collaborative and online-enabled, I've found rolling something yourself more in the vein of a "fat client" works pretty well too for a nice performance boost. I generally prefer using IndexedDB directly— well via Dexie, which has reactive query support.

bob1029 1y ago

I'm all-in on SSR. The client shouldn't have any state other than the session token, current URL and DOM. Networks and servers will only get faster. Speed of light is constant, but we aren't even using its full capabilities right now. Hollow core fiber promises upward of 30% reduction in latency for everyone using the internet. There are RF-based solutions that provide some of this promise today. Even ignoring a wild RTT of 500ms, a SSR page rendered in 16ms would feel relatively instantaneous next to any of the mainstream web properties online today if delivered on that connection. I propose that there is little justification to take longer than a 60hz frame to render a client's HTML response on the server. A Zen5 core can serialize something like 30-40 megabytes of JSON in this timeframe. From the server's perspective, this is all just a really fancy UTF-8 string. You should be measuring this stuff in microseconds, not milliseconds. The transport delay being "high" is not a good excuse to get lazy with CPU time. Using SQLite is the easiest way I've found to get out of millisecond jail. Any hosted SQL provider is like a ball & chain when you want to get under 1ms. There are even browser standards that can mitigate some of the navigation delay concerns: https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API https://developer.mozilla.org/en-US/docs/Web/API/Speculation...

packetlost 1y ago
Latency is additive, so all that copper coax that and mux/demux in between a sizeable chunk of Americans and the rest of the internet means you're looking at a minimum roundtrip latency of 30ms if server is in the same city. Most users are also on Wi-Fi which adds and additional mux/demux + rebroadcast step that adds even more. And most people do not have the latest CPU. Not to mention mobile users over LTE. Sorry, but this is 100% a case of privileged developers thinking their compute infrastruction situation generalizes: it doesn't and it is a mistake to take shortcuts that assume as such.
- markasoftware 1y ago
  uh have you ever tried pinging a server in your same city? It's usually substantially <30ms. I'm currently staying at a really shitty hotel that has 5mbps wifi, not to mention I'm surrounded by other rooms, and I can still ping 8.8.8.8 in 20ms. From my home internet, which is /not/ fiber, it's 10ms.

aboodman 1y ago

> Using Zero is another option, it has many similarities to Electric, while also directly supporting mutations. The core differentiator of Zero is actually query-driven sync. We apparently need to make this more clear. You build your app out of queries. You don't have to decide or configure what to sync up front. You can sync as much, or as little as you want, just by deciding which queries to run. If Zero does not have the data that it needs on the client, queries automatically fall back to the server. Then that data is synced, and available for next query. This ends up being really useful for: - Any reasonably sized app. You can't sync all data to client. - Fast startup. Most apps have publicly visible views that they want to load fast. - Permissions. Zero doesn't require you to express your permissions in some separate system, you just use queries. So the experience of using Zero is actually much closer to a reactive db, something like Convex or RethinkDB (). Except that it uses standard Postgres, and you also get the instant interactions of a sync engine.

deleted 1y ago
[deleted]

JusticeJuice 1y ago

I remember being literally 12 when google docs was launched, which featured real-time sync, and a collaborative cursor. I remember thinking that this is how all web experience will be in the future, at the time 'cloud computing' was the buzzword - I (incorrectly) thought realtime collaboration was the very definition of cloud computing. And then it just... never happened. 20 years went by, and most web products are still CRUD experiences, such as this site included. The funny thing is it feels like it's been on the verge of becoming mainstream for all this time. When meteor.js got popular I was really excited, and then with react surely it was gonna happen - but even now, it's still not the default choice for new software. I'm still really excited to see it happen, and I do think it will happen eventually - it's just trickier than it looks, and it's tricky to make the tooling so cheap that it's worth it in all situations.

levmiseri 1y ago
I feel the same way. The initial magic of real-timeness felt like a glimpse into a future that... where is it? I'm still excited about the prospects of it — shameless plug: actually building a tool with one-of-a-kind messaging experience that's truly real-time in the Google docs collaboration way (no compose box, no send button): https://kraa.io/hackernews https://kraa.io/hackernews
- nwienert 1y ago
  Agreed, I did a talk about exactly this earlier this year: https://www.youtube.com/watch?v=RjV3Dm5giko https://www.youtube.com/watch?v=RjV3Dm5giko
  - JusticeJuice 1y ago
    Interesting talk. I think it's just a matter of making tooling where it's so easy, cheap, and simple enough that doing realtime doesn't introduce any extra time cost to a business compared to CRUD.
- JusticeJuice 1y ago
  That's a really cool project! The realtime message aspect reminds me a bit of https://honk.me/ https://honk.me/, but for like, docs.

_aobj 1y ago

Check out "Distributed Quantum Computing across an optical network link" by D.Main. Et Al. 2024. As it seems that the goals of Linear, are closely aligned with distributed Quantum Computing. Having decided I need a distributed Website with quantum entanglement. For my Web shop to sell "Federation Crypto currency" I find this post very instructive, towards that goal. " It is possible to use so little javascript and css that it makes more sense to inline it. SSR enables this " Does this imply compile time goals of browser are potentially compatible with a Distributed Quantum Computing Website? a local-first approach

nchmy 1y ago

Local first is fantastic. But something that I can't figure out is why the OG of local first, RxDB, never gets any love. As far as I can tell, it's VASTLY more capable than all of these new options. It has full-text search, all sorts of query optimizations, different storage backends in both the browser and server, and more.

fredguth 1y ago
RxDB is the OG? I thought it was PouchDB.
- nchmy 1y ago
  Fair enough, rxdb was originally built on pouchdb, but now doesn't support it anymore since that project has a lot of issues. https://rxdb.info/rx-storage-pouchdb.html https://rxdb.info/rx-storage-pouchdb.html My point/question still stands though - rxdb seems to be vastly more capable than all of the new tools that get all the attention. Very peculiar
  - jFriedensreich 1y ago
    rxdb has a toxic license and tried to do too much in too many different ways and does things like have open source components that are just working worse and are slower. its something that a lot of people were appalled by including me. they also changed so much it was hard to keep track of how things actually worked. pouchdb is definitiely the OG local first database, and it inspired rxdb and was the core of it for a long time. it has definitely flaws mainly the developer ergonomics and not very up to date and non homogenic ecosystem. my feeling is non of these issues were the reaason rxdb parted ways, they could just have decided to > contribute < by fixing them and improving, but that would not have allowed them to create moat that they can enforce users switching to pro feautures with.