Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linear sent me down a local-first rabbit hole

bytemash.net

Post reply on HN
Print view View original

121–130 of 228 posts

Re: Linear sent me down a local-first rabbit hole

#121

Post by virgil_disgr4ce »

CharlieDigital wrote: post #93
sturza wrote: post #86

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

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

UI performance is "a weird thing to index on"?

Re: Linear sent me down a local-first rabbit hole

#122

Post by rogerkirkness »

mentalgear wrote: post #27

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 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/wa…

Reminds me of Meteor back in the day.

Re: Linear sent me down a local-first rabbit hole

#123

Post by seanw265 »

ahofmann wrote: post #24
jitl wrote: post #21

Earlier quoted context omitted.

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.

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

> Now they rewrite their frontend in react and it feels sluggish and slow.

I find this is a common sentiment, but is there any evidence to find that React itself is actually the culprit of GH's supposed slowdown? GH has updated their architecture many times over and their scale has increased by orders of magnitude, quite literally serving up over a billion git repos.

Not to mention that the implementation details of any React application can make or break its performance.

Modern web tech often becomes a scapegoat, but the web today enables experiences that were simply impossible in the pre-framework era. Whatever frustrations we have with GitHub’s UI, they don’t automatically indict the tools it’s built with.

Re: Linear sent me down a local-first rabbit hole

#124

Post by jeremy_k »

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.

Re: Linear sent me down a local-first rabbit hole

#125

Post by thruflo »

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

Re: Linear sent me down a local-first rabbit hole

#126

Post by CharlieDigital »

virgil_disgr4ce wrote: post #121
CharlieDigital wrote: post #93

Earlier quoted context omitted.

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

UI performance is "a weird thing to index on"?

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.

Re: Linear sent me down a local-first rabbit hole

#127

Post by swsieber »

antgiant wrote: post #104
swsieber wrote: post #95

Earlier quoted context omitted.

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.

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.

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.

Re: Linear sent me down a local-first rabbit hole

#128

Post by 8n4vidtmkvmk »

presentation wrote: post #87
jallmann wrote: post #63

Earlier quoted context omitted.

Linear is actually so slow for me that I dread having to go into it and do stuff. I don’t care if the ticket takes 500ms to load, just give me the ticket and not a fake blinking cursor for 10 seconds or random refreshes while it (slowly) tries to re-sync. Everything I read about Linear screams over-engineering to me. It is just a ticket tracker, and a rather painful one to use at that. This seems to be endemic to the…

Yeah their startup times aren’t great. They’re making a trade off by loading a ton of data up front, though to be fair a lot of the local first web tooling didn’t really exist when they were founded - the nascent Zero Sync framework’s example project is literally a Linear clone that they use as their actual bug tracker, it loads way faster and has similarly snappy performance, so seems clear that it can be done bette…

Maybe it doesn't scale well then? I syncd my linear with GitHub. Has a few thousand issues. Lightning fast. Perhaps you guys have way more issues?

Re: Linear sent me down a local-first rabbit hole

#129

Post by nicoritschel »

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.

Re: Linear sent me down a local-first rabbit hole

#130

Post by 8n4vidtmkvmk »

layer8 wrote: post #82
m-s-y wrote: post #74

Earlier quoted context omitted.

150ms is sluggish? 4000ms is normal? The comments are absolutely wild in here with respect to expectations.

150 ms is definitely on the “not instantaneous” side: https://ux.stackexchange.com/a/42688 The stated 500 ms to 1500 ms are unfortunately quite frequent in practice.

I think under 400ms is fast enough for loading a new page or dialog. For loading search suggestions or opening a date picker or similar, probably not.
Post reply on HN