JSConf.us: The Pirate Edition

I always like to take my time writing the JSConf posts. Once the hangover has worn off (what happens at JSConf stays at JSConf), the digesting of material begins. It's so hard to quantify the conference because the "B-track" is the main stage line-up for almost any other conference, and the "A-track" is basically a who's-who of JavaScript. And me.

So here is my totally biased review of the material.

First up, Crockford — and security

First up, Crockford. I get to work with Doug so I'm definitely pretty biased right off the bat. That said, Doug is crazy smart. Doug has been advocating improving JavaScript security for a while, and this was a major theme of his talk. I've been writing about AJAX security recently too.

One of the key points is that you shouldn't let other people write scripts to your page, because once they do, it's game over. One problem is that many of the ways to inject JavaScript onto a page are fairly obscure (PDFs, anyone?). Heck, there are lots of good reasons you might want to include someone else's script.

Doug Crockford mosaic

Doug has a great perspective on what we can do to help make JavaScript safe. He started ADSafe as a safe subset of JavaScript that we could hold advertisers to.

We've also done a lot of work with Caja at Yahoo.

Doug has suggested we need to think much more closely about HTML5. With local storage and many other HTML5 features, we are going to make web apps much much more complex. That creates a lot more that can go wrong, and we aren't investing more in JavaScript security. One way to deal with this would be to add sandboxes to ECMAScript so that scripts can be isolated from each other.

(Shameless plug: If you want to come work with Doug and me at Yahoo, email me your resume. We have several awesome positions.)

Crockford had to leave early to fly to another conference in Asia, but have no fear: JSConf had it covered, as the picture shows. It's a Crockford facts cutout :)

Node.js and performance

Next I'm going to gush on Node.js for a while. Ryan's talk about it didn't cover anything dramatically new, but there was some interesting stuff which makes me confident this is for reals. Firstly, he explained that back at JSConf.eu, Node was mostly thin wrappers over C. Now, it's mostly JavaScript. It turns out that V8 is very, very good at optimizing code.

Ryan talked a fair amount about the performance of Node, comparing it with other event-driven servers. He picked his company well: Nginx is a tuned HTTP proxy, Thin is a Ruby event-driven server, and Tornado is a Python one.

Essentially, this means that NginX is fast because it only does one thing, very well. The others are running program code, so they don't perform quite as well. How does Node do? Well, considering no one much used server-side JavaScript 12 months ago, it's mind-blowing to think Node sneaked in under Thin but above NginX. In other words, the JavaScript community's beta product is possibly the fastest event-driven server available.

Ryan showed results of sub-50 milliseconds (ms) response times with 300 concurrent connections. That said, there are problems: Once file sizes hit a certain size, we start to see some problems with V8 and garbage collection. So everything isn't there yet, but it's close. And that's the best bit: Node is starting to settle into being a useful stable system.

Ryan didn't promise a stable API yet but he said he wants to make it stable in the 0.2 version. That's likely to be fairly soon. With 63 contributors and thousands of people interested in the project, it's going to be awesome. You can also read Ryan's full slides.

We have a really exciting project about running YUI3 on Node that Adam Moore talked about on the B-track:

Unary, binary, and ternary Fabs

Another server-side JavaScript project that really caught my eye was (fab). Fab is a really tiny framework that acts as glue between projects. Essentially, fabs curry functions so that they can be chained together. It's creator, Jed, explained how there are three kinds of fabs: unary, binary and ternary. Unary fabs have one input or output, binary have an input and an output, and ternary have two inputs and an output. Using combinations of these fabs, you can build any app you want.

I really like the approach because it encourages a lot of reuse. Also, since fabs can glue together, you can make a complex fabs out of much simpler fab. So you could make a complex routing fab that would then be really easy for anyone else to use in their code. Jed's slides below explain it much better than I could:

Eich (swoon!) and Ich

Aside from Crockford, we had another member of the ECMAScript working group, JavaScript creator Brendan Eich (swoon!). Brendan is a really nice guy with a sharp sense of humor. If Crockford is Chuck Norris then Brendan is Ash. Brendan had some serious points too, as there is a lot of great work going on in the ECMAScript committee about how to take JavaScript forward. He was really positive about making sure JavaScript and ECMAScript stay in sync. He said that as changes are made to ECMAScript, it will be important to make sure engines like Mozilla Squirrel Monkey (which he writes) stay in sync with ECMAScript as the standard rather than JavaScript.

Finally, I did a workshop on Yahoo! Query Language (YQL) I was rather proud of. While I won't talk about it a lot, the following slides are probably one of the best references for learning YQL at the moment. If you have any questions, please let me know.

Oh, and one more thing I couldn't forget: I'm on a boat!

(Photo courtesy of Holger Blank)

One of the best things about JSConf is the community. Unlike other conferences, there are enough parties and free booze drinks to keep everyone together and talking for the whole weekend. Long may that continue. So rock on, Adam Sontag, rock on.

(Photo courtesy of Ben Alman)

I love the JavaScript community.

JSConf attendees group photo
(Thanks, Brian Mitchell)

Tom Hughes-Croucher
Tom Hughes-Croucher (@sh1mmer)
Yahoo! Technology Evangelist