Live data from Hacker News

How's Linear so fast? A technical breakdown

performance.dev

71–80 of 250 posts

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

#71

These kinds of local-first syncing web apps are really interesting and can be really useful, but I think the premise is somewhat wrong. "A few milliseconds is all it takes to update an issue in Linear. A traditional CRUD app doing the same thing takes about 300ms." "Any data sent between the client and server costs hundreds of milliseconds." There’s no solving the problem of a large RTT between an HTTP client and ser…

Thank you. Was beginning to feel like I was taking crazy pills seeing people claim that 300ms is fast when 30ms has been the target TTFB for as long as I can remember. Maybe Linear takes more time on the backend for totally valid reasons and it needs some help from the frontend, but that's not generalizable, and every bit of JS comes with its own costs.

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

#73

In gamedev, "optimistic updates" are called "client-side prediction," and are a standard part of multiplayer games. IMO it's somewhat risky to apply the technique to web-apps, since each network request typically corresponds to some important operation, and optimistically updating the UI is lying to the user about whether that operation completed successfully. IMO a good approach is to update the UI immediately but s…

I see this comment over and over again, yet I know lots of Linear-enthusiastic people and none is suffering of this.

Meanwhile after a brief period of Jira being performant, it has felt into ruin again.

In any case, I've tried both, and Jira is on another whole level when it comes to map processes of different teams.

Linear is a good looking toy mostly catered to the average software engineering team, it just doesn't support the flow complexity needed by different business units.

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

#74
post #5

funny how things come back. I loved meteorjs and its still my fav framework to this day. Seeing optimistic ui and browser based databases being used this way makes me happy. I would like to understand how they do the chunking and only updating part of the graph instead all of it.

Had to scroll this far to see meteors being mentioned. It was the first framework I started my js journey with.

And it was doing exactly what is described here, using a reimplementation of mongodb, in the frontend: minimongo.

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

#75
post #63
post #11

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

I believe this is called “eventual consistency”.

No, because if a transaction fails it still needs to be handled by the user in many cases.

E.g. if you buy a book, but it turns out the book was already sold, then you will first get a message "Your book is on its way!" and then "Oops, sorry, the book was already sold to someone else".

Eventual consistency is just a property of the database.

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

#76
post #64
post #43

Earlier quoted context omitted.

Changes go through and synced to everyone on your team in almost realtime. If there's a conflict on the server and your change cannot be applied (almost never happens), your change is rolled back on your client, again, almost in realtime. If servers cannot be reached, we will show you a syncing badge within 4 seconds to tell you that you have made changes that haven't been sent to others yet. Strange that we can be s…

As a user, I like when things appear to sync instantly and perfectly, such as in Google Docs. As a developer, I hated the article and many of the comments I read thus far because: - Having clients and a server properly sync and not lose data in the event of a network failure amounts to having a consistent distributed system which is not easy to do, and the commenters don't seem to have understood that - I hate having…

In the case of a partition the client nodes get temporarily out of sync but the system will then synchronise to one state again once the partition is resolved if it’s written correctly.

So no violation of CAP theorem it just prioritises liveness over consistency

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

#77
post #33

Linear is the best web app I have ever seen, period. It is also the best bug-tracker I've ever used. I use it, and pay for it (gladly). It's worth it. I am genuinely impressed with their engineering and design — I aspire to attain these levels, though I lack not only the skills, but also several zeroes in my bank account, I think. Still, it's worth looking at what they do and try to get there! Big props and kudos to…

Jira might be a technological disaster I hate with all of my guts, but as a product, it's on a completely different level than Linear.

Seriously, I hate it, but I've worked in most other competing products, from Trello to Azure Devops to Linear, Jira is a much more powerful engine that can be easily adapted to large organizations where each team has very different processes.

What works for a software team, does not work for sales, which does not work for HR, which does not work for QA or business development. Jira is flexible enough that can accomodate any kind of operation. Linear is like a very small and catchy subset of it.

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

#79
post #44

Earlier quoted context omitted.

> There's guaranteed persistence There's not. Browsers can delete "persistent" storage at any time. https://developer.mozilla.org/en-US/docs/Web/API/Storage_API...

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

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

#80
post #11

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

I agree. To each their own, but the UI updating automatically doesn't really add much value to me. I would prefer that the view I am seeing is a snapshot in time of what the ground truth server was, not some mixed state that forces me to consider the possibility that seeing my request go through on the screen doesn't actually mean it went through and has been sent to the server.

The goal is - and I think they have achieved it - is that you don't have to think about it. They handle sync, and they do it reliably.
Post reply on HN