Is JavaScript ready for serious development? – Part III

This is the third part of a series of posts where I’m trying to establish whether JavaScript is ready for serious development.

Previously, I pointed out some major inadequacies of the language but as developers, we’re used to working with non-ideal languages in non-ideal platforms with ridiculous deadlines. We just get stuff done, so it shouldn’t be a big deal for a software craftsman that JavaScript lacks a few modern language artifacts, right? Besides, what about the simplicity of JavaScript? Isn’t there some value there?

I agree and that was the spirit I tried to keep up during my project. However, when you have a language that runs inconsistently on different screens, you lose the positive energy you try to uphold so hard.

In Flash or Java, you don’t really need to worry about the run-time too much because Flash Runtime and JVM provide mostly consistent environments for your applications to run in. Even though JavaScript is supposed to be based on standards, there are many inconsistencies among browsers.

To be fair, most of these inconsistencies are due to our big old friend Microsoft and their Internet Explorer but it’s still hard to ignore Internet Explorer, so you need to deal with these inconsistencies on your own.

During my time with Java and Flash, I ran into maybe 2 or 3 issues that are browser or operating system specific. In my 1 year of JavaScript development, I ran into at least 10, if not more, issues with browser inconsistencies.

For example, Array.indexOf is a function that is supported by bunch of browsers like Firefox, Chrome, etc. but not in Internet Explorer. You don’t know that until you run your application against Internet Explorer.

Another example is XML support. In most browsers, you have DOMParser but in Internet Explorer, you need to use the ActiveXObject.

Yet another example is XMLHttpRequest. Most modern browsers handle it one way but in Internet Explorer 6, you need to use the ActiveXObject again. Even the ones that handle it regular don’t do it consistently. For example, in Firefox, when you try to send a POST request where the first byte is zero, the POST body is dropped.

For byte array support, Firefox has a XMLHttpRequest#sendAsBinary method but it’s not a standard so others don’t have it. Internet Explorer has some byte array support but it’s VBScript and not a standard again.

In HTML5 space, I don’t have much experience other than WebSockets and that is a little messy itself with some browsers supporting hixie-76 version, some supporting hixie-76 in disabled mode, some not supporting at all, and some planing to support hybi-10 I’m sure there are more differences in other areas like CSS or UI stuff.

So how do you deal with these? Unfortunately, there’s no great solution. Frameworks like JQuery somewhat helps with these problems but again with my Java and Flash background, I expect the language to work consistently across different screens and I find it a little backwards that I need to depend on a framework to do the right thing.

Any time spent in cross browser issues is wasted time in my opinion and you’re going to waste time in cross-browser issues and that seems to be an accepted fact of life in the JavaScript land.

In our project, we didn’t want to depend on any external frameworks, so we created a central class to deal with cross browser issues and it helps that there’s one central abstracted place for all cross-browser issues but it’s far from ideal.

The main lesson here is that you really need to test your application against all browsers that you claim support for all the time because something might break in some browser at any time. You don’t have the luxury of assuming that “it should work” like you do in Java or Flash applications because you don’t have JVM or Flash Runtime to provide some kind of stability across different screens. In JavaScript land, you need to treat every browser as similar and yet different implementations and you need to keep reminding yourself that over and over again.

All of this is probably obvious to JavaScript developers but cross browser/operating system capability is something Java and Flash developers have been taking granted for some time now, so it feels like a step backwards having to think about these issues again. Thankfully, our friends at Google created tools such as Closure Compiler, Closure Linter around their Closure Library that helps with some of these issues and I hope it becomes some kind of standard or somehow seeks into the language itself, so everyone gets these benefits by the mere virtue of using the language.

The key is to have great and automated tests that you can easily run against different browsers but which one to use? That’s a whole different topic that I’ll cover in my next post.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s