enocc

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 has been exacerbated by developers themselves. I don’t like Vercel, Resend, Temporal, Prisma, or any of the SaaS platforms whose business model seemingly relies on ~~abstracting~~ 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. Indeed, all three links in the paragraph I quoted above from Thomas’s article are affiliate links. (This is not to say Thomas is doing what these creators do, I’m just pointing out how deeply rooted this economic model has become).¹

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 at the end of the day, advertising these services and not architecting software is what pays their bills.

This trend of aggressive advertisement for a fragmented app ecosystem 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 (what a terrible word tbh) 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.

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.

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.

And to this I say:

Hey, Siri: Show me how to put ads on my Readme file and make it 10 minutes long…

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, imho. 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.

In a reply to this post, Philip clarified that he uses Ghost as his blogging platform, which adds a ?ref parameter automatically. These are not affiliate links, and I shouldn’t have immediately assumed they were. ↩