Why is Front-End Development So Unstable?
Aranganathan Rathinavelu / June 01, 2022
8 min read • ––– views
We all know the meme: by the time you’ve learned one front-end technology, another three have just been released. Also, that one you just learned? It’s deprecated.
What we don’t often see is an examination why.
The typical explanation (a la r/programming) seems to be something or other about webdevs being naturally impatient, faddish and incompetent, which may constitute a more general fallacy: assuming behaviour you cannot understand is caused by an entire group being foolish, wicked or greedy (whereas your own unwise behaviour is due exclusively to factors beyond your control).
Still, fallacy or no, we do have a problem - don’t we?
Before we get carried away, it’s worth validating whether the meme really has basis in reality. Do front end technologies actually change that quickly?
|React||96986||March 2015||3 years|
|Vue||95727||October 2015||2.5 years|
|Angular (1)||58531||October 2010||7.5 years|
|jQuery||49061||August 2006||11 years|
|Angular (2+)||36665||December 2015||2.5 years|
|Backbone||27194||October 2010||7.5 years|
|Polymer||19668||May 2015||3 years|
|Ember||19003||December 2011||6.5 years|
|Aurelia||10506||June 2016||2 years|
|Knockout||8894||July 2010||8 years|
2.5 years for the youngest isn’t that old in the scheme of things - it’s less than half the support lifespan of your typical desktop OS, for example - but it’s still a ways off our caricature. So what is causing this perception of rapid, even unsustainable change?
The advantage of this architecture is that you can easily adapt as new practices emerge, which makes sense at a time of rapid innovation (like the past few years). The disadvantage is that it increases your surface area for breaking changes and demands a great deal (often too much) vetting and selection of said microlibs.
There are other ways to validate a library, of course: you can read through Github issues and search for StackOverflow questions. You can do some testing or even examine the sourcecode for yourself (in most cases). But this takes time, which isn’t really warranted when choosing e.g. a date parsing doodad.
It starts innocently enough. You have a completely clean slate and want to keep things simple. You are a devout Agilist and YAGNI is your watchword. So you begin with a ‘simple, barbones framework’. That sounds good, doesn’t it? (Even if it did not, that’s often the only choice you’ve got).
Being barebones it does little, so the task falls on your shoulders to choose some helper libraries. If you are doing frontend work, it might be helpers for Redux for forms and API requests. If backend, it might be middlewares for Express .
So you do a Google search, which reveals a Medium post that heartily recommends X.js. It later transpires the post was written by X’s author, though she never announces that particular conflict of interest (she does, however, provide a GitTip jar). Not that you could tell - all Medium articles look the same, so you can never rely on a ‘brand’ to identify reputable material.
You miss the replies pointing out some critical inadequacies in X.js, because Medium deliberately suppresses them, and move on to finding a Y.
This time you find a link on Twitter - with over a hundred hearts! You guess that’s a pretty good signal it’s been “curated” by a community more knowledgeable than yourself. You add a heart of your own in gratitude (like the hundred before) and follow the link to Github.
But not so fast. That link was old - the library is now deprecated. You can tell because the word DEPRECATED is slapped everywhere like CONDEMNED signs on a Scooby Doo themepark.
You see, Y.js was “object oriented”. You thought this was a good thing, vaguely recalling something from first year ComSci about Smalltalk and message passing. But apparently it is Very Bad.
Another Medium article tries to explain why, though its reasoning is hazy and packed in dense terminology you don’t recognise. It later turns out the terminology was invented by the post’s author, as were the neutral-looking external blog posts he cited as authorities to his argument.
So you move onto Z.js, which seems to have a lot more Github stars, though the documentation seems less useful. Lots of methods are listed, but how do I practically use it? You are heartened at least to see it uses something called ‘Standard JS’, which you assume has something to do with the ECMA Standards Committee. It doesn’t.
But how could you do better, Junior Developer? Who was there to guide you? The Senior Developers, too, are learning as they go. We’re caught in this avalanche too, just trying to keep up to date and remain employable.
Like most natural complainers I am generally better at moaning about problems than, y’know, SOLVING them. But I have a few ideas:
Medium incentivises clickbait somewhat and makes it harder to distinguish authoritative content. Classical blogging allows good authors to establish a distinct visual theme, which helps visitors recognise a source that’s helped them before.
Try to start your projects in frameworks that provide a large surface area of features and don’t require many plugins to get productive - this will immediately reduce the number of moving parts and exposure to unexpected, breaking change. It’s one reason I’m very interested in Vue.js. You could also use React as part of a starter kit or larger framework, like Next.
The only people who need to know a company’s whole stack inside and out on day zero are freelance contractors, who are paid a handsome wage to parachute in and get a project out the door. Otherwise, most employers are absolutely fine with you not knowing the ins and outs of the latest React helper library. So avoid the call to learn absolutely everything: most of it noise.