shelf
crdt-example-app
| shelf | crdt-example-app | |
|---|---|---|
| 2 | 2 | |
| 52 | 567 | |
| - | - | |
| 0.0 | 0.0 | |
| over 1 year ago | over 1 year ago | |
| JavaScript | JavaScript | |
| MIT License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
shelf
-
Show HN: Bike – macOS Native Outliner
I think you could encode a “shelf” last-write-wins CRDT into your HTML using data attributes without exploding your file size. You would need to add a data-version attribute, and if you want to support hand-editing or editing by programs that don’t understand the CRDT, a CRC32 or other parity as data-parity so your loader can tell when a user might have edited a row without updating data-version.
Shelf is really simple - the JS implementation is tiny (https://github.com/dglittle/shelf) and a walkthrough of the algorithm here: https://bartoszsypytkowski.com/shelf-crdt/amp/
It wouldn’t handle character level sync - but would let you merge documents at a rows/items/blocks level.
-
Downsides of Offline First
The CRDT I was referencing was Shelf by Greg Little. He's given a few talks about it at the braid meetups. When he first showed it off, Kevin Jahns (the Yjs author) was also there and was as impressed as I was:
https://braid.org/meeting-8
The code is all here. Its tiny:
https://github.com/dglittle/shelf
crdt-example-app
-
Downsides of Offline First
* https://www.youtube.com/watch?v=DEcwa68f-jY
And his demo implementation (and annotated fork):
* https://github.com/jlongster/crdt-example-app
-
Why do Webdevs keep trying to kill REST?
Better protocols lead to improved UX (eliminating user-facing errors and offering faster updates) and DX (shifting errors left) and they're so relevant to the "why are you avoiding REST" debate that I split them out to their own category. Technically of course, whatever protocol you use may be a layer atop of REST - if you have a separate layer (like CRDTs) that handles syncing/conflict resolution, then that is the protocol you are really using.
What are some alternatives?
swift-collections - Commonly used data structures for Swift
absurd-sql - sqlite3 in ur indexeddb (hopefully a better backend soon)
distributed-counters - Experiments with distributed counters
supabase - The open source Firebase alternative.
Homebrew-cask - 🍻 A CLI workflow for the administration of macOS applications distributed as binaries
hotwire-rails - Use Hotwire in your Ruby on Rails app
redux-offline - Build Offline-First Apps for Web and React Native
RxDB - A fast, local first, reactive Database for JavaScript Applications https://rxdb.info/
offix - GraphQL Offline Client and Server
noms - The versioned, forkable, syncable database