This Week in JavaScript Performance

This article discusses Mozilla’s and Google’s reaction to the news that their browsers will not be allowed access to Windows RT (Windows on ARM). Mozilla has branded Microsoft’s restrictions a return to the digital dark ages “where users and developers didn’t have browser choices.”

This article is the continuation of February’s part one, to which a link is provided.

Node.js uses event-driven, asynchronous i/o instead of the traditional multi-threaded concurrency model. This article shows how to monitor objects in node.js.

This short article shows us the JavaScript/HTML5 fundamentals of working with client-side files, including File references, drag-and-drop, and Ajax uploads. It includes code snippets to make everything crystal-clear. I’ll keep an eye open for part two, which will show us how to read data from a client-side file. Thanks, Nicholas.

This article explains why waterfall-chart measurements alone may not give a true picture of performance as seen by the end-user. Example: If everything is deferred until pageload is triggered, the page will become visible, but with very little usable content.

It’s a good article, but it fails to mention the free services available at Monitor.Us. Big oversight!

This academic paper is “a limit study on the potential parallelism of JavaScript applications.” “Results show that the potential speedup is very encouraging – averaging 8.9 times and as high as 45.5 times.”

The URL suggests that this article was written in 2010, so it certainly wasn’t published in the last week (which is usually required for inclusion in This Week in JavaScript).” However, it’s new to me because I just stumbled across it a couple of days ago. Its content is certainly relevant to today’s ongoing performance discussions.