Like @sebastian I’m sure a similar prototype could have been achieved with Ember 2 in the same timeframe. Also took quite some time to read up/inspect on this, think and respond.
Unfortunately this whole discussion is being complicated with the whole React vs. Ember question. I don’t want to argue for or against here, just that I’m confident both will work out well.
What really matters is the question of doing a complete rewrite. Seeing a prototype like this doesn’t really tell much in my opinion. We had a similar prototype a couple of years ago, and it took a lot of effort to reach a state of stability and detail we have today. Version 1.2 was “usable”, 2.0 was “okay” and we’re still not near “great” in terms of being bug free and having a good user experience. Doing a completely rewrite will put us back to that state. It seems like I’m the only one who has the view, but I feel confident with it because I’ve built this before and know just about all the code. Changing foundation is not magically going to solve the problem of stability, it takes iteration, which takes effort/time. I’m certainly one of those who has spend the most time doing these fixes/improvements, the commit history proves so, and most of it has been on code others have started. So simply don’t see why this would be any different on this prototype compared to the one build by @sebastian and @hlubek. As much as I’d like to have a new code base instead of improving and old one, I can’t justify it as a business decision. To me it’s really about developer happiness, not about providing the most benefit to the end users.
Neos is currently at a point where people expect stability and thus the new UI cannot replace the existing before it’s on par or there are enough pros/cons to justify it. The idea of having two separate UIs simultaneously can certainly help, but at the same time it halts development and makes the process even longer.
Going step by step, improving one area at a time and releasing to the public is a much safer bet and can be done with far fewer stability concerns. It also allows us to keep all the already stabilized/polished parts and replace parts when there’s an actual end user benefit rather than just refactoring for the sake of refactoring. I’d much rather spend my time providing additional value than reimplementing things we already have for my own benefit.
Just to give you guys an idea of how much functionality there is to reimplement, I started a document describing the functionality of the UI while working on the upgrade. Even documenting it is a daunting task and only about 20% done in it’s current state.
I also see this as a very high risk project and one I fear will have one of two outcomes: 1) it takes way longer than expected or 2) the current state is replaced by a less stable/not on par state due to lack of resources/motivation to reach it. I’m not a big fan og high risk projects, especially when the biggest benefits are not towards the end users.
I do however support the whole concept of decoupling the UI into a separate package, although this can be done regardless.
One thing I’ve asked for before is an estimate on how much effort you think is needed to reach the current UI. The following question is the likelihood of there being people willing to put in that effort and when will they have the time for it, since that will affect the timeframe. This might be much to ask, but perfectly normal when making decisions like this. Otherwise it’s all on a whim, which is certainly not something I can base such a decision upon.
I hate to be the conservative negative grinch, but I simply cannot support a rewrite. Hope you can understand my reasoning why.
And keep in mind, we all want a really nicely build application, but how we get there is the question. And creating a prototype of our vision is certainly no waste of time, even if we don’t adopt it.
Btw. it’s mentioned we’d gain new contributors, we might also alienate some.
Counter arguments very welcome.