As standards of web applications are always in flux, so too does the complexity of the technology needed to develop web applications. Things that currently work should be left alone. It’s completely unreasonable to reinvent the wheel for such sophisticated techniques and technologies therein. That’s why using frameworks endorsed by thousands of developers around the world is a very sensible approach for building rich and interactive web applications.

Frameworks have become an essential part of web development and the numbers are rising at an increasing rate. These in the main, help developers focus on their application's core functionalities while routine procedures and processes are handled by the frameworks employed. In the main, a web app is comprised of a back end (server-side) and a front-end (client-side).

A historical perspective

Back in the early days of the internet, websites were essentially made of static HTML files. Web servers were little more than file servers. A user would enter the URL or path of the resource they are after and the webserver would simply fetch and send it to the user via their browser, along with a myriad of other assets, like fonts and images, etc

The functionality of these web pages was extremely limited. Thus, more efforts were put in by various bodies and institutions to make it more dynamic. This eventually happened - when people visit a page or interact with a form, instead of just fetching data, the server would perform an operation and prepare some content on demand. That content would still be sent to the user’s browser. There, they will be a little bit of code running on the browser, to animate pages, handle form requests, but not very much else.

So up until around 2013, that was the dominant model. Code could be involved to generate content, but the browser would not do much, most of the logic will happen on servers that would just send prepared content to the browser.

However, in the early 2014s, this paradigm started to shift. With the new specification of HTML5/CSS3 from W3C (The World Wide Web Consortium is the main international standards organization for the World Wide Web. Founded in 1994), the browser became much more capable, and so people started to move the logic that would generate content from the server to the browser. Instead of sending a whole styled HTML page, a web server could just send the data needed to create it. Then, code could run on the browser to actually turn that data into HTML. That browser code could also update what the user would see, making just the required data calls.

So, in the early to mid 2014s, front-end code would typically render complex web pages from data retrieved from the back end, simulate “navigation” between different views when the user performs some actions, the entire page would change, the URL would update, etc. but more importantly, without loading a new page from the server. Maintaining the state of an application while content within could be altered and updated instantly was epic. The application could track certain things about the user and the session and won’t have to reload that information from the server all the time.

Dynamically update both contents and style of a web page

Now, all of this is possible to do in “vanilla JavaScript”. But it’s cumbersome to implement and especially tricky to do it in a performant way. There are millions and millions of “web apps” that are replacing the static “websites” of old, and which all need to dynamically render content. Should developers reimplement that from scratch each time?

Enter the web frameworks such as React, Vue and Angular. These frameworks are abstractions that let the developers focus on the logic of their web app (where the data comes from, how content is organized) without being tied to the nitty-gritty. Web frameworks make developers organize their code in building blocks called modules or components. Somebody could write a header component and someone else building a page could reuse that header component.

Following on from the aforementioned, a third developer could change the header component, and that change would be reflected everywhere the component is used. Folks could also build third-party libraries compatible with the web framework ecosystem, which would address common problems that many developers face. For instance, someone could create a date picker component (a notably tricky interface) that anyone can reuse and customize. Or create a solution to deal with exceptionally long pages by only rendering what is in the browser viewport and creating/deleting elements as a user scroll down the page.

To have the support of this ecosystem is a huge productivity boost. There are millions of developers who work with these frameworks, and the most popular libraries are very elegant solutions to some awfully hard problems developers encounter. There is though, a recent trend to going back to vanilla JavaScript - still just a trickle.