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!?
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.
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.
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
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 :)
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.
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.
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.
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.
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.
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.
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.
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.