crdt-benchmarks
MobX
Our great sponsors
crdt-benchmarks | MobX | |
---|---|---|
8 | 44 | |
397 | 27,176 | |
- | 0.5% | |
0.0 | 8.0 | |
2 months ago | 17 days ago | |
JavaScript | TypeScript | |
GNU General Public License v3.0 or later | 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.
crdt-benchmarks
-
JSON-joy CRDT benchmarks, 100x speed improvement over state-of-the-art
Author of Yjs here. I'm all for faster data structures. But only benchmarking one dimension looks quite fishy to me. A CRDT needs to be adequate at multiple dimensions. At least you should describe the tradeoffs in your article.
The time to insert characters is the least interesting property of a CRDT. It doesn't matter to the user whether a character is inserted within .1ms or .000000001ms. No human can type that fast.
It would be much more interesting to benchmark the time it takes to load a document containing X operations. Yjs & Yrs are pretty performant and conservative on memory here because they don't have to build an index (it's a tradeoff that we took consciously).
When benchmarking it is important to measure the right things and interpret the results somehow so that you can give recommendations when to use your algorithm / implementation. Some things can't be fast/low enough (e.g. time to load a document, time to apply updates, memory consumption, ..) other things only need to be adequate (e.g. time to insert a character into a document).
Unfortunately, a lot of academic papers set a bad trend of only measuring one dimension. Yeah, it's really easy to succeed in one dimension (e.g. memory or insertion-time) and it is very nice click-bait. But that doesn't make your CRDT a viable option in practice.
I maintain a set of benchmarks that tests multiple dimensions [1]. I'd love to receive a PR from you.
-
CRDT-richtext: Rust implementation of Peritext and Fugue
Diamond types author here! Congratulations on getting your crdt working! It’s lovely to see a new generation of CRDTs which have decent performance.
And nice stuff implementing peritext! I’d love to do the same in diamond types at some point. You beat me to it!
Im building a little repository of real world collaborative editing traces to use when benchmarking, comparing and optimising text based CRDTs[1]. The automerge-perf editing trace isn’t enough on its own. And we’re increasingly converging on a format for multi user concurrent editing traces too[2]. It’d be great to add some rich text editing traces in the mix if you’re interested in recording something, so we can also compare how peritext performs in different systems.
Anyway, welcome to the community! Love to have more implementations around!
-
Cloudant/IBM back off from FoundationDB based CouchDB rewrite
So yes, a particularly large document is not the norm but it can happen.
JavaScript CRDTs can be quite performant, see the Yjs benchmarks: https://github.com/dmonad/crdt-benchmarks
- Automerge: A JSON-like data structure (a CRDT) that can be modified concurrently
- Automerge: a new foundation for collaboration software [video]
- Show HN: SyncedStore CRDT – build multiplayer collaborative apps for React / Vue
- 5000x Faster CRDTs: An Adventure in Optimization
MobX
-
Episode 24/13: Native Signals, Details on Angular/Wiz, Alan Agius on the Angular CLI
Similarly to Promises/A+, this effort focuses on aligning the JavaScript ecosystem. If this alignment is successful, then a standard could emerge, based on that experience. Several framework authors are collaborating here on a common model which could back their reactivity core. The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…
- 5 Alternatives to Redux for React State Management
-
Redux 101
MobX
-
React State Management in 2024
Mutable-based: leverages proxy to create mutable data sources which can be directly written to or reactively read from. Candidates in this group are MobX and Valtio.
-
Show HN: Cami.js – A No Build, Web Component Based Reactive Framework
Looks good! FWIW I always felt the observable pattern much more intuitive than the redux/reducer style. Something like https://mobx.js.org/
Things get hairy in both, but redux pattern feels so ridiculously ceremonially to effectively manage a huge global state object with a false sense of "purity".
Observables otoh say "fuck it, I'm mutating everything, do what you want with it".
-
State Management Alternatives: Best Tools for React Apps
MobX Documentation
-
React native for Linux app development in 2023
There's also others libraries like https://github.com/mobxjs/mobx which aren't specific to RN but can be used in any JS environment.
-
Is redux and thunks still used or are there other alternatives for it now?
Valtio is like simplified MobX
-
What is React State Management?
Link: https://mobx.js.org
-
A cure for React useState hell?
But I want to impress upon you that this is just only one of many patterns you can use this hook for. While this is subjective, I am personally not a huge fan of Redux and this type of pattern. It has its merits, but I think once you want to start layering in new patterns for actions, Mobx, Zustand, or XState are preferable in my personal opinion.
What are some alternatives?
automerge - A JSON-like data structure (a CRDT) that can be modified concurrently by different users, and merged again automatically.
zustand - 🐻 Bear necessities for state management in React
diamond-types - The world's fastest CRDT. WIP.
RxJS - A reactive programming library for JavaScript
electric - Local-first sync layer for web and mobile apps. Build reactive, realtime, local-first apps directly on Postgres.
Recoil - Recoil is an experimental state management library for React apps. It provides several capabilities that are difficult to achieve with React alone, while being compatible with the newest features of React.
teletype-crdt - String-wise sequence CRDT powering peer-to-peer collaborative editing in Teletype for Atom.
riverpod - A reactive caching and data-binding framework. Riverpod makes working with asynchronous code a breeze.
y-crdt - Rust port of Yjs
valtio - 💊 Valtio makes proxy-state simple for React and Vanilla
automerge-rs - Rust implementation of automerge [Moved to: https://github.com/automerge/automerge]
Cycle.js - A functional and reactive JavaScript framework for predictable code