Ah okay, my bad. Assumed so since we decided against it in back then. Would be good to start collecting ideas for how that could work. So far Orbit.js and ember-data have been suggested, other suggestions?
This is more or less my POV too. But before being too quick in a decision where we don’t understand the alternatives fully, we thought about having a prototype to demonstrate the architectural idea of the alternative of staying with Ember.
One point where I can’t agree is that the Neos backend needs only a small feature set for the upcoming years. I would have an easier time to explain that if we had a nice shared vision on what Neos should become. But I really don’t see Neos only as an augmented website (and a site builder / editor). If we want to be less web-centric and lay the foundation for COPE or just more output agnostic publishing we need to consider not rendering a website in the first place. IMHO the Neos backend needs to consist of different modules (pages) that are configured with components (adjustable by an integrator / site developer) so it can be adapted to different requirements for content creation / editing / preview&publishing. And having a mixed architecture with app-style JS combined with server-side rendered modules and sprinkle-style JS (like we have now with the media browser) is really something that keeps us from providing the user experience we want/need to have.
2 Likes
Hey, missed the meeting too and would’ve loved to be kept in the invite loop a bit more.
Overall I’d like to shortly explain an idea I had. We’re starting to develop an application in which we need frontend editing and part of the components of Neos. We can not use the full interface of Neos though because it simply doesn’t fit our needs and leads to too many problems.
This basically means we have to write a UI anyway, which would imho be component based and in many parts similar to Neos. We would make the code opensource and could easily accept feedback, code, improvement ideas, and so on. What if we, as a preparation and way to gain experience, start working on that package (that would contain the most ideal UI structure for an application that talks to a REST API of the content repository) and open it up to the Neos team to squeeze everything out of it?
Depending how this all evolves we could decide if the package would be a solid foundation for Neos. Also I’d love to have more eyes on the package anyway so we can discuss and use it together.
Furthermore I’m (reckless as I am) in favor of a rewrite because I just don’t believe that we can patch the code into a clean cope-able thing. But I definitely see the risk of it, so project wise I tend to be with @aertmann here. Let’s move with caution and stay away from the risk to take too much work at our shoulders by completely rewriting Neos UI stuff inside the package now.
Maybe “bare mininum” was a bit misleading. What I actually meant was the exact set of features that are required by Neos, so without the overhead that is inevitably introduced by a full framework (which would lead to the custom ember build, @sebastian mentioned earlier). That set is of course not necessarily small. And I absolutely agree, that the backend itself should have a rich feature set.
I think we’re on the same page here (a stronger outlined vision wouldn’t hurt though 
) and I’m also interested in helping Neos to get pushed into that direction (while I assume you don’t mean to drop the current editing experience entirely though, but merely to embed it into a greater COPE-oriented context, right?).
I do also agree with @aertmann on the business concern. Proceeding on a step-by-step basis, might be the way to go here. Nevertheless, since we all pretty much agree on dropping vie, create and aloha obviously, there is still quite some stuff inevitable to be rewritten imho. That does not mean, that we actually need to rewrite the whole thing, but it does give us opportunity to have a closer look on what can be improved along the way.
You’re right, we didn’t manage to clarify our idea yet. And I’m under the impression that we’re dealing with a lot of misunterstandings due to this. But @inkdpixels, @akoenig and I are currently putting our heads together to write up a detailed outline of what we have in mind alongside with all the concerns we have right now.
Actually I see a lot of common ground and that we’re not that far apart. I do believe that we can develop a mutual vision of this.
1 Like
Absolutely! I think the editing proved to be one of the strongest selling points for Neos so far. It just should be one of many ways to create / curate content. And for some projects it might not be suitable, or just for defined use-cases (e.g. by node type / editor role / task).
3 Likes
Here is something on the use if iFrames I just found (again): https://forum.typo3.org/index.php/t/203717/ Might contain some helpful info, it seemed promising back then.
Yes, that prototype actually looked very promising. But we never got any feedback from the original author again. Maybe he’s still around somewhere?
Hey everybody,
at the Code Sprint in Frankfurt we had a partly-remote and partly-local meeting with the following participants:
- Aske Ertmann
- Christian Müller
- Rens Admiraal
- Sebastian Kurfürst
- Dmitri Pisarev
- Dominique Feyer
- (some more people where I cannot attach faces to names yet
) )
In a nutshell, we summed up the current state, and then directly deep-dived into the Ember vs non-Ember Discussion.
Basically I had a discussion with @dimaip on Ember vs React where we dissected the technical parts, where the others were listening in. The main points are:
- We all agree that Data-Down-Actions-Up is a great thing we should follow.
- We all agree that a componentized structure is a great idea.
- We agree that Ember is a more “monolithic” framework and React/Flux/NPM modules is more a mixing-different-libraries approach.
- I (Sebastian) favor the more monolithic Ember approach; Dmitri was in favor of the mixing-different-libraries approach.
- Interestingly, what the one sees as benefit, the other sees as drawback in this regard. So we agree on the facts, just tend to weight them differently.
- We agreed that we would be able to build Neos with both ways generally.
After the technical ping-pong between Dmitri and myself, more people chimed in and brought other (more non-technical topics) onto the table, the main one being:
- We think it is not feasible to start-from-scratch, but rather we need a way to mangle our current architecture into the new direction without rewriting everything. In the view of (at least) Rens, Aske, Dominique and myself, this is the main reason we’d like to use Ember 2.0.
That’s why in order to move forward, we settled the discussion and decided to use Ember 2.0. @dimaip said he’s also OK with the decision, and he sees the points being made. Aske said something like “for personal project or if I’d start from scratch, I’d probably go the React way, but the existing codebase and the incremental migration possibility is the big argument in favor of Ember”.
The roadmap on top of the RFC is still generally correct; I’m just updating some details to reflect this decision.
All the best,
Sebastian
7 Likes
the two guys standing around where @alexfruehwirth and me 
We will gladly participate in this project, altough i have to commit that we don’t have a whole lot experience in Ember (2.0), but we’re very eager to learn.
If you throw us bits that we can chew i’m very positive that we can certainly help you with the refactoring.
6 Likes
Since i got some experience with Ember 2+ i could try to help.
First step would be to move the current work to Github (PR) and discuss changes over there?
I also got some experience in migrating an ember project from requirejs to ember-cli so i’m trying to work on that too.
7 Likes
Hey Philipp,
would be great if you could explain a little how this process works
Thanks so much,
Sebastian
Hey @gerdner,
We’re now working with ember-cli too, and I was thinking about how to apply that to the current Neos code. But if you already have experience there I’d love to have some kickstart 
Maybe we should see if we can plan some hours that we work on the topic?
1 Like
I imported initial work from gerrit into github.
“https://github.com/neos/neos-development-collection/pull/116”
(i can not post more than 2 links :))
First step is to finish and test this work. At the moment, ember 2.beta ist commited. We should update to the last stable version 2.1 and start testing. I updated to Ember 1.12 in the past and only small problems in the build process appeared.
“We propose to have intermediate steps which can be merged directly in Master; trying to avoid a long-running fork.”
So after the update the could merge the result.
Next step is to migrate to the new folder structure from ember-cli.
I recommend to use the ember-cli pod structure since we want a component driven approach in the future.
- rename files so the ember-cli-resolver can resolve them (pods?!)
- copy files by type (views, controller, components etc.) to their pod folder
- migrate to ES6 Module loader (busywork) (i got not much difficulties in the past with that part)
- introduce package management via bower for browser dependencies
- list all current dependencies with their current version and put them into a bower.json
- migrate the build process to broccoli (perhaps very difficult - i don’t now the current gruntfile so i will have a look on that)
- have a look on the requirejs parts one the php side (yaml-config etc.)
Migrating to ember-cli is a very big step. So perhaps we could takle that on a code-sprint or something like that?
My first thoughts so far 
@radmiraal yep! 
1 Like
@gerdner: I agree that having something like a codesprint would be best, but I also think it isn’t a topic where a lot of people can work on so probably having a small group makes sense. What about a virtual sprint in which we work on the topic for for example 2 days and see how far we get? Or try to find a place somewhere half way where you live and my place and meetup?
2 Likes
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