From ‘IE6 Guy’ to ‘JavaScript Dev’ and back again

How I went from fighting IE6 quirks to wrangling application state to rediscovering my love for CSS

When I started my Web Development career in 2010, Internet Explorer (IE) was the king of the browser hill. Whilst IE8 had not long been released – IE6 was still up there as one of the most used versions even at that point. Not a bad shelf life for a browser which came out alongside Windows XP in 2001. Google Chrome had seen it’s full release in 2008, Mac had Safari as it’s bundled browser which saw a decent market share, and whilst Mozilla Firefox had risen from the ashes* of Netscape Navigator in the early 2000s – it hadn’t quite gained the traction of it’s predecessor. Microsoft had won the first Browser War, and was calling the shots in a fragmented landscape of standards support.

For us developers at the time. This meant a lot of work was required to get websites to render and interact in the same way across all browsers. Bearing in mind that at this time – a website was, in most cases, considered to be a fixed width – usually 800 or 1024 pixels wide. Clients felt this to be immutable, and pixel perfection was the dragon to be chased. Designs needed to be wrangled to work in IE8, IE7 and most awkwardly IE6. As well as these new fangled browsers which on the whole followed the standards laid out by the W3C

Enter, the IE6 Guy

My first job title was “HTML and CSS Developer” – no JavaScript huh? Well actually, yes, no JavaScript.

At this agency, my role was to take the design “flats” produced by an external designer and convert them into static HTML and CSS templates. These templates were then pass upstairs (literally) to my colleague, who applied them to an in house CMS.

But why no JavaScript?

This was never explicitly explained, and in truth, was never a hard and fast rule. It slipped over time as we strode to achieve certain things like boxes in a row being the same height without using tables (no Flexbox yet Jimmy, that comes later).

The main reason for no JS (and no table layouts) was SEO. Whilst we weren’t measuring page speed or weight directly, SEO was the most important element of the websites development lifecycle in this agency and era. Tables were seen to be bad for crawling. JavaScript slowed the page down, or confused the crawler. I didn’t know if any of this was true, but I trusted the expert and tried my best to accomodate.

So, couple this pursuit of pixel perfection, fragmented browser landscape and JavaScript (and table) avoidance – a lot of CSS magic was required. I quickly became known as the IE6 Guy in the office. IE6 was the least standards compliant browser still in circulation, and required a lot chicanery to get it to render a layout which had worked perfectly well in its successors, and Chrome/Firefox/Safari. The latter three were now being called “evergreen browsers” due to their stronger standards compliance and regular updates. I probably wasn’t doing anything special, and it may have been tongue-in-cheek at times, but designs or mostly built templates were often passed to me to make them play nice in IE6

The fall and rise of CSS Guy

In the years and jobs which followed, I continued leaning in to semantic HTML and standards compliant CSS to do most of the heavy lifting for me. This early career restriction led to me priding myself on the fact that if I could avoid JavaScript for a simple layout issue, I would. Although I was happily making use of jQuery for interaction where relevant.

I look back now this is what fills me with the most nostalgia.

I would however, often cast an eye over certain colleagues work with JavaScript, particularly at conferences and meetups, and feel a bit out of the loop (excuse the pun). This was even more apparent during the early rise of JavaScript frameworks such as React and Vue. I often felt a pang of “Imposter Syndrome” – I wasn’t a “proper front end developer” as I wasn’t crafting App like experiences. This led to a pivot in my career in the late 2010s – and a move to building more JavaScript based experiences.

Which brings me to present day, where my career has definitively moved into the “middle-end” space in my main job at least. I work on a large app, straddling the line between Front and Back end, JavaScript and PHP. I love this job, and the evolution in my skills it symbolises. The scale of the product naturally meant using CSS more as a tool than a craft, with Bootstrap helping us deliver consistently. It’s been a great chance to grow my JavaScript and PHP skills while still leaning on strong front-end foundations.

However, over the past year, I have rediscovered the joys of handcrafting CSS through freelance work and personal projects. And whilst the language has got a lot more complex than it was in my “salad days”, browser support is near universal, which makes it a joy to work with. Flexbox and Grid are the obvious evolutions over the past decade or so. But there are so many little treats I keep discovering.

Looking back, being the “IE6 Guy” shaped more of my career than I realised at the time. It forced me to lean into clean HTML, standards-driven CSS, and problem-solving without shortcuts. Even though I’ve since dived deep into JavaScript and the “middle-end”, I’ve come full circle in rediscovering the craft of CSS. The tools may have changed, but the joy of making something beautiful, accessible, and functional with just a few lines of well-written code hasn’t. And that’s what keeps me excited to open my editor every day.

Trends will keep changing, but the developers who thrive are the ones who enjoy the craft itself. That’s why I still get excited about CSS, two decades on.

Sometimes the skills you thought you’d left behind are the ones that bring you the most joy

_{* it’s original codename was Phoenix}