Live data from Hacker News

How's Linear so fast? A technical breakdown

performance.dev

151–160 of 250 posts

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

#151

It’s really unfortunate that it is built in an apartheid state.

> It’s really unfortunate that it is built in an apartheid state.

Linear is based in San Francisco. And has offices in New York and Finland. Which one of these is an apartheid state?

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

#152
If you're interested in this kind of experience for your application, check out Zero (https://zero.rocicorp.dev/).

Live demo: https://gigabugs.rocicorp.dev/.

We also list some alternatives here: https://zero.rocicorp.dev/docs/when-to-use#alternatives.

If you're interested in how these things work internally, check out the Replicache design doc: https://doc.replicache.dev/concepts/how-it-works. Replicache was the predecessor to Zero and the core protocol still works the same way.

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

#153
post #132

Earlier quoted context omitted.

Linear enshittified their UI in the name of "clarity". You know the drill: remove functionality, add small icons with invisible text and HUGE padding, hide controls, etc. For example, the search field only shows if you press "ctrl-f".

I wouldn’t call it enshittification because there’s no business purpose to it. It’s more like Applification. Apple removes every hint the user needs to know how to use its UIs in the name of “simplicity,” which makes them undiscoverable and complex.

Yeah, agreed. We need another word for that. Literally everybody in the industry is affected by this.

Typically it goes like this: you make a good UI that users like and release your product. The product manager gets rightfully promoted and starts working on other stuff.

A new manager comes in, and they can't really do much. The UI is already close to perfect, after all. So they do a major UI overhaul that inevitably removes/hides functionality and makes things worse.

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

#154

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…

> it’s very possible to run a web app backend within ~10ms RTT of most users and have the backend render responses within ~10ms too. What are you talking about? The only AWS region https://www.cloudping.co/ us-west-1 is 60ms away. eu-centra-1 is 100ms away. asia is 200ms away. and this is datacenter-to-datacenter traffic. Actual latency over the public internet to residential providers is far worse. Your database nee…

you can home tenants in a data center close to them, run a copy of your app in each region including the datastore. keep a central db for accounts, billing, etc but user content is easy enough to shard regionally.

taken to extreme, cloudflare durable objects & workers let you place data very close to a tenant automatically; but you lose total write throughput on top of sqlite.

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

#155

If you're interested in this kind of experience for your application, check out Zero ( https://zero.rocicorp.dev/ ). Live demo: https://gigabugs.rocicorp.dev/ . We also list some alternatives here: https://zero.rocicorp.dev/docs/when-to-use#alternatives . If you're interested in how these things work internally, check out the Replicache design doc: https://doc.replicache.dev/concepts/how-it-works . Replicache was the…

We've been using Zero for a while now. Originally we were looking to build a Linear sync engine in-house and came across Zero. Probably the closest thing you can get without staffing a team dedicated on this.

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

#157
post #154

Earlier quoted context omitted.

> it’s very possible to run a web app backend within ~10ms RTT of most users and have the backend render responses within ~10ms too. What are you talking about? The only AWS region https://www.cloudping.co/ us-west-1 is 60ms away. eu-centra-1 is 100ms away. asia is 200ms away. and this is datacenter-to-datacenter traffic. Actual latency over the public internet to residential providers is far worse. Your database nee…

you can home tenants in a data center close to them, run a copy of your app in each region including the datastore. keep a central db for accounts, billing, etc but user content is easy enough to shard regionally. taken to extreme, cloudflare durable objects & workers let you place data very close to a tenant automatically; but you lose total write throughput on top of sqlite.

But this is kind of meaningless unless the tenants themselves are in one geo. Take linear as an example, this strategy works as long as your company that uses linear is all colocated in one area. As soon as you have remote people it falls apart.

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

#158
post #123

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…

> it’s very possible to run a web app backend within ~10ms RTT of most users Only if your users are all located quite close to each other, or (sadly very common) you only care about making it fast for US users and screw everyone else. (Of course you can have "intermediary backends" around the world on a CDN's edge network or similar, but at that point you're paying the same complexity cost as this style of putting th…

10 years ago, I was headlining a project where we had strict performance requirements (ssr, php mind you) - the target for any operation except login was 30ms, and any endpoint taking more than 60ms in one of the devs server would have to have explicit approval. Add the nework RTT if you dont want to have a local backend, and for most geographies is still well under 300ms. Fun fact, we actually designed a system that could be easily replicated between regions and/or perform internal routing, leveraging the operator network. 3 AWS regions would make the RTT of a request well within 80% of the world population. Requests were mostly "instant" - the big trick that did it (at the time) as to avoid reflow in the browser. Funny how the spotlight is now on doing stuff that "solves" that problem with the technology that was designed to solve that problem.

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

#160

Focusing on making things actually fast is always better than putting a cache or some hack on it. Linear IS essentially a crud app so saying crud app does it in 300ms doesn't mean anything in this context imo. If you have a database stack that is actually fast. And you can use something that is actually fast on the frontend like solidjs. Then you might have something that is actually fast. But putting more complexity…

When you say most people have more than 100mb/s, 4 cores and 8gb

Do you mean USA and other developed countries? Or the world

Post reply on HN