For about half a year to one year, the community is buzzing on headless Magento. For newcomers, it is a little bit hard to grasp why this is needed. Or what it actually involves. And it seems different people decide on the concept for different reasons. Let's dive a little bit in the details of what and how.
The term headless is something I have heard before with automated browser tests (where you script the actions a browser would take to, for instance, add a product to cart). Going headless with browser tests means that you run a browser in a non-graphical environment (in Linux terms, without X-Windows or Wayland or whatever). And this could even be done with a regular like Chrome by running the output in a X frame buffer program.
When people talk about headless being more performant, we will also need to take into account that there is a difference between the Time-To-First-Byte (which will be extremely small) and the Time-To-Interact (when you can actually use the page): Only when the vital parts like products, menu, cart have been loaded, the page actually becomes useful. And this leads to the question whether going 100% headless makes sense. I'll get to that later. Ĺet's focus on the cool part first.
Lately I have been hearing a lot of different talks on different headless approaches: For instance, Sander Mangel talked about creating his own API using Slim to fetch data easily and fast from Magento. Riccardo Tempesta talked during MageTitans Italy about the challenges of integrating ReactJS with Magento. And I have heard many development agencies talk about replacing the current Magento 2 theming setup (XML layout, PHTML templating, KnockoutJS, UiComponents) with their own (Angular, React, Vue).
This is all possible ... with the right amount of time put into it. The main question is why this should be an option for anyone. Personally, whenever I hear about cool technology, I always want to dive into things myself as well. So integrating ReactJS and Magento 2 is cool and as a developer, you should go where the cool stuff is.
However, coolness can not be the only reason to replace KnockoutJS with some other JS framework. We have much more things to consider before we can actually say that Magento should make integrating some other JS framework a priority. What about the amount of work and the costs involved? And does such a framework actually help to improve Magento?
Also, this theoretically would mean that you don't need to be a Magento developer to build cool stuff upon Magento: Instead, you can focus on a REST API that simply offers everything you need to be loading. This, of course, leads to bigger issues: If a single page would be loading 10 different resources from different REST URLs, the HTML document itself would be optimal, but the entire loading time would be hell. AJAX resources would need to be bundled as single requests and perhaps cached in local storage. Believe me, I've built a bridge between Joomla and Magento and the bundling of requests definitely does not make things easier.
Magento offers a flexible framework that you can use to build your own logic (pricing, logins, checkout). However, this contains a lot of additional stuff that you don't need. Building your own pricing rules might be easier than trying to extend and modify the Magento pricing rule system. It might require effort. But you will be dumping a lot of complex logic, in favor of code that simply works the way you want it to work.
I have heard people say that performance would be a good reason to move to a headless Magento. This would require all pages to be served statically, while all dynamic parts are lazy loaded through AJAX. Well, as far as I know, this is already the setup of Magento 2: Full page cache (and Varnish) become possible thanks to the concept of Private Content that allows for this kind of lazy loading. You only have this benefit if you go 100% headless. Or put differently, maximum performance of Magento 2 can be gained by using Varnish only, and Varnish will still limit you here. There have been stories where Varnish is replaced with a NodeJS server, gaining even more performance. But this requires you to go 100% headless because otherwise you still rely on the performance of either Varnish or the Magento 2 backend. Alternative solutions also include building a simple API server that proxies (and caches) data from Magento, but not using a generic pass-through-Varnish solution, but a custom-built solution.
The loading time of the current Magento 2 system (with Full Page Cache being enabled everywhere and
cachable=false not popping up anywhere) is also quite ok for most people (I know, I know, it is open for discussion): It is not 100% headless, because the HTML document not only contains the templating part but also static content that should change less (and therefore should be cachable). It's not a perfect world - it is rather complex and it contains lots of different strategies. But to me, it is already partially headless and Knockout already seems a fine choice, when I compare its features to features with other frameworks like Angular. Obviously, if you have worked a lot of Angular, you would rather see Angular instead of KnockoutJS. But slowly the reverse (favoring Knockout above Angular) is becoming my preference: I like Knockout better than Angular - Angular dictates me to do stuff their way, with Knockout I can build whatever.
Personally, I think having an option for Angular and React instead of KnockoutJS would be very cool. And it would be even cooler if a lot of the Magento core components (UiComponents, libraries, widgets) would be reusable across any framework. However, on a practical side, I see a lot of work ahead before the Magento core components are that flexible that they fit in any frontend environment.
AMD helps a lot, but there need to be more generic libraries with less dependency on KnockoutJS. Because of RequireJS, you can already swap out Knockout with another Knockout-compatible tool (as if that exists out there) and rewrite the UiElement core behavior with your own Angular-based version. But it is not very practical. It is just very cool.
So personally, I would strongly recommend newcomers to work with whatever is supplied by Magento, while experienced JS developers should be able to play with whatever they want to integrate.
To bring the visions closer, Magento could be improved as well:
frontend area, when the API is used to actually serve the frontend area. Otherwise, this leads to many possible bugs that Riccardo Tempesta pointed out in his talk. I think the existing REST API (with its area
webapi_rest) is fine for integration with other systems, but an API for the web frontend simply has different requirements.
The matter discussed here is complex and I have the feeling that I simplified things a lot. When diving into details, there might be many more pros and cons on having headless approaches. Don't bash me too hard. And God, we have not even touched the topics of Lizards & Pumpkins, Single Page Applications, service works and Progressive Web Apps yet.