Hardcover initially chose Next.js for its perceived performance benefits and modern tooling. However, they found the complexity of managing client-side state, server components, and various JavaScript tooling cumbersome and ultimately slowed down development. This led them back to Ruby on Rails, leveraging Inertia.js to bridge the gap and provide a more streamlined, productive development experience. While still appreciating Next.js's strengths, they concluded Rails offered a better balance of performance and developer velocity for their specific needs, particularly given their existing Ruby expertise.
The blog post "We fell out of love with Next.js and back in love with Ruby on Rails" by Hardcover details the journey of a team's evolving relationship with their chosen tech stack while building their web application. Initially enamored with the perceived modernity and performance benefits of Next.js, a React framework, they eventually found themselves grappling with its increasing complexities and drawbacks, ultimately leading them back to the familiar embrace of Ruby on Rails, supplemented by Inertia.js.
The authors elaborate on their initial motivations for choosing Next.js. They sought a modern, JavaScript-based framework, believing it would offer superior performance and a more engaging development experience. Furthermore, they were drawn to the perceived abundance of readily available JavaScript developers, anticipating easier recruitment and team scaling. The allure of server-side rendering and static site generation, features prominently touted by Next.js, also contributed to their initial decision.
However, as their project progressed, the team encountered several pain points. The increasing complexity of managing both front-end and back-end aspects within the Next.js framework became a significant burden. They highlight the challenges of maintaining a consistent data flow and state management between the two, leading to increased development time and debugging efforts. Additionally, they found that the promised performance benefits were not always realized, and the complexities of optimization often outweighed the marginal gains.
The perceived ease of finding JavaScript developers also proved to be less straightforward than anticipated. While the sheer number of JavaScript developers might be higher, finding developers specifically experienced and proficient in the nuances of Next.js and its associated ecosystem presented a different challenge.
The turning point came with the discovery of Inertia.js, a library that allows developers to build single-page applications using server-side frameworks like Ruby on Rails, while leveraging the familiarity and component-based approach of JavaScript frameworks like React, Vue, or Svelte. This offered the team a pathway to combine the perceived advantages of modern front-end development with the robust and streamlined backend capabilities of Rails.
By re-embracing Rails and integrating Inertia.js, the team experienced several significant improvements. They found that Rails' convention-over-configuration paradigm simplified development and allowed them to focus on core business logic rather than wrestling with framework intricacies. Leveraging Rails' mature ecosystem of gems and libraries further expedited development and addressed common functionalities with ease. Inertia.js, in turn, allowed them to retain the benefits of component-based UI development using React, while simplifying data management and state synchronization by leveraging Rails as the single source of truth.
The authors conclude by emphasizing their renewed appreciation for the stability, productivity, and developer experience offered by Ruby on Rails, especially when combined with the flexibility of Inertia.js. They posit that this combination provides a compelling alternative to the complexities of full-stack JavaScript frameworks like Next.js, ultimately allowing them to deliver features more rapidly and efficiently. They suggest that while the allure of the “new and shiny” can be tempting, the proven strengths of established frameworks like Rails, when combined with strategic integrations, can provide a more sustainable and productive path for web application development.
Summary of Comments ( 210 )
https://news.ycombinator.com/item?id=43881035
Hacker News commenters largely debated the merits of Next.js vs. Rails, with many arguing that the article presented a skewed comparison. Several pointed out that the performance issues described likely stemmed from suboptimal Next.js implementations, particularly regarding server-side rendering and caching, rather than inherent framework limitations. Others echoed the article's sentiment about the simplicity and developer experience of Rails, while acknowledging Next.js's strengths for complex frontends. A few commenters suggested alternative approaches like using Rails as an API backend for a separate frontend framework, or using Hotwire with Rails for a more streamlined approach. The overall consensus leaned towards choosing the right tool for the job, recognizing that both frameworks have their strengths and weaknesses depending on the specific project requirements.
The Hacker News post discussing the article "How We Fell Out of Love with Next.js and Back in Love with Ruby on Rails + Inertia.js" generated a significant amount of discussion, with many commenters sharing their experiences and perspectives on the respective technologies.
Several commenters echoed the author's sentiments about the increasing complexity of the JavaScript ecosystem and the relative simplicity of Rails. They appreciated the "batteries-included" nature of Rails, contrasting it with the constant churn and decision fatigue associated with the JavaScript world. One commenter highlighted the value of convention over configuration, a core principle of Rails, in reducing cognitive overhead and enabling faster development. Another expressed relief at returning to Rails after experiencing the complexities of setting up authentication and authorization in a Next.js project. The ease of use and rapid prototyping capabilities of Rails were recurring themes in these positive comments.
However, other commenters pushed back against the author's narrative, arguing that the article presented a somewhat skewed perspective. Some suggested that the author's initial struggles with Next.js might stem from inexperience with the framework or a misunderstanding of its intended use cases. They pointed out that Next.js, while powerful, is not designed for every type of application, and that its server-side rendering capabilities might be overkill for simple projects. Others questioned the long-term maintainability of Inertia.js, citing concerns about its relatively small community and potential compatibility issues with future updates to Rails and React.
A few commenters offered alternative perspectives, suggesting that the perceived complexity of JavaScript frameworks can be mitigated by adopting a more pragmatic approach. They advocated for focusing on core libraries and avoiding unnecessary dependencies, a strategy they believed could simplify development and improve performance. Some suggested that tools like Vite could streamline the development process and reduce build times, addressing some of the author's criticisms about JavaScript tooling.
The discussion also delved into the trade-offs between server-side rendering (SSR) and client-side rendering (CSR). Some commenters argued that the performance benefits of SSR are often overstated, while others emphasized the importance of SEO and initial load times. The debate highlighted the nuanced considerations involved in choosing the right rendering strategy for different types of applications.
Finally, some commenters expressed skepticism about the longevity of frameworks like React, predicting a shift towards more server-centric approaches in the future. They pointed to the resurgence of PHP and the growing popularity of frameworks like Phoenix LiveView as evidence of this trend.
In summary, the comments on the Hacker News post represent a diverse range of opinions on the relative merits of Rails, Next.js, and Inertia.js. While some commenters strongly agreed with the author's preference for Rails, others offered counterarguments and alternative perspectives, leading to a rich and informative discussion.