Par |04 février 2021|Entreprise, Tech|

David Heinemeier Hansson​, creator of Ruby on Rails, cofounder & CTO at Basecamp, but also NYT bestseller and leader of opinion with his books Rework and Remote, agreed to talk with the ​French Ruby on Rails community about ​Hotwire​ as an alternative approach to building modern web applications. During an exclusive fireside chat with WizVille at our January 27th event, « Dreaming Bigger with Rails« , he answered our questions about the potential and upcoming improvements of this new technology.

Check out our summary of the main points we covered or scroll down to watch the full interview with David Heinemeier Hansson:​

Why Hotwire? What problem did you want to solve?

Why Hotwire - WizVille Interview With DHH
It’s been a problem we’ve been working on for about 15 years, which is “How do we make web applications feel great and fast without making the development experience feel like shit?” And I think we’ve solved the first part of that in a lot of environments, but the development experience we get is now so much worse than what I grew up with.

Hotwire is essentially « How can we get the best of both worlds? » Can we get the user experience that feels just as good, just as fast and fluid as the single page application and pair that with the best development experience for the web we can imagine? That’s the winning combination.


Why do you feel this approach is the future of modern web app building ?

Hotwire for future of modern web app building
I think the interesting thing about Hotwire is that we’ve been using the techniques or similar techniques for a very long time but we’ve never really shared them in a cohesive, complete fashion. Hotwire is a combination of things that fit together really nicely to the point that its essentially – or can be for many applications – the complete answer. You don’t need anything else! I think that’s a major step forward, in much the same ways that Rails was. 

Also, Hotwire is not just a code dump. We did the whole thing: we extracted it nicely, we made it fit together, we documented everything and almost as importantly, we branded it! We have everything to kickstart a movement. And that’s one thing I’ve learned with Ruby on Rails, it’s not just about the technology, you need a movement, you need to excite people in the same way someone gets excited when they see a great piece of advertisement. Which is funny because I’m not otherwise a big fan of advertisement. 


Are you gonna save us time with Hotwire ?

Hotwire for developer satisfaction
I’m going to save you time as in “you can measure this on the clock” but also hopefully dramatically increase your satisfaction.

The reason I like ruby is not just that it saves you time and helps you be more productive or whatever…Ruby is poetry, ruby is a feeling, ruby is more than just a programming language, it’s a love letter to the computer and programmer and we need more of that, we need more of the squishy bits.

Programmers today are all about the hard bits, like how much RAM something uses and so on. It’s much harder to measure the satisfaction that someone gets out of a job well done. The satisfaction that I get out of writing Ruby all day and then thinking like Christ I get paid to do this is just amazing.


What kind of apps is Hotwire designed for?

What apps is Hotwire built for
I think the best way of looking at it is in the negative space, as in where would Hotwire not be a good fit? I think Sigma has been one of those examples of an app, that is predominantly what we call at Basecamp « super-Hi-Fi UI », where you’re dragging things around. It feels more like a desktop app in a sense, like Photoshop or something else on the web. If that’s what you’re coding, if you’re going to have really high interaction loops on the client-side, Hotwire’s not going to solve that. 

The thing is, when you say Hi-Fi, most people hear “better”. They hear Hi-Fi is better than Lo-Fi. But, no, that’s absolutely not the case. So many applications on the web have been ruined by people building them with Hi-Fi UI when all they need is a Lo-Fi UI. I was just talking to Toby at Shopify about this. He sells themes for Shopify storefronts, and he was just like “How did we get into this situation where some of the themes that we have download a megabyte of Javascript? ». And what they’re generating is a fucking product page that has a picture and a button that says “Add to Cart”. That’s not Hi-Fi!

You are hurting the web when you bathe it in unnecessary JavaScript. Hotwire takes a very different approach to that.


On Hotwire and Progressive Enhancement

Hotwire and progressive enhancement
Hotwire’s approach is progressive enhancement, it’s a ladder. You start at step 1: if you install Turbo you want Turbodrive. All the pages will now feel faster, not in any ways you can really see, you can just feel it, it’s more snappy back and forth. Then you need a little bit more so you add Turboframe, then a little bit more so you add Turbostream then you need a little bit more so you go to Stimulus Controller…

But most pages don’t need all of that, right? A bunch of applications would be totally fine if the only thing you did was Turbo Drive, it would already feel fast enough, it would already be great. And that is the big difference I think in many cases to single page applications.

What you really want to do is identify the 5% of your app or 10% of your app where you really want the Hi-Fi experience, there you pay 100%, you build it and it takes more time and for the other 90 to 95% you get it on sale.


What about mobile and Hotwire…when will you release Strada?


Actually this is a misconception, Strada is not essential. Strada is the last sprinkle on top. It makes the communication between the HTML and the native app a little more conventionalized, but there’s nothing there that is essential.

The meat of developing native apps with Hotwire is the native adapters that we’ve released. We’ve released one for iOS, one for Android. They have everything you need to get off the ground. And by the time you need that last sprinkle, we probably will have released it and it will just be a level-up and you can just upgrade from there. You’re not going to have to go backwards. 


What do you think could hold back wide adoption of Hotwire?

Hotwire and finding the perfect timing
No matter how great the thing you make is, the timing is a huge part of it.

You take Turbolinks for example. I think we introduced Turbolinks in 2013, the timing was all wrong in terms of mass-adoption. Tons of people looked at TurboLinks, but they couldn’t even understand it. Like « what is it doing? It’s breaking my jQuery plugin… » Fast-forward to 2020, Hotwire is like 30% Turbolinks in a new packaging and people go like « Wow this is great! ». The timing is different. There are now so many more people who have tried React and realized that this is not how they want to spend their life. So they’re ready!  

But the bigger picture here, is that I don’t care. I’m making this for people who want this kind of experience. Just like Ruby on Rails: Ruby on Rails is not the most popular web development framework in the world (that’s probably JavaScript), but for the people who do use Ruby on Rails does that matter? Do you wake up every morning and think “Oh shit, I’m so depressed because 10000 more people are using something else? No, you wake up and think “Well fuck, this is great!”. 


What about Hotwire’s sustainability?

Hotwire and sustainability
There’s a lot of technology that’s launched every day and it doesn’t make it through the stratosphere, it doesn’t reach escape velocity…it crashes, it falls to the ground. I think the Hotwire Escape Velocity is off to an incredible start.

You look at the fact that Hotwire is not just a Ruby on Rails thing. If you have a particular affinity for a back-end language that is not JavaScript, you need to be part of the resistance. You need to build up the alternative to “let’s write the entire application in JavaScript”. And this is a common cause: If you like PHP, this is something that is right up your alleyway, if you like Closure, if you like Go, if you like Python, if you like Java, if you like all these other languages, we share a mission here. 

Also from the start went out and said we’re going to go out of our way to make sure that this is a cross-ecosystem, that anyone can pick it up, that we have all the documentation, that the Ruby on Rails implementation is more about reference implementation than anything. And then I think the final thing is the barriers to entry are very low. To get started with Hotwire it takes very very little. This is not a complicated ecosystem to start learning compared to that to React.

And the other thing here with Hotwire is, it’s more of a two-way street. Say you start with Hotwire, you’ve built your whole app like that and then for whatever reason Hotwire doesn’t escape velocity and you get paper hands…what is the cost of switching? Not very much!


How is Hotwire doing right now?

How is hotwire doing after a year
With Hotwire, year 1, we’ve gone off to a much stronger start than Ruby on Rails ever did.

There’s much more attention and focus, incredible activity already and most importantly not just from the Ruby on Rails community but also from the other communities. 


How should we go about hiring to work with Hotwire?

Hotwire and Hiring
The great thing about Hotwire is that it’s not a career. Any developer can learn Hotwire in a weekend, it’s not that complicated. This is a huge difference with other technologies. So hiring someone is much less complicated than Ruby on Rails.

With Ruby on Rails, if I’m hiring a developer I’m gonna advertise for someone who already knows Ruby or already knows Rails. With Hotwire that’s not at all required. The fundamentals are so close to the base building blocks that everyone has to learn. You hire any developer of any kind with basic web development ability and they’ll be able to learn Hotwire in if not a week-end, then a week at the very most.


What about visual components?

Hotwire and visual components
I often think, what would I do if I had to do everything myself? If I had to start tomorrow and I had to do it all myself and I didn’t have a Class A design team behind me, I would pick up Tailwind. It’s not tied to specific JS implementation. In fact, it doesn’t even need Javascript at all. There is Tailwind UI which is this whole series of components you can buy. It’s like 250 dollars and you get like basically every variation of everything and you just drop those things in. And you can start with that tomorrow.

And the thing is, Hotwire is an open platform…so it doesn’t all have to be Hotwire. You can dump other stuff in there. So if you find a JavaScript component that you really like, just dump it in there. Which is not true the other way around.

So, if the question is « How would I start tomorrow? », I would start with Hotwire, I would start with Tailwind and I would start with Ruby on Rails because between those things, I’d have everything I needed.


Will Hotwire and Rails remain two independent projects?

Hotwire and Rails as independent projects
Hotwire is its own thing, it has its own identity…in a large part because that’s just how the technology works but also because we want to attract people from other communities to make Hotwire stronger…

But Rails 7 is going to default to Hotwire which is also going to be a huge boost to Hotwire. 


Have you thought of opening the governance of the project?

Hotwire and open governance
Right now it’s just Basecamp people who have commit, but there’s already a ton of pull requests that have been made from outside the community.

I definitely want to open it up, but in the early stages of a community ecosystem, you really need to establish the conceptual model, in such a way that we don’t all wind up in about a hundred different directions. That’s why people like Ruby on Rails, because it has a strong direction. So I don’t want to do it too soon (…) Let’s get a nice solid track and then when we have the nice solid track we can get a bunch more developers onto it.

There’s already a small group called Hotwire Friends where we’ve been chatting with some people outside of basecamp. I think within a year, I’m quite sure that will have happened.

Watch our interview with David Heinemeier Hansson: