19 March 2021
Rails: The HTS Experiment
by Bill Barnett
Background
Ruby on Rails has long been the Web development framework of choice for businesses, gigantic and small. Ruby and Rails created to optimize development efficiency, making them ideally suited for rapid application development but fear not if your application is already at scale. A recent Financial Times post that highlighted the broad acceptance of Ruby set Hacker News ablaze with the observation that 52% of the revenue generated by the top 50 startup companies was served up by Ruby as compared to second place Python with 17% and a respectable 2% for newcomer Elixir. Surprisingly, Java came in at 1% and JavaScript less than 1%. Setting aside any debate about the accuracy of these figures, it should be obvious at least that rumors of Rails’ demise are premature. In fact, at Gaslight, we’re excited about the potential of new features of the framework, namely Hotwire, Turbo and Stimulus (HTS) but like you, we’ll reserve judgment until we’ve kicked the tires and taken them for a test drive.
That said, we view HTS as more than the latest fad in Web application development. To our way of thinking, aside from its ability to deliver a responsive experience in the browser, HTS renews the promise of a viable unified code base that would simplify talent acquisition, especially for startups and small businesses, and provide a more sustainable development process for developers, designers, and product managers.
Hypothesis
We believe if so desired and with a reasonable amount of effort, a CRUD application that employs Rails on the server-side and React on the client, can be refactored into a unified, Ruby (mostly) codebase without loss of performance on either side. (Note: We’re fans of React and our teams are proficient with a wide variety of client-side frameworks. Let’s chat if you need help on the client and are not ready to jump to HTS.)
The Plan
We have chosen a simple CRUD application that meets the requirements of our hypothesis. In a series of posts in the coming weeks, we will document our process and our findings. Our first step is to update the app to the current versions of Ruby, Rails and React, and add system specs that prove parity in functionality between the implementations; one in Rails/React and the other in Rails/HTS. You can follow our progress here. We’ll remove React entirely and, with system specs in place, restore the functionality with idiomatic Rails code. Finally, we’ll benchmark the performance of both implementations and let the numbers speak for themselves.
Our Hope
There are many more of you than there are of us. While it is encouraging to receive positive feedback, it is almost always more helpful to receive “more skeptical” feedback and our team have only so much skepticism. Any valuable feedback we receive from you will be incorporated into coming posts and we’ll do our best to address any such concerns. We’ll also highlight gotchas and helpful tips we learn along the way.
We’re grateful to Rails’ creators and contributors and congratulate them on this exciting next chapter in their long history of innovative Web development; likewise to the entire Ruby ecosystem. Shout out to James Hibbard for his well-written demo Rails/React app. Any time on his polished and professional blog is certain to be rewarded with helpful insights for Rails and JavaScript developers alike. We’re excited to explore the potential of HTS, which we’ve begun using for our clients and look forward to many interesting conversations on the subject.
Frustrated by your inability to find design and development talent needed to take your business to the next level? Have a legacy Rails application in need of rejuvenation? Looking for a team with whom you can grow as a designer or a developer while solving challenging problems in an inclusive and supportive environment? We can help you with each of these and more. Let’s talk.
