Fear Driven Development
Why Frontend Tech Choices Are Not Only Driven By Merit?
How do you choose a Frontend framework or library to work with?
The truth is, that the frontend business is a very ruthless one:
It’s either you are aware of the ongoing changes and switch your horse at the right time, or you’ll find yourself on the sidetrack with a dead or barely moving horse.
“Nonsense!” You might say… well, let me tell you a scary story because you might be in one:
I’m Roy Kass, a Tech leader at Tikal, with more than 16 years of experience in the Frontend industry.
Once upon a time, when the frontend industry was very young, there was a marvelous technology named Adobe Flex.
Flex was set upon an infrastructure of Flash which used a vector drawing plugin that you install in the browser to operate. Its most prominent version, version 3, was introduced in 2007. It was a revolution — Flex introduced many features that didn’t exist in one place until then, like virtual scrolling, dynamic libraries, full static typing and tree shaking during compilation. Flex developers were the most coveted assets in the industry. Up until Steve Jobs, the CEO of Apple wrote a letter saying the Adobe Flash plugin will not be allowed in iOS hardware from now on. As a result, Adobe delivered Flex to the community (it was renamed “Apache Flex”) but kept her plugin as proprietary. This was, in effect, an abandonment of the technology. In 2012, it was quite clear that the technology was on its way to its demise.
The once highly courted developers of Flex, needed to convert to other technologies, like AngularJS.
How do I know all this? I was one of those Flex developers. Moving from Flex to HTML5 and AngularJS was a struggle.
“OK, but that’s just one instance!” you might say.
Well, this happened again with the move from AngularJS to Angular 2.
AngularJS reached a certain point where it was too slow and too old. Google created Angular 2 which had breaking changes. You had to decide if you should invest time doing the move, searching for another technology (for example React), or paying the price for staying on a dying horse.
I know more than one company that overstayed on AngularJS, causing them to make a tremendous effort at a very late hour to completely change the technology using a micro-frontends approach. Staying was not only hard — it was now a security risk, as the technology was deprecated.
It happened one more time when we realized Angular 2 (now a few versions ahead) was diminishing in the market due to poor decision-making (a very long Beta with bugs and poor performance for example, many breaking changes and also a black box sort of complexity).
Soon, React took over the market. Most of the companies were using it.
Some might argue that it’s because React is simpler to learn and use. Angular enthusiasts would say that it fails on larger scales, where you need a more structured framework.
It didn’t matter — because eventually the right political decisions were made by Meta (React), which won the market. The discussion between whether to choose React or Angular faded away in time, making React the favorite. Angular is still alive for now, but the community is much smaller than React’s.
And to all the Angular devotees that shake their heads while reading this — I truly sympathize, as I was one of you.
I didn’t even mention technologies like JQuery, Ember, Haxe, CoffeeScript and many many more that went down the same path (and there were A LOT of them).
In the end, those frontend technologies are open-sourced. This means that if the community loses interest, you get less support. The discussion is diverted to the more popular libraries. Your wells of knowledge dry out. In the end, you don’t get updates and there are security issues as well.
Also — it’s much easier to recruit highly qualified personnel for the more popular technologies.
Fronted technologies don’t live to old age. Adapt on time or pay a dear price.
React is somewhat an anomaly in this sense, and it’s bound to enter a cocoon and rise as NextJS (more to come on that in the following articles).
It’s important for me to say that I do not like this situation. It makes the choices divert from a cold discussion about the merits of a technology to its popularity. Some technologies that are not that popular may be a better choice if you look at their capabilities alone. I also understand how controversial this subject might be.
But — this “fear-driven choice” is how the Frontend field has been evolving for more than 15 years. Something very substantial needs to change for it to be different — and for the meanwhile, you need to take this consideration as a major one.
So How Do You Check a Tech’s Popularity?
First, head to NPM Trends and compare the technology you’re interested in with its competition.
For example, let’s test React, Angular and Vue (there seems to be a weird “blip” there for Vue at the end of 2022, let’s ignore it, as it must be a bug):
In the graph you can see that React is far ahead of Vue and Angular in terms of downloads. This is a good KPI to know its extent of use.
Now let’s compare their Github stats:
React:
Vue(core):
Can you see the pattern?
React has much more traffic in all senses — more people are starring, forking and watching it than the 2 others combined!
Another interesting livability check is seeing when and where were the latest commits (and why).
This is a good test to see if new code is being inserted into the library, or if is it actually stagnant:
React:
Angular:
Vue:
The best case we’re looking for is days. We can even settle for a few weeks up to 1–3 months. If you start seeing 4+ months, it means there’s a problem with the maintenance of this library.
In this case, while all of them are alive according to the latest commits (1–2 days ago), It’s quite clear that React is leading with popularity over Vue and Angular in all other aspects.
Does it mean it’s absolutely better in every sense? No.
But is this a major consideration? In the Frontend world — the answer is an echoing YES.
When examining frontend technologies, even smaller ones like a Component library system or even a single component — make sure the one you choose is as alive and popular as possible.
As long as popularity remains a major KPI for the survivability and sustainability of Frontend technologies, this should be a major consideration when selecting a technology to work with.
Choose the most lively ones because a dead or dying horse will not get you far — and if you’re on the 2nd or 3rd in popularity, then keep checking for livability and popularity periodically. That said, it’s all eventually an educated bet. Some surprises may create sudden shifts — just stay alert for them.
In the next article, I will show why NextJS might be the next horse you should pick.
