A few months ago, I began work on a brand new project built from the ground up. It's my second run working with a startup, so I am all too familiar with the initial pains of having to decide on a tech stack. And because React is quickly becoming one of the fastest growing full-stack front-end frameworks, and because I had just spent 4 years as an instructor for a React bootcamp, it made perfect sense to continue using it for this project.
But that was a few months ago. And now that the project is fully live and being used by real users, it's time to reflect a little and to gauge whether React was actually the right choice for the job.
Because alot of things went well with using it. But some things were alot more difficult and time consuming that I would have wanted. So let's start with the big wins in using React. Starting with the most beneficial for me personally.
And that's the fact that React is very developer friendly, for any skill level. If you're a senior programmer in C# for example, then you will feel comfortable in a JavaScript framework environment, seeing as how both languages are C based.
And if you are just getting started with programming, and you know just some JavaScript, it won't be a huge leap forward to pick up React as it is essentially the same syntax just used slightly differently.
Developer friendly
Hiring for a React position, at any skill level, is alot easier than hiring, say, for a C++ position. And much much easier than hiring for something even more archaic, like Pascal. And alot of that probably has to do with the solid marketing that React brings to the table. There's definitely way more talk about React online than many other frameworks. And typically, if you search for coding tutorials in React on something like YouTube, you're bound to see high viewed videos getting made constantly using React specifically.
And looking at the latest Stack Overflow developer survey that is released every year, it looks like React is still a dominant force.
For that reason I've been able to hire junior React developers straight out of a bootcamp to work on this project with me. Because much of what they learned in the bootcamp translates almost perfectly to a new React based application.
Compared to something like C#, which is traditionally my primary language, JavaScript is substantially much easier to learn, mainly because you don't have to spend years learning the intricacies of the .NET Framework in order to start coding.
And these days, JavaScript has gotten powerful enough that it can somewhat compete with some of the older and more mature languages.
Simpler development environment
Because React is based on JavaScript, it technically just needs a JavaScript runtime and it's off to the races.
Typically that means having Node.js installed on your machine and then downloading VS Code. But technically, you can choose any editor of your choosing in order to edit files, like JetBrains Fleet, or even Notepad.
For the majority of my career though, I've relied heavily on Visual Studio 20XX in order to do all of my work. And the full Visual Studio IDE is nowhere near similar to VS Code. Visual Studio is a very large and complex application that can take anywhere from 10GB to 20GB to install (depending on configuration) and it can take months to become proficient in using it.
So moving pretty much all of my entire workflow into VS Code in a non-compiled environment where I can simply type a single command and have the entire application run has been a huge time saver for me personally.
But more importantly, it has been incredibly easy to onboard developers because of this. Whereas in the past, having to install and properly configure Visual Studio was a time-consuming and often times error prone way of staring things out for any new developer.
How's performance?
Having built applications using a variety of frameworks, I can confidently say that React is very fast overall. By that I mean that the frontend data binding is very fast.
But because we're using a client/server setup for our application, performance really comes down to 2 things. Those being the database and the data access layer portion of the application.
So while the frontend has impressive load times, performing database queries on large datasets and then running those results through a server-side processing layer is still somewhat of a standard slow process.
Because we are working with large datasets and with complex queries, much of the performance updates and improvements will have to be done on the actual database server, not so much on the web server.
But the big win in performance, is more so in the build process. Build times have remained relatively consistent through several months of work and have only slightly increased. And that's a massive win in my book, because I've worked on several real world projects where build times were over 10 minutes.
And best of all, because the stack is very lightweight, it can pretty much run on any hardware and still maintain its high level of speed.
Maintenance
Much of maintenance really comes down to how you set up your project.
If you have decent separation of concerns and have your components well isolated, but communicating effectively, then making large changes to your applications requires overall minimal updates to the codebase.
But that's if you set it up correctly. Which isn't always the case. And why I'm split in this particular regard. Because initially, when I first set this project up, I made several choices that later on failed to get the results. Things such as nesting components too deeply, and thus ending up with prop drilling issues and not nesting enough, causing duplicate code.
I also ended up with a folder structure that inevitably became too confusing to keep up with and thus had to restructure it several times over.
And as I am working with other developers, pretty much everyone felt the issues along the way as well.
Those specific issues caused for some maintenance headaches in the very beginning of our project. But once addressed and fixed, maintenance has been pretty good so far. It's at least on par with other frameworks and languages that I've used in the past.
So again, maintenance will really depend on your personal project structure more than anything else.
Overall
After 6 months, I can safely say that this project has been a success in terms of developing an enterprise level application. It's overall very fast and it's modular enough that multiple developers can work on it without an issues.
But this is mainly because we spent a great deal of time setting up a scalable framework in the very beginning of the project. It could have easily gone in a different direction if we had not worked to refactor various parts of the code.
Would I use React again on a different project in the future? I think the answer would depend on the particular project and its specific needs. Because I'm not saying in this article that React is better than all the other frameworks, not at all. But I am saying that it is just as good as some of the more widely used ones and in the end, you will have to weigh out your own options and choose the solution that is most optimal.