Just incase you were wondering how far HTML(5) could go…

This is a video demonstrating Cloud9 IDE from the ajax.org folks. It’s a few months old but I was just reminded of it by some recent tweeting. It’s incredible and really promising stuff. More importantly, it really demonstrates that a lot is possible with the technology in Chrome+Firefox today.

You can pull it down from Github and try it yourself now.

Originally posted on Thoughts from David Padbury.


With ChromeFrame can we consider HTML5 just another browser plugin?

It’s generally agreed that HTML5 today has a roughly similar feature set to plugin based RIA technologies like Silverlight and Flex. This feature set is available today in cutting edge browsers like Chrome, Firefox and Opera.


However we rarely get to make that comparison. The biggest barrier to HTML5 adoption is the significant portion of users, particularly in the Enterprise, that are still using older browsers such as IE6-8. At this point we either have the option to attempt to enhance these browsers using shims and polyfills (they can actually do a surprising amount but it’s messy none the less), or just wait until everyone upgrades.


Not a great situation if you know you’ll have to be supporting IE users.


Another option that I don’t hear talked about much is ChromeFrame. A Google produced IE plugin which seamlessly embeds the Chrome browser (V8 js engine and all…) so that when a site intentionally opts into it, it’ll take over and render the page. This is great as the biggest reason for Enterprise’s not upgrading to newer browsers is the wealth of older web based applications requiring IE. With ChromeFrame, they can carry on using their standard browser and then it’s only applications that specifically ask for being rendered by Chrome that get upgraded.


This could make HTML5 a very similar proposition to Silverlight or Flex for Enterprise development. But there’s a big difference – with Silverlight or Flex if you try to run them on a machine or device that doesn’t support the runtime, you simply don’t have a chance in hell. With HTML5, you’ve got a fighting chance of supporting older browsers and other devices like iPhones, Blackberries, and Androids. Isn’t that kind of compelling?


Of course even with the best available HTML5 application runtimes, today there’s still significant challenges delivering large HTML5 applications. Tooling and frameworks are the first things to come to mind but that’s probably fit for another post.


So I wonder why ChromeFrame isn’t talked about more. Could it be that Enterprises prefer more established browser plugins like Silverlight or Flash to the rather niche ChromeFrame?

Originally posted on Thoughts from David Padbury.

My NYC CodeCamp Talks – Javascript and Node.js

Yesterday I did a couple of talks at the NYC CodeCamp which Lab49 was sponsoring. It was a great event and I really enjoyed meeting many of the 400 developers who attended. My one regret was that due to presenting myself I missed great talks from my fellow Lab49’s Scott Weinstein and Doug Finke.

My first talk was an introduction to Javascript where I explained that despite JavaScript looking an awful lot like C# and Java, it’s in fact not much like them at all. But don’t panic – it’s an extremely simple language and once you understand it’s basics (prototype based inheritance, hoisting, functions, etc..), you’ll be able to understand most JavaScript code out there.

My second talk was an introduction to node.js and how running JavaScript on the server is in fact far from the worst idea. The intention of the talk was not to try to convert a room full of ASP.NET developers to Node, but to explain where node is innovating in the web platform space and how we’ll probably see a lot more of these techniques in the future on every platform (code sharing between client & server, simple API’s for real-time web communication). The demo’s I did during the talk can be found on GitHub.

I’d be really happy to give these talks again so please get in touch with me if you’d be interested in having me speak at any development groups.

Put decent JavaScript documentation in your address bar

As we all know the highest ranked (by Google) site for JavaScript documentation is W3Schools. The problem is, it kind of sucks. Over the past few months I’ve found the highest quality of JavaScript documentation by far can be found at the Mozilla Development Network – just look at Date for instance.

I use Chrome pretty much everywhere now and using it’s custom search engine feature, we can put MDN right into the address/search/whatever bar. Just right click on the text box itself and hit “Edit Search Engines”. From here just add a new one with https://developer.mozilla.org/en-US/search?q=%s as the url. Now just type mdn and what you’re looking for.

It’s the little things.

WCF WebSockets: First Glance

I finally got around to playing with the first drop of WebSockets support for WCF. I’m pretty familiar with WebSockets as I’ve been using Node.js to play around with them for quite a while now. The server API in Node.js is wonderful as it couldn’t be simpler – to demonstrate this, take a look at how we’d create a basic echo server.

var ws = require("websocket-server");

var server = ws.createServer();

server.addListener("connection", function(connection){
  connection.addListener("message", function(msg){


When I heard that Microsoft was planning on integrating WebSockets into WCF my first thoughts weren’t all that positive. Now I know it’s not quite the case since .NET 4, but WCF has had a reputation for rather large complex API’s and heaps of XML. I was dreading what a WCF take on the above would look like. Turns out, perhaps I should be a little more optimistic.

class Program
    static void Main(string[] args)
        var host = new WebSocketsHost(new Uri("ws://localhost:4502/echo"));

public class EchoService : WebSocketsService
    public override void OnMessage(JsonValue jsonValue)

That’s really the kind of simplicity I was really hoping to see. Now the interesting question is how it’s going to look when dealing with multiple clients. Node kind of has an advantage here as it’s entirely single threaded (yeah, I said advantage), but with .NET’s recent concurrent collections and a rather nice API for dealing with events (Rx) I’m feeling pretty hopeful.

Making Macros in CoffeeScript


JavaScript dependency management is a hot topic at the moment (see RequireJS, Dojo and StealJS). This got me thinking, why do we just treat JavaScript as dumb files to be served up to the client? Now that we have web servers that literally speak the same language, aren’t there greatly possibilities yet to be discovered? Can we write code that seamlessly merges the divide between client and server?

Well honestly? I’ve got no idea. I got a little stuck on the first problem that came to mind – how do we get the server to understand what the code is intending to do on the client? Sure, using Node we could happily execute our JavaScript. But if we wanted to have some smarts about how we deal with it, say analyze a piece of JavaScript to determine what stuff it’s dependent on, we’d actually have to parse the code. Now I’m sure this is possible; clearly Web Browsers and Node parse JavaScript quite happily. But the thought of trying to deal with that myself didn’t quite make me giddy with excitement. If only there was a language like JavaScript but had easily useable parsers on hand that let us mess with the language…


Enter CoffeeScript. In it’s own words…

CoffeeScript is a little language that compiles into JavaScript. Underneath all of those embarrassing braces and semicolons, JavaScript has always had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.

A nice language that will compile into JavaScript, which also exposes the good parts of JavaScript’s (gorgeous) object model in a simple way? Well doesn’t that just sound perfect. Sure enough, it’s pretty easy to compile a CoffeeScript program from JavaScript.

var coffee = require('coffee-script');

var nodes = coffee.nodes(coffee.tokens("a = 2 + 2"));

console.log( nodes.compile() ); // var a = 2 + 2;

The important bit for this post, is that we can get both the token stream and the AST nodes themselves before they’re finally compiled into JavaScript. These nodes are just simple JavaScript objects thrown together in a graph. To make messing with them even easier, the Node structures are extremely well documented on the CoffeeScript site (No really, go look at it – it’s the most attractive documentation I’ve seen in a while). For the statement “a = 2 + 2”, the node graph looks much like below:

    Value "a"
    Op +
      Value "2"
      Value "2"

As a first experiment, I wrote a Visitor object which would visit each node in the graph and if certain conditions were met, replace the node with a new one. In this case, I’m looking for a method call like “ADD x, y”, then I’d replace the node with another in the form “x + y”.

var addReplacementVisitor = {
	onCall: function(n, replaceCallback) {
		if (n.variable.base.value === "ADD") {
			var addOp = new nodes.Op('+', n.args[0], n.args[1]);

So I can imagine what you’re thinking, “well done Dave, you’ve managed to replace an ADD call with an add operation. Yeah, super useful…”. My original idea was to build on this and have more advanced Visitors which would transform the node graph in grander ways. However, these things are kind of difficult to write, and doing anything even slightly more than trivial took an awful lot of code. Fortunately, I just happened to show this to our product designer Eric Wright, he took one look at and remarked – “ah, like Macro’s in Lisp” (yeah, a talented designer who’s also familiar with Lisp, way to make me feel inferior). Lisp allows you to define “macros”, essentially things that look a lot like functions, but actually act more as a find and replace on the language/AST itself. (There are a lot of places online which will give you a proper rundown).

(defmacro swap (a b)
    `(let ((temp ,a))
       (setf ,a ,b)
       (setf ,b temp)))

CoffeeScript Macros

This got me thinking – by far the easiest way of representing a graph of CoffeeScript nodes is CoffeeScript code itself. So in my first prototype, I have a CoffeeScript file designated to define macros, and then a CoffeeScript source file which the defined Macro’s are applied to. So to do something like the above we’d define a swap Macro like…

SWAP = (x,y) ->
	$tmp = x
	x = y
	y = $tmp

Quite straight forward stuff – we’re just creating a function named SWAP which takes two variables (x and y) and swaps them around. Hopefully you’re wondering about the significance of $tmp and why I’ve named it a bit funny, we’ll get to that in a moment. Imagine it working on the following CoffeeScript source:

a = 1
b = 2
c = 3
d = 4
SWAP a, b
SWAP c, d

The Macro really is just a find and replace, so when it’s found the SWAP method in the above, it’ll replace it with the body of the Macro. If we were to do this twice in the same scope, like the above. We’d expect to see two $tmp variables declared which wouldn’t be good – to prevent this, any variable in the Macro scope begining with $ will be renamed to something unique. So in my quick prototype, compiling the above would result in the following JavaScript:

var a, b, c, d, __tmp0, __tmp1;
a = 1;
b = 2;
c = 3;
d = 4;
__tmp0 = a;
a = b;
b = __tmp0;
__tmp1 = c;
c = d;
d = __tmp1;

Using your body

Usually the expressions passed to a Macro are just copied directly into the Macro’s body. But what if we wanted to wrap a Macro around a whole block of code? Well, there’s a special $body argument convention that will help us cope with that. Where most arguments are just directly copied, the $body variable is first “unwrapped” and just the expressions in it’s body will be copied. This allows us to pass a function (typically as ia Macro’s last argument) and treat it as the body of the Macro’s code. The example below hopefully demonstrates this better. Imagine we want to wrap a try…catch around all of our code so that all exceptions are swallowed.

ERRZLESS = ($body) ->
	catch e
		console.log "IGNORED ERROR: #{e}"

Note how we use this macro by supplying a function as the body.

	throw "ARGGGGSSS"

This will produce the following JavaScript.

try {
  throw "ARGGGGSSS";
} catch (e) {
  console.log("IGNORED ERROR: " + e);

So what’s the point?

Hurrah, Macro’s in CoffeeScript! Well not really. This was only a little experiment of mine to see how easy it is to mess with CoffeeScript before it’s complied. Fortunately as it turns out, it’s pretty easy.

So where is this useful? These kind of techniques I’ve discussed are super useful for building internal DSL’s and meta-programming. It also looks like there’s some serious work going on to provide static metaprogramming to CoffeeScript which would give us proper Macros and an awful lot more.

Show Me The Code

All of the code for this little experiment can be found up on GitHub. If you pull it down it can be executed using the command:

coffee stirred-coffee.coffee macros.coffee main.coffee

HTML5 Live Conference

I recently attended HTML5 Live, a single day conference here in New York. The conference was pitched as an event focusing on HTML5 for enterprise developers instead of designers. I was surprised to see a number of familiar faces from both the industry and the .NET/Java community. It seems that although HTML5 applications are not yet being widely developed, they’re very much on people’s minds. That said, despite the enterprise focus, once we sat down nearly everyone pulled out a MacBook or iPad, just like any other web event…

The Keynote was given by Jeffery Hammond, an expert on application development from Forrester. In my opinion, his talk was pitched perfectly. Mainly, that HTML5 has recently been extremely hyped and as people actually get into it they should be aware that they’re going to be disappointed. Although that seems like quite a negative way to start a conference on the subject, he followed it with a very pragmatic look at where HTML5 currently is, and where it’s going to be in the coming years.

HTML5 on the Gartner Hype Cycle

I found how he described us as being at the top of the “inflated expectations” curve particularly amusing as many of these I’ve seen first hand-

  1. Marketing is keen to “add HTML5”
  2. Many technologies and API are keen to be grouped with HTML5, despite being quite unrelated.
  3. “Flash/Silverlight are dead”
  4. HTML5 is cited as the solution for just about everything.
  5. Mainstream media have already picked up on the trend. (I think he referenced the New York Times)

The bottom line of his talk was that HTML5 today is an attractive option for applications that want a broad reach across mobile devices. Whereas there are still large gaps in desktop browsers, and the tooling is still very much evolving. Everyone will find HTML5 “ready” at a different time – know your users.

Adobe and Microsoft were also both represented at the event. Representatives from both companies were keen to show their love for the new HTML5 platform; I think both had “We ♥ HTML5” in their slides. On Adobe’s front, they started by demonstrating some of contributions they’ve made to webkit as a result of it’s integration with AIR – clearly making the point that HTML5 and their RIA platform can have a mutually beneficial relationship.

As for Microsoft, I was wondering quite what they would have to talk about apart from IE9. Although I expect that we’ll see some HTML5 tooling from Microsoft in the near future, currently there’s not much to speak of. I was pleasantly surprised to hear a great overview of HTML5 and a look at the tests that Microsoft are committing to various specifications. Although not much of it was particularly new to me, I’m glad that this is the kind of talk Microsoft will be giving to introduce developers to the platform. Of course there was the mandatory IE9 fishes demo.

Like most events, I found the most interesting part meeting other attendees after the talks were over. Most of the people I spoke to were there simply to gain some understanding of what HTML5 actually is. It’s clear that despite the recent buzz (or cynically maybe due to), HTML5 is a confusing term for a lot of developers, especially in the enterprise.