Live data from Hacker News

How's Linear so fast? A technical breakdown

performance.dev

81–90 of 250 posts

Re: How's Linear so fast? A technical breakdown

#81

Earlier quoted context omitted.

Edge case but playing devil’s advocate: a user can also uninstall the native app at any time, and might still expect their last change before they closed the app to be reflected in the web version. You can never truly trust anything about a client because by definition you don’t control it

But the os can't uninstall the native app at any time unprompted right

No, it’s definitely a lot less likely and probably an edge case you can ignore in practice

Re: How's Linear so fast? A technical breakdown

#82
Writing an eventually consistent database is hard, it maybe fine for Linear's use cases, but not knowing if my updates made it to the server (aka my team),is problematic. The sync lags have created untold problems in other projects I have worked for, so I always go for a synchronous solution. All the fancy stuff comes out only if it's absolutely needed. I'd rather optimize my server to be blazing fast, and have the user "suffer" network latency.

Re: How's Linear so fast? A technical breakdown

#84
This is neat. To be honest, I never considered Linear as "fast". Seemed laggy as most web apps, but in contrast to JIRA it's lightspeed of course. Linear is great though, a real refreshment after JIRA torture.

As for optimistic routes and "fast" - maybe we ought to talk gmail first?

Re: How's Linear so fast? A technical breakdown

#85
post #23

Last year a guy reverse engineered Linear's sync engine and published it on GitHub with a cool explainer. https://github.com/wzhudev/reverse-linear-sync-engine/blob/m...

Discussed at the time:

Reverse engineering of Linear's sync engine - https://news.ycombinator.com/item?id=44123131 - May 2025 (33 comments)

Re: How's Linear so fast? A technical breakdown

#86
We use Linear at work. I’m definitely in the minority, but I really struggle with the UX. I also wouldn’t call it fast. Sure the page technically loads reasonably quickly, but half the time I see numbers updating on the page with no visual indicator that data loading is still happening.

Re: How's Linear so fast? A technical breakdown

#87
post #53

Earlier quoted context omitted.

You can locate an "intermediary backend" on the client, write outstanding mutations into local storage, have a background worker send it to the backend, with necessary retries, etc. At worst, the background worker would put out a message about a failed update which the UI tread would receive and show. But the happy path stays lightning-fast.

Sure but there's a ton of complexity in any kind of local-first syncing solution. Often the solution is CRDTs. My point above is that the simple solution ("traditional CRUD app") is actually viable even when the goal is very low latency.

100% agree. A traditional CRUD app (like Linear) can be made pretty low latency without local-first. The complexity is not worth it.

Re: How's Linear so fast? A technical breakdown

#88
post #42
post #11

Whole blog post is basically: Make a mutation in the clientside, assume it worked, and save in the background.

Works for Linear because the tab stays open, and worse case if tab is closed you can recover later when the tab is opened again and deal with conflict resolution. Won't work if: 1. user clicks a button and closes the tab thinking transaction is done and it's important that transaction is done 2. conflict resolution is difficult or impossible in future client wake up

Still works if you use beacon requests, they survive tab close

Re: How's Linear so fast? A technical breakdown

#89

> Literally the first lines of code that I wrote was the sync engine, which is very uncommon to what you usually do when you're a startup He chose the path to a better product rather than the path to a quick buck. That is definitely odd for a silicon valley startup

Based on all the comments above, it is very debatable if it is a better product all said and done
Post reply on HN