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?
151–160 of 250 posts
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?
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.
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.
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.
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…
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.
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…
It's blazingly fast approach.
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.
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…
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…
Do you mean USA and other developed countries? Or the world