In my programming career I am highly flexible. I don't find it difficult to move from one platform/language/library/framework to go learn a new one. I usually love the excitement of the possibility that there could be something that could make my development experience easier. So far my journey has been through Java, QT C++, .Net C#, codeingniter PHP, Laravel PHP, NodeJS express, NodeJS Loopback, django python and adonisjs. In this entire journey, I have spent most of my time in Laravel PHP. Also on frontend SPA frameworks, I went from angular, vuejs, react and then svelte. In the front end arena I have spent most of my time in angular and vuejs.
The dark side
Every time I start a new project, there is always a question of which development stack should I use. I always prefer NodeJS as my first preference, that any tools I choose should be based off of it. I am very biased towards NodeJS apparently. But that introduces another problem, which library/framework should I use.
Express and React are obviously the most popular libraries/frameworks out there in the NodeJS ecosystem. Be it fear of missing out, or the follow the crowd mentality, they are usually the first ones to consider and try starting my project with. Everyone loves them, why shouldn't I? Happens there is a couple of reasons.
Refer this article: Opinionated or Not: Choosing the Right Framework for the Job
It can loosely be said that both express and react are un opinionated frameworks/libraries. This means that (if you were too lazy to read the article above😏) unlike frameworks that they have assumptions that lead to having directives on how to implement features. Unopinionated frameworks/libraries do not have this. To some extent this is a good thing, as you can quickly create something of which your imagination is the limit.
But for some of us that freedom comes as a burden, especially when I am trying to start using the framework for the first time in a pet project that has a very demanding architecture.
2. No standard libraries/packages
This can be inside unopinionated but I think it's best it gets its own paragraph. Due their nature, there is barely any standard libraries/packages for certain functions, only most popular ones. For example in express, I have to choose myself which ORM to use, either sequelize, typeorm, prisma or bookshelf just to name a few.
The same applies to almost every other functionality, mailing, logging, validating, file uploading etc. This means in your development time, unless you are very experienced in them, you have to waste time to choose, learn and experiment multiple libraries for the said functionalities.
In the case of react it is even worse, it's default state management using props and state is very hard to maintain as the project gets bigger, react redux has too much boiler plate, then you find there is recoil, mobx, akita, hookstate etc. Also when you want to implement routing, form validation or http request to name a few, you have to go through the same thing.
3. No standard design pattern
You have to again waste valuable time to choose which design pattern to use. Where to keep which files, directory structure in general. Or take your time to go through articles and answers on stackoverflow looking for the most recommended patterns. Because agree it or not, your choice of design pattern will determine how easy it is to scale and maintain your project in the future it will be.
4. Writing glue code
For this one I will steal some words off of Harminder Virk's mouth, the creator of adonisjs.
Let’s go through a small example and see how glue code makes its way into your code.
- You choose a main framework that does only the routing for you.
- Then you pick the popular body parser to access form input and uploaded files.
- Next step maybe is to use a validation engine to validate the form. But wait, the validation engine has no idea about the properties that exists on the file object created by the bodyparser. Hmmmm, let’s write some glue code between both of them.
- Wait, you also want to validate the email address to ensure it’s unique inside the database. Again, the validation engine has no idea about your Database ORM. So, another glue?
Well, the reality is, a working real world application always have overlapping parts and without an integrated system, you will always find yourself writing more glue code than the actual code.
These two platforms are very popular for a reason, and maybe those reasons have not resonated with me, especially coming from and/or being very experienced in opinionated frameworks. But for some use cases and some people these are very good frameworks/libraries.