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

41–50 of 250 posts

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

#41

Post by ggambetta »

wasmperson wrote: post #36

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 was thinking exactly the same thing, this is CSP/SR. One of my favorite topics! https://gabrielgambetta.com/client-server-game-architecture....

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

#42

Post by mohsen1 »

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

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

#43

Post by artman »

prerok wrote: post #22
syspec wrote: post #11

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

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 so be polar opposites on this. You hate it, I would never write an app in any other way, ever again.

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

#44

Post by pier25 »

WhyNotHugo wrote: post #40
pier25 wrote: post #24

Earlier quoted context omitted.

For native apps this is less of an issue since they have access to persistent storage but with browsers there's no guaranteed persistence.

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

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

#45

Post by artman »

Escapado wrote: post #31
jack_pp wrote: post #25

Earlier quoted context omitted.

Don't you have the same problems with basic CRUD apps? Also you need to handle the sad path for every single request instead of having the sync engine do it all in one place.

Correct but the feedback is usually more immediate. Save a change to your issue and it fails - You will get an error toast and probably stay on the form. In the local first world you might have navigated away already and created 3 more issues of which 2 more failed because of schema drift or other conflicts. And you might have edited one that was deleted. And now you need to figure out what exactly to tell the user -…

In reality conflicts almost never happen.

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

#47

Post by apsurd »

jwr wrote: 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…

Interestingly, as a professional developer I had the opposite first experience. It's a tracker. It looks like every other tracker. Everything is really small and "clean" which means they just hide everything, for that modern look.

I was thoroughly unimpressed. "This is it?" - "It's a tracker"

I feel comfortable saying this because in the weeks after, actually using it is the aha experience. Linear nailed the UX of working where people already work. Which again is really funny because the best part of Linear is how well it works outside of Linear.

(disclaimer: I actually now use their UI a lot. It's a helpful dashboard. But it suffers from every other hard-problem of information dense task-based dashboards.)

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

#49

Post by jeffbee »

This is bizarrely laudatory. The app is fast because it is not correct. The user has no way to know if their view is consistent with any other user's view. The user has no way to know if the app silently discarded one of their inputs because of a conflict. Linear developers seem to believe that silent data loss is an acceptable cost for maintaining the illusion of speed.

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

#50

Post by artman »

wasmperson wrote: post #36

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…

Operations are on average applied within a few hundred milliseconds, and almost never fail. Because of this we treat the success path as default, and indicate that your changes haven't been applied only if we detect that you're offline, or if it takes more than 4 second to apply the changes.
Post reply on HN