DEV Community

Thomas Musselman
Thomas Musselman

Posted on

The Future of Ruby on Rails: from the perspective of a newcomer

I wrote this article as a new software engineer trying to understand the ecosystem and what direction web development is headed as I enter the industry. If I've misunderstood anything or you've got any insights to share please post in the comments!

I recently graduated from a back-end software development bootcamp where the primary technology we used was Ruby on Rails. As I've researched different tech stacks I've run across a lot of comments about how RoR is becoming obsolete in favor of leaner technologies in a Service-Oriented Architecture environment. While I'm confident I can learn any tech on the job, its a little discouraging knowing a tech that I've spent a lot of time mastering (and learning to love) wasn't really worth my time.

I'm always reassured by the fact that there are still a ton of companies using RoR, and that's probably not going to change any time soon. But I've also done a lot of research as a new developer trying to understand the current ecosystem, and I think that the future for RoR is still bright.

SoA isn't right for every project.

I've started following the developers at Basecamp (who are responsible for a lot of the development for RoR) and a point that they make is that a lot of companies are too small to justify the complexity of having too many moving pieces in their applications. With larger companies it makes sense to have an entire team dedicated to a service or feature and have its development be compartmentalized from other features. With a small, team it just means more time and effort making those services work together and less time developing features that users want.

One of the main selling points for RoR has always been its speed of development. So that makes it really appealing for start-ups and newer companies because they can get to production much faster. There tends to be a consensus that RoR may not be a "forever" solution though and that as projects and companies grow in scale, they can slowly transition to smaller services built on different technologies. While that still is the case, recent developments in RoR mean that a lot of its short-comings have been solved and that transition may not have to happen as soon (or at all) for certain sized applications.

A Faster More Dynamic Front-end with Turbo/Hotlinks

One of the major flaws with RoR and other server-side monolith applications is the fact that they require a request and full-page load each time the user navigates or modifies some data in the system. This is creates a slow user experience and is inefficient. You can certainly add Javascript into the views to make them more dynamic and require less loads, but eventually this becomes complex to the point where it just makes sense to have a separate front-end application using a library like React, leaving Rails to just be a simple API serving up JSON data.

Rails developers have tried to give solutions to this in the past, but Rails 7 ships with the latest and greatest: Hotwire. Hotwire includes the successor to Turbolinks, Turbo, as well as two other packages, Stimulus and Strada(coming soon). While I have yet to build anything with these technologies (including Turbolinks), I read and watched a couple tutorials to try to understand what they're accomplishing. Ultimately the goal is to make Rails have the speed and dynamic nature of a single-page application like React, by only rendering parts of a page on an as-needed basis.

The name Hotwire comes from the idea of sending "HTML over the wire". In essence the idea is that instead of having a back-end render JSON, then the front-end deconstruct that JSON into HTML, the back-end can directly render only the HTML needed, skipping the JSON "middle-man". This takes a number of forms, but in the most basic sense, and in the context of Rails, it means only requesting new HTML for small "frames" of a webpage instead of the whole page. Amongst other things, there are also features for easily setting up "Turbo Streams" that use websockets to stream data to the page as needed.

A General Trend for Web Applications

The most interesting thing to learn about is that there seems to big a big demand for these full-stack applications with fast and dynamic font-ends. While Rails is attempting to move in the direction of something like React on the front-end, there are projects to make React have features similar to full-stack monoliths like RoR with the development of frameworks like Next.js. Although I don't yet fully understand everything Next.js can do, it seems to me that the latest bundle of features accomplishes something pretty similar to what Rails developers accomplished with Hotwire.

Getting More In Depth

My plan now is to really learn these new frameworks and what problems they solve. I plan to build a Rails 7 applications that utilized as many of the Hotwire features as possible. I also plan to learn Next.js 13 after that and compare the benefits and drawbacks of both. I plan to post as much as possible about what I'm learning along the way, so feel free to follow along!

Top comments (2)

Collapse
 
samuelodan profile image
Samuel O'Daniels

Thanks for the article. I'm an early career Rails Dev as well, and I'm excited to start my next project with Hotwire.
Good luck on your journey.

Collapse
 
redbar0n profile image
Magne • Edited

Welcome into the fold! Excited to see how you as a newcomer will experience RoR vs. NextJS.

Based on your background and interests, you might find these two articles of mine particularly interesting:

The Rails/Laravel experience in JS/TS

The different strategies to building a cross-platform app, where I detail Hotwire/Turbo vs. variants of that and vs. other solutions.