I'm really excited by the prospect of a reactive, data-driven UI in SilverStripe!
My exposure to ReactJS has been fairly limited. I was initially worried about the added complexity of debugging a virtual DOM layer, but after talking to a few devs with ReactJS experience that seems to be a non-issue - it just works.
@Fred: While I agree that we need an overall plan for JavaScript in JS, I think we need to start somewhere - it's a huge topic, and new approaches pop up every day. The question should rather be: Do we have enough modern JavaScript knowledge in the core team and community to lead us on a stable architecture path? As Aaron pointed out, choosing ReactJS as a frontend library means we need to make more decisions (e.g. Flux, testing, modularisation) than if we're using a broader, more opinionated framework like AngularJS. And I'm confident we have that potential to make these decisions.
Responding on Klemen here, rather than fragmenting the thread
Hi guys, ReactJS sounds like an awesome choice and you have my +1. Out of curiosity - Angular is not a contender?
Do I understand correctly that essentially for SS4 CMS you are decoupling logic/API and the CMS views? Or would integrating React actually mean a heavy rework of what's out there (note I'm not too familiar with state of progress, but felt this was a conversation I wanted to join in). Doing that kind of decoupling, that would mean that integrating angular or another front-end framework could come out of the box.
In order to integrate efficiently with React or Angular, we'll need to expose data structures like page content, the page tree and a form schema through an API. So yeah, that's the plan. We're not sure yet if it's going to be a general purpose REST API, since there's a lot of complexity around expressing the different data states and query possibilities. You'll be able to use it in other frontend frameworks, it's just a matter of treating it as a CMS-internal feature or a public "SilverStripe API".
If intelligently done, SS could integrate pretty rapidly with frameworks like Polymer or Ionic (on the frontend as well). And maybe even be "themable" in a way that up to now was largely impossible (e.g. Polymer, Bootstrap, Material, Foundation themes for backend being relatively a breeze)
We have recently done multiple sites on Ruby/Angular and I keep missing SS's modular approach to building view elements. Essentially we need to build out all the interfaces by hand and I always dream of an angular version of "new Form()".
To finish this off, I think my mentioning of Angular essentially serves as a +1 for ReactJS. If we could somehow bridge the gap and have whatever JS "MVC" framework is the basis for the CMS to receive schema(mode) / form information from the "SS API", then this would open up very exciting possibilities (and possibly a reactive, non-refreshing CMS interface).
Has anyone seen and worked with Meteor? That thing is reactive out of the box.
I've worked with Meteor recently, and am fascinated by its isomorphic approach. It's very much an opinionated full-stack framework though (e.g. MongoDB and Node only). My experience so far is that it's incredibly quick to get a reactive UI and data store going without even knowing what Websockets are, but you pay for this later by a steep learning curve. For example, I've given up trying to run Selenium tests on my Meteor app, there's just too much magic going on. Getting a bit off topic though ;)