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!?
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!
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.
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.
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 :)
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!?
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..)
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.
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.
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.
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().
>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.
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.
"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 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.
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".
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
45 comments
[ 1.8 ms ] story [ 112 ms ] threadIt'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!
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.
Large numbers of people using them are going to think "I could do better myself" and some of them actually do.
But there's a hell of a lot of people, from kids to grandparents, who actually code in JS.
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 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 :)
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..)
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...
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
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.
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.
Gee I dunno-- "Why do people ask dumb questions?"
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.
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".
I'd consider it more of a library, but it's quite nice.
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