What Front-End Development Looked Like in 2005 – Blast from the Past

You know how when you meet an old friend and start talking, you inevitably go down memory lane – what it was like back then and the crazy things you’ve done together.  The same happens when coding buddies get together to share a few beers. They always start talking about code. And the conversation goes waaaay back (for us to 2005). So in this article, we decided to take you on a trip and share with you how front-end development evolved during the years we have been in this business. And we promise, even if you don’t do coding too much it might still be interesting for you 🙂

The Vivid Memories From the Past

Before htmlBurger was founded in 2007, we were making websites for clients that had heard about us and our skills in design & development. Prior to going global, we first started working with local businesses, and suffice to say they loved us. Now when we remember how we used to do things we realize how much our work has changed since we first started. How we used to write lines and lines of code, use third-party apps, and libraries for something that is now simply included by default in HTML5, CSS3, or JavaScript.

So let’s see what’s changed over the years:

• How HTML Changed
• The Evolution of CSS
• Flash From the Past
• The Code Editors
• Responsiveness?
• The Almighty JavaScript
• And a Special Place for Internet Explorer

Before HTML5 officially arrived, we used to write in xHTML, and before that it was HTML4. Long story short, xHTML was released because of the need to solve compatibility issues across browsers and became the default for every front-end developer. It was pretty efficient during its time. Compared to HTML5 it was more strict, with extended doctype, and it did not have all tags HTML5 has to offer. Overall, what makes HTML5 the bee’s knees is the new capabilities and tags. HTML5 introduced new tags for structure, media, forms, and graphics that gave us possibilities unthinkable with older versions.

• Structural tags defining separate blocks like <header>, <footer>, <nav>, and more.
• Graphic tags such as <canvas> and <svg> to support vector graphics.
• Media tags such as <audio>, <video>, <embed> etc.

HTML5 then brought unseen features like drawing, drag and drop, and other APIs and features without the need for third-party plug-ins. Even more amazing was the fact we could now make form validations directly in HTML instead of using JavaScript and PHP. And most of all it solved all issues that xHTML was designed to fix which made the latter obsolete.

Here’s where things get really interesting. In the same spirit of how HTML5 made our lives easier, CSS3 arrived with even more features and solutions, answering the prayers of developers all over the world. Here are some of our favorite examples that we instantly think of.

Rounded corners were the developer’s nightmare.

A horror story based on true events. In the early 2000s, border-radius did not exist. And to add to that box-shadow was not a thing either. So when the design had blocks with rounded corners and shadows,  we had to prepare 4 images for each corner + 4 more images for each of the sides. The example below, although slightly more complex, was giving us some flexibility to reuse the CSS no matter what the width or the height of the block.

Below is just one example of what the HTML markup was for a box of this kind.

Fortunately, the CSS3 border-radius was introduced to help us with that issue and to create rounded corners only by using CSS. To see the comparison, this is how we write this today thanks to HTML5 and CSS3:

.box { border-radius: 5px; box-shadow: 0px 0px 10px rgba(0, 0, 0, .5); }

Pseudo-classes were not very popular.

Before CSS3 and modern browsers the only pseudo-classes available were the user actions for :hover and :focus .  Nothing else was well supported, especially when we had to deal with IE6.  As a comparison, we currently use pseudo-classes for linguistics (document language), location (links and targeting elements), time-dimensional (tracking), resource state (media), and much much more.

 

Structuring sections of a layout was not a big deal.

It was either left or right. Instead of using Grid or Flexbox, the only way to position elements back then was with float: . We lived in times before the usage of layouts, so we had to improvise a lot.  We can still remember when we discovered the adding display: inline; to float:left; fixes bugs in IE.

 

Pure CSS, no SASS, LESS, or whatever.

A world without preprocessors, only the purest CSS. Now we are happy to have tools that extend the functionality of CSS and give us even more capabilities and options that CSS alone doesn’t offer. For example, SASS allows you to modify color values or analyze lists, also allows nesting, inheritances, and setting up loops. Imagine how powerful CSS3 is currently and how even more powerful it becomes with preprocessors. The improvement in comparison to the pre-CSS3 times is absolutely insane!

But let’s stop with CSS here. There could be a whole new article for CSS only. When we just think of how CSS evolved, it makes us really happy 🙂

Can you imagine times where the only way to implement videos was through Flash? Like it was yesterday when YouTube switched the embedding of videos to no longer use Flash. Ohh good old Flash.

It is either Flash or impossible.

This was something like a golden rule that we said when we had to add something fancier (custom slider, complex animations, etc.) to the website. And just a fact, Adobe Flash when we started using it, was not a product of Adobe actually. It was owned by Macromedia, who developed it, and then Adobe acquired Macromedia, so it became Adobe Flash.

Drastic change arrived when people wanted to implement custom fonts on websites. Today we can just add them in a matter of minutes. Before CSS3, however, you guessed it: Flash. Or more precisely, the Scalable Inman Flash Replacement sIFR. It worked as an Adobe Flash and JavaScript dynamic web fonts implementation that replaced the texts with their Flash equivalents. Here, we really wanted to show you some examples, but first our browsers no longer support Flash, and we also tried to bury all the evidence of such a code 🙂

In addition to video embedding and custom fonts, Flash was also used for dragging & dropping of files, all kinds of chart implementations, custom sliders, any complex animations, and more and more.

So although we hated Flash so much, we should be really thankful for all the opportunities that it gave us, because, without it, websites would have been really really simple.

As far as we remember the popular code editors back in the day were Microsoft FrontPage, Notepad++, Adobe Dreamweaver, and E-textEditor. To be fair, all those editors were pretty great for their time and some of them actually found their way to the future. For example, Notepad++ remains an absolute classic and is still popular amongst developers. Adobe Dreamweaver is also an editor that managed to evolve with all the technologies and it is a popular choice today.

At some point, we needed to change the editor to something more lightweight. And here comes the newer generation of editors that we wished to test. Amongst all, we instantly fell in love with the newly-introduced Sublime Text that is highly extendible, flexible and gives us the possibility to completely configure and customize it to work well with our coding standards.  In addition, Sublime provides shortcuts and search tools to immediately find certain functions and make changes to multiple lines on the go.

And in the past few years, many new editors arrived and became popular. Some of them are Atom, Visual Studio Code, and TextMate for macOS. All pretty powerful text editors with auto-completion, terminals, debuggers, and many additional features.

Since we are talking about times before the iPhone or mass smartphone usage for that matter, the responsive design simply wasn’t mandatory and for most of us, it didn’t actually exist. Although it was first introduced on Audi’s website in 2001, in a slightly different form, it took quite a while before it became popular and mass used. We can point out the introduction of responsiveness to May 2010, in an article in the magazine A List Apart. You can actually check the emblematic article here.

By the end of 2010, we adopted responsiveness and started offering responsive coding to our clients in 2011.

Back in the old days of front-end development, JavaScript just used to be a bonus for creating animations and some tasks. Although it was still heavily used, it was not so essential. Nowadays, however, JavaScript is so deeply implemented into front-end development, that it’s unthinkable for our projects to be released without it.

But what about the frameworks, you ask? Surely, in the beginning, when we started writing JavaScript, jQuery wasn’t even popular. Instead, we used PrototypeJS and ScriptAculoUs. jQuery became more popular when the Sizzle Selector Engine was introduced into the core.

These libraries allowed us to do some really cool stuff for their time. We can’t fail to mention that we will be forever grateful to the developers who created them for giving us those capabilities and showing us the true potential of JavaScript and the powerful tool it would become one day.

Nowadays, we take full advantage of powerful modern frameworks such as ReactJS and our personal favorite VueJS. There are also at our disposal tools like task runners, module bundlers, package managers, testing frameworks, mobile frameworks, linting tools, language flavors, and more.

It’s also a fact that today we cannot talk about front-end development without including Javascript. It’s at the core of what front-end development actually is. In 2005 JS was still very popular and important, but it didn’t have the power that it has today.

There was no Google Chrome back then. But what we did have was Internet Explorer packed with a handful of bugs. The great news was that this gave us the opportunity to discover and create some black magic hacks to deal with any bugs. Adapt, overcome, improvise. We ended up fixing really weird problems with even weirder solutions. How does this sound? Sometimes, it happened that the text in some blocks simply disappeared. In order to fix this, we gave width: 100%;   and position:relative that actually worked… for some reason.

And can you imagine fixing all kinds of bugs without even having StackOverflow on your side? N.B. If you are not sure what StackOverflow means – that’s something like a magical place for developers, where they find answers to their most frequent questions “What happened? Why did it break?”

Nowadays we are almost at the end of the Internet Explorer era and we use modern browsers that adopt the new technologies pretty fast. We no longer have to deal with most of the bugs we had to before, and there’s no longer this enemy that we had -Internet Explorer. And although we are mostly happy, it somehow makes us sad, because IE was getting the best out of us when exploring how to fix specific bugs.

In Conclusion

Years ago, we didn’t have all these tools at our disposal. It was mostly manual work with limited possibilities and the need to improvise and discover solutions on our own. After the front-end development was met with HTML5, CSS3, JavaScript Frameworks, preprocessors, and all modern tools available today, we can do what we love better, with higher quality and way faster. But there is also the other side of the coin.

Nowadays being a front-end developer is much more than simply writing your HTML with a little bit of CSS and JavaScript for flavor. The modern tools do make our workflow easier, however, front-end development itself is much more complicated and requires more knowledge and understanding of said tools.

As they say, with great power, comes great responsibility, and with great front-end development tools comes the great need for improvement and learning in all directions. Constantly.  (= Today, being a front-end developer is almost being a full-stack developer as the tools allow you to create a complete working and dynamic websites.