Rails and Next.js: the perfect combination for modern web development (Part 2)
In the first part of this post series, I gave an overview in the form of a metaphor about what led me to not use Ruby on Rails as the only development tool.
Continuing the post series, I’m happy that some readers are curious and ask me what motivated me to follow this development structure. So now, I would like to take the opportunity and answer some of them:
What does Next.js have to do with React.js?
Some readers asked me about the use of Next.js and where React comes into play. Therefore, I will list some interesting points:
- Next.js is a Javascript framework that uses React components to render web interfaces.
- You don’t need Rails to develop applications with Next.js and vice versa.
- Next.js is a full-stack framework, but more complete alternatives like Nest.js exist. At Nest, you will find a wider range of tools for web development, such as MVC, ORM, Security, Websocket, etc.
- I opted for Next.js as I only need the SPA generation part it provides. After building the application, I am not using Next.js to execute on the server side. What goes into the Ruby on Rails public directory is just Javascript and HTML files that run on the client side.
Do you need a Javascript framework to develop even the simplest applications?
The short answer is: no. But we’re here to go into details, right? So let’s delve a little deeper.
Today, one of the main languages for web development is Javascript.
It cannot be ignored that if you are looking to create or maintain a web system, you will need to have access to an active community and be able to hire specialized people. In this way, choosing a language like Javascript can be a good strategy.
Therefore, having a diversity of technologies applied to your project and using technologies that are among the top of the market, you have a good reason to use Ruby on Rails with some other Javascript framework.
In addition to the diversification of technologies, as I said in my previous post, I chose React to have the componentization part in the best way I have found so far. I removed the View layer from Ruby on Rails (ERB, HAML, Slim, Liquid, etc.) and replaced it with Next.js.
Although it seems like a drastic change, if you choose to use React in your Rails project, this is the best and simplest way possible.
Another point to consider is that having a development standard for each project within the same ecosystem is impossible. I’m not saying that if a system only has HTML, I must insert Next.js in the Rails application. But if your system needs some dynamic component (a table with AJAX for example), why not create (or import) this component with React and share the same alternative in all your projects? On the contrary, you will have double work to maintain two components that do the same thing.
Why not use Hotwire instead of React?
After everything I wrote in my first post and in the answer to the previous question, I don’t think there’s much left to add here. But in case you have any doubts, I will list some important points:
- The best way to componentize a Ruby on Rails application is https://viewcomponent.org/. View Component is an excellent library, but React proved to be more complete in the end.
- Hotwire is very specific to Ruby on Rails, and I’m afraid of limiting my project’s development to something that isn’t known by a wide range of developers.
- Hotwire uses https://stimulus.hotwired.dev/. As the Stimulus website says, it is a modest Javascript framework. That is, it will not go much beyond the basics. I would opt for https://alpinejs.dev/ if I was interested in working with managing HTML following a similar approach but with more features.
Why not use https://alpinejs.dev/ or https://svelte.dev/?
I confess that no one asked me this question, but I myself thought that a framework that, instead of just generating HTML, could also work with the HTML generated by the backend. Alpine and Svelte could be a better alternative than integrating Next.js into the Rails project.
But in the end, the same points listed as an answer to the question ‘Why not use Hotwire instead of React?’ can also be considered here.
What about Server-Side Rendering (SSR)?
This is a point that I still don’t have a concrete answer to, but what I can say so far is that if I need an SSR, I will choose to keep using Next.js, but in a separate project running the application on a Node server. As I described in another post titled ‘Consuming a Rails API with a NextJs client’.
If I were you, I would switch Ruby on Rails for a complete Javascript alternative.
In my previous post, I believe I described my motivation for not doing this well. But I confess that it took me a few years for the answer to this question to become clear enough and possible to say in a few words:
“I’m not going to give up over ten years of experience with Ruby on Rails just to have access to a better View.”
In no way do I see that Ruby on Rails is inferior to Javascript alternatives and it offers me everything I need to develop a well-structured, organized, secure, stable, and scalable API.
This means that I will keep my API in a Ruby on Rails application and all the frontend parts will be handled by Next.js.
In the next and final post of this sequence, I will detail technically how I integrated Rails with Next. You can already take a look at the code here https://github.com/raphox/rails-next/commits/main.
The last part is here https://medium.com/@raphox/rails-and-next-js-the-perfect-combination-for-modern-web-development-final-part-a88af492a00