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.
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 :-)
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.
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.
Great to see HTML5 growing so rapidly during the past few years! That said, I'm not a huge fan of frameworks, they do not work so well except for basic pattern apps. When you have an app worth building you consider very carefully what foundation stones to use. I ended upright on my feet and happily dancing using React as one of the stones.
Come on people, HTML5 is winning! Another awesome and seemingly overlooked option here is ludei.com with their Cocoon platform, launcher and cloud build service. Put that together with React/Flux and some soon to be released Famous-React for flavour and its all possible. Then top it off with Webpack and your laughing.
Crazy to finally poke around the Famo.us University and then to read all these scalling comments. The scrolling did not work that well for me either, however having seen so many APIs for graphics in Java back in the RIA days until now, I think that Famo.us is doing something fantastic for HTML5.
By the sound of the comments and also feeling the same pressure I'd say everyone is between a rock and a hard place, when it comes to getting their hands on a decent mobile framework (more than that Angular CRUD thing anyways).
Yes, it is absurd that something like what Famo.us is doing at long last has not already been done. Now that they are doing it lets give them a chance to do it (if that leader of theirs could actually code instead of act like a kingshit it would also help). I'm also sure most of you could crawl back up your stack and shut up for a bit longer.
I've had to wait a long time myself, to the point where I've just had to use a lot of engineering and progressively move toward an agnostic codebase that has become elegant as a matter of course. I would welcome Famo.us as an option for me, sure beats the incredible waste of going native. We need to support Famo.us with useful feedback not bitching.