What happens when an escalator breaks? It turns into stairs. You may have heard this metaphor for good engineering and design. This philosophy is particularly relevant and dare I say crucial in front-end web development because the browser is the most hostile runtime environment. HTML and CSS are declarative and extremely fault tolerant; JavaScript is a very successful and mature language, but by its very nature it’s the most brittle layer of the front-end when we consider that it’s expected to execute on a wide array of devices with wildly different capabilities, hardware, and network connectivity. JavaScript can break in surprising ways, and more often than we might like to believe.
I’ve been a web developer for over two decades, and while I write lot of front-end JavaScript, I’ve seen so many web sites and web apps break utterly due to a single point of failure that predictably fails. Because of this, I bake progressive enhancement in at a fundamental level into everything I do. This layered approach gives your site or app significantly better chances to continue performing its core functionality even under messy and unexpected conditions.
Server rendered or bust
Whether we like it or not, servers are the most reliable and controlled environment for executing complex code.
When someone claims server-rendered HTML can’t compete with a decoupled front-end written purely in JavaScript, I just hear an interesting engineering challenge waiting to be solved. There’s no technical reason that we can’t have smooth page transitions, partial page updates, and much more with all the security and resiliency that server-rendered HTML provides. The rise of htmx and Hotwire Turbo have demonstrated this.
Drupal
Drupal is server-rendered and extremely optimized for this out of the box with complex and flexible structured data along with a very robust and fast caching API. In my experience, if Drupal is slow, it’s usually because someone made it slow by not prioritizing caching, asynchronous processing of computationally expensive tasks, and so on.
So with that out of the way, can we make it work in Drupal? The answer is unequivocally yes. I spent many long days and nights modernizing and rewriting the RefreshLess module - and finding new and interesting ways to break Drupal in the process. It doesn’t just work on the public parts of a Drupal site but the admin areas as well. Don’t believe me? Here’s a video I recorded of myself navigating and editing things in the Omnipedia admin area with the Gin theme.
Next steps
I’ve developed RefreshLess to its current (fairly usable) alpha release on my own, but imagine how much further we can take it if several people collaborate on it:
- Partial page updates and page morphing
- Streaming page changes in real time using Mercure
- More tests
- Porting it to htmx
- BigPipe support
- And much more
Conclusion
So what happens when our escalator breaks? It turns into stairs. We owe our users that level of resiliency and redundancy.