IMHO indexedDb is almost certainly the wrong choice and whatever perceived speed wins can be accomplished without it and optimistic updates. Prove me wrong
How's Linear so fast? A technical breakdown
171–180 of 250 posts
Re: How's Linear so fast? A technical breakdown
#172[flagged]
Re: How's Linear so fast? A technical breakdown
#173If 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…
this is not local/offline first and also seems massively over-engineered for the type of apps that might use it since now you can't use plain sql and need to learn your ZQL domain specific language/library. I mean look at this code from raw sql example:
```
const markAllAsRead = defineMutator( z.object({ userId: z.string() }), async ({tx, args: {userId}}) => { // shared stuff ...
if (tx.location === 'server') {
// `tx` is now narrowed to `ServerTransaction`.
// Do special server-only stuff with raw SQL.
await tx.dbTransaction.query(
`
UPDATE notification
SET read = true
WHERE user_id = $1
`,
[userId]
)
}
}```
Re: How's Linear so fast? A technical breakdown
#174I 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.
Same. And the UI is confusing. The core functionality is buried under the many features I don't need.
Re: How's Linear so fast? A technical breakdown
#175[dead]
Re: How's Linear so fast? A technical breakdown
#176Re: How's Linear so fast? A technical breakdown
#177If 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…
this is not local/offline first and also seems massively over-engineered for the type of apps that might use it since now you can't use plain sql and need to learn your ZQL domain specific language/library. I mean look at this code from raw sql example: ``` const markAllAsRead = defineMutator( z.object({ userId: z.string() }), async ({tx, args: {userId}}) => { // shared stuff ... if (tx.location === 'server') { // `t…
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 typically use the same code client-side and server-side. There's no branching. The example you pasted is showing an escape hatch for when you want to use custom SQL. The option is there, but it's not the common experience.
This is what a typical mutator looks like:
```ts
// src/mutators.ts
import {defineMutators, defineMutator} from '@rocicorp/zero'
import {z} from 'zod'
export const mutators = defineMutators({
updateIssue: defineMutator(
z.object({
id: z.string(),
title: z.string()
}),
async ({tx, args: {id, title}}) => {
if (title.length > 100) {
throw new Error(`Title is too long`)
}
await tx.mutate.issue.update({
id,
title
})
}
)
})We are trying to make apps like Notion, Linear, Superhuman easier to create. These apps all uses custom-built sync engines that took their teams many person-years of effort to construct.
Whether this complexity is worth it depends on how badly you want instantaneous response. If you do, you will end up using sync one way or other, and you will end up with something roughly like Zero mutators.
Re: How's Linear so fast? A technical breakdown
#178Sync engines are fast to a point but if you start working with large enough datasets and/or care about security you ultimately end up with something closer to streaming immediate mode HTML. Of course that means sacrificing local first.
Re: How's Linear so fast? A technical breakdown
#179These 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…
You don't even need your backend that close if your server is fast enough. Streaming HTML immediate mode is pretty good. See this demo (server is in Germany and runs on a potato uses no optimistic updates, eveb scroll round trips) [1]
Honestly client side animations go a long way to masking latency too.
Re: How's Linear so fast? A technical breakdown
#180Sync engines are fast to a point but if you start working with large enough datasets and/or care about security you ultimately end up with something closer to streaming immediate mode HTML. Of course that means sacrificing local first.
whats the security problem here? all mutations go through the server authority and clients can only load data they have access to. the only thing i see is users being able to read cached versions of private content that was accidentally set to public then private again, and if that happens to you something is wrong with your access controls. and its also not a big deal for most organizations.