[markmiro]

I love this. Vjeux, seemed excited about it, which gives the project some immediate credibility IMO.

https://twitter.com/Vjeux/status/1250687160237211649

I've been using hooks since they came out and doing things with generators and async looks to be more intuitive to me. Instead of a language on top of a language, you just use JS, which has always been what made React great.

I also now have a reason to look for more places to use generators :) I didn't realize they could be so helpful

[CSSer]

Interestingly, the thread you linked to also has links to other discussions where the React.js team provide their reasoning for why they decided against using generators[0] that the author of Crank.js didn't mention in their post. There's also a more basic breakdown of that explanation deeper in the twitter thread here[1]. As I understand it (and I am no expert), Crank.js's usage of generators is not the most performant because it doesn't provide an avenue to avoid recalcing work. In this case, memoization/caching does nothing to save you.

There are also other interesting tradeoffs, like suddenly making everything a generator as a result (as seen here). It's not that big of a deal to me, personally, but it's not something that everyone in the JS world is necessarily used to either.

Overall, it seems to be about target audience and priorities. Facebook seems to really care about intense performance at scale and they want all of their developers to be able to use their framework with ease. It seems they don't mind if that means requiring a bit of their own 'dogmatic' education as the author put it. Regardless, I agree. This is really interesting stuff!

[0]https://github.com/facebook/react/issues/7942#issuecomment-2... [1]https://twitter.com/swyx/status/1244749594472243200 (see @samselikoff's reply and following discussion)

[fiddlerwoaroof]

I really like the way redux-sagas uses generators to represent side effects a values that get interpreted by the redux middleware they provide.

[Zezima]

This is the comment I’ve been looking for.

I’ve been writing exclusively React for 3 years and the majority of react community are ill informed as to the origins of React.

Originally an OCAML implementation, there are clear benefits from pure functions, immutable data structures, and representing views declaratively in a DAG. I am simply restating the motivations and characteristics of React.

Then Redux comes long, inspired by Elm and it’s immutable update cycle, and the React community proceeds to spend the next two years utterly confused as to why anyone would want to use Redux. Followed by an onslaught of “You might not need redux” and “How I built my react app without redux” articles by shortsighted developers who merely reimplement Redux. :facepalm:

Redux-saga is the desired solution to handling async rendering while also staying true to the core properties of React. I’m glad you mentioned it in your comment.

I find the React community to be largely defined by its misunderstanding the core design and goals of React.

I find Crank an interesting and clever application of async generators.

However claiming that the core properties principles of React - functional properties, DAGs, and priority scheduling - are “dogma” is a shameful misunderstanding.

The correct criticism is of the behavior of the React team in their community response and the Suspense API alone - rather than the intrinsic properties of functional user interfaces.

Nonetheless, I am impressed by the technical effort in creating a new async generator API for rendering JSX. This project is no easy undertaking. Sincerely hoping for its future success (and self reflection).