This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal
By
Monday 09 January 2017 6:45:34 pm
With 2017 here, and 1.7LTS out the door, we have started to work on the largest change planned this year where we’ll need lots of involvement for the ecosystem: A 2.x refactoring project, starting with making UI technology choices.
So it’s a new year, and I don’t know about you but during the holidays I celebrated that we reached the first LTS release that can be allowed to stabilize for a long time. And while we have a few more xmas bells and whistles still coming for 1.x, it’s now time to start to shift focus to 2.x as talked about last fall, first starting with refactoring work.
And while there is a lot of things coming, some of which are covered on the 7.x kernel PR that was opened earlier today, we’ll start with one open question that will influence a lot of the other work we will do for 2.x: UI technology.
Beyond the need to move away from YUI technology, you might have seen that we plan to do several other changes and perhaps wondered why we don’t just swap out the UI framework. In short there are several other problems we need to take into account.
The most important high level issues we are getting from recurring feedback from partners, customers and community members are the following:
In summary, the experience when developing on the product must be greatly improved. Developers may have a hard time getting into it and may often end up frustrated for several reasons.
But YUI itself is not the only reason for these issues, so just changing technology will cost us a lot of developer months, if not years, but won’t get us much further. We need to aim higher!
Before we jump into the prospect of changing technologies, as we adhere to SemVer, a new major release gives us a lot of freedom to do the changes we collectively see fit.
However we have a API Backwards Compatibility promise to keep here which goes across major versions, as its aim is to make sure projects using eZ Platform can rely on it for a long time. This BC promise currently covers our REST API v2 and PHP Repository API, both covering the full feature set of the eZ Content Repository. In other words, while we’ll introduce new and improved API’s, we will not break the API’s unless a given method or endpoint has been long deprecated.
Reusing section from last fall's 2.x and beyond post:
Context for picking new technology: Current UI approach of 100% REST based, single page application for Content management has provided benefits like making sure our REST API is truly cable of handling all repository features. But it has also slowed us and partners down as opposed to a traditional model using Symfony for the overall UI handling. It has also tied us deeply into one single framework in the fast moving frontend space, something we need to avoid repeating in the future and thus decouple into components so we can gradually replace them with other technologies on a case by case basis.
Now given all of the above, before we can pick a given UI framework or another, one glaring question is confronting us. And like other decisions afterwards, this is one we would very much like to involve community and partners on: what kind of UI technology we should choose.
The high level alternatives are:
Either way (A or B), we are approaching this as a refactoring project, and not as a greenfield project. That might imply refactoring existing YUI components to continue work on top of the new UI foundation short term, then gradually rewrite them one by one as either traditional or rich components later. That way we potentially won’t risk spending a year or more just rewriting code without being able to release stable versions for projects to try out and give feedback on.
Also, both alternatives above still implies lots of work on Symfony stack to simplify fronted dev, including full UGC (getting edit capabilities on the frontend as much as on the back end to natively use the same component), API changes, and changing the UI architecture to make it more efficient to work with.
So while my current preference, which is colored by last years feedback from new and old partners and community members, might be clear from the quote in Additional context section above.
What is more interesting at this point is hearing what people in the ecosystem would choose between A or B? Hybrid, or pure javascript app? Which one fits your usage the best, and why?
Please comment below to take part of the discussion if you can, it will be helpful as we’ll try to make decision on this next week to move quickly forward on the more detailed question!