As a developer knee-deep in the JavaScript world since around 2015, I’ve come to a rather disheartening conclusion: React, along with the broader JavaScript community, has failed us. It’s been a ride, but one that’s left me feeling more exhausted than exhilarated. The constant yak-shaving, the spinning of new frameworks—it’s become a cycle that’s far from productive.

The Rise and Fall of React

When React first burst onto the scene, it was a revelation. The virtual DOM was blazing fast, and it did a fantastic job of abstracting the messier parts of the DOM. You didn’t have to deal with the blur, and that was great. But as time went on, we realized that loading a file from a server and then running all the client-side processing in a single thread was slow, especially on mobile or if you weren’t on the latest hardware. It was brutal.

The narrative around React shifted to efficiency. With its abstractions, it could be more efficient—or so we were told. And sure, JSX is nice to look at, and for a while, it seemed like a good trade-off. But after nearly a decade, the supposed efficiency hasn’t translated into performance. React, at this point, might just be the most poisonous part of our toolkit, whether you’re using Next.js or, to a lesser extent, Remix with its more web-friendly approach.

The Next.js Conundrum

React has become synonymous with Next.js as the ecosystem has evolved. But let’s be honest, it’s slow, clunky, and creating a good user experience is a Herculean task. There are a lot of blogs and videos decrying the benefits of Next.js, and you might enjoy some of those, if you deploy specifically to Vercel, and only Vercel. But it’s still a heavy rats nest of virtual DOM eating resources underneath all the over engineered incremental cache validation. The cost of using React now far outweighs its benefits.

I’m working on projects in React and Next.js, and I can’t say I enjoy it. Next.js has some APIs that feel obtuse and don’t translate well to other frameworks. So, what do you start a new project in today? That’s the million-dollar question.

Exploring Alternatives

If you’re looking for alternatives, there are options. Laravel with LiveWire, for instance, is a solid choice. Rails with Hotwire, sprinkling in Inertia.js or Alpine.js, or even an Enhanced dev framework could work. Elixir Phoenix is another route worth considering.

To create the best user experience, you’ll likely need a server-side framework. And here’s where I’ll be blunt: JavaScript server-side is a mess. The serverless trend, with its gross abstractions and limitations, isn’t helping. You’re forced to deal with database connections, pooling, proxies, and a whole lot more just to get to your database.

If you’re set on going server-side with JavaScript, maybe Nuxt is an option. Redwood and Remix are mostly great frameworks, but they still rely on React. I wouldn’t start a new project with them, but if you’re shipping and you know React, I won’t tell you not to use them. However, I do hope they fall out of favor. Not because the people working on them aren’t great, but I no longer believe in the core idea of use React and a foundational part of a good web experience. For the developer or the user.

The JavaScript Community’s Identity Crisis

We don’t have a Rails to Ruby or a Laravel to PHP in the JavaScript world. Why? The community is fragmented, with different interests and agendas. JavaScript runs in the web client, attracting a wider array of users, investors, influencers, and bad actors. This diversity is likely why we don’t have a consistent, dedicated framework for the community.

A Plea for Change

In conclusion, serverless isn’t the cost-saving solution it’s made out to be. It’s likely to cost you more in money and time. For your next project, I dare you to try anything other than React or its derivatives, especially Next.js. Let’s break the cycle and explore the wealth of other technologies out there. It’s time for a change, and it starts with our choices as developers.