Ruby on Rails Creator Takes on JavaScript Frameworks with Hotwire – InApps 2022

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.

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 complementary [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 use to be.”

Is Ruby front end or backend?

Ruby is a Backend language like Python or PHP. Ruby is very best for the Backend easily can connect with SQL and other databases and very great report and crud management.

When should you use Ruby?

If you have specific budget requirements or have to meet tight deadlines, Ruby, or more specifically Ruby on Rails, is a great choice. It is popular among start-ups and small businesses because it allows for quick prototyping and development, even when there’s no clear scope or the scope is likely to change during the implementation phase.

Particularly important types of apps where Ruby on Rails fits into the tech stack are custom web apps, such as e-commerce solutions or streaming services. Ruby is also capable of creating web applications with lots of different functionalities.

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 HEY stack:
– Vanilla Ruby on Rails on the backend, running on edge
– Stimulus, Turbolinks, Trix + NEW MAGIC on the front end
– MySQL for DB (Vitess for sharding)
– Redis for short-lived data + caching
– ElasticSearch for indexing
– AWS/K8S

— DHH (@dhh) June 24, 2020

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? Contact InApps to get a consultation for your need.