NERD ALERT! The Firefox 4 beta features typed arrays in JavaScript. They have been introduced to improve performance when working with binary data e.g. in Mozilla’s implementation of the FileAPI. Currently raw data is parsed as a string and read character by character using charCodeAt(). Typed arrays let you work with raw binary data. As a side effect, a JavaScript typed array will only let you store one type of variable within it; you can not mix strings and floats. And a JavaScript typed array will not allow you to change the size of the array after instantiation. Here are the types you can specify:
Int8Array
Uint8Array
Int16Array
Uint16Array
Int32Array
Uint32Array
Float32Array
Float64Array
While the performance results (http://weblog.bocoup.com/javascript-typed-arrays) are undoubtedly impressive, is there a place for typing in JavaScript? Surely the flexibility, dynamic nature and lightweight syntax of the language is it’s appeal? Introducing typed arrays is cited as a performance improvement, but in fact many other areas of the language could be dramatically improved by changing or introducing new features, so are Mozilla setting a dangerous precedent here? The abandoned ECMAScript 4th edition (PDF link) featured optional type annotations as well as optional static type checking, but the most recently approved ECMAScript 5th edition (PDF link) has neither of these.
Interestingly, the typed array draft spec originally came out of the spec for WebGL, the 3D graphics context of the HTML5 Canvas element.
Your thoughts? Happy, sad? Tearful? OUTRAGED? Leave a comment below and let’s tell Mozilla exactly what we think of their spec-disregardin’.
Tags: interfacedevelopment, javascript, performance, syntax, typing
Lars says:
August 26, 2010
Yes, the type-flexible nature of JS is part of its appeal, but another part of its appeal is that it runs in the browser… where it gives everybody instant access to functionality. Therefore js is being asked to take on more and more functions, some of which require it to expand its boundaries.
No doubt Fx implemented these typed arrays *because* they were needed by WebGL, which Fx seems committed to.
I don’t see a problem with browsers implementing new features that aren’t yet in an official standard. All browsers innovate that way: the official specs sometimes lag years behind the browsers.
What I *do* see as wrong is when the official spec comes out defining how e.g. typed arrays should work, and a browser refuses to implement compliance (in addition to or instead of its own version).
Lars
Ken says:
November 23, 2010
I don’t see this as detracting from the dynamic nature of Javascript, any more than we already have. For example, string is a special array-like item that only holds characters (er, 1-strings?). Some things are easier in languages where strings really are a subtype-of array, but I don’t think it’s fatal to JS to have a special native string type. It shows intent, both to programmers looking to understand some code, and to the runtime looking to execute code efficiently.
More and more, I see people using JS as “assembly on the web”, and compiling to it from other HLLs. Typed arrays are exactly the kind of runtime functionality I want as a compiler writer. I don’t trust W3 or Mozilla or Webkit or anyone else to deliver the perfect language in JS, but if they give me features like this that let me efficiently compile my own language to JS, they don’t need to. It’s democratization of client-side languages, and I’m all for it!
Now if we got continuations and/or restartable conditions — everything else it lacks is pretty easy to emulate — I’d be one happy hacker.