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

31–40 of 250 posts

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

#31

Post by Escapado »

jack_pp wrote: post #25
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!

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 - or what not to tell them.

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

#32

Post by [deleted] »

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…

[deleted]

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

#33

Post by jwr »

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 the Linear team. It's an impressive app.

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

#34

Post by jack_pp »

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

Well the sync engine can figure out if there's an issue fast, say Warn the user that if they leave the website their changes won't be saved remotely.

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

#35

Post by ianberdin »

lampe3 wrote: post #15
ianberdin wrote: post #9

Thanks for the read. It is a bit more complicated than you think. I completely rebuilt this sync engine + orm with relations, lazy loading etc, using Vue + Pinia in https://playcode.io . Google Linear’s videos, they explained in detail their architecture. Yes, I spent a few months. But it worth it. Every new field, model I need to add, it is so straightforward. I do love frameworks and foundations. They make live eas…

what google linear video?

https://m.youtube.com/watch?v=Wo2m3jaJixU&ra=m

https://m.youtube.com/watch?v=WxK11RsLqp4&t=2175s&pp=2AH_EJA...

These are original video. Very clear and a way better than the blog post.

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

#36

Post by wasmperson »

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 still show some indication that the operation hasn't completed. So in a chat app, for example, add the message to the list of messages, but with contrast reduced slightly to indicate that other people can't see it yet.

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

#37

Post by IshKebab »

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.

Yeah you can easily get this speed down to like 100ms which is near enough to instant to not matter. You definitely don't need to go to client side rendering for most things to feel fast.

Also I couldn't see any explanation of what happens when a network request fails. That's a huge downside of local rendering.

I think for most sites the best option is still server-side rendering but use a fast backend (e.g. not Python) and lightweight frontend.

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

#38

Post by hamandcheese »

jack_pp wrote: post #25
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!

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.

The issue that I foresee is that the point of error becomes decoupled from the UI and the UI doesn't handle a delayed error. Especially if retrofit into existing products.

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

#39

Post by ralferoo »

I've never used linear, but just watching their example video [1] would worry me if I was a user and it's actually doing what they say it's doing.

He creates a task called "Create faster app launch", if we believe the article, it's processing that locally rather than going via the server, and then it's allocated an ID "BRO-5". That the ID is so low suggests it's just adding one to the previous issue ID, and so under heavy load, there are almost certainly going to be conflicts with other users creating tasks and getting identical IDs. Even if the system resolves this by changing one of those IDs, the system shouldn't be presenting the ID to the user until it is guaranteed unique. What if they've already pasted it into a document when the system notices the collision and renumbers it?

[1] https://media.performance.dev/posts/p_gAMR6Z7y49Fp/NZrXs70M_...

EDIT: WTH, there are some seriously bad karma people in this thread - just because I dared to have an opinion that the approach taken by this software might not be the best, my post was downvoted in less than a minute after posting! I'm sure whoever did that carefully considered my argument. If I'm wrong, explain why, don't just downvote my comment. If I'm not wrong, shame on you.

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

#40

Post by WhyNotHugo »

pier25 wrote: post #24
syspec wrote: post #11

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

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.

Post reply on HN