Great series from Egghead! What can be said is that Cycle.js is indeed a new paradigm for JS. Anyone who has worked with other frameworks out there will know, that Cycle.js is cleaner, necessary and leading progress forward into the functional reactive future.
Not sure if you've looked at Cycle Drivers, they are essentially services or plugins for side-effects. You manage them through sources and sinks and utilize them where every you like, as they run through dataflow components, very powerful and clean.
This is monumental! No other framework brings together dataflow and components like Cycle, those are just the facts making Cycle the premier state of the art framework in the JavaScript ecosystem.
What a fantastic overview of the past, present and future of UI flow and structure! There is a real need to step back and consider the available architectures and to build forward to a more natural and synergistic solution like Cycle.js.org.
I Really like the third diagram in the Nested Dialogues section and where it says "The wiring of Observables between layers of Dialogues is a data flow graph". This reveals that interactive event flow is primary and is what drives a UI, weaving through components like the nervous system does in the human anatomy.
In the diagram we are looking at an emerging and clear way of defining app flows and structures. There is potential here for a drag and drop IDE editor where the over all app can be architected and generated.
I fully agree (on the visual editor)! It's a great property of Cycle.js apps that there is a one-to-one trivial map (isomorphism to be more precise) between the program source code and a data flow graph, so I wish I had time and resources (or hope someone eventually does) to build a tool where you can work in both code or data flow graph. I'm interested in the data flow graph as a "minimap" (think Sublime Text), not as a replacement to actual code (I dont think we can get rid of code just yet).
RAD! Together with what @axefrog has in mind for tracing observable pipelines, a dash of Bret Victor and a bold Dan like initiative (https://www.patreon.com/reactdx?ty=h) DX can take a giant step to an unprecedented summit :-)
Except remember, RxJS is also a growing standard and the virtual-DOM Cycle.js uses has been tested to be a fair amount faster and robust than the one React has.
Then there is also Cycle's Model-View-Intent pattern and leading edge work on component integration, which is in line with W3C standards. Cycle's drivers also allow Cycle.js to integrate or target many options.
Things have been fragmented and Cycle.js seems to have brought the best together, representing a new and intelligent vortex of progress.
Before I took the time to understand what Cycle.js was about I was naive and thought React was it. I now understand how poorly it's reactivity has been implemented. On the other hand Cycle.js is fully reactive and has brought structure, flow and a sense of intelligence back to my app development.
Agree that those two benefits alone are super, may I also add:
3. The MVI framework, it's a great way to structure apps, much beyond the lifecycle methods React throws at ya.
4. The driver architecture, which shows forward thinking. It's ready to render to DOM or any other target or sink with any backend.
It's also the right way to think about engineering. Not just with the component mindset but more importantly, with Human-Computer Interaction being the main driver, which reveals the flow and structure of an app if you follow it through.
Okay, that explains a lot. It is also ironic because React's rejection of FRP in its completeness has also spawned a very poor substitute they call Flux.
The number of Flux versions that have been churned out as a result is obscene. That is certainly not keeping it beginner-friendly, that is just leading developers astray.
While all the Flux activity may make it look like a lot is going on with React it has instead just wasted everyone's time and kept them from learning a key paradigm like FRP.
Typo, meant to be turf, as in "React tried and abandoned..." or to toss aside without explaination. Title was getting long so turf had the edge to express the tweet.
Hell yeah! Noticed opentype.js is merging in some of that new Path2D sass too. Lets just use the DOM for what its good for, the slower more form based aspects of an app. Then use canvas for what matters most and be done with it.
IMHO state is where its at. Separate state from function and feed the component changed state and render as fast as possible. Much depends on what you need to render too. In my case I have a ton of rules for variations, which can be exchanged for even more variations, its its own injection solution.
Therefore I'm super happy about the dumb as nails canvas, it just does its thing and the state does its thing, really snappy. I don't need a scenegraph either, just a hit detection system, but hey, thats custom and thats fine.
