JSConf US

I spent the weekend in Washington, DC attending JSConf.US 2010. I wasn’t able to attend last year, due to scheduling conflicts. Javascript is a bit higher on my radar these days, so this was a good year to attend.

The program

The JSConf program was very high quality. Here are some of the talks that I found most interesting.

Yahoo’s Douglas Crockford was up first and describe Javascript as a “a functional language with dynamic objects and a familiar syntax”. He took a some time to discuss some of the features being considered for the next version of Javascript. Most of his talk was focused on the cross site scripting (XSS) problem. He believes the solving the XSS problem should be the top priority of the next version of Javascript, and he feels that this is so urgent that we ought to do a reset of HTML5 in order to focus on this problem. Crockford thinks that HTML5 is only going to make things worse, because it adds new features / complexity. He called out local storage as one feature that would introduce lots of opportunity for XSS exploits. I was very surprised to hear him advocating a security approach based on capabilities. He mentioned the Caja project and his own proposal at www.adsafe.org. He stated that “ECMAScript is being transformed into an Object Capability Language; the Browser must be transformed into an Object Capability system”. This was a very good talk, and it caused a swirl of conversation during the rest of the conference.

Jeremy Ashkenas talked about Coffeescript, which is a language that compiles into Javascript. It has a very functional flavor to it, which was interesting in light of Crockford’s description of Javascript. It also seemed to be influenced by some ideas from Python, at least syntactically. I really liked what I saw, but I’m wary of the fact that it compiles to Javascript. I am not bothered by languages that compile to JVM bytecode, but somehow that feels different to me than compiling to Javascript. I’m going to spend some time playing with it – maybe I’ll get over the compilation thing.

Gordon is a Flash runtime that is implemented in Javascript.   Tobias Schneider caused quite a stir with his talk. He showed several interesting demos of Gordon playing Flash files that were directly generated by tools in the Adobe toolset. Tobias was careful to say that he doesn’t yet implement all of flash, although he definitely wants to get full support for Flash 7 level features. It’s not clear how Gordon would handle newer versions of Flash, because of the differences beween Javascript and Actionscript. Bridging that gap is probably a whole lot of work.

Since 2008 I’ve had several opportunities to hear Erik Meijer talk about his work on Reactive Programming at Microsoft. He’s talked about this work in the context of AJAX, and a common example that he uses is autocompletion in the browser. Jeffrey Van Gogh came to JSConf to talk about RxJS , a library for Javascript which implements these ideas and provides a better experience for doing asynchronous programming, both on the client and server side. In his talk Jeffrey described RxJS bindings for Node.js.  I also met Matt Podwysocki, who I’ve been following on Twitter for some time. Matt has been writing a series of blog posts examining the Reactive Extensions. One hitch in all of this is that the licensing of RxJS is unclear. You can use RxJS in your programs and extend it but it’s not open source, and you can’t distribute RxJS code as part of an open source project. I’m interested in the ideas here, but I haven’t decided whether I am going to actually click on the license.

I dont’ remember the first time that I heard about SproutCore, but I really started paying attention to it when I saw Erich Ocean’s presentation at DjangoCon last year. The original speaker for SproutCore couldn’t make it, but Mike Ball and Evin Grano, two local members of the SproutCore community stepped in to give the talk. Their talk was heavy on demonstrations along with updates on various parts of SproutCore. They showed some very interesting UI’s that were built using SproutCore. The demo that really got my attention was related to the work on touch/multiouch interfaces. NPR had their iPad applications in the App Store on the iPad launch day. Mike and Evin showed a copy of the NPR application that had been built in 2 weeks using SproutCore. The SproutCore version can take advantage of hardware acceleration, and seemed both polished and responsive. Dion Almaer has a screenshot of the NPR app up at Ajaxian.

Raphaël is a Javascript toolkit for doing vector based drawing. It sits on top of either SVG or VML depending on what browser is being used. In the midst of all the hubub about Flash on Apple devices, Dmitry Baranovskiy, the author of Raphaël pointed out that Android devices don’t include SVG, and thus cannot run Raphaël. Apparently people think of Raphaël as something to be used for charts but Baranoskiy showed a number of more general usages of vector drawing that would be applicable to every day web applications.

Steve Souders works on web client performance at Google and has written several books about this topic. His presentation was a conglomeration of material from other talks that he has done. There were plenty of useful tidbits for those looking to improve the performance of their Javascript applications.

Billy Hoffman‘s talk on security was very sobering. While Crockford was warning about the dangers of XSS in the abstract, Hoffman presented us with many concrete examples of the ways that Javascript can be exploited to circumvent security measures. A simple example of this was a simple encoding of javascript code as whitespace, so that inspection of a page’s source code would show nothing out of the ordinary to either an uninformed human or to a security scanner.

In the past, Brendan Eich and I have had some conversations in the comments of my blog, but I don’t recall meeting him in person until this weekend. Chris Williams snuck Brendan into JSConf as a surprise for the attendees, and many people were excited to have him there. Brendan covered a number of the features being worked on for the ECMAScript Harmony project, and he feels that the outlook for Javascript as a language is improving. Someone did ask him about Crockford’s call to fix security, and Brendan replied that you can’t just stop and fix security once for all time, but that you need to fix things at various levels all the time. His position was that we need more automation that helps with security, and that the highest leverage places were in the compiler and VM.

I’ve been keeping an eye on the server-side Javascript space. Ever since the competition between Javascript engines heated up two years ago, I’ve been convinced that Javascript on the server could leverage these new Javascript engines and disrupt the PHP/Ruby/Python world. If you subscribe to that line of thinking, then Ryan Dahl’s Node.js is worth noting. Node uses V8 to provide a system to build asynchronous servers. It arrived in the scene last year, and has built up a sizable community despite the fact that It is changing extremely rapidly – Ryan said he would like to “stop breaking the API every day”. In his presentation Ryan showed some benchmarks of Node versus Tornado and nginx, and Node compared pretty favorably. It’s not as fast as nginx, but it’s not that much slower, and it was handily beating Tornado. He showed a case where Node was much slower because V8′s generational garbage collector moves objects in memory. In the example, node was being asked to serve up large files, but because of the issue with V8, it could only write to the result socket indirectly. Ryan added a non-moving Buffer type to Node, which then brought it back to being a close second behind nginx. I was pleased to see that Ryan is very realistic about where Node is at the moment. At one point he said that noone has really built anything on Node that isn’t a toy. If he gets his wish to stabilize the API for Node 0.2, I suspect that we’ll see that change.

Jed Schmidt is a human language translator for his day job. In his off hours he’s created fab.js a DSL for creating asynchronous web applications in Node. Fab is pretty interesting. It has a functional programming flavor to it. I’m interested in comparing it with the RxJS bindings for Node. It’s interesting to see ideas from functional programming (particularly functional reactive programming) percolating into the Javascript server side space. In some ways it’s not surprising, since the event driven style of Node (and Twisted and Tornado) basically forces programmers to write their programs in continuation passing style.

I didn’t get to see Jan Lehnardt’s talk on evently, which is another  interesting application of Javascript (via JQuery) on the server side. I need to make some time to go back and watch Chris Anderson’s screencast on it.

The conference

As far as the conference itself goes, JSConf was well organized, and attendees were well taken care of. The conference reminds me of PyCon in its early days, and that’s my favorite kind of conference to go to. There was very little marketing, lots of technical content, presented by the people that are actually doing the work. I heard lots of cross pollination of ideas in the conversations I participated in, and in conversations that I heard as I walked the halls. I especially liked the idea of “Track B” which was a track that got assembled just in time. It’s not quite the same thing as PyCon’s open spaces, but it was still quite good. Chris and Laura Williams deserve a big hat tip for doing this with a 10 person staff, while closing on a house and getting ready for their first child to arrive.

Last thoughts

The last two years have been very exciting in the Javascript space, and I expect to see things heating up quite a bit more in the next few years. In his closing remarks, Chris Williams noted that last year, there was a single server side Javascript presentation, and this year the content was split 50/50. This is an area that you ignore at your own risk.


3 Responses to “JSConf US”


  • Thank you for giving an overview of jsconf. I was following jsconf closely and this post really helped.

    Crockford:
    ” he feels that this is so urgent that we ought to do a reset of HTML5 in order to focus on this problem. Crockford thinks that HTML5 is only going to make things worse, because it adds new features / complexity”

    Is Crockford or anyone taking any steps to improve the security in HTML5? Or is this just a beginning which might trigger action?

  • How is it different from PyCon these days, from your perspective? Other than by size, I guess.

  • Very Interesting report.
    Thanks a lot…

    I’d like to say
    +1 for Server-Side JavaScript
    +1 for Tracks B
    -1 for the Volcano

    I was coming to present a Server-Side JavaScript solution with NoSQL on Track B…and…

    Ok I won’t say bad words while other people can’t go home…

    But we won’t give up… see you for the next One…

Leave a Reply