10 reasons MVC frameworks aren't dinosaurs but sharks

I first heard about the dinosaur 🦕 VS shark 🦈 analogy when I read this excellent article about relational databases:

You see, relational databases aren’t dinosaurs. They aren’t lumbering prehistoric relics doomed to extinction by a changing world. They are sharks. Apex predators honed by millions of years of evolution into a perfectly adapted creature that is just as effective today as it was eons ago.

In engineering field, when new technologies pop out, they tend to make the older one look worse. The hype could make us think that new tools are intrinsically better. This can prevent us to have an honest reflexion about the choice to make.

We, as developers are unusually curious creatures, and can be very excited by novelty, I get it. But we should get even more excited by avoiding unnecessary complexity, or making safe bets, because in the end, it matters more. We have to remember that the only goal of tech is to support business the best we can. Hence, the less tech you need, the best it is.

I think there is a serious shark in web sea: the monolithic MVC framework. Rails (Ruby), Django (Python), Laravel (PHP) and many others. They've been here for a long time, and even they're kind of boring, they still do the job very well. Of course, they're not the right solution for every use case. Like any piece of tech, there are always trade-offs to consider.

But I'd like to explain, in an opinionated way, why I think this piece of tech should not be discarded so easily just because of its age. If you acknowledge with many of the points bellow, odds are an MVC framework could be the right tool for your project, even in 2022.

1 - A single tool, multiple possibilities

Let's say your startup needs two different kind of apps:

A solid back-office for your own team with many pages to build → Use the whole "MVC" abilities of your framework, and don't waste time designing an API for no reason. Your framework may even give you the ability to write a page in 2 lines.
A shiny SPA with cutting edge UX → No problem, use your MVC framework for back-end only (the "M" part). He who can do more can do less. You build an API, and a modern front-end in React, Flutter, or whatever.

In a monolithic approach, having the same backend for your both apps will considerably ease the future operations.

2 - Monoliths still make sense in many contexts

Micro services are trendy and useful in specific cases. But they still don't make monoliths dinosaurs. Many startups came back from them. They were lured by the promises and underestimate all the trade-offs, especially because of their inherent complexity. Besides, micro services require more skills and people to be operated.

As Martin Fowler said:

don’t even consider microservices unless you have a system that’s too complex to manage as a monolith

3 - The revolution HTML Over The Wire is coming

Last years, using MVC framework was not an option as soon as you wanted a dynamic front-end. Having to reload a full page for every user action leads to a bad user experience and is indeed, not acceptable in 2022. To add some dynamism to your page, you had to mess with jQuery and AJAX, which often lead to very complex and hacky code in y opinion. That's why many of us started using SPAs when AngularJS came out. It was a true revolution!

So, what is HTML over the wire and why is it game changing?

As explained on this page:

Hotwire is an alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire. This makes for fast first-load pages, keeps template rendering on the server, and allows for a simpler, more productive development experience in any programming language, without sacrificing any of the speed or responsiveness associated with a traditional single-page application.

So, you can now have a good user experience AND developer experience, while keeping the very simple MVC approach. You won't need to maintain 2 different projects which communicate with a JSON API.

Hotwire is the dedicated solution for Rails, made by its creator. HTMX is a more generic solution usable with any HTML. I suspect lots of SPAs built today could be replaced by this approach, with more benefits that losses.

4 - These frameworks are all batteries included

Stop reinventing the wheel, stop making your own customised stack for every little unimportant thing. When you have a common need, you can be sure some team already did the job, and better than you'd do it.

And reinventing the wheel is not just building stuff by yourself, but also gluing stuff together. Gluing pieces of software is not easy. You have to handle compatibility, dependencies, etc. In an MVC framework, each battery is thought to integrate with each other.

You can spend so much time just evaluating simple libraries that do a single thing that in a sense, having all batteries included avoid the paradox of choices. But you're still not forced to use all the batteries. It's a "progressive" philosophy. You can even replace one of the provided batteries, if you have a real reason.

Security? ORM? Authentication? Permissions? Template Engine? Middlewares? SMTP tools? Internationalization tools? CRUD GUI? You got covered. All of them made by the same team, ensuring a consistency over time: when you go from v3 to v4, you know everything still should work together. You spend less time maintaining your whole customised stack, in which every package would evolve at its own pace, in total independence.

5 - Misleading argument #1: it's not performant / it doesn't scale

In tech press, I keep hearing about "tech X" is more performant/scalable than "tech Y". These metrics are important to know. But the fact your MVC / monolith is slow or does not scale may actually has nothing to do with the technology itself. In a request/response HTTP cycle, there can be so many ways to slow things down. To name some of them:

Maybe your SQL query is poorly written.
Maybe you made complex computing at the wrong place.
Maybe you forgot to use background tasks, hence keeping web threads busy.
Maybe you serialized way more JSON that you front-end actually need.
Maybe you set up no metrics at all, and have no clue about what's wrong.

So before blaming "framework X" or "language X", ensure your own work is clean. And ask yourself: "before tech X exists, were we really unable to build fast and scalable websites?"

6 - Misleading argument #2: too much boilerplate code

Yes, you can write a "Hello world" very quickly with few lines of code with a lightweight framework like Flask (Python) or Express (Javascript). And then what? Except the feeling you can start faster, there is no real point in having less files or less lines of code. Because the situation will be different as soon as the project will grow.

7 - Misleading argument #3: you will find more developers with this shiny new tech rather than this dinosaur

Even if it can be true in some cases, here are some points to keep in mind:

As captain obvious said, you can not have 2 years of experience with a tool that have existed for 1 year. So if you want experimented people with a specific tech, let the time go by.
If a developer is mainly attracted because of the novelty, the same person could be bored in a few months. You don't want people who wants to change the whole tech stack every 6 months because it's not cutting-edge anymore.
Does the absolute number of potentiel candidates really matter? I'd consider the ratio between the job offer and job demand a more relevant metric to assess the recruitment difficulty.
High level technologies like MVC frameworks will be easier to apprehend for beginners, because they have a structure. And if beginners make less mistakes, you'll be way more comfortable to hire them, and then your pool of potential candidates will grow naturally.

8 - They enforce some conventions that drive teammates in the same direction

You're using node.js? Cool, me too!

The more the tech tools you use are "low level", the more there will be a bunch of ways to achieve the same task with it, because you'll need many other tools, which will differ between two developers.

When someone says "I use Rails" or "I use Django", you feel pretty confident to understand its code quickly, because there are less ways to do exotic things.

There are even projects in the JS world, like Nest JS, to recreate these conventions.

9 - Not so misleading argument: it's better to use the same language on the whole stack

This is actually a good point: it make things easier. To achieve this, there is no other choice that using Javascript (or any translate-to-JS language) on the back-end, because you're forced to use it on the front-end.

However, from what I've seen, there is still no Rails / Django equivalent in JS world. Sails JS has a low satisfaction rate. Nest JS looks more like a wrapper around existing tools than a real framework. Blitz JS looks promising but has not enough traction. That may just not be the philosophy.

In addition, you may prefer using another language you feel more comfortable with, even if it's just for backend. For some people, Python or Ruby could be easier, more readable, or have a better standard library, etc.

One day, I asked on Reddit:

If there is a wonderful MVC framework available in Javascript tomorrow, would you drop Django or Rails to go full stack JS?

Some JS lovers answered "yes definitely", some JS haters answered "If I can use a Ferrari 70% of the time, and a Twingo 30%, why would I want to use a Twingo 100% of the time ?".

In that sense, I agree that being comfortable with the backend language can be more important than using the same language everywhere.

Another point is that you're not even sure to use Javascript extensively on the front-end because:

Your JS SPA front-end could be very lightweight compared to your backend that holds all the logic. I don't like putting too much logic on the client.
If you use your MVC templating engine, odds are JS will be even lighter with tools like HTMX (cf. HTML Over the wire section).

10 - Old means mature

Here are some generic advantages you get with maturity:

Security: since there is no more drastic change at some points, it becomes easier to ensure security over time. You benefits from years of bug fixes. Introducing a new one is less likely.
Consistency: best practices are now well known and documented. You won't invent new ways to do stuff, relying on others who already know. That's a good thing.
Risk mitigation: you can't really go wrong. You won't be very surprised. I mean, if you chose a MVC framework right now, you're able to evaluate the trade offs in a pretty accurate way.
Peace of mind over time: mature tech means no incoming drastic changes over time. If you take a look at recent front-end frameworks like React or Vue, you'll see how different they are in 2022 compared to 2020: APIs have changed, advised libraries have changed too. Evolution is good generally speaking, but it creates fragmentation, and forces you to at least evaluate the trade offs of a migration. As a serious developer, you'd better let the "mistakes" been made by others, before you pick that tool.

Conclusion

We focused on strengths of MVC frameworks and multiple reasons to consider them carefully. It does not mean they're perfect and I guess we could find lots of projects in which they're not the right solution.

But as a general rule, I think we must not discard a technology just because it's old. Doing so because it's too new would make more sense, if you want to build stuff for businesses.

MVC monoliths are like relational databases, they are not dinosaurs, they are sharks. We, as developers, are forced to spend lots of time to learn new tools and concepts. So, we should be relieved that some pieces of technology we learnt years ago are still relevant today. So the next time you catch yourself thinking "this is boring tech", that may be a positive thing for you and your project.