React messed up web development

In early June, I attended a developer conference .debugwhere my company had its own stand. The point of the stand was to create a “Change my mind” situation: we presented some radical idea, invited people to discuss it with us, and then showed them what we were doing interesting.

We decided to take this idea:


My first opponent was this young guy on the right, building native React apps.

Seriously, React is a good library. It is important for web development because it uses declarative and reactive patterns, and this paradigm shift was needed by everyone at the time of its creation. In those days (6-7 years ago) there were problems with rendering engines and reactivity, but React solved them pretty well.

It’s worth noting that the same problem was previously solved by Ember. However, it was not very performant and too categorical to compete with React.

useEffect (makeMess)

However, after React gained popularity, chaos began. He gave birth to a new trend in the community, when everything revolves around hype, novelty and creating new paradigm shifts. Every few months, new libraries emerged, new standards were created for how React web applications should be written, but they solved problems that were mostly solved.

Take state management as an example. Since React lacks a traditional dependency injection system (DI is implemented through component composition), the community is forced to solve this problem on its own. And it decided. And decided again, and again, and again. Each new year brought new sets of standards.


The motto of state management in React is “new year, new standard!”

React is just a rendering engine, and in a typical web application, many libraries are required to build a project framework, such as data layers, state management, routing, resource linkers, and so on.

The ecosystem behind React gave us too many choices, which fragmented the technology stack and led to the infamous “Javascript fatigue”.

There has also been a tendency to “be obsessed with comparing frameworks.” JS frameworks are constantly being compared for properties such as rendering speed and memory usage. More often than not, all this is unimportant, because the application becomes slow not because of a slow JS framework, but because of bad code.


The discussion queue is getting longer …

And as with any trend that is taking over the world, things have gone too far, and this has begun to wreak havoc on new generations of web developers. How is it even possible that library knowledge has become the most important skill on the average web developer’s resume? Worse, it’s not even a library, but a module within a library. React Hooks are more often referred to as a “skill” than actual skills such as refactoring or code analysis.

Seriously? When did we stop bragging about what was important?

Why, for example, do you not tell me that you know:

How to write simple and readable code

… not mentioning the most-starred library from Github, but showing me a couple of their best code examples.

How to manage state

… without mentioning the popular state management library (preferably ending with an “X”), but explaining to me why “data should move down and actions should move up.” Or why the state should change where it was created, and not deeper in the hierarchy of components.

How to test your code

… not telling me that you know Jest or QUnit, but explaining why it is difficult to automate end-to-end tests and why minimal meaningful rendering tests require 10% effort and provide 90% benefit.

How to release your code

… not mentioning that you are using CI / CD (like any other project today that more than one person is working on), but explaining that deployment and release should be separated so that new code can be written without interfering with old code, and so that it can be disabled remotely.

How to write code that’s easy to parse

… not to say that you are a “team player,” but by telling me that code review is just as difficult for the reviewer, and that you know how to optimize your pull requests to be readable and understandable.

How to create robust project standards

… because if you don’t work alone, you will hate your life if you don’t follow strict standards and conventions in the project. You have to say that name guessing is difficult, and that the larger the scope of a variable, the more time it will take to come up with a good name for it.

How to analyze someone else’s code

… because code review ensures product quality, reduces bugs and technical debt, builds a common knowledge base for the team, but only if it’s implemented correctly. Code analysis should not be done only from top to bottom. This is a great learning tool for inexperienced team members.

How to understand any JS framework

… because it’s not about the GitHub stars, but about the general principles shared by most modern JS frameworks. Identifying the strengths and weaknesses of other frameworks allows you to better understand the framework you have chosen.

How to create an MVP

… because technology is only a tool for creating products, not a process. Spending time optimizing a process is always better than wasting time arguing about technology.

How to optimize: not too early, not too late

… because most of the time there is no need for optimization.

How to do pair programming

… because pair programming, like code analysis, is one of the most important practices for sharing knowledge and building a coherent team. It’s also fun!

How to do continuous refactoring

… because every project has a technical debt, you need to stop whining about it and start refactoring. Each new feature should be preceded by a small refactoring of the code. Large-scale refactoring or code rewriting never ends well.

This is why I believe React messed up web development. Conference attendees were intrigued by our statement and eagerly joined the debate. We’ve had amazing conversations with several experienced React developers. None of them agreed with the title of this article, they said that “spoiled” is too strong a word. But most of them agreed with the existence of the problems described in the article.

Try to convince me that React is not so bad, and I totally agree with you!

But instead, let’s discuss more important topics – the work we actually do as software designers


Advertising

Our company offers cloud vds servers for any tasks and projects, whether it is serious calculations or just posting a blog on WordPress. Create your own tariff plan in a couple of clicks and get a ready-made server in a minute, the maximum configuration breaks records – 128 CPU cores, 512 GB RAM, 4000 GB NVMe!

Subscribe to our chat in Telegram

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *