The case for picking React as the next framework for eZ Platform UI

The case for picking React as the next framework for eZ Platform UI

There seems to be a consensus in the eZ Ecosystem for going hybrid for the refactoring of the UI. André made a good overview of the process and the questions at here. In this post I would like to try and make the opposite argument and argue why we should go for full React as the replacement for YUI.

I know that many of you may have have YUI fatigue at this point, and I really understand that. But that does not mean that we have to fall back to Symfony.

I have followed the discussion on André’s blog post and there is good engagement there but seemingly all comments go towards a hybrid approach. I really like the React approach and currently vote for that, so please spend some time to argue and convince me otherwise. As this is a important choice for the future, and we should not take it lightly.

I will not try to be balanced in this post but to try to make the argument for React hopefully I manage to be a bit provocative also.

Skills and learning something new

It seems to be one of the main points in the comments where people are looking not to learn something new (React for instance). React is not hard to learn, I have taken part in building a couple of applications in React and React Native lately and I did not find the learning curve hard. This should really not be an argument in itself. Yes, it is different than Symfony and PHP, but in a good and complimentary way.

Of course if you consider YUI and have that being the basis of your suggestions, that is fine. But please check out and build an application based on React before really making up your mind. React can be made super structured, modular and pluggable with proper separation of responsibility. Check React out. And listen to developers with more experience than me on the area.

The other side of this is that many of the organizations we are speaking with to adopt eZ Platform already have the competency on React. Meaning that they often have to ramp up on the Symfony side while they have all the front-end skills in React.

We also see that more and more of our customers are moving towards a decoupled approach where they are building front-ends in frameworks like React connecting to the eZ repository when building websites. For example on what The Economist is working on.


The React documentation is quite good which really does make a difference. And there are tons of examples and if you are stuck then StackOverflow is likely to have the answer. This lowers the learning curve. Of course this is due to React being a technology that currently attracts most developers today, globally. This is a very important point of the technology choice.

You might not realize it, but option of hybrid is not just Symfony. For our needs we need more on top, specific concepts to eZ like theming (legacy: design), module controllers. So you basically have Symfony plus eZ specific concepts that new developers have to learn. As opposed to React/Redux where you have many existing concepts and patterns that supposedly can be pretty much reused as is. Meaning potentially lower learning curve for any React developer.

In any case we have to care for the documentation on more scenarios related to frontend and backend developer experience. This goes both for React but also for a hybrid approach.

Speed of application

Arguments that single page applications are slow does not really hold water. React is and can be very fast and snappy. Take a look at for example some of the arguments of Netflix on choosing React. Just build something in React and you see that it can be blazing fast. I will not go into the arguments of virtual dom and automatic optimized rendering based on state changes, others will do that better. But check it out.

Again, it needs to be properly implemented but all evidence points towards React being able to deliver on the high performance low latency aspect. In the end with proper endpoints you by definition can have lower latency as you transfer less data and do less on screen rendering.

So this comes down to REST API, more on that below.

Speed of development

There is no reason why speed of development with React should be any slower than that of Symfony. React combined with solid REST API can be super efficient. You can achieve good re-use of components and increase developer velocity by making sure the business logic is securely managed behind the endpoints. In my opinion this is really a good practice, it is what we see with our customers that implement eZ in a headless way. We have seen good development speeds in these situations.

Right? Speaking when it is well done of course.

Size and momentum of ecosystem

The React community has seen exponential growth over the last two years and are now considered mature and ready for prime time, at least by many. Facebook and Netflix are good examples that are in production. It is really mainstream and has a huge momentum. And it is many people's opinion a fun technology that developers want to work with.

Opening up the power of the eZ engine towards the React ecosystem and tapping into the developers there could be a huge boost for eZ. Looking at Google trends you find that React has about 5x the momentum of the Symfony framework. Combining the two could be a golden opportunity.

Innovation happens really quick in the React ecosystem.

Already using React

Oh, I have to mention that part of eZ Platform UI already uses React with the Online Editor. Not a big point, but a fact.

Loading Symfony rendered components within React

Today there are several parts of the Platform UI that is done in traditional way using Symfony and with Twig templates, for example the whole admin part where you manage sections, content types etc. This loading of Symfony rendered components can of course be managed within React. It could even be made fully based on configuration files so you do not have to touch any Javascript to load these. That basically comes down to application architecture and what we define as requirements.

The opposite of course is true if going hybrid. Where you would need to load React (or other frameworks) within the hybrid Platform UI.

Battle tested REST API

One of the good arguments to use eZ is our REST API. Today we base our UI on top of the REST API which means that it is solid and battle tested, of course we need to improve here also. But if we do not base our own product on top of our REST API we risk that it becomes a side project and gets less priority over time. This must not be the case, and we really need to make sure that our API is really battle tested. A good way to ensure this is actually to base our own UI on top of this.


We are going to improve the REST API in eZ, and a main part of this could be to take more responsibility in the kernel and make perhaps more endpoints for real developer scenarios. By this I mean having one single endpoint that delivers the content and data needed to render a new page, being read or edit mode and other more specific use cases. Reducing latency by basically having optimized calls and reducing UI complexity as the endpoints abstract the underlying complexity.

My opinion is that if you build some solid endpoints that are purposely built to e.g. render a cluster of content items with all required data (Ok, GraphQL perhaps is a solution here), you can have a super efficient developer flow to build UI(s). The same should go for content edit actions, make it simple and straightforward to use the APIs and manage the complexity on the server.

I believe this is two opportunities in one: we can improve our REST API greatly as well as building a more modern and responsive UI with low latency built on React.

The overall goals

To me the main goals of this refactoring project is based around the following:

  • Improve the REST API to make it more efficient in more UI use cases
  • Improvement in documentation for developers and specially adding more use case based documentation
  • Simplify extending the UI and
  • Field types - simplify the implementation of new field types especially how we add UI for them in different contexts. There should be one unified way of defining this UI.
  • Overall take a look at the developer experience and see where we can simplify extension points and/or better document them.

All of the above can be addressed by going full React, but also by going Hybrid. In the end are we just speaking about who owns the routing? React or Symfony? Do you have good scenarios on what concrete scenarios will be hard to extend if we go React.

Good example scenarios would really help here. What would you want to achieve and extend? What is the profile of the developer that would be tasked with that work?

Your opinion?

What is your take on this? Please take a look at React and know how nicely layered and component based you can have it there, it's a whole new world of possibilities! Could we achieve the above benefits with going hybrid also?

Insights and News

By Mateusz Bieniek
12/03/2021 | 2 Min read
By Jani Tarvainen
11/03/2021 | 5 Min read
By Jani Tarvainen
26/01/2021 | 5 Min read