JSConf Down Under: A Conference Report

16 Nov 2012 JSConf Down Under: A Conference Report

I attended JSConf Down Under yesterday. The conference format was quite straightforward: one day, one stream, nine speakers. In this post I’ll talk about the three things at the conference that had the biggest impression on me: Brendan Eich’s presentation on The State of JavaScript; Isaac Schlueter on the new Node.js streams; and the JavaScript community as a whole.

The Future Of JavaScript

A highlight of the conference for me was seeing Brendan Eich – the creator of JavaScript – speak on ‘The State of JavaScript’. His overview of upcoming proposed features for JavaScript was interesting, particularly a brief mention of introducing coroutines to simplify asynchronous coding.

Most recently popularised by languages like Go, coroutines remove much callback cruft. Furthermore, it’s heartening to see that there are already simple pre-compilers on Github out that add features such as this to the JavaScript language. This leads me to my favourite quote for the day from Brendan: ‘Github beats PhDs every time’.

Speaking of compilers, it was also of interest to me that Brendan has bought whole-heartedly into the notion of JavaScript as the ‘assembly language of the web’ – a platform to which other languages can be compiled.

He took this even further by asserting that JavaScript is far better compilation target than Java bytecodes. Whilst I don’t think that Java bytecodes are going to be disappearing from the server-side any time soon, I agree that the failures of first Java applets and now of Flash certainly open up the possibility of JavaScript being the machine language of the web-browser. Furthermore, I agree that a functional language might make a better compilation target. However, I think the biggest barrier to the practicability of ‘JavaScript as Assembly Language’ is lack of a standard client-side module definition.

Say what you will about Java class files and Jar files, but they’re a standard. The strength of the JVM as a platform is that no matter what language you’re using, you can still access libraries written in other languages. It’s a chief selling point of Scala, Groovy, JRuby and Clojure.

So how’s it going to work if we’re all compiling to JavaScript? It’s been hard enough for those of us writing plain client-side JavaScript to agree on a standard for modules; there’s CommonJS, AMD, and even plain-old global namespacing. How’s it going to interact when we’re all writing in different languages that compile to JavaScript?

And even if we were to standardize on a module definition, what about class definitions? Hard-core JavaScripters can say what they want about the reduced need for classes in a functional world, but the fact remains that classes are a concept now understood by the majority of developers across all languages.

Currently I can subclass Backbone classes with CoffeeScript, but this probably has something to do with Backbone and CoffeeScript being invented by the same guy. What if I wanted to use Backbone with another language that compiles to JavaScript? At best my other language will have to give me access to the basic JavaScript primitives that let me put a shim around the Backbone classes – which in turn requires me to have a some understanding of how classes have been implemented in Backbone.

I support the idea that JavaScript could be the ‘assembly language of the web’. However, it’s going to be a while before the proposed module system for ECMAScript becomes a reality, yet there are already a number of languages out there that compile to JavaScript. I hope that lack of a shared module definition across languages isn’t a problem.

Node.js Streams

Isaac Schlueter was another highlight of the conference. Perhaps best known as the creator of NPM, on the day he was actually speaking about the rethink of streams that is upcoming in Node.js 0.10.

Isaac did a great job of explaining the drawbacks of the current API, as well as how the new API will fix those problems. Essentially it boils down to the old API continually pushing data at you – whether you can handle it or not – versus the new API simply telling you when data is available, but letting you decide when you’re going to get it. The old API required many module developers to implement their own buffering, which is both hard to do and represented a duplication of effort. The new API avoids the need to do buffering at all.

For those concerned about how the changes will affect their existing Node.js apps, the old APIs will still be available, but built on top of the new API. This means your code won’t break, and in the event that you’re currently using pause() to try and hold back the firehose of data, may even work a little bit better for you.

I hope this is the last big change to Node.js before a 1.0 release. Isaac himself admitted to a grudging acknowledgement of the need to stabilize the API. He also confessed that the new approach is something that even the venerable Unix stream programming model supports.

Perhaps it’d good to get some more old, experienced eyes over the approaches that Node is taking. I want Node.js to be more than just a platform for the current generation of talented hackers to relearn lessons that previous generations have encountered in the past. I want it to be the best of the new and the old.

The JavaScript Community

If I had to identify a theme running through the conference, it would be diversity. Talks covered the growing gamut of applications for JavaScript: traditional client-side, the emerging server-side, games, mobile – even home-automation applications.

As a developer that has built large applications with first Java, then Ruby, and now JavaScript, I’ve been able to observe the cultural differences that exist between their respective language communities. As an outsider looking in, I admire the JavaScript community for their openness and friendliness. They also don’t take themselves very seriously in comparison to other language communities. This is a good thing.

I wonder whether this is because JavaScript wasn’t originally taken very seriously by the wider software development community. The irony is that, with JavaScript actually being a pretty powerful functional language (albeit with a few unpleasant edges), many modern JavaScript developers are familiar with some rather sophisticated programming techniques.

Language details aside, their roots on the bleeding-edge of web development make JavaScript developers very creative and always probing what’s possible with the latest standards. Furthermore, there’s a big emphasis on working demos rather than theoretical speculation.

The only drawback to all of this – in Australia at least – is that the focus on new and novel applications of JavaScript draws attention away from sharing experiences writing ‘JavaScript in the Large’ – in other words, the techniques we can use for building large JavaScript-intensive sites.

Perhaps we don’t build enough of these sites in Australia, although that seems unlikely. I suspect it’s more just an understandable legacy of JavaScript’s history. Nevertheless, I hope to see more people sharing their real-world experiences of building large-scale JavaScript applications at future meetups and conferences in Australia.

Summing Up

JSConf Down Under was a great first-stab at a dedicated JavaScript conference in Australia. Perhaps next year we can have multiple streams, allowing some room for real-world experiences with large-scale JavaScript projects. I enjoy being around the JavaScript community and look forward to seeing it develop as the language becomes an increasingly important part of the IT landscape. I hope they can mature as their language ascends from its original lowly status, and yet also retain their admirable friendliness and openness to new ideas.