5 ms·
MobX is the most powerful front end development library on the market right now. It single-handedly solves the cache invalidation problem in a performant way, a
by spion 9y ago
MobX is the most powerful front end development library on the market right now. It single-handedly solves the cache invalidation problem in a performant way, and its pluggable into any framework.
And yes, promises limit it.
- mathgladiator 9y agoHow does one measure power? What market?
- spion 9y agoBy actually using the thing being criticised instead of giving it the middlebrow dismissal. The "market" of application state management libraries.
- naasking 9y agoFrankly, S.js looks better. Simple and performant.
- spion 9y agoSlightly confusing api, no structural comparison, no adapters for popular frameworks (e.g. S.js-react or S.js-preact), no laziness (computations are recomputed even if they're not requested by reactions).
- naasking 9y agoWhy use react when you can use Surplus which is based on S.js? Surplus is the fastest among all of the JS frameworks and supports JSX. "Slightly confusing" == I'm not familiar with it. Not really an objection. "No structural comparison": don't know what this is supposed to mean. Re: laziness, actually redundant recomputations are not performed. Not sure where you go that impression.
- spion 9y agoI don't want to use surplus because e.g. I want to use well developed UI components or toolkits like blueprintjs, which is implemented on top of React. Slightly confusing is a real objection. MobX strives to implement transparent reactive programming, where the way you access, update and transform values works exactly like it would with regular objects. S.js has a worse learning curve. Redundant computations are computed; see: https://codepen.io/anon/pen/vdWomE?editors=0010 https://codepen.io/anon/pen/vdWomE?editors=0010 even though the completed() computed isn't used anywhere, the reduction is still being recomputed every time todo state changes
- naasking 9y ago> MobX strives to implement transparent reactive programming, where the way you access, update and transform values works exactly like it would with regular objects. S.js has a worse learning curve. Hardly: reactive values are get/set functions, and you create new ones with S(() => ...). That's it. MobX's attempt at transparency yields inescapable and surprising corner cases. > Redundant computations are computed; [...] even though the completed() computed isn't used anywhere, the reduction is still being recomputed every time todo state changes Incorrect. The todos binding is an SArray not a regular array [1]. See my modified version where I log the events to the console [2]. [1] https://github.com/adamhaile/S-array https://github.com/adamhaile/S-array [2] https://codepen.io/anon/pen/KQyOyZ https://codepen.io/anon/pen/KQyOyZ
- spion 9y agoThe number of tricky corner cases in MobX are very few. Also, once the implementation switches to proxies the vast majority will disappear. I'm willing to accept a few corner cases as long as there is a large common subset of functionality that works both with and without a small number of decorators. This can be utilised to write models that can be used in both a reactive and a non-reactive context with a different set of decorators injected in. S.js looks too invasive to do this. Your codepen has no completed todo count. Why are the recomputations logged every time here? https://codepen.io/anon/pen/vdWomE?editors=0010 https://codepen.io/anon/pen/vdWomE?editors=0010 > That's it. What about the poorly named "S.freeze"