RFC: JS Refactoring Process of Backend

[dimaip (Dmitri Pisarev)]

A few month has passed since this discussion, during that time I’ve gained more experience participating in Ember 2.x upgrade and completing multiple React projects myself, I want to correct my own position on this topic.

@sebastian

Hey @dimaip,

I believe we could write the Neos backend with both Ember 2.x and React; both would certainly be doable – and I’d even expect the code to look somehow similar, as Ember 2 (same as e.g. Angular 2) has been heavily inspired by data-down-actions-up of React.

However, when we have migrated to Ember 2 and Ember CLI (which is some route to go still), I see most benefits because Ember 2 has strong conventions (the way Flow has strong conventions as well); and React e.g. does not tell you which file-structure you should use for writing your modules…

I feel that this discussion in the end it boils down to a “library” (=react) or “framework” (=ember) approach.

To me personally, Dries from Drupal has summed up the state of the discussion really well: Selecting a client-side framework for Drupal | Dries Buytaert

However, I’d suggest to move this discussion (e.g. which FE framework to use) out of this thread… And rather focus on our goals and not so-much on how we want to archive them.

All the best, Sebastian

Hey @sebastian, not to lead the vision discussion astray, will reply here.

Library vs. Framework

I want to tackle the point about Ember having stronger conventions than React/Redux/…/npm ecosystem. After some real life experience, I realized that the situation is quite the contrary:

• React is much more opinionated than Ember in how you do the view. Just try working with it, it will break your leg if you try to do something nasty (e.g. method names like dangerouslySetInnerHTML to set raw html…). React pushes you to write more component-based code, just as TypoScript does (no loops in the templates, you have to define the rendering object and then use .map to iterate with it). Also how the whole app is just a single tree of components and so on.
• Redux is way more opinionated than Ember Data. It teaches you very sound and elegant concepts to state management. You learn the best of functional programming world along the way. Yet the fact that its api surface is so small, allows you to switch its implementation with something different quite easily.
• npm ecosystem pushes you to go with small modules that do one thing well. Also it preaches this openness to all communities, being the one package manager to unite them all, I guess conceptually it’s more opinionated them ember-cli.

But being opinionated and providing strong conventions, is not about being a monolithic brick, and not about setting rigid file structure. To me it’s about providing guidance and setting constraints at hard domain decisions, about inspiring you with a new way thought.

The comparison to Flow is not quite legitimate here though. Flow was written by us and had Neos in mind from the start. If we were a separate team doing something different with it, I’m sure its monolithic nature would play against us.

Both React and Redux have some learning curve, they require you to completely change your habits in a lot of ways. So introducing them to the stack would require more frontend-minded people on the team, doing code-reviews, helping everyone else get on board.
Also both React and Redux have a great documentation and a lot of great video tutorials, so learning it won’t be so hard for newcomers.

Final point: frameworks separate framework developers from their users, considering them to be more dumb than themselves. Library developers stay with you on the same side, they develop something they would use themselves and share it with other like-minded people. Being a professional team full of top-notch devs, I feel we can bare the (opinionated) library approach just fine.

Refactor vs. Rewrite

A few observations here.

a) We plan to replace about everything from current stack:

• VIE
• CreateJS
• Aloha
• Use Iframe
• Inline editing and web-centric approach is no longer the solo goal of UI development. Say hello to mixdecks and structure editing.
• Inspector components require major rewrite to be decoupled from inspector.
• CSS is a complete mess.
• Same goes for validation logic and about any part of the interface we currently have. Everything is so coupled and convoluted, that decoupling it would take tremendous amount of effort.

b) Rewrite at the same time as splitting Neos into parts

We have discussed multiple times that we should split our baby into smaller units with bounded contexts: content repository, universal/isomorphic(!) rendering engine, JS admin interface…

I think this UI rewrite should happen at the same time with Neos decoupling. Provide new UI as a separate package, make it optional, and when it stabilizes make it the default choice. Of course this step requires having some sort of API and getting used to the thought that we now have multiple interface clients.

And no, I don’t believe the full React rewrite would take a year of work…

Compose frontend with npm/webpack

Also continuing the thought of new UI to be modular, I think we should do similar thing to what we currently do in Flow land: have a distribution package for frontend, that won’t contain any code, but rather pull in dependencies from npm and compile them with webpack, just as we do with composer. We may provide the default Neos distribution with pre-built JS code (in the way we still provide zip downloads in addition to composer), so if the novice would want the default interface he would get just that. But say you want to add your own interface modules, remove some modules or build a completely custom UI for your app: there you are, just create custom frontend distribution, modify packages.json and you got it.
And the reason why I think it’s best to get with npm, is that it has become the de-facto package manager in frontend world and it’s not associated with any specific vendor or framework, even projects like ember-cli or meteor allow to use its modules. This way our UI modules would be available to any custom app developers.