Constraints and compromises in ECMAScript 6

This past week I attended a talk by Dave Herman, an employee of Mozilla and member of ECMA TC39, who are in charge of the standard for JavaScript. Dave talked about a few of the features and improvements coming to JS in ECMAScript 6, including, what I think is the most exciting and desperately needed: the new module system.

I won't describe how the new module system actually works in this post, as that information is already available elsewhere (in particular at the ES Wiki). While this new module system looks great, I was concerned with the fact that it eschews the current community built around Node and its CommonJS module loading system. I asked Dave what the reasoning for this was. It boiled down to wanting to provide features for module loading which would not be possible using Node's current CommonJS system. Interoperability between client and server side JavaScript programs will eventually be achieved by converting existing code targeted for Node to the new module system.

While this may be a painful migration due to the amount of existing code using CommonJS, it seems like the best choice, given that the amount of JavaScript code targeting Node is dwarfed by the amount targeting the browser. Node will also be able to begin the conversion process fairly soon, as it only needs to wait for the implementation of ECMAScript 6 modules in V8.

Another feature Dave talked about was variable interpolation in strings via so-called quasi-literals. This feature is something very common in other high level languages, but to date JavaScript has relied on the concatenation of strings and variables with the + operator to achieve this. ES6, somewhat confusingly, uses the ` (backtick) to surround these quasi-literals and interpolates variables with ${varname} syntax. I was also curious about the reason for this awkward choice, given Ruby and CoffeeScript's precedence for using double-quoted strings with embedded expressions in #{}, but Dave had the answer. Backticks were chosen for backwards compatibility. If existing strings were to suddenly gain this ability, existing code on the web that happened to have literal occurrences of ${ in them would become syntax or reference errors. The most important constraint TC39 must embrace, unlike languages which compile to JavaScript, is that changes to the language must not break existing code on the web.

Backticks, even though they are often used to execute shell commands in other languages, were chosen simply due to limited set of ASCII characters remaining for new syntax. Again, the syntax they chose here is not ideal, but given the constraints necessary for advancing JavaScript without breaking the web as it exists today, it's a pretty decent compromise.

I'd like to thank Dave again for his talk. I'm looking forward to ES6!

New city, new job, new life

I haven't posted anything about myself in a while, so I'm happy to present this news: I have moved from San Diego to San Francisco, and am now happily employed by Change.org. This move was a long time coming. Many of my friends in college were from the bay area, as well as more friends I met through those friends. Everyone talked it up and seemed eager to return. In addition to the social motivation, San Francisco has a climate and culture that is much more akin to my taste. It's also one of the biggest tech hubs in the world, so career-wise it was a great choice as well.

I just finished my third week as a software engineer for Change.org. I'm happy to be spending my day working with technologies I love (Ruby, Rails, JavaScript, etc.), and even more so to be doing it to support a company with an awesome mission. Change.org has been receiving a lot of press lately and is growing very fast, and it's exciting to work for a company whose success I have a real interest in.

Other than one scary incident on a Muni bus, San Francisco has been a blast to live in so far. I'm enjoying the overwhelming amount of places to eat, the ease of getting around, the cool weather, and the cool people I've met so far. Meeting people in the Ruby and open source communities I've only followed online has me a bit star struck.

I will miss a few friends and the San Diego Ruby community I left behind, but San Francisco is clearly where I belong. Here's to a fantastic 2012 and beyond.

Bang goes 1.0, now with Hubot support

I just released version 1.0 of my command line utility, Bang. Bang is a simple key value store for quickly storing and retrieving text snippets. I talked about it in detail last month, so be sure to check out that post for samples of usage.

Version 1.0 merely fixes a few bugs and establishes the public API according to Semantic Versioning. Install Bang via NPM: npm install -g bang.

Perhaps the more exciting news is that you can now use Bang to smarten up your Hubot, GitHub's awesome chat bot! The Bang script for Hubot is available in the hubot-scripts repository. Clone the the repository, copy bang.coffee into your own Hubot's scripts, and add bang and shellwords to your package.json file. Deploy your Hubot and enjoy!

Page 5