Development / Tools

Ruby on Rails Creator Takes on JavaScript Frameworks with Hotwire

8 Feb 2021 6:00am, by

Ruby on Rails creator David Heinemeier Hansson recently spoke at a virtual meetup of the Chicago Association for Computing Machinery (ACM). Hansson, who has been at the forefront of web development for the past 15 years, talked about the state of JavaScript frameworks today, frontend development trends he’s tracking, and a new framework he helped create, called Hotwire.

Richard MacManus
Richard is senior editor at The New Stack and writes a weekly column about web and application development trends. Previously he founded ReadWriteWeb in 2003 and built it into one of the world’s most influential technology news and analysis sites.

Like Ruby on Rails, Hotwire has been released under the stewardship of Basecamp — the company Hansson co-founded alongside CEO Jason Fried and others. Hotwire offers “an alternative approach to building modern web applications without using much JavaScript.” It’s described as an “HTML-over-the-wire” approach, meaning it generates the HTML file on the server and then delivers it to the browser. It’s an alternative to delivering JSON, a data format used by many JavaScript-heavy web apps to send content from the server to the client.

When Hotwire was announced to the world in December, Hansson tweeted that it’s an amalgam of “all the tricks and tooling we used to build the front-end for https://hey.com.” He was referring to Basecamp’s web email product HEY, a Gmail competitor that launched last June. So Hotwire has a similar origin story to Ruby on Rails, which emerged out of the Basecamp product in 2004. Although, unlike Ruby on Rails, Hotwire has not (so far) been open sourced.

Part of Hotwire is the Turbo framework, which Hansson described as “a set of complimentary [sic] techniques for speeding up page changes and form submissions, dividing complex pages into components, and stream[ing] partial page updates over WebSocket.” He added that all of this is done without JavaScript.

During the ACM interview, conducted by Heroku’s Valerie Woolard, Hansson said that Hotwire was his “default recommendation” now for people building a web app similar to GitHub, Basecamp or Shopify (three of the most popular apps built using Ruby on Rails). He also explained that Hotwire was developed as a way to tackle the increasing complexity of JavaScript-based web development.

“Developing for the web today is seriously complicated […] because the frontend is seriously complicated,” he said, citing “setting up your build pipelines and webpack configs” as two examples. He added that building modern frontends “is really intimidating and it’s segregating in a way that [it] didn’t used to be.”

Is Hotwire Competing with JavaScript Frameworks?

Naturally, Hansson is still a believer in frameworks as a way to simplify development. While he’s now focused on promoting Hotwire, he noted that Ruby on Rails is still going strong — and indeed was used to build HEY.

The heyday (bad pun intended) of Ruby on Rails was in the Web 2.0 era, but in many ways it paved the way for the popular JavaScript frameworks of today — React, Angular, Vue.js, and others.

However, Ruby on Rails is also competing with those JavaScript frameworks — at the very least for developer attention — and so Hotwire has to be viewed in that light too. So I reached out to Daniel Kehoe, who ten years ago founded the RailsApps open source project and wrote the book Learn Ruby on Rails. Nowadays, Kehoe runs Yax.com, an open source project that promotes a “no-framework” web standards approach to web development.

Kehoe thinks Hotwire is interesting “because it shows how Hansson wants Rails to remain useful and relevant for full-stack development.” Since Ruby on Rails runs on a web server, it is generally seen as a backend framework. But Kehoe’s point is that Rails wants to remain relevant on the frontend too, especially given how important JavaScript is in today’s web.

“The alternative was to allow Rails to devolve to purely a framework for backend applications,” continued Kehoe, “leaving the frontend to React and other JavaScript frameworks. Hotwire (with WebSockets and Action Cable) shows how Rails can be used for an interactive front end as an alternative to React etc, extending the range of uses for Rails beyond CRUD [create, read, update, and delete] apps.”

It’s true that Hansson wants to make the entire web development stack understandable for web developers. He has a pet theory for this, called “conceptual compression,” which he referenced several times in the ACM meetup.

“The whole ethos of Ruby on Rails is [that] everything you need to build great applications” is available to you “most of the time,” Hansson said. “You take something that’s really hard and that requires specialists to understand, like setting up your JavaScript build pipeline, and you compress it all the way down until it can fit as one slice — out of many other slices — into the brain of a single developer.”

This is basically what JavaScript frameworks like React, Next.js and Angular try to do as well. Indeed, it’s an increasingly popular approach for many aspects of web development nowadays — CSS has its own frameworks too, such as Tailwind.

In regards to Hansson’s “conceptual compression” theory, Kehoe says that Hotwire “presents an alternative approach that builds a ‘majestic monolith’ in Rails with a mix of JavaScript.” But Kehoe, who has worked “as a director of engineering at a company with an unwieldy Rails monolith,” is not convinced this is a good idea.

“On the back end, Rails reliance on Active Record as an ORM [object-relational mapping] to a single database leads to large cumbersome applications; adding Hotwire to the front end (instead of separate front end applications) just makes the monolith bigger.”

His point is that JavaScript expertise will still be required to run an app that uses Hotwire, which means the web development process will remain complex in such a system.

“Hotwire is an attempt to reduce the amount of JavaScript required,” Kehoe said, “but there’s still JavaScript and there’s still a need for developers with JavaScript skills as well as Ruby skills. Specialization will continue; maybe with the new Rails, really smart full-stack developers (like the ones at Basecamp) have enough skill to do both front end and back end. But I’m still concerned that web development has become too complex for many casual or part-time web developers.”

The Future of Frontend

So David Heinemeier Hansson wants a piece of the frontend framework pie; and with his track record revolutionizing backend development with Rails, you’d be a brave developer to dismiss his ambitions for Hotwire.

Hansson is excited about “what’s coming after this wave of JavaScript we just went through” — referring to the past decade of web innovation fueled by JavaScript and the increasing sophistication of web browsers like Chrome. He believes Hotwire can help simplify frontend development, just as Ruby on Rails did for the backend.

“I care about the whole web stack,” he said, “and for a long time I cared a lot about the back-end. Now I feel like there’s such an opportunity on the front-end — Hotwire, in-browser ESM [EcmaScript modules], ES6. We can finally kind of dump a lot of the shim, the bootstraps, the stuff we had to do to make JavaScript livable for the past few years. Now we don’t need them anymore — all that scaffolding can be torn down.”

The JavaScript scaffolding may indeed be coming down, but the question now is: whose framework will you build with instead?

Lead image via Pixabay.

A newsletter digest of the week’s most important stories & analyses.