
The Brutal Lifecycle of JavaScript Frameworks - lainon
https://stackoverflow.blog/2018/01/11/brutal-lifecycle-javascript-frameworks/
======
Kajayacht
One of the things I don't think it accounts for in talking about the downfall
of something like jQuery is that as time goes on, the questions have already
been asked.

So of course there's going to be less questions asked about jQuery in 2017
versus 2009, because if I need to figure out how to select elements based on
an attribute rather than a class or id, it's already there.

~~~
codingdave
On the same note, the older frameworks solved older problems. jQuery was the
killer framework because it handled browser compatibility back in a time when
people not only needed to support IE8, but IE6, and few companies felt
comfortable telling people to just update their browser. Well, those days are
past, so that problem is no longer a reason to choose a framework, and when
you take that out of the picture, jQuery just isn't so needed.

The same path is likely on all frameworks - they were designed to solve
specific use cases, and as the entire industry matures, different solutions
will embed themselves in the industry in different ways, reducing the raison
d'etre for each framework, over time.

~~~
shams93
Yeah with jquery we were composing templates server side. Compared to Vue
trying to do a SPA in jQuery is a season in hell. It can be done but it's
brutal and fragile.

~~~
pascalxus
I'm quite surprised at this conclusion. I've always felt that doing SPA with
jQuery was the easiest thing I've ever done in my development career. It's so
easy to get something set up and running. And it's a breeze to figure out and
read the code too: even when it's 10s of thousands of lines of code.

Is it just me, or are many of the newer frameworks actually harder to use? I
tried Angular 1 about 4 or 5 years ago and it seemed like a complete disaster.
Recently, I've been working on Vue and this seems a bit better.

~~~
bronson
Depends on the SPA. If you're trying to do something relatively simple, where
the events and state clearly map to the UI, jQuery isn't too bad. It's even
fun.

Once your SPA goes through an iteration or two with a few different
programmers, you find your events have nasty ordering dependencies and your
data becomes inconsistent all on its own. You have no idea why because you
can't reproduce any of these issues on your own. You have to watch other
people interact with your app just to reproduce bugs ("why the hell would you
double click a link?") and git bisect becomes the most productive tool in your
toolbox. Most project discussions end with a shrug. You yearn for the days
when it was possible for a single human to ever understand the entire app, but
that was six months ago and management steadfastly refuses to fund a rewrite.
You look wildly around for any sign of hope...

As for Angular, agreed, but I'd rather work with it than a bunch of jQuery.
React and Vue are quite pleasant.

------
Sawamara
It is not really a brutal lifecycle at all, to be honest.

Everyone loves a good rant about how fast the JS frameworks burn out, but it
is not frameworks that burn out, but rather:

In the 8+ years since Iphone/Android duo made a HUGE change in how we consume
web content, we went from:

\- Having static resolution for websites to dynamically changing site
resolutions \- Having static HTML renders with some dynamic bits sprinkled
over to full-blown SPA-s because of a variety of reasons* \- Having major new
JavaScript versions and INSANE amounts of Javascript engine speedups that
allow things that were unimaginable 8+ years ago \- Having gone from "nothing"
to a CPU-based <canvas> to a full OpenGL ES-implementation, full GPU-based
(<webGL>), \- Had went from procedural code to semi-class based systems
towards functional towards functional reactive programming systems

And I could go on and on and on and on.

The DOM api matured during these years. The renderers got replaced. Their
performance altered dramatically. Layouts went from "JUST USE TABLES" towards
CSS, then towards Compile-to-css alternatives, etc. Single-core event systems
got SharedArrayBuffers, webWorkers, we got from callbacks to promises, towards
async/await. And do not get me started on almost getting observables properly.

The web has seen more transformations in terms of what is an "app" or a
"website" in 8-10 years than ANY OTHER area in programming. It is only natural
that widely different tasks need widely different tools to work with.

~~~
Klathmon
(heads up, you need have a blank space between lines in HN to render them on
different lines)

I completely agree. Many people claim the web is overly complex, but then go
back into the C++ world where you need a build tool to build your makefile
which builds your project using cross compilation on a handful of platforms.

I like to remind people that 10 years ago Android didn't exist, streaming
video was still only just becoming a thing, and the iPhone had just been
released and wouldn't have an "app store" for another 6 months.

There have been several massive changes to the web and to computers and how we
use them in that time. It only makes sense that we will use different
frameworks and paradigms to create applications.

~~~
Sawamara
Thank you! Oh, now that you mention it: just a few years ago, web streaming
was not possible without using either flash or (maybe?) silverlight or
something else because it was not implemented yet. Youtube crashed my pc
regulary during the hd4850 end-days due to driver crashes. Node was not even a
thing yet, let alone Electron/NWJS....

------
mixonic
The interesting story in this post is not about JS frameworks. It is about
StackOverflow.

The Ember community made a proactive decision to abandon StackOverflow around
the 2.0 release (about 2.5 years ago). StackOverflow simply does not provide
the tools we needed. For example when you answer a question: Are you answering
for version 1.0 of a library? 2.0? Perhaps the "correct" answer for each is
different. Perhaps, over time, an answer that once was correct is now
suggesting something deprecated or not in line with best practices.

StackOverflow doesn't provide any features for dealing with versioning and
changes in what is correct over time.

If your community has a StackOverflow moderator, perhaps you can update all
the answers you want on a regular basis. I don't know, because our community
had no such person, and the StackOverflow team was disinterested in helping us
come up with a solution (the Ember project reached out).

Additionally as a tool matures (Ember is over 5 years old) you take more of
this stuff under your own wing. Ember has a robust set of companies offering
video training, in person training, and books. We have a community chat, a
forum, and very active meetups. All of these things are controlled by members
of our community, meaning they can respond to changes more fluidly than
StackOverflow (moderated by some people outside our community) ever could.

StackOverflow just is not designed for long-lived multi-versioned software. So
guess what happens? Users of that software don't stick around on
StackOverflow. For living projects the short-term trend will almost always
look better than long-term trends.

Ember's story here is not universal. I'm glad there are developers finding
StackOverflow useful for other libraries. I think the story StackOverflow
should tell is one that focuses on what they do well. But to draw a meaningful
lesson about the JS community as a whole from such a idiosyncratic data source
is a fools errand.

~~~
simonsarris
I think this is the most important takeaway. It's especially true for smaller
libraries and commercial libraries. And even for huge ones like Rails,
questions answered 6 years ago might be little more than a catalog of improper
practices by now!

For a hard numbers example of "trends" being poor, I develop a JavaScript
diagramming library, GoJS: [https://gojs.net](https://gojs.net)

It has competition, such as JointJS, jsPlumb, etc. If I look at StackOverflow
tags, I would think we're in big trouble:

* 180 questions tagged gojs

* 449 questions tagged jointjs

* 518 questions tagged jsplumb

These aren't even enough to show up on StackOverflow's trend tool, and they
make the case look pretty dire for GoJS!

But behold, Google trends:
[https://trends.google.com/trends/explore?date=all&q=gojs,joi...](https://trends.google.com/trends/explore?date=all&q=gojs,jointjs,jsplumb)
(ignore the last, partial-data month)

In search interest GoJS is clearly ahead of these other two libraries. What's
more, if you compare the forums for each product, you'd see that GoJS gets
10x-100x the traffic of the others.

StackOverflow is simply not the a good place to gauge library interest and
activity over the long term, and its not a good place as you say to ask or
find answers to questions for products that have ecosystems which continuously
improve their APIs and evolve.

------
mkern
The PHP and Vue correlation can at least partly be explained by the fact that
Laravel, a popular PHP web framework, has first-hand support for Vue and
installs Vue by default in projects bootstrapped with their cli tool.

~~~
progx
WordPress.com But Vues triumphal march starts before Laravel or WordPress.

~~~
dktp
My understanding is that this tweet
[https://twitter.com/taylorotwell/status/590281695581982720?l...](https://twitter.com/taylorotwell/status/590281695581982720?lang=en)
kickstarted the Vue popularity. Taylor Otwell is the creator of Laravel.

Here's Evan You (creator of Vue) [https://youtu.be/D_z-
RAweP1k?t=3m9s](https://youtu.be/D_z-RAweP1k?t=3m9s) talking about the tweet.

------
mattmanser
As an aside from the interesting article, does any one else find it pretty
scary and privacy invading that stackoverflow think it's ok to match our IP
addresses to the company we work in?

It seems like a massive invasion of privacy (which I guess lots of websites
are doing).

But to me that SO can so casually mention the mass surveillance and privacy
invasion they're doing without thinking that there's anything wrong with it is
the worst part of it.

I certainly never knowingly agreed that they could check my IP address and
then try and figure out what company I work at from it.

EDIT: Once GDPR is live in the EU, I think it might be interesting to see if I
can challenge this privacy invasion and inappropriate use of personally
identifying data. I guess we'll see if GDPR has any actual teeth in this
instance.

~~~
Cthulhu_
Your IP is public, so you can't hide it; privacy invasion is a non-argument
there.

IP data retention, on the other hand, will be interesting. On the one hand,
law enforcement wants to have ISPs and companies to track and remember those,
for future investigations. But on the other hand, privacy advocates want that
kind of data to not be stored at all.

~~~
mattmanser
It's not the IP address that's the problem, it's that they're processing
personally identifiable information about their users in a way they haven't
asked permission for and is not related to the service they're providing.

Here's the UK's ICO guidance for what you can process, as far as I can tell
they've got no lawful basis for trying to match a user's IP address to a
company without the user asking them to.

[https://ico.org.uk/for-organisations/guide-to-the-general-
da...](https://ico.org.uk/for-organisations/guide-to-the-general-data-
protection-regulation-gdpr/lawful-basis-for-processing/)

~~~
andrewem
I skimmed that link and couldn't figure out what they mean by "processing".
(It's related to compliance with a law, so I assume that the common sense
meaning of a word isn't necessarily what is meant.) Do you understand what
they mean by "processing" in this context?

It seems like you're saying that analyzing IP addresses a user connected from
in order to determine their likely employer is against the UK's GDPR guidance,
_even if the data is released only in aggregate_ (but that it might be fine to
keep that IP data since perhaps there are other uses for it which would be
legitimate). Is that your understanding?

~~~
mattmanser
It's not about what you release to the public, if you're processing this data
in private it's still culpable.

This page gives it some context:

[https://ico.org.uk/for-organisations/guide-to-the-general-
da...](https://ico.org.uk/for-organisations/guide-to-the-general-data-
protection-regulation-gdpr/lawful-basis-for-processing/)

Further down are the 6 reasons for processing.

We know the first 5 don't apply:

    
    
        consent - there's no consent
        contract - it's not necessary to provide the Q&A answer site
        Legal obligation - there's no legal obligation
        Vital interests - nope
        Public task - nope
    
    

So what it falls under is "Legitimate interests", SO want to use a user's IP
address, process it to add company name, store that and then use that data for
profiling their customers to serve them ads.

One of the problems for SO is that further down they go into this a bit more
and there's a few key questions:

    
    
        Would individuals expect this processing to take place?
        Are some of the individuals concerned likely to object?
        Are you able to stop the processing at any time on request?
    

Which I would think would be answer No, Yes, No. Which seems to indicate that
there's some problems with SO's approach.

------
_greim_
> Stack Overflow Trends lets us examine how each of these technologies has
> been asked about over time.

So what are we measuring here? It seems obvious that more popular frameworks
would generate more questions, but so would:

\- Newer ones which not as many people are familiar with.

\- Poorly-designed ones which lots of people nevertheless use.

\- Ones which disproportionately attract inexperienced devs.

------
catpolice
I always have to show up to reiterate this is not a problem limited to
Javascript. There have been framework fads for as long as there have been
frameworks. I have dim memories of dozens of C++/Java/Python/Ruby/etc. next-
big-things.

It does seem like there are more of them and they rise and fall faster in the
Javascript world, but this is probably better explained by the sheer number of
Javascript programmers than anything else. The labor statistics I can find peg
the number of US software developers in 2002 at around 612,000 and around 3.87
million in 2016 - and most of the new ones focus on web development. There are
way more web programmers out there than there have really ever been, so it
makes sense that the rate of frameworks appearing (and to a degree, the
overall lifecycle churn) would be accelerated.

~~~
pjmlp
> I have dim memories of dozens of C++/Java/Python/Ruby/etc. next-big-things.

While true, none of them have changed so quickly as JavaScript ones, which
seem driven by devs eager to create portfolios on Github.

~~~
Can_Not
> which seem driven by devs eager to create portfolios on Github.

Is this supported by any facts? It seems like a hand-wavey hasty
generalization.

~~~
pjmlp
The increasing trend of startups asking for Github accounts on their job
offers.

You just need to search on job boards.

------
lakechfoma
Why is the measurement on questions asked for the first couple of graphs and
then user traffic for the latter set? I wonder if traffic is the better
measurement for the first two as well but I bet the graphs won't look quite as
doom and gloom.

~~~
var_explained
The first few graphs use the interactive [Stack Overflow
Trends]([http://insights.stackoverflow.com/trends](http://insights.stackoverflow.com/trends))
tool, which is all public data. This is useful since it lets readers modify
the graphs (for example, to add a few more tags to the comparison).

The later graphs use data that's already not public (what tags users visit
together, and what countries tags are visited from), so there's no reason not
to use visits instead.

The graphs for visits over time do look very similar (in general question
traffic by tag roughly matches questions asked, but as a slightly lagging
indicator)

------
rwbcxrz
> PHP developers [...] visit a disproportionate amount of Vue.js questions.

I would guess this is because the installer for Laravel (one of the most
popular PHP frameworks) defaults to scaffolding a Vue.js app for your
frontend.

------
cies
Remember that Merb was merged into Rails? That's a community converging,
that's what brought Ruby to the point that it is recruiter-speak synonymous to
Rails.

In the JS world: not so much. But that prolly has many reasons. I can think
of: the language changing rapidly, the community not very "close", people
coming to JS from widely different places, and the fact that a JS framework
can span either the FE or the BE or both!

~~~
scottmf
io.js?

~~~
cies
Yups. Nice one!

------
baybal2
I thank YUI and later jQuery for getting me my first real software development
job.

Today it looks surreal that a mere portfolio of mind boggling animation
effects would be enough to get a 21 year old an $84k job, but back in the time
of peak web 2.0 craze, just having words jquery and 3 years experience on your
resume was just enough to get 3 to 4 calls with ready offers every month.

------
drderidder
It's easy to see graphs trending down and say, oh, interest is waning. But the
initial spike could just be lots people going through a learning curve. It
tells you something about popularity, but ease-of-use, quality of docs, etc.
must all factor in as well. I tend to see the high number of questions on
certain frameworks as a red flag.

------
systematical
I certainly agree with the hypothesis of this article. I'd like to see how
this compares with languages and not just frameworks overtime. How does this
curve compare with mature/in-demand languages such as Java, PHP, JavaScript,
.Net, Python etc. Do we find a similar graph with languages?

------
ToJans
IME Vue is so well designed, that I hardly have any issues with it. If I do,
my go-to reference is the official documentation.

You shouldn't base your usage assumptions on the amount of questions asked;
Vue just doesn't require so many questions...

~~~
FLGMwt
Ditto for React. Pretty much every "how do I do this" is covered in the
official tutorial and every "how _should_ I do this" is covered by
supplemental guides (still official docs).

Some good ones: "thinking in React", "lifting state up", "controlled
components", and similar docs in redux: "you might not need redux"

------
lolive
My question as a Java/Swing developper is this: what is the difference between
React and Web Components? As far as I understand, both create self-contained
components that you can use in your HTML, and that will react when you alter
their DOM structure (for example changing an attribute value, or binding an
HTML input value with an internal value inside the component).

And from that perspective, will we see in the future off-the-shelf HTML
components (based on React or Web Components) just like we can use custom
Swing components ?

~~~
pjmlp
That could be the idea, but currently it seems Angular devs are more open to
that idea, given that WebComponents are mostly driven by Google.

[https://summit.polymer-project.org/](https://summit.polymer-project.org/)

[https://developer.chrome.com/devsummit/](https://developer.chrome.com/devsummit/)

You can some components here, as well as, the current state of browser
support.

[https://www.webcomponents.org/](https://www.webcomponents.org/)

Currently only HTML Imports seem to be a point of disagreement.

I am looking forward to them, as they can be the way for more sanity on Web
development.

------
rodolphoarruda
Pretty much a Gartner's Hype Curve like behaviour on each case. Accelerated
adoption, a peak, then delusion kicks in causing many people to lose interest
and step away from the technology. Late adopters find lower barriers of entry
later on caused by lessons learned and improvements made to the same
technology. Usage increases again but a lower level when compared to the
initial peak. Expectations around tech's capabilities are now more concrete
and realistic, bringing stability to the ecosystem as a whole.

------
mkirklions
About to make an App using React(and react native?)

Up until this point, I usually would make most things from scratch and pull in
libraries sparce. No big deal because my previous programs didnt need to.
(Self taught programmer for 11 years.)

For the next 3 months, I'll be working on this almost alone. Is it worth using
some of my resources to hire a React developer?

Also, this topic implies React will be gone in about ~5 years? That sounds
good for me.

~~~
brentm
I would learn React if I was you. Check out create-react-app on Github. It
will set you up with a working app to play with in a matter of seconds. If
you're expecting to use React Native it looks like they have a create-react-
native-app also.

~~~
mkirklions
Right now I'm stuck working on getting SDKs installed.

I got my android app running which was easy after all the installs and
updates.

Now I'm doing some weird command line stuff to try to get my Javascript server
to wake up. Changing ports, more SDK updates, etc... Changing my App.js doesnt
update, except if I turn everything off and back on again.

------
kuon
I moved my frontend (I mean "in browser" by that) dev to elm about a year ago,
and it's been a year of peace. I know elm has flaws, and it's development
workflow can be criticized for being too slow or conservative, but it's been
so predictable, so easy to work with, so maintainable and so solid in
production, I have never been so happy about frontend dev.

------
larrik
Alternative hypothesis:

Brand new frameworks have zero docs and zero questions in Stack Overflow.
Older frameworks have (hopefully) complete docs and a library of SO questions.
In between you get a gradient.

I'm just not convinced that the data they're looking at means what they think
it means.

------
watsocd
Just because the number of questions decreases about a framework does not mean
people have stopped using the framework. I ask very few questions because I am
normally working behind the bleeding edge and can get my questions answered
simply by searching.

------
scotchio
Woah...

Was honestly surprised to see Vue.js was so tiny in comparison to Ang and
React regarding "% of Stack Overflow questions that month".

I thought it was much bigger

~~~
kozhevnikov
Vue.js has a spectacular tutorial that answers most if not all questions one
might have about the framework.

------
nailer
Why are 'angular' and 'angular.js' seperate tags?

~~~
tboyd47
AngularJS refers to major version 1, Angular refers to 2.

~~~
nailer
Wow. That's really unintuitive.

~~~
jedwardhawkins
I agree with the sentiment. Most people view them as distinct frameworks. I
believe the use of the name Angular for major version 2+ helped retain a lot
of users. I've seen a lot of uninformed devs and managers assume that because
they already have so much code in AngularJS that Angular is the next logical
tool for their team to use.

------
simooooo
Knockout isn't a Microsoft technology

------
rplnt
The JavaScript/jQuery community (no difference from outside) was absolutely
cancerous. It was impossible to find a javascript question that didn't include
top answer "In jQuery...". Makes my blood boil just thinking about it years
later.

I wonder what effect this has on usage. How likely are new developers to use
it if virtually every question they have is answered by this (no matter how
irrelevant the answer should be today).

~~~
bigmanwalter
To be fair, that's because the jQuery solution was usually orders of magnitude
simpler. Although newer versions of javascript have absorbed enough of the
jQuery api that this is no longer the case.

~~~
rplnt
Acceptable way would be "Hey, it's done like this, but since the language
sucks there's this random library where you can do it this way".

Including jQuery for one small task would be stupid.

Including jQuery in a non-web project would be weird.

Including jQuery in some es variants would be impossible.

~~~
bigmanwalter
At that time, javascript was used exclusively for client-side web development.
It was pretty much impossible to write ajax requests in any sane fashion that
worked cross-browser. It's not such a stretch to assume the user asking the
question could use jQuery.

~~~
rplnt
The first part is not true.

And while I agree with the second, I'm talking about general language
questions not related to web in any way (no DOM manipulation, no http
requests, etc..).

