The popover drama started with a tweet about how a HEY Calendar popover loaded slowly on a throttled internet connection. Then, a heated discussion followed in the best social media way, including nuance-free hot takes and professional trolls.

The funny thing is that the popover example is not even a good one to fuel a SPA vs. HTML-Over-the-wire debate. It was a trivial change to improve, just preloading the turbo-frame lazily:

But there is a more interesting underlying question: Is Hotwire great for creating modern, highly interactive applications? You can bet it is. 

A calendar is a ridiculously complex product. A tiny crew at 37signals created one from scratch in less than ten months, and it was good enough that thousands of paying customers chose the launch version as their main calendar service. If we haven’t prioritized responsiveness issues such as the popover one, it’s because actual customer feedback made us work on other improvements instead. That's how simple and boring reality is. 

Now, analyzing responsiveness without development cost is misleading. That’s why I made the concept a central part of  this slide to talk about Turbo in my 2023 Rails World presentation:

Hotwire offers different techniques that deliver different levels of fidelity at different development costs. Let me show you three examples from the Calendar (connecting to HEY production from Spain):

Adding todos, which uses Turbo stream actions:

Editing a day title, which uses Turbo Frames:

Creating new events, which renders the whole page with morphing (Page refreshes):

See, different levels of fidelity with different costs. The best part is that Turbo is progressive. It lets you start with the happiest path and deviate as needed. In particular, it lets you launch fast and improve things incrementally, as we did with the popover example. You can be sure we'll keep improving things here.

I wrote about how this model compares to SPA six years ago and those are still my thoughts today. SPA offers potentially great responsiveness at an excruciatingly high cost. In recent years, I've heard countless first-hand stories of products failing to launch because of some SPA horror story. The real world is all about cost/benefit, and plenty of shops choose – knowing it or not – to ignore cost when picking their stacks. As sad as it is, this gives Rails and Hotwire programmers a tremendous edge.

Software development is full of merchants of complexity. They will tell you about great engineering practices and how to optimize for the local, but they never stop to discuss cost/benefit or how the system as a whole will suffer. The recent debate was a great showcase of such a way of thinking.

I saw the term engineering used a lot in this debate. Here's my hot take: an engineer who overlooks costs is a bad one!

Mind the cost-ignorers.