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

How's Linear so fast? A technical breakdown

performance.dev

Post reply on HN
Print view View original

51–60 of 250 posts

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

#51

Post by 12_throw_away »

pier25 wrote: post #44
WhyNotHugo wrote: post #40

Earlier quoted context omitted.

There's guaranteed persistence, but there's no guarantee that the host will be up anytime soon. E.g.: I might leave a final reply with all the details on an issue before going on vacation (or maybe I don't work the next day but my colleagues abroad do!). I see that it's properly posted and close the laptop. The reply with be delayed by days or weeks, but the UI indicated that it had been properly saved.

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

It depends. From the link:

> If, for any reason, developers need persistent storage [...] they can do so by using the navigator.storage.persist() method of the Storage API.

This makes a request for guaranteed permanent storage ... which can be approved (or denied) by the user or by browser defaults.

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

#52

Post by subygan »

cuechan wrote: post #10

> A traditional CRUD app doing the same thing takes about 300ms. 300ms seems like a lot. Even if this includes the whole http request+response it still seems unbelievably long.

this is kinda missing the point. yes, the raw http calls __should__ be enough for 300ms.

but the benchmark is similar software like JIRA, which takes agonizingly long to do anything reasonable.

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

#53

Post by nine_k »

jacobgold wrote: post #13

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…

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.

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

#54

Post by porridgeraisin »

artman wrote: post #43
prerok wrote: post #22

Earlier quoted context omitted.

Indeed. I have to say, I hate this. Suppose you are in a meeting, you update something and you see the result, but the rest of the team does not. Ok, a couple of hundred ms does not play into this but if the update does not make it through? And yes, it happens.

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…

(curious) What if a user closes it before 4 seconds? Ctrl+enter, it optimistically locally updates within 1 second. I close ctrl+w. But my wifi goofed and it didn't reach the server.

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

#55

Post by nine_k »

mohsen1 wrote: post #42
syspec wrote: 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

The user clicks the button, the mutation is stored in local storage. The user closes the tab, but it's not a problem.

A background worker picks up the mutation and sends it to the remote backend. It takes time, retries, etc.

Similarly, any errors reported by the background worker go to local store, and the next time the UI tab is loaded / activated, they are shown. A service worker can show a notification outright to let the user easily load the main UI. Normally this would be a rare occasion.

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

#56

Post by nilirl »

Am I the only that doesn't "get" Linear? Even if speed is the killer feature, isn't an issue tracker a relatively low-frequency application for a dev?

Whenever I use it, I don't feel like I'm doing anything new when compared to all the other issue trackers and Kanban boards I've used before.

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

#57

Post by 12_throw_away »

hamandcheese wrote: post #19

I worry that optimistic updates is going to become trendy and applied to more software, but without any plan for the "sad path" - failed to sync, sync conflict, etc. Get ready for a whole new era of race conditions and frustration!

> optimistic updates [...] without any plan for the "sad path"

based on my experience, this is a great description of the sync implementation in many already widely deployed products (say, off the top of my head, OneNote, OneDrive)

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

#58

Post by ambicapter »

nilirl wrote: post #56

Am I the only that doesn't "get" Linear? Even if speed is the killer feature, isn't an issue tracker a relatively low-frequency application for a dev? Whenever I use it, I don't feel like I'm doing anything new when compared to all the other issue trackers and Kanban boards I've used before.

I honesty can’t say it’s better than Jira, the myriad options just make it a confusing mess to figure out how to navigate and put stuff (could be my company is just hella disorganized), and the GitHub tracking is annoyingly eager (just because the first PR has been merged doesn’t mean the ticket is done).

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

#59

Post by jacobgold »

nine_k wrote: post #53
jacobgold wrote: post #13

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…

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.

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

#60

Post by Onavo »

mohsen1 wrote: post #42
syspec wrote: 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

Yes and for linear (if you break it down strictly in a theoretical CS sense, is roughly equivalent to TodoMVC in terms of application complexity assuming non-collaborative text editing) they have clearly defined states for most items and few if none truly destructive actions. The hardest part is anything text related.
Post reply on HN