In these days where MVC feels like from the dinosaurs age. Our APIs are serving multiple client apps and a lot of business logic moved to our client applications. Front end development is much more than just nicely coded interface, it’s a lot of programming, sometimes the architecture can be tricky and even serving our web app might not be as straightforward as pushing things via FTP.

This article assumes that you already have some experience with creating at least small React apps and you are about to make some bigger architecture decisions on your (first) large scale application. React is a great tool to accomplish building something extraordinary, however I often see developers trying to use React anywhere they can. If you are about to build something small that doesn't require too many backend services, maybe a presentation (landing pages) of your product, I totally recommend Webflow to save your time with creating your intentions by designing with minimum coding and deployment knowledge!

Table of contents

Before you start Team Scalability Choosing libraries for your stack My picks Summary

So, you or your company has just decided to start a big(commercial, publicly available) project and you’ve decided to use React. You’ve probably already done some research, otherwise you wouldn’t pick React, but there are still a lot of decisions to make what to use in your stack. React is just a view library and there are many missing pieces. State management, routing, localisation, styling and interface, deployment, … Do you need PWA, SSR?

(Un)fortunately, there is a lot of freedom when it comes to architecting a React stack. If you know what you are doing, you can set it up in less than a day. Or you can struggle for a week until everything works smoothly. Here I am going to talk about the ideal scenario since one article cannot cover all the gotchas and individual cases that might affect the decisions.

Before you start, analyse first and keep it simple

Analysing the goals and needs should be the first thing you do anytime you start something. Whether it’s something small or it’s a large project, write down the requirements and thoughts if you don’t have them. Of course, requirements often change, maybe even the direction of the product, but that’s in the future and no one can predict it. That is the reason why you shouldn’t try to predict it either.

To successfully release your very first version of the application (MVP), you should keep it simple, use only tools and libraries that are essential. Adding more tools and libraries that might be useful in the future just adds up complexity and slows down your development. Every developer is excited when trying something new, however I don't think that beginning of a large project is the right time to do so.

In my very first article, I wrote some thoughts about designing your application in terms of UX, even though it's meant for designers, it's written from a perspective of a dev/product guy. Even development needs good UX.

Team scalability

I've set up many projects there is one thing to say. There is no worse beginning of a project when your colleagues have to learn too many new things to start. Have you been on boarded to a project in the middle of a development and it took eternity to understand it? Surely, we want to project the best into the codebase, but everyone is a bit different and that applies to a thought process as well.

Javascript is a land of a madman and this is why common patterns and best practice are important. In theory, it should help with the clarity of the code. Surely nobody knows everything but keep in mind. You are not writing the code for yourself exclusively. Also… What do you think of a code you wrote a year ago? I got headaches sometimes so I want to make sure that it will be as least painful as it can be for the others after reading my code! Surely development tools such as eslint and flow (or if you like typescript) helps with maintaining the codebase within a large team.

Choosing the right libraries for your javascript project. Which one is the best?

It’s the library you and your team know the best and you are comfortable working with. Seriously. Do you know Redux well? Then use Redux for the state management. Do you like MobX? Then use MobX. A stack is only as good as the developer(s) working on it. I am not saying that you shouldn’t use anything new, I like learning new things as you do, but personally for me, those new things belong to some internal or personal projects where mistakes and little knowledge are acceptable. Learning a new library is not only about reading the documentation, sometimes these libraries use totally different approach and patterns and it always takes time to master.

Still feeling like you should use something you've heard about? One or two new things are fine, but make sure that it won’t affect the quality of the project. And like it or not, you will have to think about other people as well. A good developer knows how to code. A great developer knows how to work in a team. And having a shared knowledge is much more powerful for your team and business. Using common patterns and best practice was not made for fun, and the same applies when you are deciding about your architecture. Common technology (not outdated!) can speed up your development rapidly when the team grows.