Why are there so many JavaScript frameworks?
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!?
45 comments
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!?
We shouldn't compare creation of languages to frameworks. If you look at back end frameworks, like web MVCs or ORMs, each language usually only has one or two major players.
I think it's less about requirements driving the existence of languages and more about the audience - C# as a clear example of Microsoft ensuring its developers are upgrading to a technology that favors them instead of switching to Java.
Not to say requirements don't play a part - Python exists because of Math/prototyping requirements of people that don't want to worry about memory or complex syntax (generics, etc..)
Not to say requirements don't play a part - Python exists because of Math/prototyping requirements of people that don't want to worry about memory or complex syntax (generics, etc..)
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.
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...
[1] picture those variations in Stackoverflow answers leading to different not-invented-here Javascript datetime libraries: https://stackoverflow.com/questions/3224834/get-difference-b...
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...
[1] picture those variations in Stackoverflow answers leading to different not-invented-here Javascript datetime libraries: https://stackoverflow.com/questions/3224834/get-difference-b...
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.
>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
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
Understood
In the early days Java also had 3rd party UI libraries/tools from people like Marimba.
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.
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.
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.
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.
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.
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.
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
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.
I think in part it's because people just enjoy making them.
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!
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!
> 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.
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.
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.
Because it's so easy to share JavaScript code.
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.
Large numbers of people using them are going to think "I could do better myself" and some of them actually do.
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.
But there's a hell of a lot of people, from kids to grandparents, who actually code in JS.
Because Javascript runs the web, which is huge.
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.
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.
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.
Barrier to entry is low and the web is big (with many problems to solve).
Why are there so many species of beetles?
Javascript framework makers are the new rockstars. People want to be rockstars.
Not sure why this is being downvoted, it is at least a top two explanation for this phenomenon.
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 :)
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 :)
Everyone wants to be the person behind the "next big thing".
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.
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.
GitHub driven curriculum.
A Framework Author's Case Against Frameworks: https://www.youtube.com/watch?v=k7n2xnOiWI8
In part because "other programmers are dorks. I know better"
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.
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.
"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.
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.
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.
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...
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.
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.
Because the JavaScript community is HUGE.
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".
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".
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.
I'd consider it more of a library, but it's quite nice.
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
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