Call for IT Pros to Rethink Web Technology
TL;DR;
Ever spent hours debugging a cross-browser CSS issue only to find it’s an obscure rendering bug? What if the web didn’t have to be this painful? As IT professionals, you confront daily challenges with cross-browser bugs, XSS vulnerabilities, and framework churn. The culprit? HTML, JavaScript, and CSS—an outdated trio. This post argues that it’s time to rethink web technology for a simpler, more secure future.
The Origins of the Web Trinity
Throughout the history of the computer, many technologies have been created and evolved. Nevertheless, until now, nobody has faced one of the biggest technology problems: the HTML + JavaScript + CSS Trinity for web applications. HTML has been used beyond more than it was designed for. As a result, these unforeseen uses created unexpected complexity. Not only does this burden the IT professionals, but it also prevents the web from leaping ahead. The HTML+JS+CSS trinity costs companies billions annually in maintenance and security fixes.
The Birth of HTML
In 1989, Tim Berners-Lee created the World Wide Web. At that time, the most powerful computer a person could have was an 80386 PC with the impressive Clock Speed of 20MHz. The same computer would come with 16MB of RAM in its more glorious version, and 100MB of HDD space.
Although the first HTML-based website only came to life in 1991, it supported only static pages. The internet was designed and imagined for computers that couldn't handle a single background weather service that the cheapest smartphones run without any hassles. They couldn't even imagine what HTML would become later.
The Web Technology Pandora’s Box
Subsequently, when a NCSA researcher assistant called Rob MacCool, created the Common Gateway Interface in 1993, Pandora's box was opened. CGI was a way to integrate C and Perl with HTML and generate dynamic pages.
CGI came before the <a> and <p> HTML tags being formalized, which happened only in 1994 with HTML 2.0. It created abilities beyond sharing static documents. Now it would be possible to sell goodies and information through the web. This new idea ran faster than a trail of gunpowder, and new problems emerged.
HTML was designed to present structured data, readable by humans and computers. Dealing with things that native applications could do, such as authentication, was not in the HTML scope. It was not fast, and the Internet connections were unstable, resulting in the connections being lost during use.
Organizing a beautiful and consistent layout through many pages was not easy. To solve the design problem, the CERN presented the first CSS proposal in 1994. Expecting to make HTML a bit more dynamic, Netscape created JavaScript in 1995.
As soon as applications over the web came to life, there was no kind of data encryption, and the communication was completely open and unsafe. Crackers, a new kind of hackers, started to use the internet to steal personal data, defacing websites, and committing many kinds of security exploits. To deal with the security problems, Netscape created the Secure Socket Layer in 1994, but it had many security flaws. Version 2.0 was publicly released only in 1995.
I expect you to understand: HTML was created thinking about open information and static documents around the web. All the solutions to make it dynamic were created many years later.
The Undead HTML Cousin
Now, let’s take an alternative pathway and talk about XML. Just like HTML, it was derived from SGML. It was created only in 1998, being adopted for many things at that time. Since then, developers started putting XML in almost every place they could. From communication protocols to configuration files, workflow designs, and everything else you can imagine. 10 years later, it started being used to design smartphone app interfaces too.
Around 2005, every Java framework and library had dozens of XML configuration files. Some of them are still alive, and I can't explain how it could be possible. Even contenders such as Microsoft .NET used XML to configure projects, applications, persistence, and everything else.
That was a real mess: To use XML required an XSL specification to tell how its structure should be. Meanwhile, the documentation about these XSL specifications never resembled the reality. So, parsing XML was always painful. The cost to translate XML to other languages was not so small when you had a huge amount of XML coming and going. Afterwards, a Java developer became an XML developer who used Java in the vacancies.
Someday, they realized that this had gone too far. So, XML started to be replaced with simpler, lighter, and less verbose standards like YAML from Ruby on Rails and the widely adopted JSON standard. Yes, in 2010, XML started to decline. Presently, it is still used, but nobody who creates something new remembers to use it. Since then, XML is on the way to becoming part of history.
Modern Technology, Old Web Structure
But this article is about the HTML + JavaScript + CSS Web Trinity, and why was I talking about XML? New revisions of HTML incorporated many things from XML, such as support for custom tags. As long as both languages are derived from SGML, XML follows a similar structure and the markup syntax that adds lots of code to represent structured data. XML became old and unwanted 15 years ago; on the other hand, HTML is still here. As a result, I am writing a text that will be published in HTML. Someone will read it in an HTML browser. It will be indexed by an HTML-based search engine, or an LLM, and so on.
At the same time, there were many trials to improve and fix the Web Trinity:
- To structure page contents: HTML 2.0, 4.0, 5.0, XHTML;
- For styling: CSS2, 3, Sass, Bootstrap, Tailwind;
- To make apps more dynamic: Java Applets, DOM (Document Object Model), XMLHttpRequest (the grandfather of Ajax), Flash, Ajax, jQuery, Silverlight, Reactive Programming, Progressive Web Apps;
- For communication and distributed systems: SOAP, REST APIs;
- Front-end focused technologies: React, Server-Side Rendering, Angular, Vue.js, Svelte;
- Programming solutions: Node.js, TypeScript;
We already have rockets landing and being caught by a robot arm, but HTML is still here: an untamable chimera alive and kicking.
The Web Needs to Change!
Nobody during all this time has stopped for a minute and said: “I think we could create a better technology to replace HTML”? Every solution, every patch, every new way to work with the same old HTML. The old JavaScript and the old CSS. Together, creating a bunch of new problems.
To be fair, I have seen some discussions like this one on Ycombinator, or this one on Reddit. At the end, it seems that no one wants to go ahead with the discussion, or to avoid thinking about a new web solution, or just to avoid the discussion itself.
In the meantime, a new project always brings many decisions. What language and framework to use? What hosting platform and database system? However, the Web Trinity is not an option, and it is also not good. In return, there are always new solutions trying to do the same. Some, trying to make HTML less repetitive and verbose, or CSS easier to organize. Some, to make JavaScript easier and safer. None of these solutions ever considered that the problem resides at the root.
Native Apps vs. Web Apps
The idea behind iPhone apps was to rely on Web Apps. Later, Apple realized that Web Apps were too bad and decided to release the iPhone SDK publicly. When it happened, too much criticism appeared. Many people were asking why someone would develop an application specifically to run on an iPhone. The answer came too fast when the iPhone became the most-wished-for and sold mobile phone. People started to understand how bad the web was when compared to native apps.
The same happened with Android, and later with other smart devices like Smart TVs and Smart Watches. Now, companies must have a codebase to run their backend web services, web applications or websites, iPhone native Apps, Android native apps, and many others.
Many companies use to encourage users to download their native Apps. They do it by offering some special offers and conditions available only through their apps. Reports highlight the plethora of advantages of using native apps instead of websites. Better performance, better control, and mainly due to the security they offer in comparison to HTML-based websites.
The Web Productivity Crisis
Ironically, we have more jobs available due to HTML Trinity issues, but it is also a crime. Companies have to do the same application two or three times. These applications also have to work on as many devices as exist. Where lies the worst codebase to maintain? HTML + CSS + JavaScript. Have you ever imagined how much it costs for us, the end users, the consumers, the taxpayers? It is insane.
You can also disagree, but it is a fact: CREATING a Website, having in mind all the concerns it implies, is unproductive. Responsivity, security concerns, user experience, etc. Today's seniors who started programming 10 years ago can think it is ok. For an old-school guy who started programming in Delphi 4 in 1996, that is close to unacceptable. There are too many legs to be watched at the same time to do things that should be simple, as it was before.
Most of the concerns the developer has now should be addressed by another layer, like the compiler or the server. Not because the developer must reinvent the wheel for every new application: every application built from scratch needs an almost identical wheel. Each wheel costs too much to be produced. At the end, the non-functional requirements require more than they should.
Let's Rethink the Web
Some argue HTML’s flexibility and ubiquity make it irreplaceable, but this comes at the cost of complexity and fragility. Can we afford to keep patching a 30-year-old system? Let's rethink Web Browsers and Web Development.
Defying an Industry standard by proposing something like this can seem pretentious, but let's exercise our imagination a little bit. What would be the requirements for a new Web? Let's list some of them - you are free to add your thoughts in the comments:
- Removing the requirement to know 3 or more languages to create an application;
- Taking advantage of the device’s native performance;
- Improved interface responsiveness: How do you develop a website for both Occidental and Oriental languages today? Why don't we have the font size adjusted automatically? Come on, we have the technology to achieve this;
- A clear separation between public and private data;
- Indexability and readability of the media content;
- Native encryption, signing, and security of the native data;
- Progressive content providing;
- A compiled code to run on the client side to avoid unwanted data collection, and a smaller artifact generation (remember minified JavaScript);
- Transparent development of web applications: I.e, the developer should not care about the communication between backend and front end.
- The possibility of using any desired programming language;
- Detection of errors in compiling time;
- Decentralized user data. It is: the application must know only the necessary information about the user, and we can think about the Web 3 capabilities beyond cryptocurrencies.
- Device agnostic - all that the application should know is the browser, and the current web browsers provide this kind of interface.
In a brif resume
What could we have then? A common development web interface able to generate a dynamic intermediate language assembly. Each compiled piece of code knows its origin, provided dynamically to the client, able to refresh itself when it becomes necessary. A new web browser architecture, very similar to the ones we have today, from the user’s point of view. Instead of processing HTML (each browser in its own way), CSS, and JavaScript, a common intermediate compiled language that leverages performance, improves safety, and consistency.
Final Considerations
I have been reflecting on this for many years. I always tried to figure out why there are so many developers complaining about web development. Why is it so unproductive and hard to deal with, and is there no option but to start it anew? Many people can state that it would be insane because no big company would like to rewrite the codebase to a new set, but they have done it more than once, and today's price to keep many ecosystems alive is too expensive that a new set to replace it all would be cheaper than the current maintaining cost.
Do you think the web trinity is holding us back? Comment or share your thoughts!
Originally posted in my Blog
Top comments (0)