I'm unsure about many things in tech, but two things I know for certain: 1.) Cloudflare Workers (Service Workers for the server) are a stone on which other solutions will be ground down. Composition + perf FTW. 2.) The design of @replicache is correct and serious apps need it.

If I were pushed to add a 3rd, it would be that esbuild is the future for serious toolchains. Others will survive, but they will not scale.

looks cool. We've been using #firestore on @getpolarized and pretty happy but the number of active snapshots doesn't scale very well.

Firestore is, I'm sad to say, terrible vs. the design of replicache. It's frustrating that a company that built so much on OT/CRDT would field such deeply inferior tech.

If replicache is going down he OT/CRDT path I'm definitely going to dive in. We used a very minimal CRDT system in Polar to build in some new fancy realtime collaboration stuff we're about to ship

is exploiting the fact that sync w/ a single server can be somewhat less complex for similar durability: @aboodman explains: news.ycombinator.com/item?id=221755…

As with CRDT/OT, you're operating a vector clock, but the source of truth differences create different cost structures in time and space.

Open sourced a distributed data model I've used for collaborative apps and to support offline clients. Based on event sourcing so does use a backend component though

What's the killer feature (s) that sets CFW apart from AWS lambdas?

Great question. AWS Lambdas bring pre-existing toolchains to every involcation, which means their runtime's startup overhead and processing model are not aligned with moving to a fully evented, portable edge situation. They gain a lot in re-use of existing knowledge for it, tho.

CF Workers use the basic Service Worker design which strips away everything from the execution environment by default, only re-adding what's necessary. This results in both better packing within processes, as well as better safety and startup perf:

Watching Cloudflare adopt versions of optimisations we've done for Service Workers in the browser is pretty fun: blog.cloudflare.com/eliminating-co… This is, roughly, the design of Navigation Preload:

By moving to a design that isn't dragging a boulder of dependencies with unruly execution demands (native code, system threads, etc.) behind it, Cloudflare doesn't have to spend full processes on each worker...which lets them drive their execution even further toward the edge.

...and by removing the bits of DOM we left hanging around in Service Workers, they gain opportunities to make them even lighter and more portable. This, plus server-side resources, give them the ability to use the "russian doll" worker-nesting design we considered for SWs.

We couldn't do it in the browser because of security concerns, but Cloudflare can mitigate them in ways we couldn't...which means they can safely compose workers that proxy request/response pairs to each other. Turtles all the way down, with low latency.