React Developers - They Don't remEmber

Jun 07, 2022 4 minutes read
Blue and brown milky way galaxy - Miriam Espacio (pexels.com)

I think everyone will agree with the statement that the general frontend is relatively simpler than the backend (including data structures, algorithms, database systems, cloud, and so on). Therefore HTML, CSS and JavaScript/React are usually the natural choice of most beginners in web. Even beginner programming courses usually touch upon these topics.

It's hard for me to imagine a person at the beginning of the IT journey who learns C/C++, memory leaks, cursors, databases, NLP or image processing. Of course, there are exceptions, but statistically, you can rarely meet a person who is inspired by the above topics.

This introduction is only to outline that a large number of programmers begin their adventure with IT by choosing frontend one of the three most popular tools (e.g. React). And they stay with them. Nowadays, there is a huge demand for programmers, there is no pressure and no need to learn new tools to become a better hireable. It is enough to master one technology to survive the next years. This has its pros and cons. One of the biggest disadvantages for our clients is that we always offer them what we know.

According to a StackOverflow report (2021), 41% of professional developers chose React. 2021 was also significant because React surpassed jQuery as the most commonly used web framework 🥳. The next interesting thing is that almost 60% of developers use videos and blogs to learn programming 🤔.

So what do they not remEmber?

TL;DR React devs don't remember and/or keep forgetting about Vue and Angular. 🤭

When You're a React Dev, Everything Looks Like a React Component

React Dev

Big three

Of course, it's about Angular, React and Vue, which are in the top 5 web frameworks/tools. Each of them makes our code pleasant to work with. There are already many articles that cover the pros and cons. In my opinion, each of them is great.

It's hard to compare three different things, so it's best if you spend a few hours or days writing a mini-blog or even a simple calculator in your spare time. Then you will see how you work with the code, which functionalities are out of the box, and how many dependencies you need to install to achieve your goal.

In this way, you will learn the code, check what each of them gives you options, which community suits you best, which documentation is the most readable. There is nothing to lose here.

Sometimes you just want to use a specific tool to test it, play with it, or specialize in it. However, in some cases, when the client is investing a hefty budget, deadlines are tight, or the project has to be maintained for several more years (or 5, maybe 10 or more ...?) it could be better to spend more time on client needs, understand the project and choose a proper tool.

We shouldn't use React…?

Of course not, I don't mean that. But of course we should check if other tools are better suited to the project we are going to work on.

I have seen a lot of project teams and noticed that the decision on tool is usually made a few moments after contracting the project (int/ext). It happens so quickly that before we create a proof of concept, business documents or we hire a product owner, an empty repository created by create-react-app is waiting for us. Of course it's a hyperbole, but such things happen. And later on could generate a lot of costs.

Another example would be corporate requirements - yes, there are such things. For example, we always write in React, because that is what we decided some time ago 🙎. And such decisions are usually made by (unaware) clients, managers or through team pressure. Because everyone wants to use most hyped tech stack, and learn new things…

Just think about your client, don't be selfish!

A little hint for what to choose

Based on my experience, if your project focuses mostly on JavaScript code (e.g. you create a new Slack or Google Drive) and you don't have a lot of CSS and HTML, then React will probably be a good choice!

However, if your project focuses on working with HTML, styling, interactions and has a lot of sub pages, etc. (e.g. CRM), check Angular and Vue first.

Closing notes

The title of the article obviously refers to Ember.js, which in this text is only an example. I don't think there is any market need to learn Ember at the moment, unless you plan on working with some legacy code. But Ember and other tools that made their way into Web2.0 created a new approach that started before 2010.

Cheers!

Disclaimer: The opinions expressed here are my own and do not necessarily represent those of current or past employers.
Comments (0)