4 ms·
This has nothing to do with it. I love promises but they are truly limiting. Here is an example of how promises limit the power of mobx https://twitter.com/sp
by spion 9y ago
This has nothing to do with it. I love promises but they are truly limiting.
Here is an example of how promises limit the power of mobx
https://twitter.com/spion/status/958906847385341952 https://twitter.com/spion/status/958906847385341952
Another example relevant in node is continuation-local-storage (equivalent to threadlocal storage). Implementing it on top of generators or other "chainable / thenable" abstractions is trivially easy. Implementing it on top of native promises and async/await is impossible without deep hooks into the platform.
More examples here: https://spion.github.io/posts/es7-async-await-step-in-the-wrong-direction.html https://spion.github.io/posts/es7-async-await-step-in-the-wr... (see the second part)
We should've paused on async-await and waited for jhusain's compositional functions: https://github.com/jhusain/compositional-functions https://github.com/jhusain/compositional-functions
In the meantime generator based libraries would've properly explored the whole breadth of power that co-routines can give you, creating cowpaths to be paved by TC39.
Promises make trade-offs, and they end up with a design that is generally good and can be used well in some number of situations. But not all. Not nearly enough to get first class syntax support that makes them privileged over all other solutions.
- matharmin 9y agoGorgi Kosev's post highlights a very nice use case for generators (database transactions). However, in all my JavaScript over the last few years, that is the only good use case I've found so far in my code base for generators. In all other use cases I've come across, async-await works just fine, and has a much nicer syntax to work with.
- spion 9y agoI elaborated that case in the most detail, but there are many other problems that generators solve mentioned in the blog post. Another very common one is getting the current user that initiated the request (or maybe their session), which you need to pass around to all your functions/classes. What if you could simply `yield getCurrentUserSession` and the engine which ran the toplevel generator returned it back to you? jhusein's compositional functions solved the syntax issue.
- fiatjaf 9y agoMobX is horribly opinionated, a monstruous abstraction of spaghetti, and you're saying Promises limit it?
- spion 9y agoMobX 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.