Angelo DiNardi

Doin' shit on the web since 1995.

Taking Javascript Seriously: A response to "Breaking the Web with hash-bangs"

10 February 2011

Earlier this week Gawker sites experienced a site outage due, apparently, to some bad code they pushed. In the aftermath a lot of things were said, but one article stood out to me. I ran across “Breaking the Web with hash-bangs” and the rage boiled up inside.

While some good points are raised about the ability for bots/indexers/other software to handle the content on Javascript heavy sites (which I agree still needs more work) — the reasons listed against being dependent on “perfect Javascript” are just plain laughable. Unless, of course, you assume that every web application developer is a 10 year old kid.

He specifically calls out the following:

  • JavaScript fails to load led to a 5 hour outage on all Gawker media properties on Monday. (Yes, Sproutcore and Cappucino fans, empty divs are not an appropriate fallback.)
  • A trailing comma in an array or object literal will cause a JavaScript error in Internet Explorer - for Gawker, this will translate into a complete site-outage for IE users
  • A debugging console.log line accidentally left in the source will cause Gawker’s site to fail when the visitor’s browser doesn’t have the developer tools installed and enabled (Firefox, Safari, Internet Explorer)
  • Adverts regularly trip up with errors. So Gawker’s site availability is completely within the hands of advert JavaScript. Experienced web-developers know that Javascript from advertisers are the worst lumps of code out there on the web.

All of these summary points are easily dealt with by any half decent Software Engineer. Let’s look at these one at a time:

  • JavaScript fails to load led to a 5 hour outage on all Gawker media properties on Monday. (Yes, Sproutcore and Cappucino fans, empty divs are not an appropriate fallback.)

There’s a couple of things that irk me about this. First, why does there have to be a fallback? You don’t see people building in fallbacks for when their images or css doesn’t load. There are files which are simply expected to load and it is a critical failure if they don’t.

I relate Javascript files loading for a site on the same level of criticalness as any Python/PHP/etc file. If one of those don’t load on the server I’ll bet that you don’t have much of a fallback. The server won’t function. Same thing happens on the client — if a critical file doesn’t load, then you need to fix it. I believe that your Javascript files not loading should be in the “this should never happen” bucket.

  • A trailing comma in an array or object literal will cause a JavaScript error in Internet Explorer - for Gawker, this will translate into a complete site-outage for IE users

Sure, a simple thing like a trailing comma can break everything. If I mess up the syntax of some code in Python, should I expect that things will just work as expected? If I leave off braces or semi-colons in my C++ code, should it still compile without issue? Any competent developer should know how to handle IE already.

This also irks me because anyone writing software should test that software on supported platforms. If I release an iOS application I am expected to actually load the software on the devices I support and make sure it works. This is basic testing etiquette. Again, if you’re not testing you shouldn’t be writing software.

  • A debugging console.log line accidentally left in the source will cause Gawker’s site to fail when the visitor’s browser doesn’t have the developer tools installed and enabled (Firefox, Safari, Internet Explorer)

Once again, any Engineer with half a brain should know this. There’s also plenty of tools for Javascript which can help you avoid pushing such things out on to live sites. This is a problem with any software on any platform. I shouldn’t ship with debugging code. This, again, seems like it should be common knowledge at this point.

  • Adverts regularly trip up with errors. So Gawker’s site availability is completely within the hands of advert JavaScript. Experienced web-developers know that Javascript from advertisers are the worst lumps of code out there on the web.

Last I checked random Javascript errors on a page won’t break other Javascript executing on the page. Bad ad code can break as much as it wants, my Javascript isn’t going to have any issue running.

Now, if I write code which depends on their Javascript executing for a callback or similar — then that’s my fault. This is, again, not something that should stop me from using Javascript.

His summary of reasons why it is bad to be dependent on Javascript are all reasons why when you hire someone to develop Javascript based applications you need someone competent. If you hire someone with very little experience — then expect those easily avoidable mistakes. An experienced Web Application Software Engineer doesn’t even think about these things. It’s all second nature.

What’s the point?

The point is that once you take Javascript as a language seriously then such silly arguments go away. Although you could make similar arguments about Python or Obj-C, if you did everyone would laugh at you. There’s a certain expectation about competence when talking about writing code in those languages. Rookie mistakes are for rookies. Why are rookie web app engineer mistakes considered the norm?

The problem with Javascript is that people still don’t take it seriously. It is a hugely powerful technology and coupled with web browsers are incredible to develop for. Many people still have the 90’s stigma that Javascript is only useful for popup ads and the only people developing in it aren’t real engineers. That just isn’t true anymore.

What is it going to take for people to give up their old notions and accept Javascript as a “real” language and platform? There are some of us that do “real” engineering with Javascript every day.