Live data from Hacker News

How's Linear so fast? A technical breakdown

performance.dev

21–30 of 250 posts

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

#21
I'm glad to see more positive takes on client-side rendering. Unless SEO and crawlability are important for your site, server side rendering is such an overprescribed solution. If I put my tin-foil hat on, I'd say it gets a lot of attention because it's a lot easier to charge people for server time spent in SSR that you just don't have in CSR.

Bottom line is, if your app's content is behind a login screen, just use client side rendering. It is way lower complexity and a way better user experience.

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

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

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

#25

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.

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

#26

I’ve actually found Linear to be quite slow? There was a week where it would also spin at 100% CPU if I left a tab with it open for a while :(

It appears to use a lot of memory too, at least in Firefox. I can't have more than a few Linear tabs open at a time.

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

#27
Honestly you can POST to an API to the other side of the world and receive a response in less than 300ms. That's literally the blink of an eye. There are very few use cases where you'd need even lower latency than that while at the same time sacrificing reliability (there's no guaranteed persistent storage in a browser).

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

#28
I love using linear and where applicable I try to use optimistic updates in the applications I build too and I think it's a good article that touches on the most important aspects of a performant web app of that caliber.

One thing I would like to point out though is that building a performant sync engine that behaves the way you would like in most cases is a non-trivial thing.

If two users are offline and add, edit, remove issues and come online again, you need to reason about what happens. Sometimes you can get away with Last Writer Wins but what happens if an issue is deleted and then edited. What happens if an item in a list gets re-ordered differently on different clients, what's the final ordering? In which cases can you merge what state and in which do you need to discard something. Do you show a conflict resolution UI? How do you deal with rollbacks. How do you deal with schema drift and updates on items that would be affected by schema drift? Business logic might change between being reconnects. FK constraints can shift. Can you set up your data and the sync engine so that it only syncs the minimum amount of changes and batches them correctly during longer offline sessions so you don't fire 5000 change requests after reconnecting?

I recently had to implement local first + remote sync on some fairly complex dynamic forms and where luckily there is usually only one writer and I can get away with last writer wins and reject if things are too old or if there is schema drift and can just display an error message and roll back. But what I am trying to say is: Whatever can go wrong in an online-first world, can also go wrong in an offline first world but you might get informed of that all at once at a later time - or not at all and your data is not what you think it should be. Some sync engines like zero from rocicorp has opted out of supporting offline writes entirely because of all these problems.

And just to be clear: I love offline first approaches. I yearn for fast performance. And in a lot of cases slapping a sync engine on your app can really be helpful for that if your use case allows it. But it's absolutely crucial to be aware of the pitfalls that come with it.

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

#29
TL;DR: Background syncing instead of synchronous updates to the cloud.

This is basically a thick client, and comes with according trade-offs. It's interesting and there are some best practices, but I can't help but feeling that either the author is a huge fan or the post is an ad (or "sponsored").

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

#30
> 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

Post reply on HN