• Why is front-end Development So Unstable?
  • By Jimmy Breck-McKye
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: Colafornia
  • Proofreader: GeniusQ1981 Sunhaokk

We all know the joke: By the time you learn one front-end technology, three other new technologies have been released. Not only that, but the one you just learned has been discarded.

We don’t often see explanations for why this is the case.

Typical explanation (from Reddit’s R/Programming channel) This seems to have something to do with front-end developers being inherently impatient, following trends, and having limited abilities, which adds up to a more general fallacy: Assume that the behavior you don’t understand is caused by the stupidity, badness, or greed of the whole group (while your own unwise behavior is caused entirely by factors beyond your control).

Whether it’s a fallacy or not, we do have this problem, right?

quantification

Before going off the deep end, it’s worth determining whether the problem really has a basis in reality. Is front-end technology really changing fast?

In terms of mainstream (or not) attention, consider this Github ranking of “high star” JavaScript front-end technologies:

+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + | | library Star count age | | | release time | -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + | React | 96986 | | 3 years in March 2015 | | Vue | 95727 | 2015 On October 2.5 years | | | presents (1) | | 58531 | | 7.5 years in October 2010 | jQuery | 49061 | | for 11 years in August 2006 | | presents (2 +) | In December 36665 | 2015 | | 2.5 years | Backbone | 27194 | | | 7.5 years in October 2010 | Polymer | 19668 | | | 3 years in May, 2015 | Ember | 19003 | | 6.5 years in December 2011 | | Aurelia | 10506 | | 2 years in June, 2016 | | Knockout | 8894 | | | 8 July 2010 years +------------------------------------------------------------+Copy the code

The youngest project is two and a half years old, which isn’t that old — it’s less than half the maintenance cycle of your desktop OPERATING system, for example — but not quite as the joke goes. So what is causing this sense of rapid, even unsustainable change at the front end?

React and its friends

It’s probably React. As a powerful tool, it requires a series of helper modules and support libraries to support it, and that’s where the problem lies. The React ecosystem, which I call the “microlib architecture,” is huge. Its applications are made up of numerous discrete, single-purpose JavaScript libraries, a nod to the Unix philosophy.

The advantage of this architecture is that when new practices come along, you can adapt quickly, which is very useful during periods of rapid innovation like a few years ago. The downside is that it requires frequent large iterations and requires you to sift through numerous (often too many) so-called microlibs.

This is the gist of my argument: the problem is not the JavaScript language itself [1], the Web or any particular technology, but rather poor “choice architecture” that forces developers to follow trends.

NPM problem

NPM is the greatest asset and liability of modern JavaScript. It provides a wealth of modules that can satisfy almost any specific need, but these modules are difficult to filter and manage. Which modules are really supported? Which modules really have the right functionality? Which modules are not just carriers of malware? The real choice method used by JavaScript developers is popularity — number of downloads and number of stars on Github, which definitely adds to the trend of chasing popularity.

Of course, there are other ways to identify a library: you can browse its Github issue list and search for questions on StackOverflow. You can also do some tests and even check the source code yourself (in most cases). But these methods are time consuming, and there’s no need to do that when choosing a gadget like a date-parsing module.

I admit that this is a cultural flaw for JavaScript developers. As an interviewer, I often ask candidates how they approach technology selection, and the answer is frustrating: popularity is always the only indicator they know. Software engineering is at least partly a research job, and we need to train junior engineers in these research skills, but even if we do, engineers may not make the right choices.

Imagine yourself as a junior engineer

Write a new application for the first time from the perspective of a beginner, intermediate JavaScript developer.

You were naive at first. Your project is very clean and You want to keep things simple, You are a devout Agilist and YAGNI (You aren’t gonna Need it) is your slogan. So you start with a “simple framework.” It feels good, doesn’t it? (Even if it doesn’t feel good, it’s often your only option).

As a basic framework it can do very little, so the burden falls on you to choose some helper libraries. If you’re in charge of the front end, it’s probably Redux’s secondary library for forms and API requests. If it is a back-end, it may be Express middleware [2].

If you Google it, you’ll find a Medium article that strongly recommends X.js. It turned out that the article was written by x.JS, though she never claimed a conflict of interest (she did provide a GitTip JAR). Not all Medium articles look the same, so you can’t rely on a “brand” to identify reputable material.

You missed some comments pointing out x.js’ fatal flaw because Medium intentionally suppressed them, and then you went on looking for a Y.

This time you found a link on Twitter with more than a hundred hearts! That’s a good sign, you guessed it, because Twitter is “curated” by a community that knows more than you do. You click on hearts in gratitude (like 100 others before you) and follow the link to Github.

Things are not moving that fast. That link is out of date – the library is deprecated. You see that because the word “DEPRECATED” is all over the page, like the CONDEMNED sign at a Snoopy theme park.

You discover that Y.JS is “object oriented”. You vaguely remember what you learned about object-oriented programming languages and communications in your freshman year of computer science and think this is a good thing. But obviously that’s bad.

Another article on Medium tries to explain why, but his argument is not only vague, it’s a tangle of jargon you don’t recognize. Later you discover that the author of the article invented these terms, as he did when quoting from a seemingly neutral external blog post, citing his own argument.

Things got worse. The article claims that mentioning OOP in a JavaScript interview will also cause you to lose the offer! You’re totally confused right now. Thankfully, the solution is at hand — a $50 JavaScript development course from the author of this article. You jot down the link to the course, feel lucky to have found it, and give a clap (the 19,000th clap of this article) in gratitude.

So you go on to Github’s High Star project Z.js, even though its documentation looks useless. The documentation just lists a bunch of methods. How do you actually use z.js? At least when you see z.js using something called “Standard JS”, you think it has something to do with the ECMA Standards Committee. However, there is no relationship between them.

How can I do better as a junior engineer? Who can guide you? Senior engineers are also learning by doing. We’re stuck in the middle, just trying to keep up and keep working.

So you give up resistance: choose the project with the most stars and votes on Gihub. This is why JavaScript is driven by trends and hype.

What should be done?

Like those born to complain, I’m better at complaining about problems than solving them. But I have a few thoughts:

Be cautious with Medium

Medium encourages a bit of clickbait, making it hard to identify authoritative content. Traditional blogs allow good writers to create unique blog themes that help readers identify content sources that have been previously helpful.

Be wary of self-improvement

The last few years have seen more aggressive self-promotion in JavaScript, which may be related to the increase in paid content online and the advantages of being a Github “influencer” for employment/consulting. That’s fine for people who pay for great content and are happy with it, but increasingly people are encountering fake tactics: self-citation, inventing proprietary terms (so search engines will take you back to the author’s article), and fake names (like “standard.js”).

Consider a non-microlib architecture

Try to start your project with a framework that provides rich features and efficiency without additional plug-ins, which will immediately reduce module churn and unexpected changes. That’s one of the reasons I’m interested in vue.js. You can also use React like Next as part of a beginner’s toolkit or larger framework.

Don’t worry too much about employment

The only people who need to be fully briefed on the tech stack inside and outside the company on reporting day are outsourcers, who can complete projects outside the company and get paid handsomously. Beyond that, most bosses don’t care that you don’t know the ins and outs of the latest React helper library. So ignore the calls to learn everything, most of which is noise.

annotation

[1] There are many, many mistakes in this thinking.

[2] Can you believe that Express requires middleware to parse JSON-formatted POST requests? Sorry, Express just does what they want.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.