| If you haven't already, you should be betting on React. It's the future But last week the future was AngularJS, and the week before that it was Ember or Backbone or Knockout, and a few days earlier it was jQuery. Next week it will be Angular 2.0, maybe, or something with Web Components, and the week after that we're all abandoning JS in favour of some declarative functional language that hasn't been written yet but will be on TodoMVC tomorrow. Seriously, this is a beta of a pre-release package. The article mentions, as motivation for the major architectural change, some other react-something packages, and literally in the opening section of their README.md they say things like "This project is a work-in-progress. Though much of the code is in production on flipboard.com, the React canvas bindings are relatively new and the API is subject to change." By all means let's experiment with newer and potentially better ways to build sites and apps, but betting heavily on an ecosystem this immature for a long-term professional project seems like asking for trouble. Isn't this what we have all been waiting for? It's certainly not something I've been waiting for, as someone who works in the relevant fields. Rather like "isomorphic" libraries, I feel combined web/native generation is mostly a solution in search of a problem. No doubt a few people really do have that problem, but I'm guessing that for most day-to-day work in the real world this theoretical flexibility adds little practical value. There's no particular reason the same tools should be good choices for writing both web and native apps, any more than we should expect the same tools to necessarily be good choices for writing both server-side and client-side code in a web app. In this particular case, I'm more concerned by the change in emphasis than the technical changes. To me, the big advantage of React over most other front-end libraries and frameworks is the efficient DOM updating, which in turn makes this kind of component model viable with acceptable performance where various other UI libraries/frameworks have struggled in the past. However, it looks like the React team think that is a secondary benefit and the real advantage is using components. I can already build a complicated web app rendering layer using the same modular design skills I've spent the last 30 years learning in other programming contexts. After all, that's what I did before we had the modern generation of template/component driven frameworks, when we had to update the DOM manually using plain JS or libraries like jQuery. So did plenty of other people. Maybe I'm missing something, but while React might be a sensible enough choice for part of the UI rendering work, I don't see why it has anything unique or special to offer compared to many other libraries here. If the React team focussed on the efficient DOM updates, flexible but reasonably simple component model, and then stability so the community could develop the ecosystem around a solid foundation, I could see it becoming a good choice for projects that can't afford to have their dependencies constantly shifting around and the maintenance overheads that incurs. But this separation and increased emphasis on react-native and the like feels like it's leaving behind the very things that made React attractive in a very crowded field of JS UI libraries. |