In the past few days, I have read three articles, all of which engineers regret using new technologies.
The first article “Why We Abandoned the Elm Language”
The second article, GraphQL: From Excitement to Deception.
Part 3, “Why I Regret Using Iionic”.
The above three new technologies have all been born in the past 10 years. At that time, they all claimed to have solved major problems in development, and they looked promising. Therefore, as soon as it was born, it became a hot spot and attracted very much attention, and these engineers adopted it.
Let me talk about the advantages of these technologies.
The ELM language guarantees that web scripts no longer report errors.
GraphQL only sends a single request, which satisfies all the data needs of the frontend.
Ionic lets you develop Android and Apple mobile apps using any JS framework.
If you are a front-end engineer, you will probably be immediately impressed when you look at these technical features.
However, when you actually use them in production, problems will slowly come to light, and you may regret it in a few years just like the author of the article above.
Elm: The last update was in 2019, and integration with the current JS ecosystem is becoming increasingly difficult.
GraphQL: The performance improvement after use is not obvious, but the background architecture becomes complex, and the problems such as paging and caching are troublesome.
Ionic: Insufficient and chaotic documentation, no community and ecology.
When you regret it and want to change the technology stack, it’s too late. It’s easy to get on and off, and the project has been invested for several years, so it’s easy to modify the structure.
The lesson is to be cautious when using new technologies. One of the biggest risks of new technologies, which are often overlooked, is that they are not used enough and the problems are not exposed.
I remember someone doing research that only 20% of the cost of enterprise software is the cost of early development, and the remaining 80% is the cost of maintenance and update in the later stage.
Many new technologies seem to save 20% of the first 20% of development costs, but may greatly increase the maintenance costs of the latter 80%.
Here’s why so many businesses choose Java over trendy and fancy new technologies in real life: Java is tried-and-tested, doesn’t have strange problems, has good long-term maintenance, and has relatively low risk and cost for long-term enterprise use.
If developers really think about themselves, want to be simpler in the future, and don’t have to worry about complex and strange technical problems every day, they should give preference to reliable old technologies for long-term company projects.
The problem with old technology is that it’s tedious: all possibilities have been explored, and there’s not much room for creativity. Many programmers (especially new programmers) therefore feel that the old technology does not show technical ability, it is not fun enough, the new technology is more fun, and the improvement of themselves is greater.
That’s true, but only if your project doesn’t require long-term maintenance, otherwise it’s very risky to use untested new technology.
Leave a Reply