2.x refactoring work, round one: Deciding on UI Technology

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.

Before we begin

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 problems to solve

The most important high level issues we are getting from recurring feedback from partners, customers and community members are the following:

• Takes too much time and effort to customize and extend the platform backend UI
• The PHP APIs needs to be easier to use and better match common use cases.
• The REST API feels complicated to use and extend, especially for UI work, including our  own built in UI.
• Hard to find relevant documentation (ongoing work)
• Stability of the platform (ongoing work)

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!

Requirement: Keeping our API BC promise

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.

Additional context for picking UI technology

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.

Picking a UI Technology

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:

A: Change to hybrid model

• A base built on traditional parts using latests standards (HTML 5.1, ES7, ..), Symfony, Twig, theming, and potentially more reusable "modules", aka reusable controllers.
•  
  • Alt i: Relay & React, ii: Polymer v2 & JSON API, iii: ??, but this is for next round.
  Selected rich parts using a front and a backend technology which integrates natively (no/less need for custom rest client), and solves the REST round trip problems
•  
  • Not considered modern? Same argument that made us choose rich YUI app
  • Hybrid, as opposed to pure traditional or pure JS application adds complexity for having to make several technologies work seamless together.
  Downside

B: Change fully to single page JS application using REST

• Like rich part in A, using for instance React/Redux/Relay over YUI, including REST API made for UI use
• Downside: Slower to develop given it’s a separate application which needs to duplicate logic we already have in eZ Platform application layer. Several of our partners have a clear preference for a solution closer to Symfony so they can enhance UI much faster.

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.

The open question for now

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!