javascript

Typed arrays in JavaScript

Very Large Array
Very Large Array by Julia Manzerova

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: , , , ,

2 comments Add This

Interface Development team weeknote (week 1036)

Week ending 09/07/10:

Andrew spent some time this week catching up with our TripleLBi colleagues in Copenhagen, and was pleased to find the Danes were developers with sharp skills. Project Battle of the Giants is being built out of Copenhagen with Andrew advising on architecture and beer. And them Danes are giants: what do they feed them over there? Yes, I know, bacon and blue cheese; blue cheese that made Andrew’s eyes water and filled his hotel dreams with monsters with flowing fair manes.

Jon conjured up a nice piece of news over on Project Raiders of the Orient Express: they’ve tamed the Photoshop JavaScript engine (actually ExtendScript, Adobe’s extended implementation of JavaScript), which has been a standard part of the application since version 7. Using it they’ve written a script to receive a JSON file and an image button template and automatically generate 50 buttons in 5 different styles and themed 5 different ways. That’s 1250 different buttons! The script generates in 15 minutes what may take a tablet-wielding Mac operator much, much longer, no matter how strong their Photoshop-fu. Apparently the JavaScript took a while, but that’s an impressive return on investment.

Tom and Ray delivered another massive code drop to Project Incident In Istanbul, which includes some seriously innovative banking transaction representations. I’d love my bank’s website to have even a tiny bit of the impressive functionality and design polish that this project is currently rolling with.

Martin spent last week involved in yet more discoveries around the capabilities of CSS3 gradients and RGBa opacity, and investigating server-side image generation to enable Project Aurora to use fonts that we are unable to embed via @font-face due to restrictive licenses. It seems that this is the only non-sIFR method of including such font faces that doesn’t require JavaScript to work, and won’t present the FOUT (Flash of Unstyled Text ). It’s not a discovery he’s particularly pleased about, and says it’s very frustrating to deal with font foundries who refuse to embrace the changing nature of the web by updating their licensing (seriously, he’s been bitching in the back-channel all week long about technologically-retarded and reality-denying font foundries)

Tags: , , , , , , , , , ,

0 comments Share

Interface Development team weeknote (week 1029)

A weekly note detailing the joy and the pain of LBi’s Interface Development team.  One of the apparent conventions of the weeknote format (which started with the esteemed BERG, according to Russell M Davies in this Wired article) is that the week numbering scheme runs from the date of the business’s incorporation.  LBi has a long and interesting history, but I managed to trace it back to the earliest incarnation of the group: Linkhand, date of incorporation 03 September 1990, hence the spectacularly high week number.

Week ending 21/05/10:

This week Will spent a few enjoyable days appreciating the benefits of working to a single platform when he put together an iPhone-specific implementation of one of our clients’ sites. It’s probably a bit hush-hush for now so we’ll do a big reveal of that at some point in the future, but let’s just say it’s “kinda interesting”.

After an enquiry from a colleague as to the existence of a platform-independent version of the popular performance analysis tool dynaTrace Ajax Edition, Ray started to put together a “node.js traffic proxy analysis tool thingy” which has the beginnings of something very useful. It lets you route all your http requests through a node.js webserver, where you can analyse the request headers for all sorts of interesting information. Some further tinkering with this will prove fruitful.

Andy and I continued work on our top secret iPad-targeted webapp. We’ve already spent a few weeks developing the client-side architecture, where we employed an MVC pattern to manage the app, made use of mobile Safari’s offline storage capabilities to take care of state, and layered on our own touch interaction system. Now we’re taking a deep dive into the rendering of the views, which it looks like we’re going to split out into a smaller, independent module and which, thanks to some impressive design work, presents some unique challenges. We’re delivering this module with its own test suite of QUnit unit tests, and we hope it will be integrated into a larger continuous integration workflow.

Our fortnightly Interface Development team meeting had two presentations — Filip talked about the HTML5 geolocation API, and I showed an outline of “How To Design A Good API” which will be pertinent to some of the code libraries we’re developing in-house. We also got some amazingly good biscuits.

We currently have around 20 interface developers in the team so we’ll feature a few here each week and try not to bludgeon you to death with detail.  We’re also looking for some more great interface developers, so if you like what you read here then get in touch!

Tags: , , , , , , , , , ,

0 comments Share