Reading Hacker News comments on JavaScript frontend articles is a depressing task these days. The majority is complaining: Tooling too complex, bundling too complex, Too many different frameworks, best practices change too quickly. Spearheading: The React ecosystem. Completely modular with an abundance of libraries, patterns, and abstractions, pushed by an…
I have been writing React/Flux applications for a year now. Looking back at one year of Flux development I can clearly say that this Flux thing works. Past are the days of "I'm not touching that event chain". All the Flux codebases I have worked on were clean, debuggable…
At my company, we recently finished the fifth iteration over a medium sized, but very interactive and graphical web-app. We started a first prototype with Backbone and as the project got bigger, expanded to Chaplin with d3.js. Some time ago, we started to use React and liked it so…
Our company put the approach I outlined in this post into production roughly 6 weeks ago. Recently, I dove back into our Flux application, having not looked at it for a couple of weeks. Returning to a project after a longer hiatus is - in my experience - one of…
UPDATE: the methodology of this post is not optimal, read here for a better approach. More and more examples surface on how to use React. The Flux pattern is very important for React, since it enables you to write complex applications without a big framework solution. This is attractive because…
I've compared React to tradional MVC in this blogpost. I covered one important point: re-rendering everything is nice. But I also claimed all kinds of other things (like not needing MVC patterns), but didn't actually reason about them. This caused me to write this follow up. Let me throw out…