In an article for Contraption comparing Ruby on Rails and Next.js, Philip I. Thomas writes:

The truth is that the new wave of Javascript web frameworks like Next.js has made it harder, not easier, to build web apps. These tools give developers more capabilities - dynamic data rendering and real-time interactions. But, the cost of this additional functionality is less abstraction.

He then makes a great point about what makes Next.js apps unstable:

Using cutting-edge frameworks introduces instability through frequent updates, new libraries, and unexpected issues. Next.js applications often rely on a multitude multiple third-party services like Vercel, Resend, and Temporal that introduce platform risk.

This problem is exacerbated by SaaS platforms whose business model seemingly relies on obfuscating away control of an application by selling their services to new and impressionable developers who hear about them for the first time from their favorite social media personalities.

As an industry, we’ve shifted from the millenial devlog to the YouTube tutorial. And while there’s absolutely nothing wrong with video as a format, the incentive for monetizing content makes developers-turned-creators perpetuate this cycle of overcomplicating software through third-party services, because advertising these services and not architecting software is what pays their bills.

This trend of aggressive advertisement for a fragmented app infrastructure preys on the ever-present FOMO in the industry. If Meta and Netflix and the rest of the FAANG companies are using the latest technology… why not me?! But FAANG companies solve unique problems for their products, and thus write solutions that work for them. See also: Ruby on Rails is slow and doesn’t scale. When your app reaches a large enough amount of users to bring Rails to its knees, you’re not going to regret choosing Rails, you’re going to laugh and feel proud and incredulous that so many people have found value in your work.

The need to create content about what we’re building isn’t new. There’s always been a large portion of developers who have maintained blogs throughout their careers, taking the time to explain and share their knowledge with the community. Marco Arment and David Karp famously did it while working on Tumblr. DHH did it while developing Rails. Tom Preston-Werner blogged his way through Semantic Versioning, Jekyll, and GitHub.

For independent developers, Preston-Werner even suggested README Driven Development as a solution to the problem that Next.js and the JavaScript ecosystem continues to perpetuate. He puts it this way:

I hear a lot of talk these days about TDD and BDD and Extreme Programming and SCRUM and stand up meetings and all kinds of methodologies and techniques for developing better software, but it’s all irrelevant unless the software we’re building meets the needs of those that are using it. Let me put that another way. A perfect implementation of the wrong specification is worthless. By the same principle a beautifully crafted library with no documentation is also damn near worthless. If your software solves the wrong problem or nobody can figure out how to use it, there’s something very bad going on.

And that’s one of the problems with the JS ecosystem. Rather than building software to meet the needs of its users, it builds more software to meet the needs of its developers in a way that is unclear to experts and newcomers alike. It's no coincidence that we have an entire industry predicated on learning tools like React without really understanding why your product would benefit from implementing it.

Preston-Werner proposes the following solution:

Write your Readme first.

First. As in, before you write any code or tests or behaviors or stories or ANYTHING. I know, I know, we’re programmers, dammit, not tech writers! But that’s where you’re wrong. Writing a Readme is absolutely essential to writing good software. Until you’ve written about your software, you have no idea what you’ll be coding.

In favor of Rails, Thomas explains what makes it so attractive for both small and larger teams:

Developers choose Rails today because, 20 years later, it remains the most simple and abstracted way to build a web application. Solo developers can create dynamic, real-time web applications independently (as I did with Booklet and Postcard). Enterprise teams use it to build applications with multiple models and access controls, supported by thorough testing. Rails helps small teams work faster while reducing development and maintenance costs.

He concludes that “polish fades while utility persists”, with the latter referring to Rails. But I’m doubtful that Next.js has that polish. The JS world has it backwards. It prioritizes technology over people. As an enthusiast, I love JavaScript. As a developer, it’s exciting to see what can be done. It’s fun. We absolutely do need to push boundaries within web development and as it currently stands, the Next.js crowd is definitely doing that.

Rails on the other hand is mature. It’s reliable and I’m confident that my applications won’t run into issues caused not by my own doing but rather the myriad of third parties introduced into the back-end.