The History of Modern Web Development- – 12 minutes read – HistoryModernWeb Development
Let’s take a dive through 20 years of web development and how it came to be, what earlier techniques inspired the current generation and where we might be heading next.
In the 90s, as the internet was growing in popularity, most web pages were simple and static. Raw HTML is shipped to the browser. The browser, at that time Internet Explorer or Netscape, would then request some CSS and assets, usually images, then gather all that and present the now styled HTML page.
A user would see a collection of links and images that could be clicked. Whether they were browsing articles or shopping, the interface consisted mainly of these links and images. The user clicks a link and the browser retrieves a new page. Theserver responds with the requested HTML, the HTML is parsed and the browser reaches out for more downloadable assets. And the cycle continues.
This is also the era of GeoCities (1994) where people could host their basic HTML, CSS and images for everyone to see.
In 1995, PHP is released and quickly gains traction among users as it is particularly easy to pick up, learn, and run, so soon lots of sites would move to this more dynamic approach. Together with alternatives like JSP, ASP and Adobe’s ColdFusion.
This release gives rise to the introduction of the first CMS’s (Content Management System), which makes it even easier for people to pick up and build a dynamic site. This makes PHP basically the first server-side rendering tool that gained wide popularity. It would take different HTML templates and populate these with user information, relevant & up-to-date data like post information and amount of views. It would then render the resulting HTML page on-demand and the final result would be served to the browser.
In the early years of 2000, the Internet starts to boom and explosively grow in popularity and usage. As more and more regular people get access to computers and the Internet, so does the demand and need for web pages and services grow.
But in these early days, scripting is still very uncommon. The content might be dynamic, but the pages themselves are fairly static and offer little interactivity.. With the introduction of Firefox (Mozilla, 2004), the browser market starts to shift and this brings a new wave of slightly more interactive webpages.
These are also the years of MySpace (2003, ColdFusion) and Facebook (2004, PHP), taking the web by storm. In The Netherlands, we had our own alternative: Hyves (2004, PHP/ASP). These platforms all pop up around the same time as more people start to use the Internet on a daily basis. In the same time period, out-of-the-box tools like phpBB (2000) and WordPress (2003) also become available, making it much easier for anyone interested in starting to build a website to do so.
This is the beginning of webpages figuring out that interactive websites are a lot more engaging, and that clicking a vote button or submitting a post shouldn’t hijack your complete web experience but keep you in the same place and update it live. Perhaps it’s also a better user experience if the page helps you correct mistakes with some rudimentary validation before sending a form. With some scripting, you could send that click on the upvote button to a different place to save it. The next time you loaded the page, the server would get the latest data and render your upvote. With some more scripting, the page could eagerly update the vote count so users wouldn’t even have to refresh their page anymore. Adding a comment and directly showing it on your page would be a close next step.
In 2004, Google released Gmail to the public, which was one of the first fully interactive interfaces. This inspired a much wider audience to go and explore interactivity on the web, which is only just beginning.
jQuery then almost becomes a default for modern web pages as it makes adding some interactivity to a page easy. As of writing, it is still claimed to be running on 77% of web pages according to Wikipedia.
Fully interactive pages are slowly becoming the norm, and the movement to what will later be called “web apps” is slowly getting under way. With the browser technology getting better, the introduction of HTML5 (2012) and the compatibility gap slowly closing between browsers, the road is now paved for more intricate and complex web applications.
In comes AngularJS (2010), a library that is written by Misko Hevery and then adopted by Google. In that same year, both KnockoutJS and BackboneJS (2010) are also released which share many of the same concepts amongst each other, of course with slight differences in approach. These libraries popularized the “MVC” model, or “Model-View-Controller”, which is a concept that helps you structure your apps and split your domain models from your view logic. This is also the time where the abbreviation “SPA” or Single-Page Application is gaining in popularity as these types of applications become more mainstream.
In 2013, React is released by Facebook to the public. This takes the web by storm again and gains even more popularity with an easier learning curve. Although in the early days of AngularJS and KnockoutJS, hybrid combinations of page and application were still quite common, where a page would retrieve some data for rendering on the server-side, package it with a AngularJS or KnockoutJS app, and send it over to the browser. The browser then has to start the client-side application and use all the data that was sent over to build some application state.
This idea is slowly being overtaken by a new idea, with a singular app that would just do it all. Retrieve a bunch of data, render a new set of components, navigation, et cetera. For React this means the growth of a massive community exchanging ideas and libraries, some of which growing to massive sizes like React-router (June, 2014) and Redux (June, 2015).
In 2014, Angular 2+ is announced at the ng-Europe conference, and 6 months later a developer preview is released (April 2015). This complete overhaul in approach from AngularJS turns Angular into a full framework that has a clear opinion and comes “batteries-included”. Angular comes with a bit of a steeper learning curve, by default together with TypeScript, and rethinks a lot of concepts developers have gotten used to from AngularJS.
Return of SSR
In the years after 2016, we see a resurgence of “Server-Side Rendering” solutions. Angular Universal (May 2016), Next.js (October 2016), Nuxt.js (October 2016) are all released in the same year and enjoy different levels of success and popularity.
An even more extreme example is
HTMX, which seems to be quite recently released (2022). This completely removes the reactivity model and instead goes back to having server-side rendered HTML, which can then be easily called using events and replaces existing targeted HTML elements like
But does every website need a web app? How much interactivity does a blog really need? Surely there will be a need for full-fledged web applications to enable users to do their work in an efficient manner. Some applications simply have a realtime nature to them, or require a bunch of information coming from different sources to be combined in a smart way. But not every site out there needs that level of interactivity. It depends on what the user needs and how they are supposed to be using said application, not to mention the increased complexity for maintaining such sites.
This is a complex field with many routes to success. Yet I don’t think every website requires the amount of interactivity like we’ve been building for the past 5 years. Not every site needs to be a web app. So many web pages with little interactivity, like an interactive search with filters, could just be a singular component within a server-rendered whole. Of course, the dynamic nature of the data may change the level of interactivity and how much can be pre-rendered. However, I think that we’ve shipped off too much logic to the client to the point where we have to duplicate application logic in both front-end and back-end. This may offer a nice user experience,, but it’s not really required or even demanded by the users.
Perhaps we could do better and be smarter about the level of interactivity our users really need. Other business related requirements, like requiring a full REST or GraphQL API for other applications (like mobile apps), might influence how we want to approach the type of applications we write ourselves, and the complexity and interactivity required.
I personally think the time of taking any idea for the web and making it a client-side web application is over. And perhaps, that’s a good thing.