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!?
Why are they so many distros of Linux?<p>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!
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!?
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 <i>did not include an opinionated and standard GUI library</i>.<p>Compare that to how Java and C# gestated internally <i>for years</i> 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).<p>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.<p>Javascript is so barebones that people made frameworks for:<p>- manipulating DOM elements (e.g. JQuery, etc)<p>- simulating classes & objects<p>- calculating dates (e.g. Momentjs)<p>- UI and state flow (Vue, React, Angular, etc)<p>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 <i>multiple people reinvent</i>. Another famous example of Javascript's small standard library is not having a builtin leftpad().<p>[0] <a href="https://www.google.com/search?q=javascript+Brendan+Eich+10+days" rel="nofollow">https://www.google.com/search?q=javascript+Brendan+Eich+10+d...</a><p>[1] picture those variations in Stackoverflow answers <i>leading to different not-invented-here Javascript datetime libraries</i>:
<a href="https://stackoverflow.com/questions/3224834/get-difference-between-2-dates-in-javascript" rel="nofollow">https://stackoverflow.com/questions/3224834/get-difference-b...</a>
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.<p>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.<p>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.
God, Javascript can be such a train-wreck though.<p>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.<p>I spent more time debugging than actually building / updating the website. lol
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...
"Every developer is trying to pull the market share towards themselves."<p>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...)<p>Second fight was among the programming language preferences that people adopted. (php/java/la la)<p>Third fight was between the backend and front end developers. Front end developers raced forward. (zzzzp)<p>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.<p>Now, there is a fight between browser vendors and a race among the front end developers.<p>A fight who will win market share in browser usage and A fight who will gain most of the stars in the github.<p>Backend developers just sit back with popcorn and enjoying the circus show.
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.<p>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.<p>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.<p>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.<p>Frameworks should then only be interface managers, not implemented conglomerates of fat "helpers".
There are two parts to the equation. Why do people create them? Why do people start using them?<p>The first question has been answered nicely by many other people.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.
The nature of the javascript type system means that large software systems written in it are built on very shaky foundations.<p>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.<p>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.<p>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.<p>And, a large part of it is simply that javascript is an incredibly popular (possibly <i>the</i> most popular) language.<p>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've thought about this a lot as well and here's my humble opinion.<p>1) Writing frameworks in languages like C++ is hard. So you would expect to see fewer frameworks.<p>2) When a language is popular, like JavaScript, you get a lot of activity. (Notice the lack of new COBOL frameworks on Hacker News).<p>3) JavaScript can be fixed with polyfills, frameworks, monkey-patching, etc. So we fix the language until that fix is part of the language.<p>4) JavaScript is almost perfect for writing web clients and servers, and we're all trying to fix that 'almost' part.<p>5) Ego is part of it - you have to engage in some level of promotion (otherwise you can't cut through the noise).<p>6) It's fun. It amazes me what I can do with JavaScript some times. I wouldn't mind doing that all day.
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.
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
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.
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.
A Framework Author's Case Against Frameworks: <a href="https://www.youtube.com/watch?v=k7n2xnOiWI8" rel="nofollow">https://www.youtube.com/watch?v=k7n2xnOiWI8</a>
Unlike many pieces of software the shortcomings of JavaScript frameworks are obvious and numerous. Frankly they aren't very good.<p>Large numbers of people using them are going to think "I could do better myself" and some of them actually do.
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.