I’m the author of ChocolateChip-UI, a framework for building hybrid mobile web apps. Over the years I’ve written libraries for DOM manipulation and animation. I write code every day, for hours. I’m chained to my NPM/Node build tools. Heck, I write my own build scripts. I’ve done Grunt, Gulp, NPM and straight up Node scripts. I bundle with whatever – Browserify, Webpack, JSPM. Sometimes I fall asleep at night with my laptop in my arms. And when I wake up in the morning I push the previous night’s code to Github. Sometimes I have trouble sleeping because I spend the whole night dreaming of coding while trying to figure out a weird bug I discovered the day before. And sometimes I even wake up with the solution.
I’m 67 years old, pushing 68. I have cataracts and glaucoma, so I sometimes have problems reading other people’s code, or even my own. Sometimes I have dizzy spells. I have numbness in my feet that can make it hard for me to walk. Yeah, I’m getting old. But you know what? I’m not suffering from JavaScript fatigue. Every time I hear someone complain about JavaScript fatigue I feel like screaming. For me, JavaScript and its ecosystem are not moving fast enough. Don’t tell me I’m going to have to wait until I’m 72 before all the browsers that don’t support ECMAScript 2015 are gone. I want them gone like last month already. Sheesh! I want to see my beautiful ES6 code working with all its goodness in browsers now, not transpiled by Babel into ES5 mush for old fogie browsers. When I have to go back to ES5, I feel like I’m looking at the cave scrawls of Neanderthals. Don’t even get me started on async and await. Why has this taken this long???
For you new guys just starting out in life as Web developers and complaining about the JavaScript ecosystem, let me tell you something. I started on the Web back in ‘93. I had the ViolaWWW browser. Yup, that mouthful was it’s real name. There was HTML 1, and no image tags. The web was text only, nicely formatted with semantic markup because that’s all there was. And links. I still remember when the image tag was introduced by Marc Andreesen in 1994. It was shocking. Some digerati said it would be a disaster. We would be buried alive in an avalanche of cat pictures. Sadly, they were right. Oh yeah, and the font tag. This dinosaur still lives and functions in browsers today. Before HTML 4 we used it for all text. It had attributes that let you set a font’s family, size and color. In those days all text on the web was enveloped in a tangled mesh of font tags. It wasn’t untile CSS came into wide use in this milenium that use of the font tag fell by the way. It was formally deprecated from the HTML standard in 1998, but lives on in old content to this day.
Back in those days, before JavaScript, the Web was simpler, you could build a Website with static markup. Except that many businesses needed dynamic content. So they installed Apache on their servers with Perl, PHP, ASP and JSP. If you wanted to be a Web developer, you had to learn one of these. Perl was always the first choice for speed. Developers loved Perl because there were so many ways you something. This meant it was always a challenge to read and understand other developers’ Perl scripts.
In 1994 I started using a new browser, Mosaic. It later became Netscape Navigator. In 1995 JavaScript shipped in Netscape Navigator, except that it was called LiveScript. That same year Microsoft shipped their own browser, Internet Explorer. A year later Microsoft added a scripting language called JScript to Internet Explorer. It was backward engineered from JavaScript, but it was not JavaScript. They shared things like variables, loops and conditionals, the standard stuff. After that, everything was different. I’m talking about the DOM. You could not implement a button click, a callback, or a DOM manipulation in the same way. Internet Explorer and Netscape Navigator had incompatible interfaces for their browser DOMs. In fact, they had different ideas about what constituted the DOM. To do anything cross-browser, you had to test the browser before branching off to browser-specific code. You could never duplicate the same experience in both browsers, their DOMs were that different.
Into this mess of incompatibilities was born the revolution of DHTML. That stands for Dynamic HTML, just so you know. It was like a dam burst. Everybody and their brother started writing DHTML libraries. There were thousands. Some were alright, but most were crap. Some were very focused on a single widget that tried to replicate the same interface and behavior across browsers, but this never turned out very good. Some libraries tried to be generic for things like animation. Thus tasteless and unnecessary animation thingies began to proliferate on the web, because why not? These were the 90s, when no one browser ruled the roost. So you had to support them all. During these wild times I also wrote DHTML libraries (blush). At the time, they seemed like the solution to the anarchy of Web development caused by incompatible DOM implementations.
To be honest, the failure of DHTML libraries was not their fault. They were working with such a nasty situation. You know, after you put enough lipstick on a pig, it stops looking like a pig with lipstick and more like a messy pile of lipstick. During these dark times, the W3C worked out the first recommendation for HTML4 and JavaScript 3 for browser vendors to implement. This included a proposal for a standarized DOM interface for browser vendors to follow. Netscape, who by 1999 had begun losing considerable marketshare to IE, was hard at work on a new version of Netscape Navigator that would support those proposed standards. Even Microsoft half heartedly embraced them while creating IE6. But since Microsoft had so much marketshare, they didn’t think they had to implement everything the standards body recommended. After all, it was only called a recommendation. They adopted some parts, and winged it with the rest. That’s how the unholy IE6 was conceived. Microsoft kept in support for a lot of the whacky things they had done in previous versions of IE. As a result, IE was incredibly buggy.
The choice to not fully accept standards would come back to haunt Microsoft, but much later. Meanwhile, in 2000 Netscape finally shipped Netscape Navigator 6. It had the real DOM. It made sense, it was easy to wire up events on elements, it was easy to style, and it was easy to change styles dynamically. It was what we had always wanted in a browser. What a breath of fresh air. But the developers who embraced Netscape Navigator 6 were a tiny group. Most developers were already developing websites that only worked with IE6. If it didn’t work with IE, nobody would bother with it. IE6 was job security. It was backed by Microsoft. The first round of browser wars were over. Microsoft won.
After the launch of Netscape Navigator 6, people started publishing tutorials about how to do things with the new DOM standard, things that you couldn’t do easily or at all in IE. But businesses only cared about what worked on IE6. You could never get a client to let you build a site that also supported Netscape 6: “But our customers prefer IE”. This was partly Netscape’s fault. The Netscape browser, while supporting standards, was a horrible user experience. The browser was an interface to the world of Netscape, which included AOL. This meant constant nagging to view channels and ads, ads, ads. Sound familiar? Netscape Navigator was so bloated by the AOL parts that it took forever to load, and it was sluggish to use. In contrast, IE loaded quickly. And all the websites looked proper on it because developers made sure of that. There was no money to be made supporting Netscape Navigator.
During this time of darkness when the Internet stagnated under the dictatorship of IE6, Netscape decided to spin off an open source project called Mozilla. Some developers there took the Netscape browser, striped away all the AOL and Netscape branding and created a streamlined browser that supported the new standards. It shipped in 2002 and was called Phoenix. Later they changed the name to Firebird before finally settling on Firefox in 2004. Slowly Firefox clawed its way up from the depths of obscurity and irrelevance, changing the way people thought about the web as a platform. This would later lead to the birth of Safari and Chrome.
Firefox turned the browser market upside down, and even Microsoft was forced to support standards they didn’t create. But Microsoft wasn’t going to concede quietly. They took one more stab at trying to dominate the Web. Only this time they wanted to completely replace HTML and JavaScript with their own technology. HTML was a joke for presentation and JavaScript was the worst language in the world. So they created Silverlight. It ran on their .NET platform. For markup it used XAML, a variant XML, and their C# language for interaction. All those guys who only knew how to support IE took up Silverlight. I even did some work with it.
For a while it looked like Silverlight would replace HTML and JavaScript and Microsoft would determine what the Web platform was. But a funny thing happened. In 2007 Steve Jobs introduced the iPhone. It was touch-friendly. It had a desktop-quality browser. But there was no public SDK for making apps. Steve told everyone to user Web standards to write Web apps for the iPhone. The most significant thing about the iPhone browser was that it did not support plugins, so no Flash or Silverlight. That earthquake knocked the foundation out from underneath Flash and Silverlight. They would never recover.
With the rise of Firefox, Safari and Chrome, Web developers no longer had to be on Windows. They could work on the Mac or Linux. This resulted in a tectonic shift of Web developers from Windows to other platforms. Minds were opened and developers explored their options and tried new ways of doing things. It was like that quote from Mao: “Letting a hundred flowers blossom and a hundred schools of thought contend…”
And here we are today. Deelopers are complaining about JavaScript fatigue. You don’t realize how lucky you are. Browsers follow standards. And most standards originate from developers who are looking to make our craft better. From my perspective, we are in a Golden Era of Web development. Yeah, there’s a lot going on. That’s not new. JavaScript is not static, it’s a moving target. Every new feature will nudge developers to think how to do things differently. Then they will come up with new patterns and libraries and frameworks. Do you need to learn everything that comes along? Well do you have to listen to all music that gets produced?
Here’s a strategy. Do exactly what you need to be doing right now. But on the side, when you have some spare time, check out other libraries and frameworks. That means just read about them. Pick one that you find interesting. Download it. Look at some examples. Does it make sense to you? Do you find the approach interesting? Look for some tutorials. Keep it simple. No need to rush in. After a couple of weeks you’ll realize if it’s not for you. At least you will have learned something. Go read blogs, explore Github. Wonder off the beaten track. You won’t get mugged. You can always go back to what you were doing before. One thing though, you can’t be complacent. If you’re unwilling to learn new things, you’ll wind up like the IE only guys – out of work.
JavaScript fatigue is not the fault of JavaScript or the Web. These are only getting better. Your fatigue means there’s something wrong with you. What are you doing that’s causing you such fatigue? Are you just bored? Have you lost interest in Web development? What has changed? Maybe you could use a career change. People change careers all the time. There’s nothing wrong with that. In fact there’s plenty good about it. But please, don’t blame us for your fatigue. It’s like runners in a marathon blaming the other runners for their fatigue.
Stephen Hawkings has severe physical limitations. I’m sure he has frustrations. Yet he doesn’t let that stop him from exploring and communicating the most profound things about the universe we live in. For me, I’ll stop coding when I can no longer stitch together two coherent thoughts. Let your imaginations run free. Try something you’ve never tried before. Maybe go do something totally different from what you’re doing now. You don’t have to do big things. Many little somethings combined become something big. That’s all programming is, really – 0s and 1s. Let a million frameworks flower and millions of developers code.
