Since the word
The purpose of this article is not to provoke debate or make us argue over one thing. As I read through the article, I realized that the issues raised are often overlooked and very important for building sustainable project development.
Both soldiers and leaders should continue to pay attention to these things.
The following is a translation of the text: original source: medium.com/building-pr…
The following is the translation:
React was a great library, important for Web development because it introduced declarative versus reactive templates, which was the paradigm shift everyone needed at the time. At the time (6 to 7 years ago), we had a paradigm shift that needed to happen, and React handled it well.
By the way, before React, Ember tackled the same problem. However, it doesn’t perform as well, and the framework prescribes too much than React.
React, however, became a mess after it became popular. There’s a new trend starting in the React community, and it’s all about hype, novelty, and creating new paradigm shifts. Every few months, new libraries emerge that set new standards for how we should write React Web applications, while also solving most of the problems that have already been solved.
Let’s take “state management” as an example. Because React lacks a traditional dependency injection system (DI is implemented through component composition), the community had to figure this out on its own. Then, however, it became solving the problem over and over again, bringing a new set of standards each year.
React is just a rendering engine. In common Web applications, you need to use many libraries to build the framework of your project, such as data layers, state management, routing, asset bundlers, etc.
The React ecosystem gives you too many of these options, and the tech stack becomes fragmented, leading to what is known as “Javascript fatigue.”
Another trend has emerged: a “framework craze”. Rendering speed and memory footprint are often compared between JS frameworks. In fact, in most cases these factors don’t matter at all, because the slowness of the application is not caused by the slowness of the JS framework, but by bad code.
However, like all trends around the world, this one went too far and even endangered a new generation of Web developers. I wondered, why is a library the most prominent technology on a Web developer’s resume? Worse, it’s not even a library, just a module within a library. React Hook is often referred to as a “technology,” even comparable to actual techniques such as code refactoring or code review.
Seriously, when are we going to stop touting this technology?
Like, why didn’t you tell me, you know:
How to write simple and readable code
Don’t brag to me that you have the most star-earning library on GitHub; Instead, show me a good snippet or two.
How to manage state
Instead of talking about a popular state management library, tell me why “data should go down and actions should go up”. Or why state should be changed at the point of creation, rather than deeper in the component hierarchy.
How to test code
Don’t tell me you know Jest or QUnit, but explain why it’s hard to automate end-to-end testing, and why the minimum rendering test takes 10% of the effort but delivers 90% of the benefits.
How to publish code
Don’t tell me you use CI/CD (because there’s more than one person on every project these days), but explain why deployment and release should be separated so that new features don’t affect existing ones and can be launched remotely.
How do I write reviewable code
Don’t say you’re a “team player”, but tell me that code reviews are just as difficult for reviewers, and that you know how to optimize PR for readability and clarity.
How to establish solid project standards
Unless you are the only person on the team, you must adhere to the standards and practices in the project. You should have told me that naming is difficult, and that the wider the range of variables, the more time you should invest in naming.
How to audit other people’s code
Code reviews ensure product quality, reduce bugs and technical debt, build team knowledge together, and so on, but only if they are followed through. Code review should not just be a top-down activity. This is a great learning mechanism for less experienced team members.
How to find your own way in JS framework
It doesn’t matter how many stars you have on GitHub, you should learn the common principles that most JS frameworks have these days. Knowing the pros and cons of other frameworks will give you a better understanding of the framework you have chosen.
How to build a minimum viable product
Technology is just a tool for making things, not a process. Instead of wasting time on technical arguments, spend time optimizing the process.
How to optimize: Not too early, Not too late
Because in most cases there is no need for optimization at all.
How to pair program
Because pair programming, like code review, is the most important practice for sharing knowledge and building team cohesion. And it’s fun!
How to keep refactoring
Because every project has technical debt, you should stop complaining and start refactoring. Small code refactorings should be done every time a new feature is developed. Massive refactoring and rewriting never ends well.
That’s why I think React has ruined Web development. Many people are interested in this statement and eagerly join the debate.