Project Spartan and ECMAScript 6

Microsoft just released Project Spartan to the Windows Insiders that are running the Windows 10 Technical Preview – a new browser that pretty much kills off Internet Explorer. At a minimum, Project Spartan renders Internet Explorer squarely in the “legacy camp”. I had two questions of this release. Firstly, could it handle ECMAScript 6 natively. Secondly, could it handle Web Components natively.

To check on ECMAScript 6 support, I turned to Kangax. They host a compatibility test suite and run your current browser against the test suite, checking the results against other browsers, standard transpilers and polyfills. Let’s see how it did:

This one deals with recursion and I’m going to call this one “no big deal”. After all, the only current solution that deals with it at all is the BabelJS transpiler.

This is where the “big deal” stuff comes in. I’m using default function parameters on a regular basis now, so I would definitely miss those. I’m not using destructuring so much. Destructuring is about inferring what you meant. For example, if you used the following code:

var [a, [b], c] = [5, null, [6]];

A literal read of this would assign [b] to null, but type inference would yield [b] = [6]. That’s destructuring at work. Personally, I don’t like this – it stinks of accomodating sloppy coding. Maybe I just don’t have a good use case of where this is a good idea.

This one honestly surprised me. The only place you can’t use a let statement is in a for loop, which is probably going to be one of the places where this functionality is most used. I really hope they are planning on fixing that.

No support for generators yet. Given that Firefox has this functionality (albeit with slightly different syntax), I don’t count this as a must have. Good news, Facebook released Regenerator – a polyfill specifically for generators.

Good support for the new built-in types. The last one – well-known symbols – is not important now but will be in the future. I can see myself using symbols, but not in the near future. Only BabelJS has better support on that area – no-one is particularly good right now.

This part of the spec is better supported in Spartan than anywhere else. It is just lacking in those symbol areas again. I suspect that Symbol support will be high on the list for compatibility with ES6. Again – no-one else does it better.

Apparently, you should be able to subclass things. I’m not so sure that is required. However, BabelJS and Traceur both allow you to subclass Promise. Also, subclassing primitives like Boolean, String and Map (which is in that miscellaneous subclassables section) is likely to be useful.

How about Web Components and HTML5?

There are a whole bunch of things that Project Spartan does not support yet. According to html5test.com, Project Spartan comes in at 375/555 or 68% – lower than I would expect. Explicitly, it does not support any of the elements required for Web Components yet. Other than that major glaring hole, there are unsupported areas all over the specification.

The Verdict

I’ll give Project Spartan a C on this one. If you look at ES6 compatibility, only BabelJS comes out ahead (76% of tests passing for BabelJS, 73% for Project Spartan). Project Spartan is also ahead of every single browser currently out there. I’d rate their ES6 compatibility a solid B. However, their failing grade on Web Components and HTML5 in general is concerning. I hope they jump on that band wagon.