You might not need React — A blog about Rails, JavaScript and Trade-Offs
Which are the go-to strategies when you want to integrate React into a Rails application? In December we visited the Ruby User Group Hamburg and held a talk about exactly that.
While you may consider this blog as a standalone transcript of our talk, we also welcome you to check out the slides linked here to follow along.
Do you remember the old days, remember how frontend development was done in the rails world in 2010 and before (~> Rails 3.0)? Typically all your javascript code was stored in the “public” folder together with other static media, like images and stylesheets. We had script.aculo.us, prototype.js and lots of jQuery plugins.
Things evolved and eventually (with rails 3.1.) we got the asset pipeline — a huge step forward. Now we had better file organization and a framework to concatenate and minify JavaScript, CSS and the ability to integrate new technologies like Sass.
Rails 3.1 made “assets first class citizens”.
This also meant your User Interface…well, it was just an asset. Which was probably fine for smaller Ajax powered interactions and some DOM manipulations and fancy animations.
Sprockets as the heart of the Asset Pipeline tried to keep up, but with the rise of new javascript frameworks for building Single Page Applications (SPA), developing heavy client-side applications within Rails was not really joyful…
:fast_forward:
6 years later, with the release of Rails 5.1., we finally got a promising solution with the integration of NPM and Webpack to handle our UI dependencies.
Also Webpack will be the default JavaScript compiler for the upcoming Rails Version 6. Even if you’re a dedicated “backend developer” who never touches the frontend — believe us — the war is over and webpack will make even your life better.
At its core, webpack is a static module bundler for modern JavaScript applications. When webpack processes your application, it internally builds a dependency graph which maps every module your project needs and generates one or more bundles.
How to JavaScript in Rails
Ok, now that we have that out of the way, we differentiate between three common strategies on “how to JavaScript in Rails”:
Modern Rails
With the simplicity of Unobtrusive JS and Server-generated JS responses, we have a very powerful combination which has been part of the Rails stack for ages. And Rails is still very good at rendering HTML. Paired with the new Turbolinks Implementation and Stimulus.js to “add sprinkles of JavaScript to make (your HTML) sparkle”, we believe it’s THE fastest toolkit to get a working product shipped. Especially for small teams.
This might not be the hippest approach nowadays but for simple UI/UX requirements, it’s definitely one that is less complex and requires less JS skills.
While, in the classic MVC layered application, features tend to distribute over all layers, this also applies to the Modern Rails strategy — and therefore requires some discipline to keep the codebase clean. But with easier testability (by having everything in one place) comes good maintainability.
On the plus side, with this strategy your application supports usually any device that can show HTML.
Hybrid Approach
Rails is still a very good framework for building web applications and with the new versions it’s even easier to integrate rich client-side frameworks like React, leaving us with the strengths of both ecosystems to build clean solutions even for complex interactions.
But this strategy is certainly one that comes with trade-offs.
You always need to decide which part of your application is responsible for which part of your business logic. Especially when you’re building very complex user interfaces with many dependencies.
Still, we had a positive experience applying this strategy while modernizing the frontend of a really big legacy application. The barrier when integrating component based design, thus staying flexible, is very small.
SPA with Rails API
If your planning for the best native look and feel you might need a solid backend that speaks only json instead of having a full-stack application that renders HTML templates. Since Rails 5.0 we have the API mode for having a great companion for “the new crop of client-side javascript or native applications”.
Being the most flexible and advanced approach, this comes with complexity on a variety of topics, including a harder Setup, development, testing, deployment, security and/or error handling for your API layer.
This strategy might make sense for very big teams with separate departments and parallel projects.
Summed up: Which approach for whom and what?
Your mileage may vary, and we don’t say it’s not possible for a team of three to go the SPA + API way … but as a rule of thumb we would recommend to challenge decisions against the following graphic.
In the end it’s a matter of preference or business constraints. Don’t just follow the hype and build microservice architectures and SPAs just because “everyone does it.”
A lot of very large companies are super successful with a much simpler architecture. :)
The talk and the slides were done by Marco and Jakob.
Want to talk about Rails and React in more details? Check out our Twitter or visit our website. Let’s chat ❤
