Table of Contents
A Brief History of Web Development
Until now, the series has focused on XPages. That’s understandable considering my previous series that this is inspired by. However, recently it’s become apparent that much of this series is relevant to a much wider audience than just XPages developers. Most web developers are used to developing with a specific framework. That’s understandable considering the history of the last 20+ years. But that means this series is relevant to a much wider audience than HCL Domino developers using the JSF-based XPages framework.
The Rise of Corporate IT
In the 1990s the internet started to become more prominent. Home computers were still mainly focused around gaming, but desktop computers began to become more prominent in companies. By the time I started my first office jobs in the late 1990s, desktop computers and email were starting to gain prominence. But a main use of word processing products was for generating paper letters that were mailed to other companies and customers. Emailing documents or spreadsheets was not a common task. The internet was used mainly for websites, applications were in desktop platforms like Lotus Notes, Microsoft Access or Excel.
Slowly web applications started to spring up and exploded in the 2000s. Developers learned hacks to work around differences in how Internet Explorer, Firefox and (later) Google Chrome implemented or ignored the slowly-evolving web standards. In UK, Safari and Mac computers were a rare occurrence outside graphic designers. As a result, and because Internet Explorer came pre-installed on Windows devices, Internet Explorer - and specifically IE6 - became the de facto standard corporate browser.
The Rise of Frameworks
Then in the second half of the decade, frameworks started to appear. Dojo and jQuery came out around the same time. The differences were that Dojo covered a broad array of web development needs, not only libraries for browser and web-page manipulation but also “dijit” Dojo widgets. jQuery,on the other hand, focused only on browser and web-page manipulation and AJAX. This initially gave Dojo a major advantage. The Java world were slower to the party, with JSP and JSF coming in around the turn of the decade.
Around that same time AngularJS was also released. This also provided components, but also brought the MVC (Model-View-Controller) approach to prominence amongst JavaScript developers. Dojo lost some favour, not least when they changed the way components were coded. React came along a few years later and, after a few years of competition with AngularJS, took over when AngularJS also changed their whole API. Other frameworks like Vue, EmberJS, Svelte and NextJS have their proponents and prominent applications.But frameworks were still the way to go…because we still had to fight with Internet Explorer 6!
Browser Companies Playing Nice(r)
Microsoft Edge was a major game-changer. Not because it was a better browser than the competition, but because it finally killed off Internet Explorer 6. The other key was that Edge was the last browser that auto-updated. This means no longer do developers have to wait for reluctant IT departments to update all their end users’ laptops. Now business users are likely to be on a modern browser. End users are often on a mobile device or a reasonably modern browser. And the browser companies are often collaborating together on web standards.
There are also key advances in web development, which will be used throughout this series. Rather than spoil the fun, I’ll leave them for when it becomes relevant.
Frameworks vs Browsers
Now we’re in an era where frameworks still exist. Indeed there are probably a lot of applications built on old versions of frameworks like Dojo or AngularJS, stuck with technical debt, supported by frustrated developers working for IT companies that are unwilling to justify the ROI of rewriting the application. Some applications will even be using multiple frameworks in a single application.
But whether it’s one or many, the problem still exists: frameworks have a specific way of working. There’s a whole website arisen to try to break developers out of the knee-jerk use of jQuery called You Might Not Need jQuery. But there are frameworks and components out there almost inextricably tied into the technical debt of jQuery. Sooner or later the developers will move on and it’s not advisable to be one of those left struggling. Combining jQuery with native document.selector() or fetch calls is not too difficult.
But frameworks have their own way to do things like light and dark mode or components. And as I’ve found, trying to integrate native options into a framework is far from straightforward. Indeed, it’s probably not worth it. So what does the future hold? Well, as we saw with Internet Explorer 6, it will take a long long time for companies to move their applications to options browsers natively support. And developers will be stuck with technical debt for probably over a decade. Developers may also be reluctant to adopt those options too. Despite the one constant in IT being change, humans are inherently resistant to change.
But it’s easier than ever to develop a web application without using a framework. And that’s the focus of this series, and why the name is changing.