How do these ideas work for domains which need encryption at rest? (e.g Healthcare, fintech, etc)?
Lack of native encryption in indexedDB is a dealbreaker for certain use-cases.
How's Linear so fast? A technical breakdown
191–200 of 250 posts
Re: How's Linear so fast? A technical breakdown
#192Earlier quoted context omitted.
yeah we specifically decided not to be local/offline-first because these add huge complexity that is not needed for the type of apps we want to support. I spoke about this a bit here if you are interested: https://www.youtube.com/watch?v=86NmEerklTs&t=1764s As for ZQL: a) basically all of our customers already use Drizzle/Prisma. So they are very used to custom DSLs, and like them. I know, I was surprised to! b) You…
Most of the improvement opportunity is in the offline-first the cache or fast reads already have lots of solutions by using zero I lock my self in thinking in your library's design language and not in terms of what I already know that is raw SQL. If your happy/convenient/recommended path is ZQL then of course people will choose it and only later realize it only works for simpler queries like most ORMs I've been burnt…
We do support Replicache: https://i.imgur.com/R1pR58i.png.
But I get it. Unfortunately something like this cannot be a sidecar, or at least I do not know how to make it one. It's central to your app in the way that React is.
Fortunately the category is expanding and there are several sync engines that plug in exactly how Zero does - by replicating your database. You can switch between them easily. So as long as you think you do need a sync engine you aren't that married to Zero specifically.
Here's a demo of that!
Re: How's Linear so fast? A technical breakdown
#193I think the interesting thing that made a small "aha" for me reading this was that: This is a direct parallel to an application on your PC or any other program you would install.
1. They do Client Side Rendering(CSR)
2. they have client side database
3. they sync asynchronous to to the server (or atleast some do, and other have direct manual action for it)
However this also brings back to the point of why would we expensive html page compared to a small app? (The question is obvious that it is portability and also the accessability of just accessing a link). - And this here we could start to think about instead of continuing to rely on HTML, JS and CSS, alternatives could be invented, that be much more efficient and powerful.
Re: How's Linear so fast? A technical breakdown
#194Any 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?
This is less serious a recommendation but https://github.com/npiesco/absurder-sql.
Re: How's Linear so fast? A technical breakdown
#195This is cool! Maybe I can incorporate something similar into the browser game and engine I’m developing to remove load states entirely after first load? My thing is fully client side static assets no server. For context I’ve been obsessed with performance with this game. Prior to this weekend I was struggling to simulate 128 simultaneous players (pathfinding, heavy strategy logic, rendering, all in viewport) and main…
There is Spacetimedb
https://github.com/clockworklabs/spacetimedb
Specifically targeting your use case with high fps.
Downside: db lives in memory and has to be stored separately for long term use (as of now, may change laterl
Re: How's Linear so fast? A technical breakdown
#196I 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.
Linear is probably starting to hit enshittification territory. The feature bload is immense and they are trying extremely hard to not be left behind on the AI wave.
Re: How's Linear so fast? A technical breakdown
#197Earlier quoted context omitted.
Say what you will about Jira, at least it’s not a total maze.
Guess you've never seen the administrative side?
On the contrary. I’ve been an admin more than not and configured it from scratch 4 or 5 times.
But even if the admin side is baroque, for a user just dealing with tickets and projects/epics it’s far less confusing.
Re: How's Linear so fast? A technical breakdown
#198Sync engines are fascinating way to build modern apps. I think they will become the norm soon, here's what we have so far: https://shivekkhurana.com/blog/sync-engines/
Re: How's Linear so fast? A technical breakdown
#199These 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…
> 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.
Very true, mostly because it's pricey to do so--or more specifically, putting a server in DCA is $.005/user, putting a server in JNB is like $.50/user sooooo....
Sometimes this is a "so what", other times it has huge implications for app architecture.
Re: How's Linear so fast? A technical breakdown
#200Hang on...
What if this happens?
1. User makes a mutation
2. UI updates instantly
3. User closes the app before sync happens
4. User comes back and is surprised to see that their mutation did not actually happen
The loading / error / success states in a UI serve a purpose.