Hey everybody,
I’ve taken some time to write this reply, as I wanted to play around with React first, get the prototype running locally, do an in-depth code review and start hacking on the prototype, and submitting my first PRs to it.
Thanks @inkdpixels and @wbehncke for your work on this, I think a specific prototype really helps to judge things.
Following are my personal reflections – so take them with a grain of salt 
The Good
-
I really like the code structure in the prototype.
-
Working with the immutable data and domain-specific commands to mutate that data feels really good to me, and will fit well with Event Sourcing on the backend side.
-
The whole code-base reminds me of clojure’esque-functional-style-programming. (Which I enjoy writing and thinking about!)
-
Having global, immutable state describing the whole app (in Redux) immensely helps debugging and tracing what is going on – I especially like that we essentially get a time-travelling debugger for free.
The Bad
(don’t worry that this part is “longer” than the “good” part above; as I tried to include possible solutions and ideas to start a discussion how to resolve these issues)
validating global redux state
I feel that the global Redux State is at the one side a blessing, at the other side a “curse” in the sense that everybody must extremely well understand how this state is structured, and if this state must be restructured, we must be quite careful to do this.
Solution idea: To me, the current Factory.js contains way-too-little documentation; or maybe we can create a JSON schema against which the state is validated. This would in my opinion circumvent this problem.
What do you think?
fast-evolving NPM & React Ecosystem
I have the feeling that as soon as we decide on some package / dependency, it is already outdated & a “better” alternative exists – so we could basically “update our packages all-the-time” without creating value. Often, packages also get deprecated quickly and superseeded by “better” alternatives.
That’s just something which I feel is the case in the NPM ecosystem in general, and the React ecosystem in particular.
There’s a thin line to this problem:
- If we update/switch libraries too conservatively, we end up in the same mess we’re in now with the Ember 1.x codebase (where we did not update libraries, switch to Ember CLI, …).
- If we update/switch libraries too often, we’ll be reorganizing the code again and again without creating value.
Solution idea: I think this is just the way it is; we just need to be aware that this is a long-term effort for the whole team.
Code Conventions/Best Practices to code-organization “non-obvious”
Granted, the tagline is a little “bold”, but basically I have seen tons of React starter-packs claiming to be a “best-practice” way of building react apps, which connect together the libraries in many different styles. So while the rendering using React is always fundamentally the same, how you organize your code is different from project-to-project.
This means we have to come up with our “own” style of creating React projects (which will be based on what Wilhelm and Tyl did of course). We did the same in the past with EmberJS (in combination with Require); and Angular 1 projects suffer from the same problem.
This hit me once more when recognizing the tremendous value of Ember CLI in the Ember Ecosystem; which basically means that all Ember projects look, feel and behave the same. And you do not need to document it, but can just point people to the well-written ember-cli docs. Not to speak about all kinds of testing which works right out of the box, and the addon system.
However, as we’re currently creating our own Content Management Platform, this is less of an issue, as people will adapt to the code conventions we prefer. We don’t know if in a year from now, a platform/build-tool like ember CLI might become the de-facto standard for React tooling. If so, we might think of switching. But that’s nothing we need to handle now.
Solution Idea: For me, it would be really helpful to have a LIBRARIES.md document in the codebase, which contains the following information for every library we use:
- Short-Description of the Library explaining its role in the project (e.g. “immutable.js provides immutable JavaScript objects, lists and maps, inspired by languages like clojure. Immutability benefits: time-travelling debugger, global undo-redo, …”).
- short explanation of interactions with other embedded libraries (e.g. “immutable.js is used inside the redux store”)
-
Alternatives with a short explanation why this one is not (yet) used (e.g. “Freezer.js is too immature compared to immutable.js, but could be an option lateron.”, or “mori.js is not maintained anymore”). I also imagine that when we find new libraries, we add them to this list, so we can periodically review it and decide whether we need to update or switch the infrastructure.
Ember (2.0) vs React
I couldn’t resist to write this small part, as IMO a few people were bashing Ember 2 a little
- Ember 2.0 has been heavily inspired by React, but is more of a holistic framework than React. When I checked the code, I think one could have built a similar-looking codebase in Ember 2.x.
- For me, a clear benefit of the React platform (the way it has been built in the prototype) is its enforced state immutability and functional-style programming.
- Ember I think is platform-wise more mature; because of Ember CLI all “modern” Ember projects look and feel the same.
Comparing the current Ember 1.x-grown-codebase to a “new React” codebase is I think of little value; as the comparison would be quite similar comparing the 1.x-grown-codebase to a clean start with Ember 2. Maybe the idea to “upgrade from Ember 1 to Ember 2 using the compatibility layer” was a bad idea in the first place, as the compat layer adds quite some overhead and difficult-to-debug behavior.
Also comparing performance numbers is really hard; for the same reasons. I have seen various Ember2 vs React benchmarks; and depending on the metrics you look at, the one or the other is faster (depending on the use-case and measurements).
Summary & Conclusion
In the end, I think the decision between starting fresh with Ember2 or starting fresh with React is a matter of personal preference and sort factors, not hard, technical ones. With both technologies it would be perfectly possible to build what we intend to archive.
Knowing ember, I was able to get productive in React really quickly, and it felt generally good. Sometimes a little more high-level than ember, sometimes a little more low-level.
There are some soft factors speaking in our case in favor of React I think:
- We have a working prototype already which I’d be comfortable extending.
- React is currently “hip” and “hyped”, meaning we can get lots of exposure in this community, and can somehow “ride” that hype wave.
- We can grow the Team by @inkdpixels and @wbehncke (I hope).
Summary: Going the React way is fine for me, and I’ll support it whereever I can.
Suggestion: Next Steps
I think the rewrite is a big task and I see a lot of work coming up. There lots of features deep inside Neos already, which would need to be re-created (e.g. like Content Constraints, updating the URL, all the editors in the inspector, drawing editor borders, preview modes, dimensions, to name a few).
So for me, there is no guarantee we will make this transition reality; it is a rather high-risk project. But if we manage to finish it, I am sure we’ll be happy with the results.
That’s why it is extremely important that we as a full team pick up this task and commit to it. If only one (or two) people work on it, that will likely not work.
UI wise, I’d focus on re-creating the current state in a more bug-free manner. However, there’s one thing I’d do right from start, and that is integrating CKEditor (for the reasons described in this RFC). CKeditor will be included in NPM really soon, see this issue. And we have great support from the CKEditor team!
The End.
Wow, that was a long post. Took me about three hours to write, but I think it was worth it Thanks for reading and I’m looking forward to the upcoming discussion and decisions. I see a consensus coming up!
All the best,
Sebastian
for the soft facts so from my side good to go. But me being me I want to add a few points that should not be forgotten while doing this:
