As a web developer, choosing the right stack for your project can be a critical decision. With the rising popularity of React, many developers have been drawn to its simplicity, flexibility, and scalability. But with so many different React stacks to choose from, it can be challenging to decide which one is the best fit for your project.
So, what is your favorite React stack? There are several popular options to choose from, each with its unique benefits and drawbacks. Here are some of the most widely used React stacks:
MERN Stack
The MERN stack is a popular web development stack that combines MongoDB, Express, React, and Node.js. This stack has gained significant popularity over the past few years due to its flexibility, scalability, and ease of use. Each component of the MERN stack has its specific role in web development.
MongoDB is a NoSQL database that uses JSON-like documents with dynamic schemas, making it flexible and scalable. Express is a web application framework for Node.js that provides a robust set of features for web and mobile apps. React is a JavaScript library used for building user interfaces, while Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine.
One of the primary advantages of using the MERN stack is its versatility. The stack can be used to develop web apps for various industries and sectors, such as healthcare, finance, and e-commerce. Another benefit is the ease of deployment, which is made possible by the use of Node.js as a server-side runtime.
MERN is an open-source stack that is supported by a large community of developers. This community provides ongoing support, updates, and new features that make the stack even more powerful and efficient. The stack's modular structure enables developers to work on each component separately, making it easy to scale up or down as needed.
The MERN stack is also suitable for creating real-time applications, such as chat apps, due to its ability to handle complex, multi-channel communication. This feature is facilitated by the use of WebSockets, which enable real-time data exchange between the client and the server.
The MERN stack is an excellent choice for web developers looking for a robust, scalable, and versatile stack. Its components are well suited for building modern web apps that require real-time data exchange, dynamic data structures, and scalability. Its open-source nature, community support, and modular structure make it a favorite among web developers worldwide.
MEAN Stack
The MEAN stack is similar to MERN but uses Angular instead of React. This stack is a collection of technologies that are often used together to develop web apps. The name MEAN is an acronym that stands for:
MongoDB: a NoSQL database that stores data in a JSON-like format.
Express: a web application framework for Node.js that provides a set of features and tools for building web apps.
Angular: a front-end JavaScript framework for building dynamic single-page apps.
Node.js: a JavaScript runtime environment that allows developers to run JavaScript code outside of a web browser.
Together, these technologies provide a complete solution for building web applications, from the front-end to the back-end. MongoDB provides a flexible and scalable data storage solution, while Express and Node.js provide a server-side environment for running JavaScript code and building RESTful APIs. Angular provides a powerful front-end framework for building dynamic web interfaces and connecting with the back-end.
The MEAN stack has become popular among developers because it allows them to build web apps using a single language, JavaScript, from the front-end to the back-end. This can help simplify the development process and allow for more efficient communication between different parts of a development team. If I say more, the use of open-source technologies like Node.js, MongoDB, and Angular can help reduce the cost of building web apps, as these technologies are free to use and have large developer communities.
React Redux Stack
React Redux is a popular stack for building web apps using JavaScript. It combines two powerful libraries: React and Redux, to create scalable and efficient applications.
React is a JavaScript library for building user interfaces. It allows developers to create reusable UI components and manage the state of the application in a declarative way. React provides a virtual DOM, which allows for efficient updates to the UI, and a component-based architecture, which promotes code reuse and separation of concerns.
On otherside, Redux is a predictable state container for JavaScript apps. It provides a centralized store for managing the state of the app and ensures that state changes are made in a predictable and consistent way. Redux is based on the principles of functional programming and immutability, which makes it easier to reason about the behavior of the app and to test it.
Together, React and Redux provide a powerful stack for building web apps. React provides a flexible and efficient UI layer, while Redux provides a predictable and manageable state layer. By using these two libraries together, developers can create scalable, maintainable, and testable web applications.
Next.js Stack
Next.js is a full-stack framework for building modern web applications. It is based on React and Node.js and provides a powerful set of tools and features to build scalable and performant applications. Next.js allows developers to render web pages on the server side, which improves website performance and search engine optimization.
The Next.js stack includes:
React - Next.js is built on top of React, a popular JavaScript library for building user interfaces.
Node.js - Next.js uses Node.js as its server-side runtime environment, allowing for server-side rendering and API integration.
Webpack - Next.js uses Webpack for bundling and optimizing JavaScript and other assets.
Babel - Next.js uses Babel for transpiling modern JavaScript code to a format that can be run in older browsers.
Express - Next.js uses Express as its server-side web framework, providing a flexible and easy-to-use API for building web apps.
CSS Modules - Next.js supports CSS Modules, allowing for modular and reusable styling of components.
TypeScript - Next.js supports TypeScript, a typed superset of JavaScript that adds additional safety and clarity to code.
GraphQL - Next.js integrates with GraphQL, a powerful query language for APIs, allowing for efficient data fetching and management.
Serverless - Next.js supports serverless deployment, allowing for easy and cost-effective scaling of apps.
The Next.js stack provides a comprehensive and flexible set of tools for building modern web apps.
Gatsby Stack
Gatsby is another framework for building server-side rendered React applications. This stack includes Gatsby, React, and Node.js. Gatsby is used to create server-side rendered applications, React is used for building the UI components, and Node.js provides the runtime environment. This stack is preferred by developers who want a more fast and performant solution.
The Gatsby stack typically includes the following technologies:
Gatsby: a static site generator built on top of React that allows developers to create blazing-fast, highly optimized websites and applications.
React: a popular JavaScript library for building user interfaces that is used as the foundation for Gatsby.
GraphQL: a query language for APIs that is used by Gatsby to pull data from various sources, including CMSs, APIs, and databases.
Headless CMS: a content management system that separates the content management functionality from the presentation layer. Examples of headless CMSs that work well with Gatsby include Contentful, Sanity, and Strapi.
Git: a version control system that is commonly used in combination with Gatsby to manage code changes and collaborate with other developers.
Hosting platform: Gatsby sites can be hosted on a variety of platforms, including Netlify, AWS Amplify, and Firebase, among others.
Plugins: Gatsby has a large ecosystem of plugins that can be used to extend its functionality, such as plugins for image optimization, SEO, and accessibility.
Moving forward to conclusion, the Gatsby stack provides developers with a powerful and flexible set of tools for building high-performance, modern web applications and websites.
Choosing the right React stack for your project depends on your requirements and preferences. Consider factors such as scalability, performance, development time, ease of use, and maintenance. Whatever stack you choose, make sure it aligns with your goals and provides the necessary features and functionalities to make your project a success.
There is no one-size-fits-all solution when it comes to choosing a React stack. Each stack has its own unique strengths and weaknesses. Ultimately, the right choice depends on your project requirements, skill set, and goals. So, take the time to research and evaluate each option, and choose the one that best suits your needs.
🍀Support
Please consider following and supporting us by subscribing to our channel. Your support is greatly appreciated and will help us continue creating content for you to enjoy. Thank you in advance for your support!
Top comments (36)
That's so difficult to decide, it depends a lot on the project and deployment method, my here are my favs in order of preference.
UI
Databases
Frameworks
Thanks for your comment.. Yes, you're absolutely right that the choice of a React stack ultimately depends on the specific needs of the project and the deployment method. Material-UI & ChakraUI are both fantastic choices for UI frameworks.. I appreciate you taking the time to share your experience...
Is this post from 2009? Since then...
If you just started programming with Khan Academy you might still learn MERN...
Ant Design lib is also a masterpiece that no one ever mentions.
Let's stop pushing MongoDB everywhere, it's harmful.
In which way is MongoDB harmful? Are there security issues we should know?
Also - express is still a pretty solid choice for simple projects.
Besides that I fully agree with replacing redux with contexts, that simplified things a lot!
MongoDB is harmful because 99% of developers use it as a general DB, without paying attention to the fact that they will loose ACID transactions, have to denormalize their schemas in order to compensate the lack of SQL JOINs, and deport the complexity in their own code instead of relying on powerful SQL transactions.
All of this for what? JSON. But nowadays you have JSON in MySQL and PostgreSQL which are much more advanced and faster databases than MongoDB.
Also you can't do big data with MongoDB, as soon as you activate sharding you loose half of the aggregate operators and query computing is not parallelized so if your dataset is above 5GB you will end up with a 30secs timeout.
I've done that mistake for many years, and going back to the SQL world saved me.
I'm not saying pick MongoDB, use the CORRECT databse for the work.
But, almost every NoSQL supports ACID transactions.
mongodb.com/basics/acid-transactions
And the correct database for 99% of the work is not MongoDB.
ACID has multiple degrees of consistency... serializable transactions, MVCC etc... it's easy to throw "ACID" on marketing pages, the devil is in the details.
So many use cases don't need insane level of consistency.
The internet on a whole is basically "eventually consistent" and that becomes more apparent the larger the scale and reach of your platform.
It is probably better to architect for eventual consistency everywhere over pinning hopes on a database to save you. Of course, at a smaller scale or if everything is in one data center, sure. I guess. At small scale Mongo will be consistent just fine.
I get there is a lot of bad feelings with MongoDB. It had a rough start. It isn't my go-to database myself. Personally, I use DynamoDB (or DocumentDB) on AWS, Firestore on GCP or CosmosDB on Azure. If I need relational data, I first look at a graph database like ArangoDB. If I need analytical data, I look at something like GCP Big Query. Complex searching? ElasticSearch or TypeSense.
My "source of truth" databases are almost always a super fast and super scalable NoSQL. Most data is just a bunch of documents anyway and 99% of the time I am accessing them by ID. I also follow domain driven design, so by core business domains access their data through APIs. So a shopping cart service would get inventory from the inventory API and the pricing from the pricing API and never through a JOIN in a single database.
Obviously, there are cons to a distributed data model. Not as much these days. The tooling has come a LONG way. Storage is cheap, having a data stream from the transactional DB into an analytical DB is easy enough. Or if I want a powerful product search engine, then that might have a "dirty" copy of product, price and inventory where the actual product landing page gets the data directly from the APIs for more "up to date" information.
Would I be fine using Mongo as my pricing DB. For sure. The advantage of this pattern is that you really can pick a DB optimized for the data. MonoDB might not be the best for pricing data. I'm looking up price by a productID and maybe some other filters/projections. AWS DynamoDB would be super fast. GCP Firestore as well, plus it has a bit more query tools. Really, a super fast columnar DB is pretty ideal in this case. An RDMS is just going to be overkill.
To take advantage of the platform as a service model we live in, I think it requires a shift in thinking on how we build large enterprise platforms. And if you are building small - well, the DB choice doesn't really matter all that much other than the cost to run it.
by reading the other comments I just noticed that this post attracted frontend / fullstack devs, who mainly write JS / PHP...
makes sense no one understands the importance of JOINs and SQL transactions here... good luck with MongoDB
Again, transactions are a part of just about all databases these days.
As for JOINs. that is a use case. It would be important if you are doing analytics for sure! If you are joining data cross-domain in a large enterprise platform - well, that is just going to cause huge issues down the road for scalability and waterfall release schedules.
RDMS is not a bad choice. It isn't the ONLY choice anymore though.
Again, from my example - you can shove everything in an online commerce app into one RDMS and join your price, inventory, user data, coupon data, etc... all in one huge SQL query.
Now, changing the schema for inventory means multiple code areas could break. It is way harder to maintain a V1 Db schema alongside a V2 Db schema than following an API-first design for that same data.
But, maybe you won't scale huge. Most people don't. And again, I am NOT a person who goes for MongoDB as my primary DB. It is pretty foolish to discount it as an enterprise grade / production ready solution. I would suggest to anyone, if starting a project, consider both popular and up-and-coming DB as solutions and don't be afraid to use more than one. That's the nice thing about microservices and domain driven design - use the right tool for the job.
I forgive you.
Next Js for sure.
In most projects it just doesn't make sense to have a non-relational database, so MERN rejected to what matters for answering the question of the post.
You can use Mongo along Next if you need so btw, just add mongoose and you're good to go.
I usually use Next Js with Sequelize (PostgreS, MariaDB...) because you have a monolithic App that works API-first so you can scale it whenever you want.
To be honest, Vercel people did, and are doing a great job in "standardizing" the development process around React while providing great features out of the box that most projects need sooner or later, plus the SSR thingy is king when dealing with public websites or web Apps both bor UX and SEO.
Aside from that, you can sure use Gatsby or any other headless CMS along with Next JS (idk why you set Gatsby as its own "stack" 😅). The same can be said of having Next JS to work with Redux or MobX, though most projects don't really need neither one or the other.
Why? In most projects I see people using CRUD methods to access documents. I think I can count on my fingers the amount of times someone actually needed "relational" data.
It is super easy to JOIN that user data with the inventory and pricing to fill out the shopping cart. I do get that. There are so many times that I want to break those separation of concerns and just read the data directly.
The reality though, if I actually keep my business functions in a domain design and access domain data through APIs, events or some other clearly abstracted (loosely coupled) pattern, then I now can scale faster and develop faster with larger teams.
So yeah, now the cart service has to call the pricing, inventory and user services to gather up all that data. I pay for this in some additional milliseconds. But now if inventory needs to change into a different DB for performance or if the users domain needs to change their DB schema - they won't break my code. Well, as long as their honor their API contract (or other public interface).
ORMs are cool. They make things a bit easier, for sure. That's the reason front end full stack devs keep picking it up. A tool like Prisma is popular and easy to start up with. The "better" choice would be to pick a database that handles the data in the best way possible. User data, for example, is often very document in nature and has such a high read count, I almost always put it in a fully managed NoSQL that can scale horizontally really well.
"In most projects it just doesn't make sense to have a non-relational database" -> there are tons of cases where this statement is wrong. Like for any case where you don't often combine data from different objects.
Thanks for your detailed comment.. Yes, I agree with you that the Vercel team has done an excellent job in standardizing the development process around React and providing many useful features out of the box..
I appreciate your point about the possibility of using Mongo along with Next.js by adding Mongoose..
For Gatsby, I mentioned it as its own "stack" because it is a popular framework in its own right and while it shares some similarities with Next.js, there are some key differences that make them distinct. But as you mentioned, it is entirely possible to use Gatsby along with Next.js, depending on the needs of your project..
I also appreciate you taking the time to share your experiences and insights into the Next.js stack..
Thank you again..
I’m old-school, and so while I appreciate Node/Express, I feel like I don’t have all the tooling I like from developing in PHP using Laravel. It’s super easy to make very expressive models that emit themselves as JSON responses for APIs, with React or Angular in the frontend. There are things I like about Angular, and things I like about React. I use React in my day job so I’m leaning that way currently, but I really liked Angular’s dependency injection for services, and RXJS’ observables. We use Redux during the day, but I’m playing around with just using React’s Context API, and it really simplifies thing when you only have one or two states to maintain.
Agree. I love the tooling and DX when using Laravel. For frontend, my choice is React, never tried Angular.
I am a solid Next.js enthusiast.
That's great to hear that..
Nextjs anytime.
Indeed..
i learnt a lot of new information about React, thanks!
I'm so glad to hear that you found it helpful. Thank you for reading it..
React - Meteor - MongoDB
T3 Stack
Thank you for this reference. I will try it out..
Honestly I can't choose between Next.js and MERN stack. Nice post though!
You can choose MN 😂😂
Next brings Express React and Node on its own, you just add Mongo (or any other DB) on the stack and you're good to go 😁
true :)
Thank you for your comment. Both Next.js and the MERN stack are fantastic tools for building web apps and it can be challenging to choose between them. It really comes down to your project's specific needs and requirements..