We use Linear at work. I’m definitely in the minority, but I really struggle with the UX. I also wouldn’t call it fast. Sure the page technically loads reasonably quickly, but half the time I see numbers updating on the page with no visual indicator that data loading is still happening.

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

Last year a guy reverse engineered Linear's sync engine and published it on GitHub with a cool explainer.

https://github.com/wzhudev/reverse-linear-sync-engine/blob/m...

Writing an eventually consistent database is hard, it maybe fine for Linear's use cases, but not knowing if my updates made it to the server (aka my team),is problematic. The sync lags have created untold problems in other projects I have worked for, so I always go for a synchronous solution. All the fancy stuff comes out only if it's absolutely needed. I'd rather optimize my server to be blazing fast, and have the user "suffer" network latency.

I would always hear about how Linear was fast, but after actually working daily with it, I’ve lost enthusiasm. Search is quite slow, the UI is often clunky (looks good though), “Pulse” is a torrent of noise even at small scale, and I have trouble finding things I need and resort to adding everything to favorites.

Early days’ Trello was the best project tracking experience by far.

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 server when it’s due to the speed of light.

But what you can do is locate the backend near users and make sure it’s fast.

For example, 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.

In other words, you can absolutely create a traditional CRUD app where doing the same thing takes more like 30ms, not 300ms.

Linear still only uses j/k for up and down. I've asked over and over for the past 5 years for ctrl+n/ctrl+p up and down and have gotten nonsensical answers from support.

What's crazier is they support this navigation key combo in their command palette but no where else.

The vim line nav is a nice thing in apps, but it's extremely frustrating I can't change it.

This is neat. To be honest, I never considered Linear as "fast". Seemed laggy as most web apps, but in contrast to JIRA it's lightspeed of course. Linear is great though, a real refreshment after JIRA torture.

As for optimistic routes and "fast" - maybe we ought to talk gmail first?

Apparently "Hacker News" won't allow me to delete my account. Well let's give this a go:

HACKER NEWS is ran by a bunch of idiots that think karma is an actual thing, If this is so - then explain this?

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

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 :(

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.

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!

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.

I’ve never thought of Linear as particularly fast.

My Linear client gets stuck "syncing" all the time, completely blocking all interaction. I'd rather have loading spinners than getting, essentially, locked out of the whole app for 10 minutes.

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 easier later by a lot.

The linear MCP is amazing to work with as it lets me keep all my workflows in the terminal. The ergonomics around search and ticket management are dead simple going through a terminal agent, so I didn't need much more convincing after enabling that configuration.

Pretty nice how they package each article into a skill, wonder how useful they actually are in real world workflows.

https://performance.dev/skills

https://performance.dev/how-is-linear-so-fast-a-technical-br...

Interesting. Looking forward to the next article explaining how it is so slow. (TL;DR it's a webapp disguised as a desktop app.)

I recently started interacting with JIRA exclusively through AI agents (as a Skill in Cursor) and the difference between Linear and JIRA has immediately evaporated. No UI clunkiness problems if I don't even use it :)

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.

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.

I like it when a spinner represents the truth about the state of the value on the server. I want to know when/if it's been updated.

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

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.

Any good resources or wrappers for indexedDB people would recommend? The API seems kinda unapproachable compared to other data stores.

https://github.com/tinyplex/tinybase seems kinda good maybe?

I was expecting a post about how O(n) algorithms can sometimes beat o(n), if you can take advantange of the hardware. Instead I get some mountain of stuff targeting "agents". Bah.

funny how things come back.

I loved meteorjs and its still my fav framework to this day.

Seeing optimistic ui and browser based databases being used this way makes me happy.

I would like to understand how they do the chunking and only updating part of the graph instead all of it.

I've always wondered how they made the UX so slick - thanks for sharing.

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.

I miss Pivotal Tracker

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

I was expecting a post on how hardware accelerate linear algebra lol

just one thing, this is not the simplest stacks you can find.

They're doing some really cool stuff with Agents too.. automating software pm. it's a huge difference between this and their (unnamed) larger competitors.

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.

Did we need five thousand words (easily 1/3 of which didn't deal with the main topic) on techniques that aren't exclusive to Linear in the slightest?

It’s webscale

> 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

Meta: so many words to say - save local first & sync in background.

Feels like AI slop.

Doesn’t address the concurrent update problem except for “optimistic”. At least provide some data why that’s ok.

[dead]

[dead]