MERN is not your god

This article addresses a very specific conversation that I find myself having repeatedly with beginners who were suggested that they should learn web development in the MERN stack. I want to address it because there's a very real dumb reason why MERN is such a common suggestion, and why I'm sort of angry about it: it's because you can say MERN out loud, and remember it written, since it looks like a word more than any other common tech stack. We humans, we love our acronyms, we love to make them sound like words, and we have generally lost the ability to generalize the full stack technologies by shoving it in the MERN acronym which is often literally used, not metaphorically. The Meaning of MERN Let's first explore what MERN actually means: M stands for MongoDB, a document database that was very popular when the acronym was coined. E is for Express, which for decades was the defacto HTTP server library you wanted to use in node. R is React, the most popular front-end client-side rendering, one used by the industry, and still very relevant. N doesn't even relate to a specific part of the stack but rather just "node". This means that the stack is really just "mongo + express + react", which is not a bad stack per-se. The Alternatives My point, though, is that it's just one single variation out of so many possibilities. So for each of those 4 parts, let's first explore just specific changes we can make. Mongo can be about 2 dozen different databases depending on your needs. MySQL, Postgres, Oracle, SQLite, etc. Not to mention hosted/distributed systems like Firestore, Cloudflare and AWS offerings. Express has much better, more modern, more solid alternatives. Fastify first of all, but also more specific depending on your needs. Hono, Nest, Koa, strapi, etc. React also has alternatives like Vue, SolidJS, Angular, Svelte and a slew of other more minor libraries. Even Node has alternatives: Deno and Bun, for example, are well known, and Bun also includes its own http server and build tools, and it's more performant. But does anyone want to remember PFSD (Postgres, Fastify, Svelte, Deno), or ONVB (Oracle, Nest, Vue, Bun)? What about SSSN (SQLite, Strapi, Solid, Node), why is that not valid? My point here is that there are hundreds of possible combinations of all of these alternatives, all equally valid, all equally potentially useful for your project, or appropriate for your needs. The not-even-acronyms Now, what about not even doing this as a completely separate stack, but an actually integrated solution that's all in one? What if we chose something a lot more modern that was actually built for generating frontends quickly, effectively, in a short period of time? On the stage, we now have systems like NextJS, Astro, Tanstack Start, and Remix. All based on their own specific configuration and libraries, but all doing the same thing, in terms of pure JavaScript stacks: they add the backend directly into your project, using what is called "server-side rendering". This is done via very different methods for each, sometimes using loader methods, sometimes with server functions, or api routes, etc. These full stack libraries would usually cover both the front-end and back-end libraries (express+react would be replaced by Next or Remix), and the 4 I named above are literally just ones I know from the React world - every front-end library has its list of possible full stack frameworks. Each of those frameworks also can connect to any database or even other APIs and backends, they can do caching and SEO and so many things, that would be much harder, if not impossible, using separate React + Express stacks. Not Industry Standard Some might claim that the MERN stack is somehow an industry standard, potentially citing numbers about React being the most popular front-end JavaScript framework (it is), Node being a good backend language (it is), MongoDB being very popular in node circles (it is) and Express being the most used node http server (it is!). However, those separate facts about popularity are pure cherry picking. They all stem from a forced choice of node as an engine, and JavaScript as a language, and while JS is in fact the most popular browser language (by virtue of it being the ONLY browser language standing for decades), it is by no means the most popular backend language, a position which is held by PHP. MongoDB is the most popular node database but the actual most popular databases are Oracle, followed by MySQL and then Microsoft SQL server. React is the most popular JavaScript framework but it's overshadowed by a lot of other frameworks in other languages : you have Django in python, Laravel for PHP, etc. All that being said, the cherry picking is very strongly biased towards Node and JavaScript. Again, this isn't an invalid combination of technology, but it is not, in any way, "the industry standard" or even close to being the most pop

Apr 7, 2025 - 18:07

This article addresses a very specific conversation that I find myself having repeatedly with beginners who were suggested that they should learn web development in the MERN stack.

I want to address it because there's a very real dumb reason why MERN is such a common suggestion, and why I'm sort of angry about it: it's because you can say MERN out loud, and remember it written, since it looks like a word more than any other common tech stack.

We humans, we love our acronyms, we love to make them sound like words, and we have generally lost the ability to generalize the full stack technologies by shoving it in the MERN acronym which is often literally used, not metaphorically.

The Meaning of MERN

Let's first explore what MERN actually means:

M stands for MongoDB, a document database that was very popular when the acronym was coined.
E is for Express, which for decades was the defacto HTTP server library you wanted to use in node.
R is React, the most popular front-end client-side rendering, one used by the industry, and still very relevant.
N doesn't even relate to a specific part of the stack but rather just "node".

This means that the stack is really just "mongo + express + react", which is not a bad stack per-se.

The Alternatives

My point, though, is that it's just one single variation out of so many possibilities. So for each of those 4 parts, let's first explore just specific changes we can make.

Mongo can be about 2 dozen different databases depending on your needs. MySQL, Postgres, Oracle, SQLite, etc. Not to mention hosted/distributed systems like Firestore, Cloudflare and AWS offerings.
Express has much better, more modern, more solid alternatives. Fastify first of all, but also more specific depending on your needs. Hono, Nest, Koa, strapi, etc.
React also has alternatives like Vue, SolidJS, Angular, Svelte and a slew of other more minor libraries.
Even Node has alternatives: Deno and Bun, for example, are well known, and Bun also includes its own http server and build tools, and it's more performant.

But does anyone want to remember PFSD (Postgres, Fastify, Svelte, Deno), or ONVB (Oracle, Nest, Vue, Bun)? What about SSSN (SQLite, Strapi, Solid, Node), why is that not valid?

My point here is that there are hundreds of possible combinations of all of these alternatives, all equally valid, all equally potentially useful for your project, or appropriate for your needs.

The not-even-acronyms

Now, what about not even doing this as a completely separate stack, but an actually integrated solution that's all in one? What if we chose something a lot more modern that was actually built for generating frontends quickly, effectively, in a short period of time?

On the stage, we now have systems like NextJS, Astro, Tanstack Start, and Remix. All based on their own specific configuration and libraries, but all doing the same thing, in terms of pure JavaScript stacks: they add the backend directly into your project, using what is called "server-side rendering". This is done via very different methods for each, sometimes using loader methods, sometimes with server functions, or api routes, etc.

These full stack libraries would usually cover both the front-end and back-end libraries (express+react would be replaced by Next or Remix), and the 4 I named above are literally just ones I know from the React world - every front-end library has its list of possible full stack frameworks.

Each of those frameworks also can connect to any database or even other APIs and backends, they can do caching and SEO and so many things, that would be much harder, if not impossible, using separate React + Express stacks.

Not Industry Standard

Some might claim that the MERN stack is somehow an industry standard, potentially citing numbers about React being the most popular front-end JavaScript framework (it is), Node being a good backend language (it is), MongoDB being very popular in node circles (it is) and Express being the most used node http server (it is!). However, those separate facts about popularity are pure cherry picking.

They all stem from a forced choice of node as an engine, and JavaScript as a language, and while JS is in fact the most popular browser language (by virtue of it being the ONLY browser language standing for decades), it is by no means the most popular backend language, a position which is held by PHP. MongoDB is the most popular node database but the actual most popular databases are Oracle, followed by MySQL and then Microsoft SQL server. React is the most popular JavaScript framework but it's overshadowed by a lot of other frameworks in other languages : you have Django in python, Laravel for PHP, etc.

All that being said, the cherry picking is very strongly biased towards Node and JavaScript. Again, this isn't an invalid combination of technology, but it is not, in any way, "the industry standard" or even close to being the most popular.

So what do I choose, then?

That is a great question, thank you for asking! And unfortunately, the answer is that it doesn't matter, or that it depends. But here's a joyful bit of information, however: even if you do decide to go with MERN because there's a slew of popular tutorials and videos and courses, none of what you learn there will be completely lost if you move to a different choice of technology in the future. Concepts of rendering, APIs, databases, security, front-end dynamic pages... It's all good, it's all useful, it's all something you will be using in the future.

So do what you like, learn what you can, but just be willing to learn new things in the future, as you define yourself in your development journey.

Interact with this post!

I would love to hear your thoughts on what stack you've learned with (whether it's JavaScript or not!), and if you continued in that stack in projects, at work, etc. Did changing to a different stack or technology take time to adapt? How did you cope? Let me know in the comments!