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.
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.
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.
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.
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…”
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.
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.