Why are there so many frameworks for web development? [closed]

UPDATE: This answer refers to the original un-edited and ambiguous question, so is based on an interpretation about the use of different frameworks for different aspects of web development; it doesn't address the use frameworks which compete against each other in the same space.

Given the substantial rewording, this answer may no longer be a good fit for the question, however its content remains mostly un-edited on the basis that it relates closely enough to the topic and is hopefully still useful and relevant to other readers.

How the web works

In a nutshell, the web is built around the concept of web servers which serve data and content in response to inbound HTTP requests, and web browsers which send HTTP requests to a web server in order to obtain data and content from an HTTP response.

Furthermore, HTTP is Connectionless. That means that the web browser does not hold any kind of connection or socket with a web server. Browsers know nothing about web servers. Web servers know nothing about Browsers. The two act completely independently of each other.

A browser typically expects a response when it sends a request but it has no idea what is listening at the URL it has sent the request to.

A server receiving a request has no idea what sent that request - it just picks up that request, sends back a response, and then forgets about the request altogether.

That naturally means you always have two problems to solve - what happens in the web browser and what happens on the web server.

Web Server technologies

In the early days of the web, nearly all web content was just plain static HTML - usually a mix of text and images and not much else. Web development tended to mean just churning out loads of static HTML documents which were stored in a folder structure, hosted on a simple HTTP server.

Most modern, sophisticated web apps do not do this. Servers rarely store plain static HTML pages any more; content tends to be generated on-the-fly. If that content is to be generated on the server, then you'd either use a Content Management System like WordPress, or write a web service using a framework like Django or Flask.

If you're writing a web server, any code which runs on that server generally has the full capabilities of languages like Python at its disposal, as long as the server itself has permissions (e.g. talking to a database, accessing the server filesystem, accessing network resources, etc.)

Client-side technologies

HTML does not need to be generated on the server. It can be generated within the browser instead. Most sophisticated web apps have advanced, dynamic, programmatic behaviour running directly within the browser itself.

However, a browser is not a run-time environment. Therefore a web browser cannot use languages like Python, Java or C# to build dynamic UI behaviour.

A browser is just an application which happens to have a built-in scripting engine; the capabilities of web browser scripting are limited to being able to work with web content displayed in the browser (real time creation/manipulation of HTML elements), to be able to work with events and user inputs in real-time, and to be able to work with HTTP requests/responses.

So to build dynamic behaviour which runs within the browser, you need ECMAScript (formerly known as JavaScript). However, just as modern Desktop/Mobile GUI frameworks in C#/Java exist for helping developers write GUI apps (along with patterns like MVC and MVVM), the same thing exists with client-side frameworks like Angular and Vue.

These frameworks solve the same problem for web developers that GUI frameworks solved for Windows/*Nix desktop developers 15-20 years ago; providing high-level abstractions for web developers to build the rich, interactive, dynamic behaviour which actually runs within the user's browser. Otherwise, you'd be faced with direct, "low-level" manipulation of raw HTML elements using ECMAScript instead (which is fine if you just want to do something very simple, but for sophisticated web apps it's very difficult)

Aesthetics

The content for most websites/apps often has very sleek, stylish aesthetics. Unless you want your websites to look like they belong in 1995, you should avoid the default styles.

However, unless you wish to spend a great deal of time designing your own look/feel aesthetics with raw CSS and getting it to work consistently with lots of different browsers/devices, you are much better off using a simple CSS framework like Bootstrap which can give you a neat/clean/modern/sleek look-and-feel with minimal effort and without needing to spend very much time at all learning how to do it.

Why Use Frameworks

Different frameworks exist to solve different problems and work with different aspects of the web. There is no requirement to use any framework, but modern web development has moved a long way beyond plain old JavaScript and static HTML pages with Times New Roman fonts.

Ultimately they exist because people expect their experience to be far more sophisticated and to look/feel a lot better than it did 20+ years ago, and because trying to build a web app which meets peoples' expectations will either involve using something like WordPress (which involves minimal technical expertise), or it involves using those frameworks.

Web development is the use of different frameworks.

You could, if you want, write web application without any framework at all. You can, for instance, use Common Gateway Interface (CGI) on server-side, and plain JavaScript on client side, and this will bring you two benefits:

• You won't have any dependency.
• You will have to have a good grasp of HTTP protocol.

On the other hand, this has a major drawback:

• You won't be able to develop large applications quickly enough.

Frameworks do a good job of abstracting away the complexity of the underlying technologies. HTTP is quite complex. JavaScript is less complex that it used to be a decade ago with all the language quirks and IE's freaking behavior, but still presents a bunch of difficulties, including but not limited to the manipulation of DOM and the [lack of] data binding. With frameworks, you don't need to think about all the low-level stuff most of the time, and so can focus on your project itself.

For instance, imagine you want to send a static file such as a PDF for the user to download, and you need the file to be cached for two hours on client-side. With any decent server-side framework, you do it in a few lines. Without a framework, you'll have to spend a lot of time reading the HTTP specification (and this is not the nicest thing to read!) to understand which HTTP headers should be used, how values should be encoded, etc. Usually, you don't want to spend time doing that (well, maybe you do, but most developers don't and are not paid for that).

This doesn't mean you should know dozens of frameworks. Chose one for server side (you've chosen Flask; that's great!), and one for client side (Angular and React are fine, but if you want to go low level, jQuery is still a viable alternative, although it is not a framework per se). Stick with your choice for a year, and learn those frameworks well enough. Once you understand them, you may find what other frameworks do best.

More importantly, don't do the mistake of so many programmers to jump twice per month to a new framework because it's fashionable. You'll be able to put lots of fancy names in your resume, but it won't get you the real skills or understanding of web development.

You are used to using general purpose languages that can do almost anything with enough effort.

You're reading about domain specific languages / frame works which do a few things well. HTML, JSON, CSS, rails, etc. which all make doing exactly what they do easer. But since that one thing is all they do well it's hard to use only one of them.

You can expect that using anything that does many things will make doing those things harder than if it only did one thing. The only advantage of a general purpose language is you only have to learn it once. That doesn't make it the best choice. That's why the hodge podge has so many languages.

Add that the web has a long fractured history with subverted standards and it's really hard to build a uniform platform that rules them all.

So sorry, you need to learn at least one tool that does each needed job well. Start with learning what each of those jobs are. There is often more than one way to do them. Pick something and learn it.

The other answers here provide some great history and explanation of web design, but do not answer your exact question directly: why are there so many different, competing frameworks?

The answer is because web application development as we know it is basically just around a decade old. The Web Development industry is in its infancy inside the larger software industry, which is itself an infant when compared to pretty much every other industry out there.

Prior to the explosion of the IPhone, there was a legitimate debate in the web development community around whether or not we'd even be using HTML/CSS/JS, or if something like client-side Java or Flash was going to become the default environment for Rich Internet Applications (ie, anything fancier than your blog). So web devs were splitting their time between wrangling HTML/CSS/JS in Internet Explorer, plus learning Flash when they could, and praying that Java applets were still truly dying off. It was a mess, and the server-side world was firmly disconnected from the client-side.

Its easy to forget now in our modern JavaScript based world that prior to Google Maps coming out, no one thought that using JavaScript to develop large interactive applications was a good idea. So even appreciating JavaScript as a robust language has only been a thing since around 2005.

It was around 2008 when the iPhone really started exploding in popularity, and Apple's decision not to support Flash on iOS was, in my opinion, the death knell for Flash. And even then, it took us a few years to truly digest this fact.

So, given that its only been 10-11 years since we, as an industry, decided that HTML/CSS/JS was going to be default stack for web development. So given such a young age, all the various frameworks that are out there represent both our industry trying to figure out, on the fly, the most efficient way of binding server generated results with HTML templates. At first, the thinking was "generate the template chunks on the server and combine them into an HTTP response". This model worked/works well, but back to your core of your question, the reason there's Java/Spring, ASP.NET, RoR, Django, etc etc is because of the fact that different kinds of servers allowed different levels of software to run on them at different pricing structures, there was not a one-size fits all approach at the server language level. Java and .NET were expensive to run, but allowed for very, very broad development. Plus, you can do desktop apps in them as well. PHP was practically free, but slightly limited when comared to them.

With each new year, at the language level, developers were asking "can I bend this older language to suit the web, or should I pick a brand new language designed solely for the web itself?" Since by 2010, 99%+ of web applications were being written in JS/HTML, all the folks who had been doing Flash/Silverlight/Applet had to jump into the HTML mix, and their preferred way of doing things like data binding was not natively available in pure Javascript, so they introduced a pressure inside the web development industry to come up with web frameworks that made the web feel state-full.

The initial frameworks that worked in this way included things like Knockout JS, which was eventually replaced by Angular, which went so deep into doing everything on the client, that a host of alternatives sprouted up for folks who felt that the juice just wasn't worth the squeeze for Angular's complexity. Furthermore, there's so much that you just can't do on the client alone (proper security, encryption, etc), that we are forced to spread the load between client and server and this leads to loads of differing opinions on exactly what functions should be placed on the client and what on the server. And since there's differing opinions here, then different frameworks emerged to solve the problem differently.

Finally, yet another variable got thrown our way in perhaps the last 7-8 years, where the rock solid principle that JavaScript was just for the client side was thrown away via the introduction of Server Side JavaScript. This came from the folks who were frustrated that they had to learn 2 languages minimum to do proper web dev: JS plus a server language. This has led to the modern explosion of Node.js, which has once again forced a paradign choice upon devs.

So in summary, there's about 3 different foundations for web development:

• Mostly server-side non-Javascript code (PHP, ASP.NET, Java, etc)
• Super heavy client-side frameworks (Angular, React, Ember, etc) Pure
• JavaScript hybrids (Node.js, etc)

And inside each foundation above, there's a dozen or more various frameworks/strategies that are differentiated by their pricing, their language, their server requirements, etc. So this is the reason there is not one single framework to rule them all for modern web development.

I think if you really want to learn something, you should start by learning the basics. This is html, css and vanilla javascript.

In this way you wil understand whats happening "under the hood" of any framework and maybe realise you dont need to use a framework for every singel task you are going to do later.

But its very populair to show off how many frameworks your know and it might have a higher value then only knowing the basics of web development (html, css and js) when you are looking for jobs.

I think the best way to learn this would be to create some project for your self as a singel Page app and try to understanf how to load json data, add/remove events and modify the dom.