Why JavaScript, why now?

Earlier this year I left the comfortable world of XAML and WPF behind and began developing almost exclusively in JavaScript. My daily focus has also switched from developing desktop applications to Single Page Applications (SPAs) using ASP.NET MVC and KnockoutJS: but, as we’ll see, JavaScript does not restrict me to web development.

I was discussing this change of direction with a good friend of mine and he asked whether that wasn’t a little extreme. I suppose it would certainly seem that way, especially for someone who has made a name for himself in the XAML community. I would not make such a drastic change lightly. I thought long and hard before making the move and, after twelve years in one place, I even changed jobs to facilitate the effort. I thought it would be worthwhile to share some of my reasoning behind this latest change of direction.

Not long after I had made the switch, I had the pleasure of hearing Douglas Crockford speak at a conference. Mr. Crockford, as most people insisted on calling him, is the author of “JavaScript the Good Parts” (by O’Reilly), JSLint, and JSON, and is a member of the ECMAScript Standards body. I’ll never forget the quote he made that “JavaScript is tragically important”. My one line take on this is that, for all its faults and foibles, JavaScript cannot be ignored.

JavaScript is ubiquitous. Every PC, Mac, laptop, tablet, slate, netbook, ultrabook, and smart phone that is out there in the wild today runs JavaScript. It’s already there, it’s already installed, and it’s amazingly consistent across the different operating systems and devices. It took a while for me to realize that JavaScript comes closer than either Java or .NET to fulfilling the old promise of “write once run anywhere”. If for no other reason than universal reach, JavaScript is a serious language.

The ubiquitous nature of JavaScript means that the pain of framework and platform deployment is a thing of the past. The browser is the platform, the Internet is the deployment model. Thanks to the browser manufacturers there are no frameworks to deploy, no installers to execute, no administrator permissions issues, and virtually no versioning issues. Regardless of your personal feelings about JavaScript it is undoubtedly the single most important computer language in the world today.

JavaScript: it’s not just for browsers anymore

In recent years the reach of JavaScript has begun to extend beyond browsers and the Internet. Thanks to projects like Node.js JavaScript is now being used to develop server applications. These applications have no Document Object Model (DOM) and don’t run in the browser: they are real server-side applications. The introduction of headless unit testing tools, such as PhantomJS and Zombie.js, built on Node, demonstrates that you don’t have to have a browser to run JavaScript.

For Windows 8, Microsoft made an unprecedented move and elevated JavaScript, HTML, and CSS to a first class development stack for creating Windows Store Applications. This is not some specialized version of JavaScript: these applications leverage the same Chakra engine that runs inside IE10. That means you can use the same JavaScript you use for web applications to develop Windows Store Applications, including the use of third party libraries. This move makes it conceivable for web developers to create Windows Store Applications using the same core technologies they code with every day which reveals the true reason I decided to become a JavaScript developer: I now have a single technology stack that allows me to develop for the web, servers, and even Windows.

I’ve been asked several times recently, in the context of Windows 8 development, which stack a developer should select. My answer is simple: if you already know XAML and C#, then that is the obvious choice. If you are a web developer and already know JavaScript, HTML, and CSS, then that is the obvious choice. But what if you don’t know either? Maybe you’ve only done WinForms or FoxPro development, what then? The hands-down winner is JavaScript. I believe that, in the current state of technology learning, JavaScript is the best investment you can make for your career. In fact, I believe that, in the near future, JavaScript will be an essential tool in virtually every developer’s toolbox.

But everyone hates JavaScript

I’ve heard many developers say “I hate JavaScript”. In the spirit of full disclosure, I’ve said it myself any number of times. Most people who have encountered JavaScript have felt this way at one time or another. What I’ve come to realize, however, is that we unfairly blame JavaScript for things that are not its fault.

A lot of developers first encountered JavaScript during the browser wars when it was a significant challenge to develop websites that worked equally well across the different browsers. If you don’t remember web sites with “Works best in IE” badges, count yourself lucky. The good news is that the wars are largely over. The bad news is that nobody won, it is more of an uneasy truce. Any experienced web developer will tell you that DOM manipulation stinks, but we should not blame JavaScript for the shortcomings of the DOM API.

JavaScript is a wolf in sheep’s clothing. It is a functional, dynamic, loosely typed language with a C-inspired syntax. The visual similarity to languages such as C# and Java is unfortunate because it misplaces developer expectations. At first glance it looks as if curly braces should define scope, that “this” should refer to an instance of a class, and that “==” means equality. None of these things are correct. The problem is that as developers we expect JavaScript to function like Java or C#, and we are often surprised by the differences. Because it is so easy to make incorrect assumptions about its behavior from its syntax, and because the language is so flexible, it is very easy to code one’s self into trouble. This is not the fault of JavaScript but rather our own flawed expectations. To overcome this issue, we must embrace what JavaScript is instead of lamenting over what it is not.

Before I get a slew of messages telling me about all the stuff that’s wrong with JavaScript, I am not saying that it doesn’t have its difficulties, or as Mr. Crockford would say “bad parts”. Like any language, it’s up to us developers to learn how to use the language effectively. This can be a painful process, again largely because the syntax looks so similar to the languages we know and love. I believe that, if you invest the time to become familiar with it, you will find JavaScript to be a flexible, powerful, and very usable language.

The importance of 3rd party libraries

Modern developers have become accustomed to frequent and volatile shifts in technology, but JavaScript has largely escaped this phenomenon. While JavaScript has been around for nearly 20 years, it has only had a handful of major updates. ECMAScript 3 (ES3) was published in 1999, skipped a version, and ES5 was published in late 2009. This stability is a welcome change from the frenetic pace of most other technologies. It is also an understandable necessity: JavaScript can’t afford to move fast because of the sheer number of websites and applications that use it. A breaking change in .NET is inconvenient for the developers, but a breaking change in JavaScript would have disastrous implications across the Internet.

This isn’t to say that the JavaScript ecosystem is stale, in fact it’s quite the opposite. Third party libraries have improved the JavaScript development experience dramatically by abstracting away many of the more troublesome aspects of developing JavaScript applications. There are many libraries that mitigate things like DOM manipulation, publish/subscribe operations, string manipulation, and much more. And there are new libraries being published all the time. The open source nature of JavaScript development should ensure this trend will continue for some time to come.

Another great point about third party libraries is that including them in your application is only a script tag away. They don’t need to be compiled into your application and you don’t need to ship DLLs or packages. In fact, you have several options for importing the JavaScript into your site. You can store copies of them locally and deliver them from your server (preferably bundled and minified), you can reference files stored on the publisher’s server, or you can reference a Content Delivery Network (CDN) for optimum performance and availability.

Of course, you don’t need to use third party libraries at all. Anything these libraries can do you can do in plain old JavaScript. Some people even argue that you should not use third party libraries, at least until you learn the language itself. The argument is sound: you should know what a tool is doing before you use it.

Another concern with third party libraries is performance. Performance tests indicate that plain old JavaScript can be up to an order of magnitude faster than third party libraries for core operations such as looping and querying the DOM. In many applications this is almost unnoticeable, but the more complex an application, the more it could benefit from better performance.

Personally, I like the additional libraries, but these are valid concerns. If you want to read more about this, and have a good laugh in the process, check out http://www.vanilla-js.com.

Moving forward

A quick search of any of the major job sites shows that the demand for skilled JavaScript developers is high. This is no surprise given that web applications run on every conceivable device and constantly grow more sophisticated, and the engine that drives those applications is JavaScript.

JavaScript is a vital language. It has power, flexibility, and most importantly, unprecedented reach. You can use it to develop web sites, server applications, and Windows Store Applications. I even recently heard someone say that JavaScript is the new Assembly language.

Whatever your personal feelings about JavaScript, I think the verdict is clear: it absolutely should be in your toolbox. If you want to strengthen your career and enhance your options, learn JavaScript. Who knows, you might even find that you really enjoy it, but just be sure to avoid the bad parts.