Virtual Code Sprint for the Ember Update. Please vote for a date.
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.
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
dangerouslySetInnerHTMLto 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.mapto 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.
1 Like
I don’t change my point (even if I understand the @dimaip comment).
React with tons of modules, based on our needs, sounds good, but I’m afraid of the nightmare to maintain those dependencies correctly and React + tons of libs will not be a lots lighter than Ember 2.0 
Yes moving to Ember 2.0 is a bit of a pain, but moving to any where else will also be a lots of pain. As we don’t use the Ember routing, an Ember component based apps, as a lots to share with the React alternative. Glimmer (the rendering of Ember) did a pretty good job (in term of performance and memory). The VirtualDOM is nice (and faster), but need higher memory usage, and for a really big UI apps, we need to take care of memory. If we target tablet, memory is a pain point.
The modularization can also be done in Ember. Ember CLI use NPM …
About the decoupling at the same time that the rewrite … I prefer to go step by step and dont push the decoupling too fast. Decoupling require a rock solid API, and creating this kind of API is pretty complex, and can depend on stuff like CQRS.
1 Like
I just can not agree with this. Moving to Ember 2.0 is a huge pain, come join us in @gerdner’s fork. I’m sure the rewrite would be faster, as we have to change about everything.
Sorry, but this sounds as theoretical complaint to me: we can’t be certain of this without trying, and my experience with React projects tell me different. Our main dependencies would be the React itself, which has a clear upgrade path, with deprecation warnings and so on. Stuff like Redux is not really a library but more of a concept, don’t see any problem coming from that, and if we would want to switch it to something else it would be fairly easy to swap it out, because of clear separation of concerns. Take any other dependency like lowdash or isomorhic_fetch: won’t expect anything scary from it…
Regarding the need for solid API: yes it’s true that we need it. But it shouldn’t stop us from UI development: the part that is facing the API should be encapsulated and easily manageable, then we can always adjust it if things change on the backend side.
Anyways, I’m tired of JS discussions without seeing any code. @robert had said yesterday that there is already some React prototype done by Sitegeist guys. I think we should look at it once it’s published and then re-evaluate the decisions we had taken here.
Moving to Ember 2.0 is indeed a huge pain. I think without @aertmann i could not contribute a single line of code.
I don’t know if a rewrite would be a better idea at the moment. We definitely have to rewrite a lot of stuff anyway.
But i’m a big fan of ember and ember-cli and i don’t like react/jsx for various reasons. But that doesn’t matter. It’s more important that we get things done. Currently 70-80% of the work is done by @aske. Is it because no one else has time or are there people who doesn’t know where to start (like me 
).
I’m completely lost in the contend module if there isn’t somebody around the corner pointing me in the right direction.
@dimaip also tried to contribute to the ember update and got similar problems.
So what can we do to make things easier. If a complete rewrite is more work but everyone has a smile on his face i’m ok with it. And i think more people would join the update if we can give them a good starting point.
Like “we have prepared a list/concept of all components of the content module, pick one and start your work”.
And not like “Image Editor is not working - view is destroyed but i don’t know why”.
Hey everybody,
I’d like to ask @christopher about his opininon as well, so feel pinged
BTW: We’ve recently moved a HUGE Ember Codebase from 1.05 to 2.2 (at a customers from us); so my colleagues in Dresden have lots of experience in updating Ember code. If we decide to go for it, I am sure they’d very happily join forces with us during the code sprint in March!
All the best,
Sebastian
3 Likes