Web Development Nightmares from the Past

The web has evolved a lot during the last 20 years. There was a time when you could find HMTL coded in all caps and it was not considered a bad practice (it was not a widespread approach to HTML either). But, the web opened the door for a lot of software engineers and more are coming out each day. That is one of the reasons I think we also see web frameworks coming to solve the same problem over and over. But the web today is way better than it used to be because the browsers at least are following the standards. Here, I will discuss some of the issues faced over a decade that new developers or even new users don’t know about. They are not in any order as I was writing as they came to my mind and I am sure that there is more that could be added to this list.

Each Browser Doing Its Own Thing

Competition always brings innovation. But, when competition comes with each one doing their own thing while excluding the users and designers in the process, it is a recipe for disaster. That is basically what happened in the first browser war. (Of course, I won’t mention all the things that Microsoft did to kill the competition.) However, introducing non-standard elements was common back then because browsers wanted to differentiate themselves by adding elements that were not in any other browser. So, when you visited a page “Optimized” for Internet Explorer, you were forced to install their browser to see the page properly.

Every site that you visited back then had the label “This website is optimized for browser X”. That was painful because you could see differences between browsers, and to gain the whole experience, you needed to install that browser on your computer. Even the same browser vendor could have different behavior depending on the version (IE 5, 6, 7…). For example, you had to use conditional comments to hack different versions of Internet Explorer to render the page the way you wanted. Those hacks were useful back then because you could target different browsers with different CSS files. But it is something of the past that must stay in the past.

There were two box models. One for IE and the W3C one which was the standard. But I must say that IE was right about the box model. I don’t know what the W3C was thinking on the standard box model because it did not make sense if we looked back. The box model presented the Microsoft had fewer surprises because if you gave a width to an element, you were sure that the element kept the width no matter what. This was a pre RWD which means that making sure that the width and height were behaving as expected was very important so your design didn’t break.

DHTML – JavaScript Madness

For a language that was designed and implemented in a week, JavaScript has done very well the last almost 30 years. But, the late 90s was pure madness with all the DHTML used on web pages. Animations in the title bar, words jumping around the page, images changing without any purpose, and all the crazy things that you could think of, were done with JavaScript in this “new” era of the web.

During this time, it was popular for web pages to have a welcome page with a clock showing you the time. Hover effects over images in the navigation with JavaScript, animations in the status bar and the title bar, etc. Also, this was the time that ads got annoying and some sites opened a dozen popup windows.

Limited CSS effects and Animations

Oh, you don’t know how hard it was to create the effects that we take for granted now! If you wanted to create a rounder border or just shadows for text or boxes, it was very problematic. That was a lot of image slicing in Photoshop to cut the corners of a container into images to later use them as background in each of the corners with nested elements in your HTML to simulate rounded borders. Similarly, it was necessary to create a transparent image or just a normal one with a shadow to simulate this effect without CSS. Transparent images were not related to CSS but it was another problem because transparent PNG was not supported by default in Internet Explorer 6. Thus, you needed to add filters for this purpose. IE implemented a lot of transitions and filters even before the standards. However, the way they did it was difficult to even understand for developers. Opacity, shadows, transparency, and more were done on IE using filter and transitions. I invite you to read about them just for the sake of knowledge but all of them are deprecated for modern and standardized ways to do it.

In short, CSS animations and effects was we know them today did not exist and most animations had to be made with JavaScript. The greatest thing that you could do with CSS in terms of animations was using :hover to change some properties of the elements.

The DOM was Bad. Yes, Worse than Today!

It is not a secret that the DOM was not well designed from the start. The current state of the DOM is not perfect (perhaps will never be) but it is better and easier to deal with in modern browsers. Just to remove an element from the DOM, you could not delete the element directly. It was necessary to get the parent element, and then remove the element you wanted to delete. For instance, by clicking a button, you will remove the image with “delete-me” as the ID:

let button = document.getElementById('button');
let image = document.getElementById('delete-me');

button.addEventListener('click', function(){
  image.parentElement.removeChild(image);
});

In modern browsers, you can still do the same thing. But, the alternative is easier by calling the delete method in the element to be deleted without having to pass by the parent element:

button.addEventListener('click', function(){
  image.remove();
});

Microsoft was doing its own thing with Internet Explorer which created a nightmare for developers and designers. An example was event handling in Internet Explorer and other browsers. Right now, we use addEventListener. But back then, it was another beast. If you ever wanted to manage an event in JavaScript, you need to consider IE and the standard way.
The following is a function that was used for attaching events to an element in different browsers.

function addEvent(element,event, fun) {
  if(element.attachEvent) {
    element.attachEvent(event, fun); //IE
  } else if(element.addEventListener) { //W3C
    element.addEventListener(event, fun);
  } else {
    element['on'+event] = fun; //Old IE versions
  }
}

In modern web browsers that is not the case. You can trust that the browser already implements addEventListener instead of the craziness of different web browsers and differences in implementations for similar things. This is one of the main reasons that jQuery and other libraries/frameworks became popular in the mid-2000s.

Layouts with Tables

Before having all the goodies of Flexbox and Grid Layouts, there was a time when pages did not have layouts. Then, web design evolved to use frames to serve as separating content like navigation on the left side while having the main content on the right column. Then, tables became the go-to approach for creating layouts.

Even though tables were not used for their original purpose, it was useful because developers could locate those items right where they wanted. The problem back then with this approach is that tables make it very difficult to maintain the site if you need to add, update, or remove an item because it could break the entire layout. Even when you exported from a popular design tool, the layout generated was made with tables.

Then, the web design community pushed for the use of CSS to create layouts. The community is glad that CSS matured so, we could create layouts with pure CSS and get away from the nightmares produced by table layouts. Websites like CSS Garden were paramount for this transition by showing what it is possible by using CSS.

Making a layout with three columns is something easy to make with Flex or CSS Grid layouts. But, a while back, it was very difficult because the only thing in hand for pure CSS layouts was floating and clearing divs. In fact, this layout was called the Holy Grail layout as it was difficult to implement. But, even the two columns layout needed Faux Columns if you needed the columns to take the entire height of the page.

Divitis and Classitis

Divitis and classitis are the use of a lot of divs and a lot of classes that could be done with some classes and more semantic HTML tags. However, there were some excuses to use divs for almost everything as there were not semantic elements like header, footer, aside, article, and others. But what could be done with one of two divs, was done with a lot of nested divs which made the code more complicated.

Unfortunately, we still can see divitis by the use of frameworks/libraries like React which each component is wrapped inside a div.

Webmaster Job and Web Developer

The webmaster job has evolved into a back-end and front-end developer. It is rare to see really full-stack software engineers considering that what is considered “full-stack” is really a frontend using REST APIs. In the past, it was different, a webmaster or just a web developer needed to work with everything including servers, HTML, CSS, JavaScript, and any programming language required in the backend. The majority of websites were pure HTML while applications were coded in PHP, ASP.NET, and Perl.

XMLHttpRequest and Active Objects

The Ajax technique was used in some early applications before the actual Ajax was popular. The XMLHttpRequest was invented by Microsoft to be used in Outlook in the mid-90s. However, this feature became a revolution in the mid-2000s because it allowed the creation of desktop-like experiences without refreshing the entire page.

Ajax was more difficult because it was necessary to check if it was supported by the browser and checking also what kind of technology was implemented. For instance, IE had the ActiveXObject(“MSXML2.XMLHTTP) while Firefox used the XMLHttpRequest object. Also, add to this that this object is low level compared to fetch and it was necessary to check for when the request was ready and the type of response sent by the server. Also, most Ajax were done with XML as it was the interchangeable language used in the enterprise for most things and as I mentioned later, XML was used for everything.

At first, Ajax was an acronym for Asynchronous JavaScript and XML. Nowadays, it is just known as Ajax and it refers to sending and receiving HTTP requests without having to update the page. As much as we would like hate IE6 and Internet Explorer in general, the XMLHttpRequest was one of the keystones for the revolution of the internet post-dot-com bubble and entering the Web 2.0 era.

Flash and Silverlight

Flash became popular because it enhanced HTML by providing the tools to make animations and even including video and audio to web pages. Back then, there were a lot of “Splash” or loading screens waiting for all the Flash resources to download before playing. Remember that a lot of people still used dial-up until the mid-2000s. Therefore, a person with a 56kb connection waiting for the page to load was normal.

Flash was seen as the future for everything web and desktop in the eyes of Adobe and some Flash developers. Video players, cartoons, animations, and sections of web pages like navigation were made in Flash. That is why they push for Adobe Flex and Adobe AIR. But Microsoft had something similar to Microsoft Silverlight. So, basically, the web would have been dominated by plugins and private companies providing proprietary technology if HTML5 didn’t succeed.

Slow Internet Connections

I mentioned already the 56k connection. In 1997, I was still connecting to the web via a modem at 56k per second. But, before that, I also had a 28k modem to get online. It was normal to visit a page and slices of images start loading slowly and take several minutes for them to be finished. Today, even with the slowest connections, we don’t have that problem.

I believe that in developing countries you can still find slower connections and cyber cafes that would take a while to load your pages. Thus, still be careful when creating your websites.

Java was “The Future”

There was a popular belief that in the ’90s and early 2000s, you didn’t need to learn anything other than Java because you only had to code once and run everywhere. Java Applets were supposed to take the world in the name of Java and JavaScript was a toy language that would die eventually. It is important to clarify that Java and JavaScript were two different languages with different target audiences. Fun fact is that JavaScript was could have been named Mocha as the little brother of Java.

There are developers OK with working on Java projects full time. The thing that I consider a nightmare is that Java was another plugin like Flash for the browser. Java was not used in the browser to interact with the DOM directly or improve the website. It was used as an add-on to run Java programs on the web. This approach will never improve the web because it tried to replace it.

VBScript vs JavaScript

Microsoft tried to be sneaky by reverse engineering JavaScript available only on Netscape. That was a smart move because it allowed JavaScript to be used more since it would work on IE browsers as well. This reverse-engineered language was JScript and it was so good of a copy that the bugs were also ported to JScript. But Microsoft didn’t stop there because VBScript was another language based on Visual Basic that was included in IE browsers. Glad that this language did not gain traction on the web and only stayed on Microsoft systems.

Quirks Modes

You created the perfect website but the browser was behaving kind of erratically. Most of the time this was due to the fact that a quirks mode was triggered because you forgot to include the correct doctype.

Before the web standards, I mentioned that browsers were doing their own thing. So, in order to follow the standards, and render the page properly in what were considered modern browsers when IE5+ and Netscape 4+ came out, it was by checking the Document Type. Based on the Document Type or doctype, the browsers rendered the pages appropriately. For example, if the page lacked a doctype, it assumed that the website was very old and did not follow any standards so it rendered the page in a quirks mode so the page can function as expected by the developer. There were three types: Quirks, Standards, and Almost Standard. All of them affected how JavaScript worked, the layout of the page including the box model, and more.

XML Everything

Another that was supposed to take over the world was XML. Web services and SOAP were the future and XML was the de facto standard for communication between applications. XML was projected to be so big that even HTML was influenced by XML and we got XHTML. Pages in XTHML were supposed to replace the old HTML 4.0 specification but gladly it didn’t. Things as simple as opening a new page with target=”_blank”, became invalid in XHTML.

I still remember working with web services in Visual Studio.NET and having a hard time making it work consistently. Also, parsing XML after an Ajax request was difficult. Most of the DOM methods did not work on XML. Thus, we should be thankful that JSON took over.

Internet Explorer 6

If you ever had to create websites in the 2000s, you had to deal with the issues of Internet Explorer. But, Internet Explorer 6 was the most hated because while the web was evolving, IE was stuck in the past. Believe it or not, Internet Explorer was very innovative when it came out in 2001. The main issue is that it took Microsoft several years to bring a new version to this browser and there was no clear path to automatically update the old IE 6. Therefore, we were stuck for several years with IE 6 which lasted until the beginning of the 2010s. The browsers IE6, IE7, and IE8 were the peak of the conditional comments era that still hunts old developers today.

I think that ignoring the web community for years was the biggest mistake made by Microsoft believing that they won the browsers war. Firefox continued progressing and Google changed everything with Google Chrome. Microsoft had the largest market share in web browsers and operating systems. Today, it is only operating systems and the browser engine now is the same used in Chrome.

Browser Toolbars

It felt like every major company provided its toolbars. Every installed taskbar also included a search bar. A lot of users installed those toolbars without even knowing it because they came bundled with free antivirus and another type of software. I remember the Yahoo, Ask, Google, AOL, Alexa, AltaVista, and many more having toolbars.

They not only cluttered the UI and reduced the real state available for the web pages, they also modified the behavior of the browser in some capacities. Some changed the home page of the browser and introduced weird pages that loaded on the browser without users’ intervention. Furthermore, some became a security hole for most computers. Let’s say that none of those toolbars were useful and that is the reason that they are dead.

Conclusion

Browsers and the web have evolved over the years. These were some of the nightmares that we had during the mid-90s to late 2000s. If you worked during that era, a lot of new features that are common today were implemented manually by developers and designers. However, this progress does not mean that everything was bad back then, I might create another post discussing some of the great things that happened in those days. This post might not be 100% accurate since it is stuff that is long past 10 – 15 years but it provides a good description of the web development over a decade ago.

Teylor Feliz
Teylor Feliz

Teylor is a seasoned generalist that enjoys learning new things. He has over 20 years of experience wearing different hats that include software engineer, UX designer, full-stack developer, web designer, data analyst, database administrator, and others. He is the founder of Haketi, a small firm that provides services in design, development, and consulting.

Over the last ten years, he has taught hundreds of students at an undergraduate and graduate levels. He loves teaching and mentoring new designers and developers to navigate the rapid changing field of UX design and engineering.

Articles: 182