
Ask HN: Why is everything in JavaScript changing so fast? - blohs
Change and variety of options is a good thing, but in js the rate of change in methodologies, frameworks, libraries is so much high. For example angular 2 is not compatible with angular 1, so before you even learn a framework its API is different and when you finally learn it, probably is considered outdated.
Why is this happening especially in js?
======
lacker
The open-source-JavaScript community right now is just the largest, most
active open source community that has ever existed. Check out the stats that
GitHub recently announced:

[https://octoverse.github.com/](https://octoverse.github.com/)

Open source JavaScript activity as measured by pull requests has doubled (!!)
in the past year. It's more than the next two languages (Java and Python)
combined.

Most of the top repositories on GitHub are JavaScript too:
[https://github.com/search?q=stars:%3E1&s=stars&type=Reposito...](https://github.com/search?q=stars:%3E1&s=stars&type=Repositories)

Demand for JS developers is growing too, as websites become more complex,
Node.js becomes more popular on the backend, and frameworks like React Native
(more popular than any other iOS or Android library on github) start to pick
up mobile developers.

JavaScript performance is also starting to be significantly better than the
other scripting languages, e.g. [https://www.quora.com/Is-
JavaScript-v8-faster-than-Python](https://www.quora.com/Is-
JavaScript-v8-faster-than-Python) . Not because of anything inherent about
JavaScript, more that it's worth a lot of investment from big companies in JS
performance.

Basically, it's not just the number of frameworks. Everything about JavaScript
is taking off right now, and leading to a network effect where all the other
aspects get boosted too. Sort of funny to have this happen twenty years after
its invention.

~~~
jacquesm
To a large extent this is true because the javascript community is busy with
the re-invention of all of computer history, only without applying all of the
lessons learned.

Activity does not equate quality.

~~~
cdata
It's easy to sit back and critisize JavaScript and the web with dismissive
comments like this. I have heard variations on these same memes for many
years.

But something that I almost never hear: critics offering a candid explanation
for why their platform / language / framework - which maybe wasn't perfect but
CERTAINLY compared to JavaScript was awesome - did not become the de facto
tool across as diverse a spectrum for delivering features / products / tools
to users.

It's always fair to criticize so that we ask ourselves the hard questions. So,
it's also worth asking ourselves if we are staring too close to the wall when
we try to paint other languages as backwards and therefore bad (or at least a
bad choice). Just maybe, the language feature bullet list in your head (and
corresponding subtleties of implementation) isn't the thing that matters most.
Maybe the thing that really matters is something not as easy to codify as a
language tool chain, like human consensus.

Also, it is false association to suggest that quantity != quality is somehow
particular to JavaScript. Infinite monkeys will produce infinite crap no
matter what brand typewriter you give them.

~~~
tempodox
> explanation for why their platform / language / framework [...] did not
> become the de facto tool

You're implying this happened to JS because of some merit. But it didn't, it
was just sheer coincidence and bad luck (for most of us at least, including
users).

~~~
roblabla
Explain what the coincidence was ? There are alternatives everywhere (ActiveX,
flash, java, visual basic IIRC). And yet here we are, with JS.

I believe JS came here because it actually is the best language we have had in
the web. It's so easy to throw shit arround, but let's be honest with
ourselves, this isn't purely out of luck.

~~~
qznc
JS is the only language integrated into the browser and the DOM. Netscape
rejected other languages (Python, Perl, TCL) because of syntax, so Brendan
Eich disguised Scheme into Java syntax and hacked up a prototype in 10 days.

Today, Javascript is sooo interwoven with the DOM in browsers that it is near
impossible to separate them. Google planned to do this for Dart, but gave up.
If they had done this and other browser vendors had followed, adding a third
and forth and more languages would have been (relatively) easy, because the
abstraction were in place. Then we would have seen a healthy competition.

There is asm.js. Maybe we will get a "web bytecode" at some point, but that
will easily take a decade and more. The pressure is increasing, because our
CPUs don't get exponentially more powerful anymore. And delivering apps via
the web is still going strong.

~~~
BrendanEich
1\. WebKit rejected adding barriers to support multiple garbage collectors and
a super-GC to collect cycles, required by Dart or any 2nd VM. See
[https://lists.webkit.org/pipermail/webkit-
dev/2011-December/...](https://lists.webkit.org/pipermail/webkit-
dev/2011-December/018811.html) where Fil Pizlo of Apple cites 5% throughput
regression.

Dart was never going to make it, and adding 3 or 4 VMs with their own GCs is
even less plausible.

2\. See [https://github.com/WebAssembly](https://github.com/WebAssembly) for
progress on what asm.js showed was possible: a 2nd, initially co-expressive
with asm.js, eventually more expressive, binary syntax for the Web. It's
happening now, this year and probably shipping experimentally in 1Q2017.

Writing "easily take a decade" out of ignorance just says to me you didn't
even bother to use google!

~~~
BrendanEich
And now:
[https://news.ycombinator.com/item?id=12838335](https://news.ycombinator.com/item?id=12838335)

------
bloomca
The problem is that everything in JS exploded during just few years (Node was
published in 2009), and it took few years to build tooling around Node to
start utilising all this power.

And then everyone started to build "rich" web applications (it is called
differently every year), with the "best" tool existing. I personally see two
major problems – usually cool startups who can afford using the bleeding edge
will die soon (or will get enough money to completely rewrite it), so
'maintanence' in idiomatic way doesn't work here – life cycle is extremely
small, and it reflects in the way libraries are written in JavaScript. Also,
the barrier is low, and therefore we have a lot of complex websites built by
novices, running in development mode in the actual production.

Community also is very "poisoned" with the idea that you _have_ to work in
your evenings (contributing to OSS, writing your own or just playing with hot
technologies), and therefore new stuff is baked extremely quickly. It is
usually very low quality, and you have to cope a lot in order to make it work,
and often you have to dive into source code, and it is considered as normal,
which is quite sick from my point of view.

Also, it is truly "hype" community, which is super excited about what is hot
now – and it means that today kings will be overthrown very soon (right now
stuff like Cycle.js and Vue.js is gaining traction). Nobody wants to maintain
their libraries – and very often you can see projects with a lot of stars
completely abandoned.

Recently, Babel.js was defined as _defacto_ standard, and it basically started
transpiling era, which is not going to end in the foreseeable future. It
shakes the stability, and makes extremely easy to add new features (like
stage-0), and people just used to unrealiable tools.

So, all of this works as a snowball, which only speeds up. People create more
and more complex web applications, and also js is going into other fields
(like microcontrollers, Node.js grows in popularity, React Native is super hot
now). When it will stop? Nobody knows. Maybe WebAssembly after implementing
will stop it (people will spread over competing technologies), maybe no.

~~~
ourmandave
Soon we'll have trouble hiring Angular 1 devs to maintain legacy code, like
COBOL.

Except COBOL started in 1959, not 2009.

~~~
Roboprog
Angular 1.0, June 2012

[https://github.com/angular/angular.js/releases?after=v1.0.4](https://github.com/angular/angular.js/releases?after=v1.0.4)

...

And I actually prefer ng-1 to the transpiling mess that is ng-2, as well as
preferring to use functional composition rather than pseudo-static classes for
the controller logic.

[https://github.com/roboprog/ang-prog-enh](https://github.com/roboprog/ang-
prog-enh)

------
nickstefan12
In an industry without a guild / license / what have you, the incentives skew
towards articles of proof. Articles of proof could be demo websites, screen
shots, and open source libraries.

Being the creator or top two contributor of a library is now worth so much
more than being a small time contributor that the incentives are skewed
towards everyone just making a new thing, always.

It's their way to stand out.

So why is this more prevalent in JavaScript? Front end inherently has more new
comers. Long time hackers or cs grads feel less of a need to prove themselves
making free software?

I think it's natural that the web programmers would understand web self
promotion better than other languages. Guess who's better at Twitter? The js
people! Why? They were writing the web to begin with!

I wish it would stop. Our qa engineer is writing web driver tests in
JavaScript and I don't understand why! There's nothing about testing that
NEEDS to be async! The python API would likely be no slower and much easier to
write and debug.

Sane defaults are an important part of tech, and default async is a terrible
setting. Python sync is easier, and Go routine concurrency is easier. Always
on async just seems like a terrible default. For speed I'd do Go, and for all
else Python.

~~~
spion
On the other hand, Go's type system is so bad that it nullifies all the
benefits it brings to the table. I'd rather have no type system than Go's type
system, but why even ponder that if I can have everything? With JS I can start
out with dynamic types, then switch to static types if the need arises
(typescript, flow), fully or partially. Oh, and both of those have really good
generics btw.

And we have async/await too now, which means async code can also look almost
the same as sync code. So I would still choose JS over both Python and Go (at
least for that particular use case). mypy still has long ways to go before its
anywhere near TS or Flow.

~~~
nickstefan12
Ive never put the words together, but you've basically highlighted what I
want:

Python (and its type system) + Go routines

Where can I find that!?

~~~
ricardobeat
TypeScript?

------
dandare
The answer is bit paradoxical: It is because JavaScript itself can change only
very slowly. What you see changing is everything around JS but JS itself,
while powering the whole web, is still to an extent the same scripting
language that Brendan Eich prototyped in 10 days back in 1995. Why is that?
Simply because the JS runtime environment - the browser - is not controlled by
a single entity that could plan and enforce radical change. Instead all the
big players have to progress together, which is usually not in the interest of
all of them at the same time (It used to be Microsof who was not interested in
progressing the web standards, now it seems to be Apple. Not because they are
bad people but because it makes sense in their situation.) Plus you have to
maintain backward compatibility with older browsers, one can still not simply
use ES6 in production website because it would not work in significant portion
of the (older) browsers. That is why everything around JS changes so fast in
an attempt to find the best workaround, polyfil, transpiler, module etc.

~~~
roblabla
The language itself evolved as well though. Chrome/FF/Edge (the Big Three) all
support a large subset of ES6. I use it in prod because I have the luxury to
not have to care about those people stuck in the past. And the portion of
older browser isn't that big anyway, thx to autoupdates. Only people using IE
and safari are problems nowadays.

~~~
lexicality
Or if they use Debian. Evergreen isn't evergreen if it's on Linux.

~~~
roblabla
Meh. Desktop users should all use a rolling release distro anyway. I'll never
understand the point of versioned distros for desktop...

~~~
lexicality
People like stability.

~~~
roblabla
I never had any problems running archlinux for 3 years now. Im sure there are
other rolling release distro that are more stable.

------
combatentropy
Is it because it lacks a shepherd?

Perl has Larry Wall. Python has Guido van Rossum. PHP had Rasmus Lerdorf and
later Andi Gutmans and Zeev Suraski (Zend). Ruby has Yukihiro Matsumoto, and
Rails has David Heinemeier Hansson. JavaScript came from Brendan Eich, but it
was like a work for hire, wasn't it? Microsoft and Netscape just kind of ran
with it.

Then I guess it did have a shepherd, the W3, and all the browsers followed its
standard, except the one that had 90% of the market. At long last, in the past
few years, market share has passed to companies that are much more willing to
follow open standards.

But at the same time, the user base is huge, a churning mass of millions of
programmers of every level of ability, and each one of them can now publish
their framework on Github. Plus there are several large web companies that are
competing with each other.

Thankfully at least the language itself has a single standards track. Cross-
browser agreement isn't perfect, but it's much better than it used to be. It's
just that we don't have a standard library, like Perl's CPAN. Instead we have
NPM.

I wasn't paying enough attention when Perl and these other languages
developed, so I don't know for sure why they're different, or even if they
were that different at this stage. Even they have their different web
frameworks to this day.

~~~
inimino
It's not necessary to have a single person in charge, but it helps to have a
single entity that can push changes through. Mozilla added a lot of features
that never went anywhere because IE lacked them. The W3C never standardized
JavaScript, but eventually ECMA did. The stagnation was caused by competitive
factors between browsers and standardization didn't change that.

~~~
BrendanEich
Chronology: when I was at Netscape and still (apart from part-time help) the
only person working on JS and the DOM and the rest of the browser embedding,
we took JS to ECMA (now Ecma) in 1996. It was never brought to the W3C.

The IE stagnation came later, after IE4 which was innovative (because
Microsoft wanted to embrace/extend/extinguish Netscape and the Web).

Almost everything we added to JS at Mozilla made its way into standards.
Examples range from __proto__ to generators in ES6.

~~~
inimino
Thanks for the clarification!

------
prewett
I think all the churn is a sign of several problems. First, the language was
not designed to do what people are trying to use it for. Second, I question
whether the framework makers are familiar with "native" UI APIs (e.g. Java,
Qt, NextStep), which solved a lot of these problems years ago. Notice the lack
of churn in native UI APIs (exception of Microsoft). Third, it seems like the
frameworks try to build on top of HTML, which I think is a mistake, because
HTML was not designed for layout flexibility and pixel-perfectness (unlike
native widget APIs). Furthermore, HTML was poorly designed for anything but
simple word-processor documents: why is there no <block> element that is
inline-block?! That's the first thing I end up assigning to everything. But
the whole declare-your-document approach is inherently too simplistic for much
beyond a word-processor document. Note that PostScript, and PDF which is an
enhancement, has been pretty stable and standard for years, which indicates it
is a good solution to the problem. Ultimately, you need to be able to program
your documents and put pixels exactly where you want them. But even just
sending over a blank HTML page and then having JavaScript add everything
programmatically is probably better-suited, despite having to ultimately get
squeezed into the HTML approach.

In my opinion, we need to realize that webapps are not documents, and
document-oriented HTML is the wrong tool. I don't think things will get better
until we start looking at webapps as essentially drawing on the screen, like
native UI APIs. I think we need a standardized virtual machine, like a
lightweight JVM (or, better, a heavyweight Lua), which would allow people to
use whatever language they prefer, as long as it can compile onto the
instruction set. Static-type people can use a statically-typed language, and
dynamic types can use dynamically-typed languages. Make an instruction set
that maps well onto native CPU instructions, and provide well-thought out
input and drawing primitives. We essentially need a PostScript for apps.

~~~
ng12
Every time I see this argument I have the same response -- we tried this. We
came really close to having Java be the standard and it failed for a ton of
reasons (security was incredibly difficult, absurd slowness, UI/UX problems,
user adoption issues, etc). What makes you confident we could get it right the
second time?

~~~
prewett
Yes, you have an excellent point, and I worry about that. It also worries me
that what I am proposing is pretty much what Flash did, I think, and we all
hate that. I think we can do better because we know what we need now, and we
have some good and bad examples to guide us. The problem with the JVM is that
it is too heavyweight. But we know that lightweight is possible because
everyone loves Lua.

Security is doable because BrowserVM does not need to do everything. It isn't
generable purpose like the JVM, it is an embedded VM like Lua. Lua has great
security, as far as I am aware. I expect that having a secure VM is no more
difficult than having a secure ECMAScript implementation.

I think we want low-level execution primitives (i.e. assembly), which pretty
much forces a VM, because it gives people flexibility to use whatever language
they want. However, even the minimum of keeping JavaScript and having the page
be a large canvas with (fast) drawing primitives would sufficient. Writing
windowing systems and UI toolkits is a solved problem. I think the browser
should, at minimum, provide primitives for drawing widgets, so that webapps
can take advantage of OS-native widgets. A well-designed toolkit, though,
would be handy. And here we have a number of examples. Qt is very well-
designed and a pleasure to use. Cocoa is a little clunky, but effective. Even
Java/Swing was fine (aside from horrid aesthetics). We know that Microsoft-
style MFC is a bad idea, the Win32 callback idea is clunky, and Android is a
mess. In particular, a constraints-style system seems to be clunky. It was
clunky in Motif, clunky in Android, and even Apple's version doesn't seem all
that great. Constraints seems to suffer from the same problem of HTML:
describing the system is clunkier than just telling the system what to do.
Hence, Qt and Swing's layouts are a lot easier to reason about.

~~~
rer
Finally, someone gets it. Thank you!

------
rhizome31
Because nobody has yet invented a compelling way to write JavaScript
applications, so people keep trying. We're still waiting for the Ruby on Rails
of frontend development.

I'm not saying Ruby on Rails is the best backend framework (I don't use it
anymore), but when it came around everybody understood that it was getting
something right. It popularized a new model for server-side web development
that all other communities started to follow and improve. When it came out,
most developers who were already working with the web could see that it would
be very useful, it solved real-world problems they had, it just made sense.

This is much less clear with JavaScript frameworks. They usually have a tough
learning curve and the benefits are not always coming as expected. So people
keep trying to find a model that works well.

~~~
inimino
Plenty of people (including me) took one or two looks at RoR and dismissed it,
too. I don't think it was the slam-dunk you're making it out to be. React
seems to be doing pretty well these days, but it is too soon to say if it is
going to dominate the field.

~~~
niftich
On the contrary; Rails was a massive innovation because it proved that
opinionated, reasonable defaults ("convention over configuration") is how most
people actually want to write software. For a CRUD app, Rails was a shining
beacon of light, because it allowed you to crank one out in mere hours,
instead of days of fiddling with repetitive glue code that you would've had to
write instead in literally any other web framework of your choice. It meant
average coders could be productive instead of overwhelmed, and competent
coders could move on to different projects faster.

The GP post has a point. Almost every MV* JS framework starts from scratch
because they all believe their slight variation of the paradigm is better than
everyone else's, but the greater scheme of things they are more similar than
different. When one comes out with a framework that in earnest changes how JS
development is done -- and achieves some staying power -- things will be
different from the myriad of near-equivalent-but-totally-incompatible choices.

~~~
inimino
> how most people actually want to write software.

[citation needed]

Honestly, Rails wasn't the first or last RAD platform and I don't think a
randomly-selected subset of programmers who have used it would describe it as
a shining beacon of light.

JS frameworks are actually pretty diverse, and if you think the ecosystem is a
bunch of MV* variants just waiting for something innovative to come along,
with respect, you just aren't familiar with what's out there.

~~~
niftich
> [citation needed]

Okay. The year is 2005. PHP5 was fresh out of the oven and most people were
still on PHP4. From PHP's point of view, there's rumors of something happening
in the Ruby community that will be big, and should be talked about [1].

Then Rails 1.0 drops at the end of the year. From this Slashdot thread [2] on
the announcement you can gauge the contemporary reaction; comments detail the
fact that Rails was breath of fresh air from the configuration-heavy Java
frameworks of the day -- represented by Struts [3], but others weren't much
different in this regard, as these books from 2002 and 2004 about alternatives
to Struts show [4][5]. Several ASP developers, detail their positive
experiences in switching their web development to Rails [6][7][8]. The PHP
world is forever changed -- by 2006, frameworks inspired by Rails abound [9].
"Ruby on Rails" becomes a popular phrase, some frameworks borrow the naming
scheme along with the ideas: "Groovy on Grails" [10] tries to bring Rails'
ideas to the Java world, "PHP on Trax" (formerly "PHP on Rails" [9]),
"ColdFusion on Wheels" [11].

I'd say Rails made quite the splash.

[1]
[https://blog.phpdeveloper.org/2005/12/31/25/](https://blog.phpdeveloper.org/2005/12/31/25/)
[2]
[https://developers.slashdot.org/story/05/12/14/0034219/ruby-...](https://developers.slashdot.org/story/05/12/14/0034219/ruby-
on-rails-10-released) [3] [http://weblog.rubyonrails.org/2005/2/22/comparing-
struts-to-...](http://weblog.rubyonrails.org/2005/2/22/comparing-struts-to-
action-pack-railties/) [4]
[https://www.safaribooksonline.com/library/view/programming-j...](https://www.safaribooksonline.com/library/view/programming-
jakarta-struts/0596003285/ch01s08.html) [5]
[https://www.safaribooksonline.com/library/view/programming-j...](https://www.safaribooksonline.com/library/view/programming-
jakarta-struts/0596006519/ch01s07.html) [6]
[http://weblog.rubyonrails.org/2005/6/28/asp-net-vs-rails-
ana...](http://weblog.rubyonrails.org/2005/6/28/asp-net-vs-rails-analysis-
from-a-veteran/) [7] [http://weblog.rubyonrails.org/2005/12/20/neters-tell-
scoble-...](http://weblog.rubyonrails.org/2005/12/20/neters-tell-scoble-why-
they-left-for-rails/) [8] [http://weblog.rubyonrails.org/2005/7/5/not-knowing-
where-it-...](http://weblog.rubyonrails.org/2005/7/5/not-knowing-where-it-
hurts-in-asp-net/) [9] [https://h3rald.com/articles/rails-inspired-php-
frameworks/](https://h3rald.com/articles/rails-inspired-php-frameworks/) [10]
[http://grails.1312388.n4.nabble.com/Groovy-on-Rails-is-no-
mo...](http://grails.1312388.n4.nabble.com/Groovy-on-Rails-is-no-more-kind-of-
td1313422.html) [11] [http://cfwheels.org/blog/how-oo-almost-destroyed-
business/](http://cfwheels.org/blog/how-oo-almost-destroyed-business/)

~~~
vorg
> Groovy on Grails

The source you quote says "Groovy on Rails", which was the official name until
it was contracted to "Grails" due to the insistence of the Rails crowd that
"on Rails" not be used in any other product names. The "Groovy on Grails"
phrase you wrote was a later unofficial but intended mispronunciation of the
earlier name put out by the Grails crowd to make it sound like "Ruby on Rails"
as a snipe at the Rails crowd. To those of us who thought Groovy would make a
good language outside of its use in Grails, the mispronunciation made it sound
like someone in the Grails crowd thought Groovy's only use was for scripting
Grails.

------
gravypod
I think many people are missing what's happening here. This isn't the first
time we have seen lots of churn. Every time some group discovers something
"new" they latch on to it and try to shape it in their image of what is the
best. This is natural and important.

Even looking back about 20 years, how many companies where making CPUs? How
many different architectures where there? How many companies where making PC
clones?

Remember

    
    
        RISC is going to change everything - Hackers 
    
    

We get fanatical about random things every few years because the technology is
generally good, then we all thing "that's stupid I like it better like this"
and after a few years of unmaintainable messes we settle on the middle ground
that most people are ok with (x86).

This is natural the world isn't ending

~~~
kxtells
Small Comment.

The ARM architecture is RISC. And mostly every phone/tablet/wearable(even
stuff like your TV) has one of those.

~~~
gravypod
It's not a "true" RISC architecture anymore. There are "complex" instructions
that would be frowned upon by the original RISC community.

------
mambodog
A lot of comments here seem to suggest it's just because of people creating
projects to get attention. I think this reason is massively overstated, and
appeals to the unfortunate HN meme of disparaging other people's work to
signal that the commenter is smarter than the herd.

However, I would suggest that we are now building applications at a level of
complexity which has not previously existed on the web before (unless you
include non-standard tech like Flash/Flex or Java Applets, which both had
their shortcomings).

If you accept that some of the things which are being built actually unlock
new possiblities in terms of user interface fidelity, and therefore has at
least some purpose, then I would point out that the level of churn can be
explained by the following:

1\. JS has become very widely used very quickly, which means that there have
been lots of hastily built things, which have been replaced by better things
(and for every 'better thing' there are many alternatives which fell by the
wayside), and a larger pool of people to build them.

2\. It's easier than ever to build new tools (or any kind of app, for that
matter), because the npm ecosystem makes it trivial to combine existing
smaller pieces of code into new combinations.

~~~
HelloNurse
If you believe in things like the "npm ecosystem" you have already lost the
war on immaturity.

What's being disparaged is bending web technology to unsuitable purposes
instead of adopting something better, not individual projects that, ignoring
the often insufferable hype and smugness, are often technically clever, as
good as a bad premise and a bad purpose allow.

~~~
macawfish
The war on immaturity? What is this, chitty chitty bang bang? You sound like
the child catcher.

"Bending web technology to unsuitable purposes"... This could mean _anything_
, it only depends on what specific orthodoxy you're implying.

Good vs. Bad. Immature vs. Mature.

The world is actually a colorful place if you open your mind and heart just a
little bit!

------
ronilan
It may not be the common view, but I think that what you are witnessing is, to
a certain extent, "deliberate".

Every framework has a "sponsor". Every strong "sponsor" either has a vested
interest in the web, or, a vested interest in some other platform with which
the web competes.

The importance and power of the web are obvious. So, it is a dance. "Embrace,
extend and extinguish". And, hop, here we go again.

~~~
inimino
What do you mean by "deliberate"? It sounds like you are hinting at some kind
of bad faith or at least perverse incentives but I can't tell what exactly.

~~~
ronilan
There is no "bad faith". There are "diverging faiths". JavaScript frameworks
as an analogy for life :)

~~~
inimino
It seems we agree. Each framework is deliberate, while the number of
frameworks being higher than everyone agrees it should be is a side effect.

------
Illniyar
I have a pet theory about that.

I think it based on two factors:

1\. the size of the community, JavaScript popularity is huge, it's probably
the biggest programming community in the world, even the not so popular
frameworks have a bigger community then the biggest frameworks in other
popular languages (as a not at all accurate measurement, see vue.js and
Python's django github stars/followers).

If you look at js frameworks/methodologies/libraries compared to the sum of
the other languages' frameworks then the pace of change in Javascript compared
to how many people use it is not as bad.

I had a similar experience with Java when it was the king of the web
frameworks - JSP, JSX, JSF, Spring MVC, Struts, Stripe, Wicket and a dozen
others.

Java was big enough to contain all of these frameworks, and it was big enough
for people to support new ideas rather then iterate on existing ones.

I'm not familiar with C/C++ enough, but I think it has a similar amount of
change to Java (which is somewhat less the JS)

2\. the other big factor is how decentralized it is - JS is extremely
decentralized, there are tons of big organizations contributing to it's
advancement, to frameworks even building their own compilers (all the
browsers).

Java is very similar in this regard, even in their governing model (a
collection of companies that decide on standards together, though Java has
drifted from that model with Oracle's lead lately).

C# is the opposite, it's one of the biggest languages but doesn't have a lot
of change in it - everything is dictated by the central authority (Microsoft)
and competing frameworks that don't get popular enough.

There are other factors of course, but I think most of those can be seen in
other languages with less change, and are less relevant overall.

------
fiedzia
Imagine that you have a furniture factory. There is one room where one guy who
works for you produces tables. In next room there is another who produces
sofas. And then another one who makes chairs. The demand is great, so
routinely you hire more people to produce more things.

As you walk, you realise that each of them uses selection of screws and
chisels and screws and wheels, and types of wood and door handles and all of
them are somehow different. Not because they have to be, but because they were
acquired independently by each worker. You come with an idea that if you
standardise on some set of commonly used wheels and handles and chisels. This
means you will need less of them, it will be easier for each worker to
acquire, reuse and combine them, less time spend relearning different tools
and a lot more other benefits. Once you did that, you may realise that the
things built on top of that - like drawers, doors, covers - can benefit from
the same standardisation. And so you do and keep improving your factory.
Notice however that such idea would never come from single worker.

So JS is stuck at being early-stage factory. Main thing that it lacks is a
boss that looks at it and improves it. Any proposed change has to gather
momentum, convince some committee and even than it takes years to push it. It
takes so much effort that most of the time anyone who tries just gives up.
Where in other languages its enough to send complain email and propose a
solution to one mailing list to get someone involved and get proposed change
deployed in the next release a month later, you can't do it with js. For the
same reason there is nobody to make a sweeping change and wipe this disaster
from earth. Too much politics involved. So everyone hack his way around it,
and hacks are not very maintainable, so you'll need to redo them on next
project, but very differently. Making any two projects incompatible and hard
to build one on top of another.

Java had its Sun, Python had BDFL Guido, JS has no such thing.

~~~
robinson_k
> Java had its Sun, Python had BDFL Guido, JS has no such thing.

For JavaScript the TC39 is responsible for its improvement and
standardisation. Thats were ES6 was developed. ES2016 aka ES6 took a fair
amount of time, but the TC39 switched to "rolling releases". ES2017 aka ES 7
is already in the works and is going to be released 2017.

[https://github.com/tc39](https://github.com/tc39)

~~~
shawndellysse
Actually, ES2015=ES6, ES2016=ES7, which was released earlier this year. Most
people mess that up due to the combination of unfortunate naming and the fact
that ES7 wasn't nearly as big of a jump as ES6 was.

------
inimino
First, Web technologies (not just JS but HTML, CSS, DOM, etc) are implemented
by multiple browsers, who compete and have other agendas, as well as backend
and non-Web platforms. This underlying technologies are just messy in a way
that only a world-wide, massively distributed, twenty-year-old platform can
be.

There's nothing quite like this anywhere else in tech, as most platforms are
dominated by a single vendor. Imagine what Windows development would be like
if, in addition to the need for backwards compatibility, there were three or
four competing vendors of Windows, each with different feature sets and bugs.

Second, tools and libraries can overcome many of these problems, but these
fixes come with costs, including library maintenance, cognitive overhead,
security risks, complex build and deployment processes, and retraining and
hiring issues. Because JavaScript is used across many industries and teams of
all sizes, what is perfect for one may be completely inappropriate for
another. Many projects, like GWT, meet the needs of the environments in which
they were designed, while being so much a product of those environments that
they become anti-productive elsewhere. So we have a very diverse set of tools
on top of a very messy and relatively old set of underlying technologies.

Finally, many new programmers come into this incredibly diverse, sometimes
frustrating, environment every year. It is an environment that encourages
open-source contribution. It's no surprise that many new tools and libraries
are released every year, and some of them gain adoption.

------
viraptor
My interpretation of this is that js was a pretty cool idea, but it was used
as a hack on top of websites initially. (Think Netscape times) It was held
back for a long time by lack of improvements, no real coding environment, no
real modules apart from copy pasting. It was held in place by a huge rubber
band while people actually tried to pull it their way.

Relatively recently the standardisation, improvement of the language itself,
real origin policy, common frameworks and finally npm released whatever was
holding it back. It shot out from the rubber band and it's trying to catch up
in months where other languages had years to find the way. You may notice that
even though a lot is changing, not much is really new. Async existed before,
so did dynamic languages, so did MVC, so did immediate mode UI, so did many
other things. Js is now going through all of those ideas quickly because the
path is known and clear. It will slow down though. There's only so many
paradigms that we know. At some point people will run out of easy ideas and
will have to start slow experimentation just like all the others.

------
dpweb
The perceived benefit of creating a new framework is large (I'll solve
programming the internet!) and the cost is quite small (easy to write js with
little knowledge), there's a huge number of devs, and no one really owns the
space.

Compare it to say, creating a new operating system. Sure the world could
benefit from a better OS, so why not make one? The perceived benefit is small
(why do this when Linux exists) and the cost is large (it's hard and you need
a lot of knowledge).

Also a lot of half baked ideas. The number of js writers is huge but on
average very inexperienced compared to other languages.

------
dancek
I think it's because of historic baggage and politics.

JS used to be a horrible ecosystem where different browsers behaved
differently, the language itself had various pitfalls and most code was
written in classical script kiddie style. This has been changing for the
better for a long time in small steps, but frankly something has always
sucked, warranting the next evolution.

The second point is politics: JS is huge these days, and there's still a lot
of room for improvement. Everyone wants to be the company behind the de facto
standard library for web apps.

------
twblalock
Coming from a Java background, it seems to me that a lot of what is going on
in the JS world is similar to what enterprise software went through over the
past 20 years: the "framework" craze.

This is appropriate because websites and web apps are more complicated than
ever before, and face the same challenges that traditional enterprise software
faces: large codebases that stay around for a long time and need to be
maintained and refactored, integration with various APIs, asynchronous
communication, separation of concerns, separation of model and view, business
logic, test coverage, development of different parts of the application by
different parts of the engineering team, etc.

At some point, the benefits a framework provides outweigh the time it takes to
adopt and learn the framework. A framework provides an overall way of doing
things that gives structure to the project and makes a lot of the challenges I
mentioned easier to deal with. Frameworks significantly reduce the number of
"how do I implement this feature?" questions that are bound to arise, by
providing a standardized way of doing things. They make it easier for teams to
collaborate, because the codebase is relatively consistent and engineers
aren't constantly dealing with other team members' idiosyncratic code. (Yes,
that means there is less room for individual creativity and expression, and it
makes programmers interchangeable to some extent. Welcome to the world of
business.)

So, why are there so many more JavaScript frameworks than Java frameworks? I
suspect it has to do with the low barrier to entry of programming in
JavaScript as compared to Java. I also think that dissatisfaction with
whatever frameworks are current is a major driver behind the creation of new
frameworks. (I suspect that a lot of the dissatisfaction with the current
frameworks is misdirected and is really due to the nature of JavaScript as a
language, and TypeScript is an example of an explicit reaction to that).

Another reason for the proliferation of frameworks is that the playing field
keeps changing. Most recently, it has been smartphones and social media that
have revolutionized the way people use the web. Before that, it was streaming
video and "Web 2.0." Whatever the next big thing is, I'm sure it will inspire
a new flurry of new web development frameworks.

------
HelloNurse
There is a high rate of change in fads, not in reality. What is actually worth
learning and following has a normal change rate. Fads are governed by a vast
community of hipsters who clearly prefer to spend time and effort on earning
15 minutes of celebrity with some library or tool than on more productive
tasks like improving their own web site, working for customers or learning
principled computer science and software engineering. Meanwhile, web standards
like HTML, CSS and ECMAScript and web browsers evolve at a reasonable pace and
in a saner way: doing more things and doing the same things in a nicer way.
The traditional design attitude of figuring out how web standards and imposed
technology allow to do what is needed and only then selecting tools and
libraries that look useful is the main way to ignore fads.

------
hoodoof
Cause JavaScript is used in browsers so it is the language of the web, and
because it has turned out to be incredibly flexible and adaptable, and because
it's pretty simple once yo get past the async thing, and because alot of
effort has gone into making it fast.

~~~
justinlardinois
I think out of all the comments so far this passes closest to the real reason.
It's simple: if you're developing for the web, you almost certainly _have to
use Javascript_. That reality corrals so many more people into Javascript than
any other language.

~~~
inimino
That is certainly part of the reason, but other platforms enforce language
choices and don't have the same level of churn. Two popular mobile platforms
come to mind.

~~~
justinlardinois
You don't have to use Java on Android and you don't have to use Objective C or
Swift on iOS. You're heavily corralled towards them, but there are still other
options.

------
SFJulie
It is because JS does not change much that there are all this libraries around
that changes a lot to try to give an underfed horse more power.

In comparison, java, PHP have undergone some more than welcome mutations in
terms of syntax clarity. Evolution in JS is made by adding features in
frameworks, not in the core definition of the language.

You could see JS as the assembly language of the browser and all the
frameworks as some C/fortran/C# that translates into JS.

The problem is the web would look definitively balkanized/ghettoed between old
and new computers if you made a non backward compatible change of JS ...

JS is the most ducked taped language of the landscape of computers. And it is
leaking memory, performance, abstraction from everywhere.

------
ggregoire
> For example angular 2 is not compatible with angular 1, so before you even
> learn a framework its API is different and when you finally learn it,
> probably is considered outdated

Angular 1 has been released in 2010 and Angular 2 in 2016. Obviously, if you
started to learn Angular 1 last year it can be frustrating (specially with
Angular, it's not the easiest framework to learn out there [1] [2] ). But I
would say the majority of Angular developers has used it for 3 or 4 years now
and most of them probably enjoy to have the chance to learn a new modern
framework that fixes the design issues of the first version.

To generalize: The front-end world is surely overwhelming for the new comers
(but is it not the same in all the other fields of programming?). However,
after some years into it, you realize that you have mostly sticked to the same
tools for years. [3]

[1]
[https://www.bennadel.com/resources/uploads/2013/feelings_abo...](https://www.bennadel.com/resources/uploads/2013/feelings_about_angularjs_over_time.png)

[2] [https://i.imgur.com/5rJH3co.png](https://i.imgur.com/5rJH3co.png)

[3]
[https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19...](https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19851a33)

------
neilsharma
Slight tangent, but if someone were getting started in JS today and wanted to
build medium-complexity, async-heavy, web apps with decent-sized backend, what
stack should he invest his time on? React, angular, node, elm, express, etc?

Let's assume he wants the skills/tools to still be relevant in 1-2 years time
in a sizable percentage of the job market (noticed that many startups don't
like people with web experience that isn't in React/Angular/Node).

~~~
Zyst
Opinion based, yada yada: React if they want to join startups or similar
cutting edge companies. Node if they want to do server work. Angular 1.x if
they want to go into consulting.

While the JavaScript ecosystem does move insanely fast a lot of consulting
companies need to have people with similar skill levels in a framework/etc.
Which means you can't just switch frameworks every year (You can, however,
create smaller teams with new technologies, so if a few of the guys learned
React you can just make a React team with them as a base.

A big misconception I've seen is that a lot of JavaScript stuff disappears
after a couple of years, while in reality a lot of Consulting companies are
still recruiting people for jQuery positions (In my country, might be
different in the US).

Sure, the new startups who are using all the newest coolness maybe won't touch
jQuery and similar technologies with a 10 foot pole. That doesn't mean those
technologies disappear.

It depends on your goals as a person. Personally I enjoy chasing the newest
thing, learning is fun. Maybe when I become more jaded at re-learning stuff
every year I'll move from that kind of ecosystem.

All in all, the advice I wish I could've told myself years ago is to invest a
bit less time learning frameworks in depth and a bit more time learning
JavaScript. JavaScript has a lot of pitfalls, but if you learn to navigate
around those you are left with a very fun and powerful language. And most
importantly, that knowledge is still gonna be relevant 3 years from now even
if you are switching frameworks.

------
intrasight
I'd say the opposite - it's changing way to slow - at least in browsers, where
IMHO is the only rational place to use JavaScript. The big change will be the
arrival of webassembly.

~~~
alasdair_
Mind sharing why you consider node.js and other server-side javascript tools
irrational?

~~~
mahyarm
Unless your project is small (like under 10-20k lines), why use node when you
can use a typed language? Javascript is a mess and if I'm server side and
using something dynamic, I might as well use something nicer like ruby or
python.

~~~
z3t4
Types are low level. JavaScript is very high on the stack, and has no concept
of types, it only has "value objects" (variable values: string and number,
plus static values: true, false, null, undefined) and "normal objects" (Array,
Object, Date, Function, etc). There's a debate though on what type should be
used for numeric values in JavaScript. In JavaScript you rarely see getters
and setters, as you do not need any abstraction over the type system, although
it _is_ possible to do bitwise operations, so if you want to you _could_ make
your own types, although you will not have full control of their binary
representation, witch you would need a "real" programming language with a
proper type system, but I've only seen that in optimization witch rarely runs
faster then native JS. You get a lot of productivity by not having to worry
about types in JS, and you rarely se buffer overflows witch is common in lower
level languages such as C and C++. JavaScript is an an abstraction where you
do not have to worry about the under-layer like imperative memory management.
If you have to decide between small int vs big int vs floats, it's a leaky
abstraction. JavaScript is one level above that.

~~~
tscs37
You seem to assume that

A) Types are low level

B) C++ and C are the only competition to JavaScript

C) Not having to worry about types makes you faster or in any way better

A) is simply refuted by looking at java or SQL. SQL is a very high-level
language compared to other stuff, yet it's heavily typed simply to ensure that
data is either valid or the query fails (SQL Injection is still valid data in
this case)

B) Take a look at Go. It's blazing fast. It beats Node.js in all benchmarks
but Regex matching ->
[https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...](https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=node)

Furthermore, Go is statically linked which means deploying to production is a
simple scp operation to drop the binary.

Lastly, Go is opinionated on how you write programs, you will write programs
that are scalable simply because of how simple goroutines are, using channels
you can utilize asynchronous execution as you would in node.js but also
utilize all available cores without having to think about threads or
synchronization. Just pipe data through the channel!

C) Is a red herring, depending on who you ask it's either opinion or static
typing being "better". [http://danluu.com/empirical-
pl/](http://danluu.com/empirical-pl/)

Some studies indicate that it does not matter, some indicate faster
development but more bugs for no types and others indicate less bugs and
slightly longer development for types.

IMO Types are good. I want to worry about the types because when I receive
user input I can be sure that once parsed it's 100% an int or a float or it
fits in a certain struct. For the same reason I think relational databases are
better than document stores, they ensure that my data is valid.

I don't have to write as much validation logic. It is sufficient to know that
my function has been passed an int-type, I don't have to check if it's nil or
a string.

~~~
Roboprog
Compile time types are nice to have, if they stay out of my way (type
inference, the ability to easily opt out for certain "tricky" code...)

Types keep things (except for database column names or JSON import...) from
blowing up the very first time you try to run it, rather than stopping the
compile. That's useful, as far as it goes. (as long as it saves me more time
not fixing a typo and rerunning than it does generating stupid cluttered code)

We have bigger problems (not that JS really addresses them, either).

Mutable data, cyclic update graphs and temporal coupling. (at least JS makes
it easier to do FP type programming and to freeze objects to force
immutability if you need to). This is a paradigm change we probably won't see
until after most of us raised in the C/Algol era are dead, sadly.

Pet peeve: infix operators, and precedence rules. I have seen this bite badly
in subtle ways, but it's a sacred cow of computing that you MUST have
algebraic expressions. Lisp had it right - parens first, now you are trained.

Now that we have effective garbage collection, can we please STOP writing
(thinking) in Algol/Simula 67 dressed up with curly braces??? (which really
isn't that much higher level than COBOL/CICS, especially when you look at most
Java dreck)

~~~
mahyarm
Type inference is horrible. Mostly because as soon as your project gets large,
type inference eats inordinate amounts of time during compiling and indexing
and developer experience degrades. Combine that with operator overloading and
generics and it gets even worse. Right now I'm suffering through it with swift
with a +100k LOC project. The obj-c equivalent compiles and indexes 5-10x
faster.

If you can make type inference scale, then I would be all for it. If I'm
restricted to a small LoC count, might as well use a dynamic language.

Static typing is a scalable tool. It lets me avoid an entire category of bugs
and unit tests. It make refactors easier as I just have to change my thing and
then fix all of the obvious compile errors once. It helps me define parts of
API contracts in code vs documentation and unit testing. And when a project
gets large, the automated nature of static typing helps a lot!

~~~
Roboprog
Operator overloading is doubly evil :-)

FWIW, I mentioned that I think even the built it infix operators are a bad
idea, rather than functions, such as variadic add(...), multiply(...),
or(...), and(...). (subtract() and divide() really should only have 2
arguments, and not() just one)

------
btbuildem
Because the ecosystem is mostly built by people with no formal education and
little experience -- they're literally re-inventing everything from the
history of computer science.

~~~
wiredearp
Or perhaps because the ecosystem is built by people with much formal education
and industry experience applying traditional computer science paradigms to a
stack with bizarre and unconventional tooling, not realizing it was made by
other experienced backend developers attempting to fix the same imagined
problem in a domain they don't understand. The outcome would be the same, so
it's hard to say for sure.

------
anilgulecha
I think it's because of certain new paradigms that are opening up so many
opportunities.

With HTML5, CSS3 and ES6 being released, and seeing wide adoption, the web-
application layer and APIs suddenly have access to a magnitude more
functionality, and we're essentially in the early romantic period where we're
pushing these new features to the max, and figuring out what sticks.

Over the next year, we'll settle at the maxima of efficiency and usefulness
with the web framework. Despite some negative voices, IMO these are very
exciting times for the web :)

------
pmarreck
First of all, Angular sucks (/opinion), so that's a bad example.

I think it's due to the fact that Javascript is _so terrible_ at any scale,
yet is _so pervasive,_ that working with/around it becomes this deer-in-
headlights thing you can't ignore... since most HAVE to work with it in some
form, doing any Web stuff.

I recommend Elm, as a way around Javascript's problems while still allowing
you to run in browsers: [http://elm-lang.org/](http://elm-lang.org/)

------
daxfohl
Because you can write a new JS/HTML framework in a few days. Compare this to
e.g. Qt or GTK or WinForms or WPF. Each of those would require man years of
effort to reproduce from scratch.

Also these JS frameworks tend to be opinionated with how databinding works
etc, such that there's always _something_ that you have to work around when
you're using the framework in real-world projects. People get annoyed enough
that hey it's easier just to create another framework.

------
sebringj
NPM + Github + Node.js + JavaScript is easier + JavaScript was already front-
end ubiquitous came together in a perfect storm to allow JavaScript packages
to be created and spread like butter on toast. JavaScript is the easiest to
develop with, has the most adoption, runs client/server and has the easiest
package manager to both publish and use. Why is this even a question? This is
not an argument for JavaScript but merely stating why it is changing so fast.

------
whostolemyhat
I think it's due to the new version of Javascript being released recently
after years of stagnation. ES4 was abandoned and ES5 was mainly standardising
existing practices, while ES6 has added a lot more - new syntax, new types,
iterators, generators, modules and so on.

A lot of the churn going on is due to people trying to work out the best way
to use these new features, along with whether or not to keep backwards-
compatibility with existing frameworks and libraries.

------
dfabulich
JavaScript is a programming language that was frozen in amber for a decade,
and is only now starting to thaw.

Brendan Eich initially designed JavaScript in an infamously short time--he
coded and designed the first prototype of JS in just 10 days.

It quickly became the only programming language you can use in a web browser,
with multiple vendors, including Microsoft, owning mostly compatible
implementations. Due to trademark disputes they couldn't even call the
language standard "JavaScript," so the language standard is called
"ECMAScript."

Microsoft didn't want/need JavaScript to change or grow at all. Once Internet
Explorer 6 became the dominant browser on Windows, (which was and still is the
dominant PC operating system,) they stopped releasing new major versions of IE
for five years (2001-2006), and IE7 wasn't a very big upgrade, especially in
terms of JS language features.

Mozilla unilaterally released new language features that only worked on
Firefox, so nobody could use those language features in practice on the web;
in many cases, new language features wouldn't even parse in IE.

In 2007, there was an attempt to build a major new JavaScript version
(ECMAScript 4) with a _ton_ of new features, (classes, a module system,
optional static typing, algebraic data types) but it was scrapped due to
disagreements between Mozilla and Microsoft. They wound up implementing a much
more modest upgrade (ECMAScript 5) which shipped in IE9.

In all this time, there was essentially no interest in running JavaScript in
command-line tools or on the server side. That changed in a big way in 2009
with Node.js. It used V8, Google's JIT engine for JS, and it was surprisingly
fast.

This is when the language really started to unthaw. IE declined in dominance
as Chrome rose, and the demands of server-side development started to be felt
more strongly in the JS community.

ECMAScript 6 started to add back in a number of cool features, and by this
time, JS developers were desperate to use them. This lead to the development
of "6to5," (now called "Babel") which allowed you to write code in ES6 and
"transpile" it into older JavaScript versions, so developers could experiment
with new language ideas without pushing them through the standardization
process.

Languange evolution kicked into high gear at that point. There are a bunch of
interesting pluggable transpilers out there, including TypeScript, JSX, and
Flow, and countless non-standard plugins for Babel.

And that's just the language itself! The "standard library" for JavaScript for
years was just "whatever IE6 could do" and that wasn't very much. IE6 was
pretty buggy as well. jQuery became popular as a library to smoothe over
differences between browsers, but mostly to work around bugs in IE.

Client-side frameworks were tough to implement on IE6, not least because IE6
was just so darn slow. As newer, faster browsers came out, it became possible
to trade off some performance to improve developer productivity.

And everybody has their own ideas about what those trade-offs might be like!

At the same time as IE6 started to decline in popularity, the mobile web on
iPhone and Android rose in importance. Smartphones include a bunch of new
sensors (GPS, orientation, camera) and new limitations (RAM, slow/unreliable
network). This spurred on browser vendors to "compete with native apps,"
adding features to the browser platform, inviting developers to respond to
these with new frameworks.

As for the JS server-side, Node.js is still a relatively young platform as
these things go, and so it's not surprising to see a lot of churn in server-
side libraries/frameworks, especially given how much churn the language itself
is undergoing.

Node.js is also the first major platform to be born in github, which IMO
encourages experimentation (and flame wars) via forking.

Node.js's standard library is designed to be small, (they call it the "core"
and resist Python's "batteries included" philosophy,) forcing folks to rely on
libraries and frameworks to keep the lights on. Even most libraries themselves
need to take dependencies on other libraries, because of this "small core"
philosophy.

I think it's going to be at least a few more years before things start to cool
off a bit. Enjoy the ride, if you can!

~~~
tmzt
What language features only worked on Firefox?

~~~
inimino
Quite a few, if you browse the JavaScript pages on MDN you can read about
them. Many of them inspired ES5 and later standardization work. Getters and
setters, let and const, generators.

------
bbbbbbbbbbb
There are two different questions there.

Angular 1 was written by people who knew nothing but OO programming.
JavaScript isn't OO. So they spent a lot of time square pegging a round hole
because they were ignorant of what they were doing (probably a group of young
coders).

People are now starting to get on the functional train (which JavaScript is
more like than OO), and angular is trying to now fix the fact they were short
sighted and too opinionated about the wrong things.

JavaScript, in general, has always been in a rapid state of change. Or, more
broadly, the UI of the web. From flash and silverlight to mootools and jquery
and CSS animations and canvas... there isn't a good way to do web UIs yet.
There is a lot of trial and error happening which makes for some rough waters.

------
techbio
JavaScript was originally a way to create interactive webpages, but because it
broke or replicated MVC, became the backend too.

The variety of backend requirements, and the flexibility of UX, led people to
solve many individual workflow bottlenecks or generalize to any/many.

Then so, like the English language, exploded to the simple-->jargon range of
overloaded usage and niche comprehension, very quickly fragmenting, but
universally powerful.

Developing a framework as a startup for a particular use case may take more
time than prototyping on an existing framework--this is why the prototype
should be discarded, and a critique of how open source/reusable code has
always been a source of technical debt apart from the rare, shining outliers.

------
scotty79
It's due to openness of npm ecosystem. Any other language you'd have 50
different angulars at the same time but almost noone would know about any of
them because they'd be confined to the companies that spawned them.

Frameworks as a popular thing started because people (rails?) started sharing
their code and no other can share code as easily as JS and npm.

Angular 2 should be called Begular because it doesn't have anything to do with
Angular but inspiration. You can stay on Angular but don't be surprised that
people will prefer to develop something else since Angular folk painted
themselves into a corner so hard that to make framework that sucks less they
need to go back to drawing board.

------
mgalka
I've wondered the same thing. My guess is that it's because node is still
pretty new, whereas most other popular languages have been around for a while
and the "right" way to do things has already reached some consensus.

~~~
blohs
I wonder id its worth to learn all those cutting edge libraries now, because
whatever code I write today maybe outdated next month and I'll have to learn
yet another framework/library/syntax etc.

~~~
toast0
This is general advice, but use as few libraries as possible. If you learn the
base language, the knowledge is portable to most frameworks, but learning a
framework may not be.

If you want your code to work in the future, you are ultimately responsible
for your code and all of its dependencies. The less code, the better.
(Although some libraries have earned a track record of dependability, projects
and companies may be abandoned and you may need to pick up the slack)

------
m_mueller
To piggyback here: How long until we can just use whatever language we like,
including Std.-Libs, package ecosystem, sandboxed FS (and thus DB support) and
JIT it to JS in all commonly used Browsers?

~~~
cheiVia0
See WebAssembly

~~~
hood_syntax
Can't wait, I may actually switch to front end development when there are WA
backend(s) for a language/languages I like.

------
tomphoolery
The change in JS isn't "out with the old, in with the new"...it's just "in
with the new". There are more choices than ever before, because you can build
about 100x the kinds of apps that you could have before with JavaScript. Prior
to 2009, JavaScript was pretty much only good for web applications. Now, you
can build servers, embedded devices, native applications for every platform
imaginable, you name it. Pretty much anything that _can_ be built, can be
built with JavaScript.

------
wiseleo
JavaScript is being redefined. The language is flexible enough because of
prototypal inheritance that every method can be redefined at runtime. ES6
added many missing features.

That's unusual. These frameworks extend the language. Angular's developers
reasoned that anyone smart enough to figure out Angular 1 will be able to
migrate their code to Angular 2. It's looking more like C++ and less like CSS.
:)

Take a look at Meteor's code sometime. It does things I never expected
possible with JavaScript.

------
fibo
Cause we are living in a transition period. Remember the CVS war, cvs vs
subversion, then hg vs git. Now git seems to be the winner and there is no big
change since few years. In these days there are a lot of progress going on,
let's wait things get stable but it Will take a very long time considering:
es6, es7, vr, webgl2, serviceworker, webaudio, http2, webassembly and a lot of
other stuff in some way related to js.

------
spion
I touch on it a little bit here:

[https://spion.github.io/posts/javascript-is-not-
cancer.html](https://spion.github.io/posts/javascript-is-not-cancer.html)

TLDR: I believe its mostly due to the lack of basic language facilities in
pre-ES6 JS. With ES6 covering the basics this will probably slow down (At the
very least people will stop writing their own module and object systems)

------
nodesocket
One could make the argument that the JavaScript / Node.js community are uber
early adopters and push technology more often and further, but I'm not certain
that is what is really going on.

However, moving fast does percolate down from the top. Look at Node.js and how
often they release new versions.

------
agentultra
Because there's a lot of investment in the language and its ecosystem. There's
more money pouring into V8, *Monkey, and other JS compilers than goes into
most any other that I can think of. With popularity comes rapid evolution.

------
jerf
Javascript and the browser environment it is still pretty much glued to (Node
notwithstanding) has several major architectural flaws and some unique
challenges that are particularly acute for Javascript, and a lot of energy has
been expended trying to figure out how to use the not-very-strong tools in a
way that can support high-quality applications without too much developer
effort.

Also, some of these things are getting addressed over time, so I'm kinda going
to talk about the state of JS over the past decade rather than the state it is
in right now. Some of these things are being mitigated (very few things are
really being "fixed"), but it's still early. These issues have historically
included, but are not limited to:

1\. Poor modularity brought on by being not just a "scripting language" like,
say, Python, but a language actually designed to write small event handlers
that fit into a single HTML tag attribute. "x = 56" defaults to putting x in
the global namespace. The language did not provide modules or very much in the
way of separation by default. You've pretty much always been able to namespace
things, but you had to really work at it; the language did not help. (I'll
also toss in the dynamic typing here, just because I don't want to give it a
full slot here, but it does inhibit making big projects easily.)

2\. Very poor control-flow management ability due to the choppiness of event-
based programming. There has historically not been a way to maintain a call
stack across events, which strips away all the tools of structured
programming, a set of tools so fundamental to how we operate that we often
don't see them as a fish doesn't see water. Promises and generators allow us
to try to mitigate this, but at the cost of spending design budget; promises
for instance introduce a second entirely new set of control flow mechanisms
that mirror the base language's looping and flow control constructs,
particularly annoying because you must control both error and normal flow on
both of these levels.

3\. The browser's interface to JS is the "Document Object Model", which due to
historical reasons is a Java-designed API bolted on to the side of JS. A
native JS model could have been much more powerful and easier-to-use,
requiring us to burn less design budget on simply interfacing to the browser
in a reasonable manner. A lot of the design churn is attempts to answer the
question "How can we make manipulating the DOM more JS-native?" There are also
several performance issues introduced by the fact that the DOM model, combined
with the rendering model, is _extremely_ rich; things like manipulating a node
on a page vs. detaching the node, manipulating it, and reattaching it have
historically had end-user-significant differences in performance, as every DOM
change triggers an incredibly complicated set of updates to a widget toolkit
that was designed for flexibility rather than performance.

4\. Browers themselves further introduce many complications. Then you have all
the _security_ issues that arise from being fundamentally client-server with
dubiously-trustable servers. You have all the details like what cookies flow
between what domains and where and when, that you need a different domain for
your static content both for security and performance reasons (prior to HTTP2
particularly), and any number of crazy APIs that also _vary_ across browsers,
requiring the developer to use shims for things as simple as XMLHTTPRequests
because you just never quite know what you actually have.

5\. I could have list "client-server" in #4 there, but it's also worthy of its
own callout. Many frameworks have different solutions for client-server
interactions, ranging from ignoring the problem and letting you solve it up
through Meteor-like attempts to completely blur the lines between the two, and
everything in-between. Client-server interaction has been further inhibited by
the fact that historically, there have not been any reliable and high-
performing mechanisms for streaming things between the client and server,
creating a design limit around needing to be request-based, further creating a
wide variety of ways of hacking around this problem, each with their own
quirks.

6\. As an open standard, nobody is really empowered to fix these problems in a
coordinated way. As a result we're sitting on top of 20ish years of standards,
some well-done, some poorly-thought out, some hackily fixed after security
issues, many poorly-understood by developers, and all in the browser.

7\. Finally, one must not ignore the fact that web pages continue to become
intrinsically more and more diverse. The best framework for a document-centric
app is one thing, the best framework for a CRUD app another, and neither of
those will help you much with an intrinsically real-time streaming app like a
chat client.

And there's probably a couple more dimensions I could come up with if I
thought more. What you see is that there's a lot of possibilities for
mitigating all these issues ("solving" is often not on the table, these are
mostly fundamental issues arising from layers below the JS), and the framework
churn is in many ways nothing more than people combining all of the various
combinations of possible answers to these problems, looking for synergies,
solving different problems (per #7), and basically frantically rifling through
60+ years of computer science theory looking for the perfect solution to
problems in an environment with so many fundamental strutural issues that no
perfect solution is possible. Which is also why you see such vigorous advocacy
sometimes; someone thinks _this is it, this solves all my problems once and
for all_ because it worked for a couple of weeks, and only once the community
has chewed on it for a while does it become clear that there's a lot of people
with different needs for whom that doesn't work so much, and it also didn't
actually solve all the problems once and for all after all.

BTW, none of this is criticism of the JS community, merely explanation. Given
the hand we've been dealt in the web browser, lots of people trying lots of
things is the best we can hope for. The fatigue is just an unfortunate, but
unavoidable, side effect. The best solution for the fatigue is to concentrate
more on the fundamentals being explored than the details of a particular
framework. For instance, "reactive" programming is its own paradigm, with its
own lore and learning; learning how to program that will also let you write
better spreadsheets and be better at creating database triggers, for instance.
Concentrate on the fundamentals. The fundamentals are not churning that fast.

------
aikah
> For example angular 2 is not compatible with angular 1

That's not the problem, angular 1 and angular 2 are 2 completely different
frameworks that share the name and the team only. The team wanted to piggyback
on the fame of the first version, but they share absolutely nothing
conceptually. and contrary to what the Angular team says there is no "upgrade
path", you need to learn the stuff from scratch once again.

The problem is, and the Angular team will find out very soon, "second systems"
unless they provide huge advantages over the first version, are always a
failure.

~~~
prophesi
It was quite the rough path when I converted an app from v1 to v2. First I had
to get the app to work with Typescript (not necessary, but it seemed there'd
be better docs/tutorials in Typescript with v2). Then gradually rewrite each
piece of code using ng-upgrade as I relearned everything. But I still must say
that v2 definitely provides the advantages to warrant the hassle.

------
techbio
[http://hotframeworks.com/](http://hotframeworks.com/)

Skip the chart, look at the long tail of listings.

~~~
vinayan3
It doesn't have React. Is this an oversight or does it not count as framework
in their definition?

------
techbio
Is there any existing tool to interrogate a codebase for adequacy for a set of
tasks? Ie. PageRank/'citations' for frameworks?

Should there be?

------
niroze
millennials ;)

...and it is where a lot of excitement is now. Excitement drives development
(of tools themselves and general usage). Much of the time, it is for the best.

People tend to get lost in tooling, which I can understand.

------
kewp
It's the Internet - remember that remarkable decentralized network for
informational retrieval developed by ARPA in the 70s ? It's going to change
the world !

It's always on. Anyone from anywhere can interact with what you create
instantly. What else is like that ?

------
d0ugie
Why didn't the Dart VM make it into Chrome?

------
grigio
Because nowdays js has so many use cases

------
cygned
My (very) personal opinion: I think, the culture is a important factor here.

There are very great developers in the ecosystem, who write great tools and
libraries which become popular, are well maintained and documented. But the
majority of the developers are just average developers. As everyone, they
attend conferences and bootcamps, and when I then talk to them, the usual
thing they learned there were two things: (1) make a blog and write about what
you are doing and (2) make some OSS projects or participate in existing
projects.

It is very great to have people who create projects and bring in new ideas, it
helps create a mature technology. But the truth is, most of the average
developers have never been in larger projects, have never been digging into
complicated/large open source libraries and have never had to manage larger
applications. One of the most important things you learn in such projects is
to be calm and think about documentation, architecture and dependencies
carefully.

And this leads to the current situation;

\- we have a lot of libraries doing the same things, just because developers
do this "just create an oss project on GitHub/npmjs" thing without searching
for existing solutions

\- some hip developers have so many projects that I always ask myself how they
are planning to support all these

\- when a problem arises, e.g. a bug in a library, many developers these days
seem to tend to write their on lib fixing that problem (if it is a small
library) or building an internal workaround instead of contributing back to
the original project

\- on the other hand, there are a lot of project maintainers who ignore issues
and pull requests just because they have a very strong opinion about what
their library is doing. Oh boy, sometimes it took me days to write a PR which
(from my point of view) improved something or added a new feature, carefully
followed existing guidelines (code formatting, docs, etc) just to get the
answer "nah, that's not my scope. Fork the project or write your own"

\- it seems to be easier to convince people with less business experience.
They often jump on the next hot train coming along that sounds good. I don't
want to exclude me here completely; as I read about React, it started working
with it directly - because it seems to solve all the problems I had with
Angular and Backbone

\- I have the feeling that a lot of developers today (still) have this "read
the f*g code" mentality. Even mature libraries developed for years have so bad
documentation (even though they have their own .io domain just for it) that I
have to read their source to see what parameters I can pass into a function.

I think, browsers/engines/tech companies/... are also part of the problem. For
years, JavaScript has been "developed" (language spec) slowly and browser have
been adopting features slowly. But then, suddenly, everything exploded. And
now we have very awesome features in the language that allow for things that
have not been possible before. And in fact, these features deprecate some
libraries or frameworks. And instead of abandoning a project by deciding that
only bugs will be fixed in the future and no new features will be added, the
developers either try to move to the new technology with their product; or are
forked by people who were part of the project but didn't like its
developers/strategy/whatever and want to use the new opportunity with the new
language feature to change things; or get company by another project that does
basically the same but started from scratch and uses all new language
features; or all together.

As a side note, I work with JavaScript every day and that is only my opinion
on the topic. Please don't feel offended.

[edit: typos and formatting]

------
jlebrech
because it blows.

we need a full IDE, Language, Library combo for better development.

~~~
Roboprog
There are IDEs that support JS.

Use JS to do FP (functional), rather than OOP, and it totally rocks.
Refactoring stuff works pretty well with nested functions - function names
have to be "real" (if avoiding eval()), as opposed to properties that can be
provided as associative array string indices (not that there's anything wrong
with that, if that's what you need).

I'm not a script kiddie, either - I have been programming since the early 80s
when I was earning my CS degree. I'm not scared of dynamic scripting languages

~~~
jlebrech
we just need it to be as easy as xcode

------
NotAJSExpert
I think one of the things that's led to the mess with javascript is that it's
kind of crazy to have settled on using a language to write such large
applications that:

\- Has no standard library. \- Is used to automate host platforms that have
either no standard framework or very little (e.g. Node on v8 doesn't have
_nothing_ but it's quite small). \- Has no module/namespace system.

The effect of this is that immediately, anyone building anything in non-
trivial has to make a decision about how to fill in things that would be
covered in a standard library. I'm not even talking about fancy stuff, just
the stuff supplied by underscore, lodash, etc. The choices are basically:

1) Write all the code yourself. This is an extremely low ROI option 2) Adopt a
series of libraries and hope you can get them to work together 3) Adopt a
framework, that by its nature, will be designed to use some sort of new
pattern and this pattern will be expressed on top of whatever libraries the
framework uses, so just draft behind that.

There aren't really many other mainstream systems where a language is used to
specialize applications on a platform where this situation obtains. Windows,
OS X, iOS, Android, even Java, come with enormous, enormous amounts of library
code. Generally, this library code also pushes one fairly firmly towards
certain design patterns.

Imagine if we all decided to use...hmmm...Scheme, I guess, to develop Windows
applications, and you took away everything but the lowest-level Windows APIs.
I'm using Scheme because the Scheme standard outlines a remarkably small
language that has nothing approaching a standard library.

We'd probably be in a similar situation. How do you do this? How much does
adopting this or that library force you to do this or that? It's just not very
common to have a situation where to do anything non-trivial, you need to
either: \- adopt an enormous amount of third party code (because the situation
works at every level, each third-party solution will also not be built on a
standard library ecosystem) \- write an enormous amount of boilerplate code.

And further, the issue is exacerbated by the fact that js doesn't really have
a standard module system, so even the approaches taken to fill these gaps are
frequently non-compatible, or just choosing which system to use to manage
modules often means replacing huge chunks of your application.

There are other reasons why JS the language is moving, all of the sudden: JS
has had a lot of rough edges and all of the sudden a confluence of interest,
capability, and technology has made it possible to sand down some of those
edges.

But I think even if the ES process slows down, and we all agree that language-
wise the features in the language are pretty good or something happens that
freezes, we'll keep seeing lots of churn because of the interaction between
every project being built on towers of third party code with far-reaching
effects.

When Java, for instance, was released, the standard library it shipped with
included: \- a set of standard container classes: hashes, vectors, arrays,
etc. \- a rich set of real types (e.g. numbers that weren't insane, Objects
for compatibility with the object system, primitive types in the language for
performance) \- a whole tree of calendar/date manipulation code \- a standard
way of connecting to SQL databases and all the code for that \- a standard
GUI-drawing and event-handling system \- a big, rich set of APIs for handling
IO of various kinds with different performance/complexity tradeoffs. \- a
concurrency api, threadpools, etc.

That's just a sample. And all of the bits worked together, and sort of implied
patterns in how things should be built and used.

You could certainly replace anything, should you choose to, in your project
(e.g. the calendar stuff really sucked), but the point is, there was a
default, and there was a standard pattern for where and how to bring in new
library code, and that new library code would in turn be built on as little
third-party code as possible.

Look at an average iOS project's Podfile or Carthage file, Android project's
Gradle file, and then look at a Node or browser js project's package.json.
Then actually look in Pods and node_modules. The average amount of third party
libs in a JS project is many orders of magnitude higher than in the others.

There are like, what, five or so competing implementations of Promises in
javascript land? And they aren't mutually compatible always, so this means if
you want to use non-ES6 babel-compiled Promises in your code, you have to: \-
choose a library \- hope that other libraries and frameworks you use use the
same style \- add shims or something where they don't, or else switch out the
library and framework.

This is just like...no one writing an Android app is like "which Runnables
library are you using?". No one writing an iOS app is like "soo...the new GCD
spec looks interesting, which GCD lib are you using for your project? Oh yeah
how spec-complete is it? Does it work with AFNetworking?"

"Lodash makes JavaScript easier by taking the hassle out of working with
arrays, numbers, objects, strings, etc. Lodash’s modular methods are great
for:

Iterating arrays, objects, & strings"

Iterating arrays, objects, & strings is something that most other languages
have decent std lib support for, and so even your third-party libs will use
the host language's affordances. In Javascript you have to ask these questions
all the time.

------
tolmasky
My theory, which I think goes fairly against what others will say here, is
that JavaScript/Node is the first truly post-internet environments to reach
critical mass. By post-internet I mean they consider _sharing_ and open source
as foundational to the environment (as opposed to tacked on later, or merely
supported).

The "JavaScript standard library" (or lack thereof) is a clear example of
this: NPM is the LARGEST collection of packages of any language, and you can
almost always find someone who has already written what you need most the
time. It _never_ ceases to surprise me. During the Pokemon Go craze I was
curious to play with the protocol: there was already a package to do it. I
wanted to ping my find my iPhone, there's already a package to do that. Its
incredible. And yet the actual _built in_ standard library is notoriously
lacking. Although not by design, certainly the end result is that that has
become "OK" thanks to NPM.

Compare this to something like AppKit (and UIKit), which were very much in the
pre-internet/sharing mentality: there is one framework everyone has and
becomes experts in and is fairy stable, because its kind of the only thing you
can rely on being around. Sharing code is very difficult, to the point where
just copying and pasting files is still a valid contender.

The explosion of options and the increase in churn is a natural consequence of
this. There are simply more people working on more problems, all encouraged by
an environment where _sharing_ code is a fundamental property. If step 1 of
setting up node is _downloading other people 's random packages_ then it
should be no surprise that step 4 of sharing your own packages will seem
natural. We should expect this to only get faster -- the more people program,
the more crazy ideas will be tried, the more switching there will be. I really
don't understand what the alternative is: arbitrarily choosing frameworks to
be around for a 5 years (a decade?).

We are simply taking the last measure of stability, which was largely governed
by how long it _used_ to take information to disseminate to the entire
community, how long it used to take one controlling body to get their large
waterfall releases out the door, and using that as an arbitrary comparison
point to how long it takes hundred of individuals to release their individual
takes on software. Asking to "stop the churn" is a strange request: there's no
single entity pushing stuff out "too fast", this is the _aggregate_ affect of
all programmers in the node community publishing their ideas. Who are we
asking to slow down exactly? I can understand saying the single case of
Angular 1/2, but the "JavaScript fatigue" people actually feel is due to the
interaction of all the JavaScript projects that each gain and lose popularity.

Unless you believe we're _really close_ to figuring this whole "software
development" thing out (whatever that means), I wholeheartedly believe that
programming 20 years from now will look more like this -- _faster_ pace of
developments.

~~~
inimino
"post-" usually means after, so I initially thought you were saying the
internet is over. Maybe you could say "internet native" or something. I don't
think it's true, by the way (the CPAN folks would have a word with you, just
to mention one that comes to mind).

In response to your point, eventually, most of us who build software just want
to use tools we know to get things done. There's a tremendous benefit to
having few and highly trusted dependencies. Imagine civil engineering if every
week there was a new flavor of concrete with different construction methods
and structural properties.

Not too many people with a decade or more of development experience think that
"downloading other people's random packages" is a fantastic or a confidence-
inspiring idea. Ideally, those line-of-business CRUD apps that the modern
world runs on should be write-and-forget, not rewritten continuously. This is
why "churn" is a bad word to some. And yes, writing CRUD apps is pretty much
solved, that is, it hasn't gotten _that_ much more efficient in the last ten
years if you look at the best tools.

------
douche
It's because JS is, at it's core, a shit language. All of this flailing around
and creating a new framework every week is like the poor sods trying to
struggle through the mud at Passchendaele. The more you fight it, the deeper
it gets.

Better languages have sensible defaults, and a decent standard library built
in. If we could run Python or Java natively in the browser, nobody would
bother with all of this illogical complexity that has arisen to try to make
writing Javascript moderately tolerable.

------
k__
Because, finally all big players are in the game and Javaize the stuff.

------
RFVenter
It's all hype and fads. People re-inventing the wheel to make money.

