
Why are there so many JavaScript frameworks? - brzoapp
It’s like each region of the world has a preference on JavaScript frameworks. Do we really such have different requirements that there need to be so many!?
======
mikece
Why are they so many distros of Linux?

It's a feature of open source. You don't like how something is done in
framework X or you have an idea for building something useful/productive/cool,
go ahead and do it. Separating JavaScript frameworks from Linux though is that
everyone online uses a browser, and therefore, uses JavaScript. To say it's
popular is an understatement; companies invest a lot in their JavaScript
projects and ecosystems, and if you can create a differentiation or
competitive advantage by creating/modifying/forking your own thing... then why
not? The best ideas get combined in the end and fold back into the overall
ecosystem so let a thousand frameworks bloom!

~~~
smacktoward
_> It's a feature of open source._

There are lots of open source languages out there that haven't displayed this
pattern. After their initial burst of frameworks, most FOSS language
communities ended up coalescing around one or two -- Ruby around Rails, Python
around Django (and to a lesser extent, Flask), PHP around Symfony and Laravel,
etc.

------
syntheticcdo
Conversely, why are there so many back-end programming languages? C#? Java?
ColdFusion? PHP? Node? Rust? C++? Ruby? Python? Do we really such have
different requirements that there need to be so many!?

~~~
sloum
Really the idea of "backend" and "frontend" is a web phenomenon that does not
really have the same equivalency in other spaces. MANY of the languages you
mention were not developed for use in the web space and have had libraries
built to support their use in that space: C++, Rust, Python, Java, Ruby (?)
all fall into this camp. Yes, they can be used for web stuff, but it is not
their primary purpose (unlike PHP, JS/Node, etc). As a result I do not find
this counterpoint to have a lot of meaning in the context of the question.
Though, why are there so many programming languages is an interesting question
in its own right.

------
jasode
Javascript language was originally written in ~10 days by Brendan Eich[0]. The
limited time meant that it was a bare bones primitive language that _did not
include an opinionated and standard GUI library_.

Compare that to how Java and C# gestated internally _for years_ at Sun and
Microsoft before the v1.0 of the respective languages were released. With more
development time, they included a bigger standard library. Java has AWT (and
then Swing), and C# had WinForms (and then WPF).

Yes, one could argue that Java and C# also have "UI frameworks" on top of
their base GUI technology but it's nowhere near the same chaotic degree as
Javascript's landscape.

Javascript is so barebones that people made frameworks for:

\- manipulating DOM elements (e.g. JQuery, etc)

\- simulating classes & objects

\- calculating dates (e.g. Momentjs)

\- UI and state flow (Vue, React, Angular, etc)

In Java/C#, you can subtract 2 dates in using their standard library of
datetime functions. Javascript can't do that easily[1] and programmers end up
rummaging through github repos and/or npm for libraries that _multiple people
reinvent_. Another famous example of Javascript's small standard library is
not having a builtin leftpad().

[0]
[https://www.google.com/search?q=javascript+Brendan+Eich+10+d...](https://www.google.com/search?q=javascript+Brendan+Eich+10+days)

[1] picture those variations in Stackoverflow answers _leading to different
not-invented-here Javascript datetime libraries_ :
[https://stackoverflow.com/questions/3224834/get-
difference-b...](https://stackoverflow.com/questions/3224834/get-difference-
between-2-dates-in-javascript)

~~~
barberousse
Javascript was never designed with the intent of ever being anything like Java
is terms of reach and magnitude though, that's a hindsight thing.

~~~
jasode
_> Javascript was never designed with the intent of ever being anything like
Java_

I agree.[0]

I'm not criticizing Javascript nor Brendan Eich but trying to state why
Javascript's particular _history of minimal built-in capabilities_ has a
ripple effect of motivating lots of bespoke frameworks.

In a similar vein, the early C++ language didn't have a very extensive string
manipulation library. So what happens? _Different C++ programmers wrote their
own little custom string libraries_. E.g. Qt QString functions are different
from Microsofts MFC CString. Take that example of code diversity and multiply
it by 1000x for Javascript.

[0] _" The by-design purpose of JavaScript was to make the monkey dance when
you moused over it."_ \-- from
[https://softwareengineering.stackexchange.com/a/221658](https://softwareengineering.stackexchange.com/a/221658)

~~~
barberousse
Understood

------
brightball
Because the language already does everything it needs to do for the space that
it's in, which makes it easy to create frameworks that are little more than
moving things around and/or defining rules for how to structure things.

You see this in Javascript and PHP where there are tons of frameworks because
the language already has so much built in for the problem space.

Other languages that aren't designed to be web native, general purpose
languages, tend to rally around frameworks geared towards opening that problem
space to the language.

------
bananatron
Barrier to entry is low and the web is big (with many problems to solve).

------
torgian
God, Javascript can be such a train-wreck though.

Frameworks break all the time when people want something updated. For example,
updating a website from an old version of Middleman to the latest, while also
using Webpack 3 (but can't use Webpack 4 because that further breaks things)
and also use a theme that is difficult to work with both middleman and
Webpack.

I spent more time debugging than actually building / updating the website. lol

------
throwaway66666
Javascript framework makers are the new rockstars. People want to be
rockstars.

~~~
scranglis
Not sure why this is being downvoted, it is at least a top two explanation for
this phenomenon.

~~~
throwaway66666
Because it comes off as snarky and provides little value I would guess.

I would say that due to jQuery's explosion, framework writers went from geeky
technical people to being looked at as heroes. Back in 2007 there was actually
a big javascript framework war between jQuery and MooTools. Technical blogs
left and right on why jquery is bad, or why mootools ecosystem sucks. It was
weird to behold. I don't think I have seen in any other community such
rivalry. Even later, when angular vs react vs ember became a thing, people had
overly heated arguments about them. That's so odd. In the non-js world, people
usually welcome the new approaches provided by new frameworks or question the
usefulness of yet another new framework - and it stops there. I suppose
framework writers are not rockstars in those communities :)

------
mti27
I think a lot of people just get excited about code for code's sake (vs code
as a means to deliver a product) and get creative... It's not really a
problem, unless your company culture sets up a natural conflict by highly
valuing both knowing the latest shiny frameworks and also providing
manufacturing-style time estimates to complete work...

------
imvetri
"Every developer is trying to pull the market share towards themselves."

The first fight was between the closed source and the open community. Open
community went blazing fast when compared to big corporates for web
application builders. (visual basic/ oracle products / SAP builders...)

Second fight was among the programming language preferences that people
adopted. (php/java/la la)

Third fight was between the backend and front end developers. Front end
developers raced forward. (zzzzp)

Browser vendors started providing features that front end developers could use
and need not rely on backend. Front end developers are playing the fight game
effortlessly.

Now, there is a fight between browser vendors and a race among the front end
developers.

A fight who will win market share in browser usage and A fight who will gain
most of the stars in the github.

Backend developers just sit back with popcorn and enjoying the circus show.

~~~
x0x0
The one thing I think you forgot is good design is derivative of fundamental
language decisions, and people took a while to figure out what was is good
design for js. And then that was further reset by improvements driven by v8 in
what designs are performant.

------
tabtab
I'd like to see a move toward mini-kits instead of frameworks. The problem
with frameworks is you are dealing with a dark-grey box. If the components
work, everything is great. If they don't, you have to either fiddle a lot to
find a work-around, or read and debug thousands of lines of framework code.

For example, a "routing engine" to translate URL's into specific
function/method calls doesn't have to be rocket science for smaller
applications, yet they are rocket science (thousands of lines of code) in many
frameworks. Come up with a standard interface for routing engines and let me
choose which implementation best matches our org rather than have to use the
thousand+ lines of code version.

You have a choice: bicycle science, car science, and rocket science versions.
A large org or special domain may need the rocket science routing engine,
that's fine, but don't force all framework users to use the rocket science
one. If I use the bicycle-science router, I can read it and fix or customize
it quickly.

ORM's, HTML templating engines, field managers (models), can all also be
interface-itized this way, and ship with or offer 3 levels: bicycle, car, and
rocket.

Frameworks should then only be interface managers, not implemented
conglomerates of fat "helpers".

~~~
andrewnc
You might be interested in svelte.dev it's a JavaScript mini-framework of
sorts.

I'd consider it more of a library, but it's quite nice.

------
o_____________o
Because Javascript runs the web, which is huge.

~~~
futureastronaut
We have a winner. There are so many JavaScript libraries and frameworks
because there's so much JavaScript being written. It has nothing to do with
anything about the language, apart from perhaps the thin standard library.

~~~
sli
I'd be willing to bet that a massive number of frameworks, especially the
smaller ones, start out as something a dev writes for themselves to use in an
app, then just decides to release it because why not. That's a good bit
different from (and a lot more realistic than) concerted efforts to just pump
out new frameworks in isolation just because.

I generally see the whole "framework paralysis" as being fairly artificial and
more just a convenient complaint to make. React/Angular/Vue have the
enterprise space pretty well covered and you'd be more or less fine just
picking one of those by throwing darts at a dartboard, unless you already have
a preference for paradigm or style, in which case just pick the one that fits.
These things are mature, after all. And the first two are backed by companies
with huge vested interests in the frameworks being good, as they presumably
dogfood them to hell and back.

Beyond that, I feel it matters much less what you use. But still, the general
idea of just picking the one that best matches how you think about writing an
app is still workable advice. It isn't like you _have_ to look into every
single framework ever, you just check out ten or so major ones.

------
kangnkodos
There are two parts to the equation. Why do people create them? Why do people
start using them?

The first question has been answered nicely by many other people.

To answer the second question, I think you need to consider the people who are
trying to make a living from open source software. The teachers, bloggers,
live streamers, book authors (are there still any book authors?). If they
manage to jump on the next big wave early, they can become the established
expert, and this may lead to money. 4 - Profit.

So many new framework will be met by a few early adopters trying to eke out a
living, or maybe make it big. Especially if the new framework promises to
solve an issue present in an existing popular framework. And this is
impportant... All existing frameworks have different drawbacks. There's always
tradeoffs when you design a framework. When you optimize a framework to make X
easier, you almost always make Y harder. I don't think there's any way around
this.

Then, when the average programmer sees many blog posts about a new framework,
they may pick it up, and give it a try. The circle of framework life.

------
AlchemistCamp
There are many reasons. But ultimately, it comes down to incentives.

People who spend hours a day working with a flawed tool have incentives to
find another. I had that experience myself using BackboneJS day in and day out
for over a year. In my own time, I started exploring better alternatives such
as AmpersandJS (which was very similar but handled subviews gracefully). After
discovering React, I saw a further improvement beyond my then local maxima.

People who lead products and hire engineers have incentives to choose
something that will appeal to engineers who are looking for better ways to do
things. It can both allow more hiring competitiveness at any given level of
salary and filter out candidates who don't care about learning or finding
cleaner solutions.

People who create open source software have tremendous incentives to create
something new and grow it. Even if it's not actually better than what it
replaces, being the author of a popular framework carries tremendous career
capital.

------
pytester
The nature of the javascript type system means that large software systems
written in it are built on very shaky foundations.

This means that it's very easy to build a framework but also that it's very
likely for a framework to break and under sustained, real life use cases.

This led to a cycle whereby javascript developers would get excited at the
potential of a new framework, use it IRL and then get disillusioned before
getting excited about another new framework.

I think this also drove the average age of javascript developers down (older
developers were less patient with this pace of change) and this cycle sort of
fed on itself too, as younger developers are more likely to jump on something
new.

And, a large part of it is simply that javascript is an incredibly popular
(possibly _the_ most popular) language.

From what I understand this cycle has kind of come to a halt now and most
people seem to default to react and the type system is getting a little less
train-wreck-y with stuff like typescript.

------
Juzkus
I think in part it's because people just enjoy making them.

------
darcinc
I've thought about this a lot as well and here's my humble opinion.

1) Writing frameworks in languages like C++ is hard. So you would expect to
see fewer frameworks.

2) When a language is popular, like JavaScript, you get a lot of activity.
(Notice the lack of new COBOL frameworks on Hacker News).

3) JavaScript can be fixed with polyfills, frameworks, monkey-patching, etc.
So we fix the language until that fix is part of the language.

4) JavaScript is almost perfect for writing web clients and servers, and we're
all trying to fix that 'almost' part.

5) Ego is part of it - you have to engage in some level of promotion
(otherwise you can't cut through the noise).

6) It's fun. It amazes me what I can do with JavaScript some times. I wouldn't
mind doing that all day.

------
benologist
There are lots of frameworks because there are lots of developers doing
different things in different ways. You don't get to a point where there are
half a dozen solid choices like React, Angular, Vue etc without
experimentation.

------
jacknews
Why are there so many species of beetles?

------
ravenstine
Everyone wants to be the person behind the "next big thing".

------
barberousse
Besides the need to differentiate one's resume creating the supply, the demand
for all these frameworks partially comes from the fact that computer science
education is significantly less standardized amongst front-end developers, so
there's urgency to find solutions that one groks more than one that is
demonstrably more robust, etc

------
caymanjim
Part of it is Not Invented Here Syndrome. That's not always bad. No framework
does everything well, and the ones that come close often have fundamental
architectural limitations. Even the best of them become bloated or outmoded
over time. Once things start being designed by committee, they tend to go
downhill quickly.

------
nicoburns
Because the JavaScript community is HUGE.

------
timwis
That's like asking why do I have so many outfits in my closet. I choose my
JavaScript framework based on what I have going on that day, what sort of mood
I'm in, and how sassy I'm feeling.

------
rodrigopetter
A Framework Author's Case Against Frameworks:
[https://www.youtube.com/watch?v=k7n2xnOiWI8](https://www.youtube.com/watch?v=k7n2xnOiWI8)

------
andraaspar
Because it's so easy to share JavaScript code.

------
gfs78
In part because "other programmers are dorks. I know better"

------
codedrome
Unlike many pieces of software the shortcomings of JavaScript frameworks are
obvious and numerous. Frankly they aren't very good.

Large numbers of people using them are going to think "I could do better
myself" and some of them actually do.

~~~
vorpalhex
A lot of people bill Haskell or OCAML as ideal languages.

But there's a hell of a lot of people, from kids to grandparents, who actually
code in JS.

------
pjmlp
GitHub driven curriculum.

------
notus
There's only a few that are commonly used at most companies, the rest are just
pet projects people made cause they wanted to learn how to make a framework.

