Experts Blog

Virtual DOM and a predictable state

  • Fredi Bach


Virtual DOM based libraries where you work with a declarative UI, using components and not direct DOM access like in the past, and Flux libraries that gave us a predictable state to work with, are arguably the two most important innovations of recent years in frontend app development.

Facebook was leading the way here, first with React and later with Flux. Now we have a wealth of great libraries using components and virtual DOM, with React still being the main player. On the other hand, the flux pattern did go through many different libraries and implementations till Redux finally won the hearts of most serious web application developers.

That in mind, it was good to see two serious talks at this years Frontend Conference about those two topics. First was Pierluigi Pesenti with a very risky live coding talk about a handmade virtual DOM implementation. I was really curious about this one, as just a few days ago I stumbled over a talk by Jason Miller, the creator of Preact, a fast, small and probably the most popular React alternative, that was quite enlightening. Definitely a must watch! How did Pierluigi fare against him? Having in mind that this was Pierluigis very first talk ever, and that he was live coding the biggest part of the talk … well, live commenting in and out thankfully, I would say he did quite well. However, I think the talk could have been much better if he would have concentrated more on key features of a virtual DOM implementation like the abstraction of the DOM and the diffing process (aka reconciliation), and less on other less important implementation details like on how to implement ES6 features without Babel, that would have given him a little more time on explaining the really important parts. And I would have liked to see him explain the importance of element keys, as did Jason so well in his talk. I’m not 100% sure, but I think he completely missed this very important feature in his simple virtual DOM implementation. Overall, it was still a very interesting talk and with a better focus on the key parts, I’m sure his next talk will be a must watch.

Later came João Figueiredo with a talk on the topic of framework-agnostic web applications with Redux. João started the talk with a good overview of the current state of NPM modules and frontend libraries we use and that hardly anyone can catch up anymore these days, causing a kind of fatigue that was quite the intense topic between developers worldwide for a while. He made a very good point that we should care more about making great products, than following every new trend. And he identified Redux as a good candidate to have as much framework agnostic code as possible. In his talk he compared React, Angular and Vue implementations, how Redux fit into them and how much code could be shared between those implementations, so that replacing a framework later on would be as easy as possible. While Redux makes it possible to put a lot of the business logic into reducers and it made the concept of container components quite popular, the different frameworks still made the implementation details of the view logic quite coupled to the implementation details of each of the three frameworks. We certainly still have a long way in front of us till we reach a truly agnostic frontend framework codebase, but it’s good to see that we are moving in the right direction. One thing is for sure, the web will keep changing, and we should continue to work on finding ways which help us to embrace change when the inevitable happens and a better frontend stack arrives once again. For the moment I think we’re in a nice consolidation phase where all popular frameworks promote the same key concepts, a declarative component based world with predictable state and happy developers. And for that, Redux, together with some additional libraries to make writing reducers easier, is certainly a very good way to go.

Headless at EnergieSchweiz: Where Everything Interacts

A headless content management system alone is not yet a website. A Kubernetes cluster cannot deploy anything on its own. It is only when architecture, code, tools, processes and people are allowed to interact that the adjustments made to the content in the CMS trigger an update in the statically generated website.