Since the introduction of reactive JavaScript libraries, the last decade has seen significant changes in website building methodologies. We began separating projects for managing front-ends; headless CMS platforms arose, with easy REST or Graphql API access; third-party tools became necessary for everything.

This created a Frankenstein’s monster of technology, making the use of larger web frameworks seem almost obsolete—at least in some circles.

From a certain perspective, this makes a lot of sense. Small firms, specializing in one language or another and not proficient in databases or servers, found it reasonable to lean solely on JavaScript (for example) and outsource everything else.

I’ve done a fair amount of this myself, from small blogs (Gatsby + Contentful) to larger Next.js projects with a headless backend like WordPress. If the setup is simple enough (like the first example), it can be no big deal, and you get a speedy static site you can host for free on Netlify. However, venturing into the realm of the second example complicates the project significantly.

Juggling Servers and Services

Now, in addition to your front-end hosting, you have to host the CMS somewhere, assuming you’re not using a service like Contentful. Either way, you’re likely to pay - for a non-free tier service for large datasets or capabilities, or for a separate web server to host your headless WordPress or other source for your content.

Now, you’re managing two codebases and two servers. If you add staging environments, that doubles to four servers, along with additional deployment processes… you get the idea. Managing the overhead can become a project in and of itself.

And what about authentication? If you’ve divorced your project from a user-management system, you’re left depending on third party tools again. Does NextAuth support your authentication method of choice? What if you’re not up to speed on auth systems in general? Everything is abstracted away, leaving you in a maze of documentation to figure out tasks we once took for granted.

Traditional Frameworks: Better Than Ever

While this whole mess of a situation was unfolding, the “traditional” web frameworks of yesterday never did disappear. Indeed, they continued to improve and solve the same problems we keep trying to solve over and over again in scenarios like I was describing above. Rails is still here, as is Laravel - perhaps “yesterday” is the wrong word then 🤔

Thankfully, these frameworks provide many things we need out of the box, or with a quick command to scaffold common features. On top of that, they might have already solved some of the complex integrations like authentication with a package that can be added, such as Laravel Socialite.

Why create a monster when the hard stuff has already been done? Especially if goal was make life easier.

Forging a Balanced Path with Monolithic Frameworks

As we navigate the ever-evolving landscape of web development, embracing monolithic frameworks doesn’t feel like a retreat to the past but rather a strategic alignment with technologies that have continually adapted and improved. It’s like rediscovering the depth and richness of a timeless masterpiece in a world constantly chasing the next big thing.

By merging the reliability of frameworks like Rails and Laravel with today’s advancements, we’re not so much looking back as we are finding a more balanced path forward. It’s about taking the best of both worlds—proven stability and new innovations.

This approach doesn’t mean we’re stuck in the past; it means we’re smartly choosing a foundation that has stood the test of time while still embracing the future’s possibilities. Blending the old with the new isn’t just practical; it’s a forward-thinking strategy that prepares us for whatever comes next in web development.