Frontending – A brief history of webdev – Part 1

Intro

Web development has come a long way since the early days of internet. From the first web page created in the early 90s to the dynamic and interactive web applications of today, the evolution of web development has been driven by a constant effort to solve problems and improve user experience. However, the road to modern web development was not without its challenges. In this two-part blog post, we’ll start by taking a look back at the early days of web development and examine the problems that developers faced. By understanding these challenges, we can gain a greater appreciation for the solutions that modern web development provides and better compare the newest offerings on the second part of this series.

First Age

Someone tried to divide by zero and caused the big bang, some fish decided to walk on land, a cow licked some ice, this dude made a ring that makes you invisible, idk, idc. I mean, if there were no computers nor airbenders, is it even worth remembering?

Pre-web-ic Era

Back in 1989 Sir Tim Berners-Lee and his team at CERN had a problem: they needed to create and share scientific stuff, but researchers were using a bunch of proprietary software programs that were not super easy to use, nor cheap. But worst of all, those tools were not communicating properly with each other. This made it difficult to collaborate on projects and access information from other researchers. To solve this they created HTML.

HTML was designed to be a simple markup language that could be used to create documents that could be easily shared and accessed in a technology agnostic way over the network – a big deal at the time. It provided a way to structure text and add links between documents, which made it easier to navigate and explore information on different documents.

The Static-as-Stone Age

The first web page ever made was created by Sir Tim Berners-Lee in 1991. It was a simple page that provided information about the World Wide Web project, which was still in its infancy at the time. The page had the classic plain white background with black text and blue links, which we still know and love from basic unstyled html.

The reason why the first web page was created was to provide a platform for sharing information and resources on the World Wide Web. Sir Tim Berners-Lee envisioned the web as a way for scientists and researchers to share information and collaborate on projects more easily. His goal was to create a decentralized network of information that could be accessed from anywhere in the world.

At this time, HTML was designed to display static content only. This meant that early websites were essentially digital versions of printed documents – there was no way to incorporate dynamic elements like animations, videos, or interactive forms. You could only read what was there, and navigate to another document.

As a result, early web pages relied heavily on hyperlinks to connect different pages and provide users with a way to navigate through the website. While this approach was functional, it could also be frustrating for users who had to constantly click back and forth between pages to find the information they were looking for. Especially since there were no tabs back in the day.

It gets even worse (by our standards), since each HTML page is static if you wanted the same sidebar in multiple pages, you would need to manually code it in every single page. And if you wanted to update it, good look at updating all the pages that used it. There was no such a thing as reusing templates or components. A truly handcrafted work, made by the ancient HTML smiths.

But everything was fine, until someone decided to go a little further.

The Iron Servers Age

The worst part of a static rendered HTML is that once you loaded a page, there was no way to update its content without refreshing the entire page. Plus, if you wanted to include dynamic content like user input, you had to use cumbersome and limited solutions.

This is where server-side rendering came in. Instead of relying on simple HTML files, developers had the genius idea of writing code that would generate the HTML on the fly.
Thus it would be possible to change the HTML (kind of) dynamically between refreshes.
This was the start of server-side scripting languages like PHP that were used to generate HTML dynamically.

With server-side rendering, you could include dynamic content like user input or database queries without having to rely on clunky solutions (refreshing all the time, inserting other pages through iframes, Flash-like libraries, you name it). You could even have different pages rendered for different users, maybe even add their names to the topbar. How awesome is that?

Remember that sidebar that the HTML smiths manually inputted on every page? No more of that, no more typos, no more rework, just call the same function and you always get the same sidebar, truly glorious.

Back then, the cool kids were rendering HTML on the server with tools like PHP. These solutions were lightyears ahead of simple HTML files. Server-side rendering was just plain cool back then!

While this idea of server rendering is no longer the only game in town, keep it in mind, since it’s still an important part of the web development toolkit.

The Classical Javascriptic Era

Ah, the mid-90s. Some would call it the golden age of web development. While server-side rendering was revolutionizing the way the incas and mayans built web applications, another technology was starting to emerge: JavaScript.
JavaScript, as you may know, is a client-side scripting language that allows developers to create dynamic, interactive web applications. But back in the mid-90s, JavaScript was still in its early days. In fact, it wasn’t until 1995 that the first version of JavaScript was released.
And it changed the game in a big way. It was like the missing puzzle piece that unlocked the potential of the web, and users experienced a number of benefits as a result.

One of the biggest changes that JavaScript brought to the table was interactivity. Prior to it, web pages were (mostly) static, with limited interactivity and no ability to respond to user actions without a full page reload – as we discussed, I hope you were paying attention. But with the introduction of JavaScript, web developers suddenly had the ability to add interactive features like animations, form validation, and dynamic content updates, all without requiring a page reload.

The result was a more engaging and dynamic web experience for users. Instead of passively scrolling through a static web page, users could now interact with elements on the page, trigger animations, and receive real-time feedback. For example, imagine filling out a form on a web page and seeing instant feedback on whether your input was valid or not? Absolutely insanely amazing next-level stuff, by the standards of the time.

But with great powers comes great complexity. Javascript opened up a whole new world of possibilities (and problems that didn’t exist before – stares intensely at XSS attacks) for web-based software. It’s no exaggeration to say that JavaScript has transformed the way we think about web development.

The Middle Javascriptic Ages

Ah, the middle ages, when Javascript became synonymous with jQuery and Ajax – two classical tools in the web development world that have made our lives much different! Let’s take a closer look at what they are and why they were so popular.

jQuery is a JavaScript library that was created in 2006 by John Resig. It was designed to simplify common web development tasks like DOM manipulation, event handling, and AJAX requests. What’s AJAX, you ask? It stands for Asynchronous JavaScript and XML, and it’s a technique for making HTTP requests to a web server without requiring a full page reload.

So, why was jQuery so popular? For starters, it made web development a lot easier and more efficient. With jQuery, developers could write less code to accomplish more, and they could do it more quickly. This was especially true for common tasks like event handling and DOM manipulation, which could be done with just a few lines of jQuery code.

Keep in mind that at this time most of the built-in DOM manipulations and selectors we enjoy today were not available. Their creation and necessity was heavily inspired by the way developers interacted with jQuery itself. One could say that jQuery helped to shape native javascript as it is today.

Another reason for jQuery’s popularity was its cross-browser compatibility. In the early days of the web, different browsers had different implementations of JavaScript and DOM, which could make developing for the web a bit of a headache. But jQuery abstracted away those differences, making it easy to write code that would work across all major browsers.

Now, let’s talk about AJAX. As I mentioned earlier, AJAX is a technique for making HTTP requests to a web server without requiring a full page reload. This means that data can be loaded and displayed on a web page without the user having to wait for a full page refresh. This was a big deal, as it allowed for a more seamless and responsive web experience.

But AJAX was not without its challenges. Writing AJAX code by hand could be a bit of a pain, especially when it comes to handling errors and managing asynchronous callbacks. That’s where jQuery’s AJAX functionality came in. With jQuery, making AJAX requests was as simple as calling a few functions, and the library handled all of the messy details like error handling and callbacks.

Overall, those were two game-changing tools in the world of web development. They simplified common tasks, abstracted away browser differences, and paved the way for a more dynamic and responsive web.

Early Modern single page Application Era

Ah, single-page applications – or SPAs for short – another fascinating development in the world of web development. So, what are they, and why are they so popular? Let’s dive in!

A single-page application is a web application that operates within a single web page. Some madman thought to himself:

“Now that we have all this javascript, why do we even need pages? Why can’t we load an initial blank page and just continuously update things on the same page?”

“Why would we do that? Because we can! We just need a framework to make this process easier.”

For users, SPAs offer a more seamless and responsive experience, with faster load times, fewer page refreshes, and better overall performance. For developers, SPAs offer a more modular and flexible development experience, with easier code maintenance, better testing capabilities, and the ability to reuse code across multiple applications. SPAs allowed web applications to become more complex and more seamless.

The first SPA frameworks started to emerge in the early 2010s, with Backbone.js and Ember.js being two of the earliest examples. These frameworks provided developers with the tools they needed to build complex SPAs, with features like two-way data binding, routing, and event handling. But it was AngularJS (now known just as Angular), released by Google in 2010, that really brought SPAs into the mainstream.

AngularJS was a game-changer for web development, allowing developers to build complex SPAs with relative ease.

After AngularJS came out, a bunch of other cool kids popped up on the scene, like React and Vue.js. They took what AngularJS did and made it even better. For example, React, created by Facebook in 2013, is lighter and more flexible than its predecessor. Plus, it introduced the concept of a virtual DOM, which lets you update the user interface in real-time without refreshing the entire page. And it’s component-based, which means you can build complex apps by breaking them down into smaller, reusable components. Nice, right?

Vue.js, which came out in 2014, is similar to React but with its own flair. It’s often called a “progressive” framework because it can be used for both small and large applications. Plus, it’s easier to learn than React or AngularJS, which is a big plus for anyone who doesn’t want to spend weeks studying. With Vue.js, you get a simpler syntax and a smaller learning curve.

First Industrial Server Revolution

So…
Remember that old approach of rendering stuff on the server instead of using SPAs?
Well SPAs run the JS on the user Browser, so they are way cheaper and way faster after the initial JS is loaded. So we didn’t need those servers.

But the servers are so cool that we brought them back. Server side-rendering (SSR) FTW.

So, why did SSR become so popular all of a sudden? There are a few reasons for this.

Firstly, SSR provides better performance and SEO. With CSR, the entire application is loaded onto the client’s browser, which can lead to slow initial page load times, especially on mobile devices or slower internet connections – although after the initial load the page is super fast. With SSR, the server sends back a fully-rendered HTML page to the client, which means the initial load time is faster. In a world where the attention span is trending towards the length of a Tik-Tok this is a huge win.

Furthermore, since SPAs initially start with an empty page and change it over time, search engines can have trouble parsing it. This is not true for SSR where crawlers can easily parse and index the page content. This results in better SEO, as search engines can understand the page content more easily, which can lead to higher search engine rankings.

Lastly, SSR is more secure. Since the server is responsible for rendering the page, it can perform security checks and sanitization before sending the content to the client’s browser. This can help prevent security vulnerabilities such as cross-site scripting (XSS) attacks.

But why now is the moment that SSR rises from the grave? Well, it boils down to supporting infrastructure. With the modern cloud providers such as AWS, GCP, Azure, Oracle and with even more cloud resellers such as Vercel, Netlify, Firebase, and others, it became increasingly easy to deploy and manage servers. Coupled with several improvements on CDNs, serverless functions, edge computing, and overall global improvements on internet standards, we can see that most of the issues and drawbacks caused by having and maintaining servers are greatly mitigated.

The cherry on top was that another cool thing about both Angular (not AngularJS anymore) React and Vue.js is that they’re not just for SPAs (single page applications). They also brought server-side rendering and other optimizations, mostly through their metaframeworks – mainly Angular Universal, Next.JS and NuxtJS.

This all combined created the perfect situation for SSR reborn.

Framework Wars I

With all that happening, it was an exciting time for web developers, but also a confusing one. As we saw, after Angular, a number of other frameworks emerged, each with their own strengths and weaknesses.

This created the “war” between JavaScript frameworks.

Smaller frameworks, like Ember, Backbone, Knockout, CanJS, Aurelia and Durandal that gained popularity in the years of AngularJS, quickly succumbed to the pressure of bigger players. They eventually lost ground to React and Vue, which emerged as the two most popular JavaScript frameworks while AngularJS became Angular (we don’t talk about angular 2.x).

React, which was developed by Facebook, was one of the first frameworks to challenge Angular’s dominance. Taking a different approach to building web applications, using a virtual DOM to improve performance and make it easier to build complex user interfaces. React quickly gained popularity, and today it’s one of the most widely-used JavaScript frameworks out there.

Vue took a more lightweight approach to building web applications, making it easy to integrate with existing projects and codebases. Vue also gained a lot of popularity, especially in Asia, and today it’s a popular choice for building modern web applications.

Those three emerged as the strongest players in the “war” between JavaScript frameworks. But ultimately, a choice between them comes down to personal preference and the needs of your specific project.

In the end, the “war” between JavaScript frameworks was a testament to the innovation and creativity of the web development community. Some people say that, to this day, a new Javascript framework is born every other week. While some frameworks emerged as winners and others fell by the wayside, the competition helped push the boundaries of what was possible with JavaScript and helped make the web a more dynamic and interactive place.

The Great Javascriptic Depression

After the initial “war” the survivors were mostly by Angular React and Vue.
For a few years, these three frameworks dominated the space, with developers relying on them to build a wide range of web applications. But then something interesting happened: for a while, we didn’t see many new frameworks emerge. It was like everyone was content to just keep using those and not mess with a good thing. The “war” became more like a cold dispute between who was the best between those three heavy-hitters.

Maybe developers were just happy with what they had and didn’t want to rock the boat. Or maybe they were hesitant to embrace new technologies until they had been proven to be reliable and effective.

But as with any fast-moving field, things eventually began to shift. In the shadows, gathering forces to challenge the status-quo, some innovative projects started to rumble. After all, those three old favorites started to show their ages. They have been comfortable for too long, they have become complacent, they are slow to move, two of them are commanded by tech behemoths.

Peace was never an option, it was just a prelude to a bigger storm.

We are starting to see things changing. It already started in the base tools of web development.
Webpack has lost its ground to Vite.

Sass is challenged by PostCSS.
Bootstrap is going down and Tailwind is sailing high.

NPM is all but replaced by PNPM.
Node has competition in Deno and Bun.
The base structures of the old-age are changing, the very ground where web-dev stood is shifting.

The competition is starting to leave the shadows, slowly but surely the Monsoon is going away.
We are heading to the:

Framework Wars II (current)

So why did it take a few years for new frameworks to emerge after Angular, React and Vue took over the world?

Which are the frameworks that are rising? What do they improve upon?

We will explore these questions and compare those frameworks in the Part II (and final) of this series.

Credits

Written by Lucas Ferreira

‍