I am a backend developer at heart. While I appreciate looking at a nicely designed website, my personal strengths lie with architecting backend applications, processing data and using the web protocols to communicate.

For the last 10 years, I was fortunate to work on a large pure backend application that gathers product data from some 40 sources, aggregates it into a consistent representation and uses Elasticsearch to offer a real-time REST API. The output is raw JSON or XML data which is then used by frontend applications to render nice websites. Now that our customer internalised the project, I got to work on several projects that involve actual web frontends. I got to rediscover the state of web browser technologies 10 years later. Let me share some love and hate.

CSS

Last time I did CSS, the debate was between lesscss vs sass. I contributed the lessphp integration for the PHP library assetic.

I was thrilled to discover that all current browsers support the CSS3 features of nested CSS out of the box. (Well, mostly. Chrome has this annoying bug for nested qualifiers: If one qualifier is unknown, instead of ignoring that and everything inside it, chrome ignores all nested qualifiers in this definition. Not ideal when the CSS minifier generates legacy support moz- prefixed copies of some definitions)

CSS also got selectors to check on parents, allowing some neat things like CSS only collapsibles. Looks like the browser developers hated jquery so much that they set out to make it entirely obsolete šŸ˜‚. (Note that the specific example of collapsible is a bit contreived - you could also use the <detail> HTML tag to get most of that functionality without needing any CSS logic.)

I also discovered CSS grid, which is amazing at arranging content on the page with nice spacing and responsive design. Thanks for the enthusiastic introduction by my colleague Pascal Thormeier - he even wrote the actual printed book Mastering CSS Grid.

Tailwind CSS

I had to use Tailwindcss on several projects now. I was promised that I would grow to like it. But so far that has not happened. To me, it feels like a poor excuse to write inline CSS all over the place. And because everything is expressed as magic class names, I have to constantly look up things that I would have known how to write in plain CSS.

I much prefer to globally define the default layout of my page elements and introduce semantic classes for certain elements as needed. With nested CSS, this can often be a single class on the container to namespace rules. The whole <h1 class="h2"> situation seems quite ridiculous to me.
I found this blogpost by Aleksandr Hovhannisyan goes into great detail with discussing the issues with Tailwind.

Frontend Applications

Over the last decade, single page applications became quite popular. When done right, they provide a great user experience, being quick and responsive. In 2024, there was quite a hype among Javascript developers who re-discovered the advantages of server side rendering. Rendering on the server is both easier because all the data is available and you donā€™t need to duplicate model classes let alone business logic, as well as less prone to security issues.

Backend rendering (or static HTML) is how the web was originally conceived. However, for a long time, backend rendering meant that the browser had to fully load and render the page after each click. This is slow and does not look particularly nice.

Hotwire Turbo

Instead of backporting frontend frameworks to the server side, a much easier and straightforward option showed up: Hotwire from the Ruby on Rails community proposes the Turbo Framework. The basic idea is to use ids in the HTML and allow the backend to replace targeted fragments instead of the whole page. A lightweight Javascript wrapper handles form submissions asynchronously and replaces the fragments.

With Turbo Streams, it is even possible to use Server-Sent Events (SEE) to update other clients that are browsing the same site with minimal effort both for the server and for the client.

Stimulus

The Stimulus framework is Hotwireā€™s solution for when actual Javascript is still necessary. With Stimulus, HTML is in the lead. Stimulus is only about the glue code to provide custom interaction to HTML elements.

Being driven from HTML, it plays well with Turbo. When Turbo replaces a fragment, the stimulus controllers are automatically rewired if the new fragment has Turbo attributes.

I quite like the approach, particularly that I explicitly control wiring and data from HTML. The only gripe I have with Stimulus is that the wiring is based on naming conventions between the HTML attributes and the stimulus controller, and there is very little error handling. For the most part, typos just lead to silently nothing happening, instead of errors in the browser console that would help to debug the issues.

Closing Words

Working again with frontend applications was a fresh experience, and I was able to quickly learn and apply Stimulus and Turbo expecially on the Liip project to build a tool for the W3C Sustainability Guidelines. I also wrote a non-technical blogpost about the project titled Simultaneous editing: Easy mode with Hotwire