The JavaScript blog.


talks music audio

Free Online Training, React Sound Player

Posted on .

Free Online JavaScript Training

Bitovi is hosting free weekly training sessions for intermediate to advanced JavaScript programmers. The content covers core concepts like closures, prototypes, and DOM manipulation.

This training is designed to make people proficient at JavaScript application development from the ground up. A fundamental understanding of how JavaScript, the DOM, and other technologies work is, in the long run, essential to make good choices in large scale application development.

The sessions are held over Google Hangouts on Air, and the videos are posted to YouTube. The material is based on content that was used for a Frontend Masters course.

If you want to join in, go to the page about the workshop and get the Google Calendar link.

React Sound Player

React Sound Player

Dmitri Voronianski sent in a very nicely designed React library for SoundCloud (GitHub: soundblogs/react-soundplayer, License: MIT, npm: react-soundplayer). It has a high-level component (SoundPlayerContainer), and there are lots of other components relating to audio playback. This includes buttons like PlayButton and NextButton, but also play position (Progress, Timer), and album art (Cover).

My screenshot is from the example near the bottom of the page, which is a full-blown audio player that uses most of the features of the library. It looks very nice, and is all done through HTML5, React, and the SoundCloud API.


irc node modules security talks slides

Node Roundup: 0.10.24, irc-message-stream, 100% Uptime

Posted on .

Node 0.10.24 Released

Node 0.10.24 was released soon after 0.10.23. It updates uv and npm, but presumably this release was due to CVE-2013-6639 and CVE-2013-6640. These are security related patches for V8:

... allows remote attackers to cause a denial of service (out-of-bounds read) via JavaScript code that sets a variable to the value of an array element with a crafted index

If you run this example in Node 0.10.22 you should see a segfault.

var size = 0x20000;  
var a = new Float64Array(size);  
var training = new Float64Array(10);

function store(a, index) {  
  var offset = 0x20000000;
  for (var i = 0; i < 1; i++) {
    a[index + offset] = 0xcc;

store(training, -0x20000000);  
store(training, -0x20000000 + 1);  
store(training, -0x20000000);  
store(training, -0x20000000 + 1);

for (var i = -0x20000000; i < -0x20000000 + size; i++) {  
  store(a, i);


irc-message (GitHub: expr / irc-message, License: BSD 2-Clause, npm: irc-message) by Fionn Kelleher is a small parser that outputs objects based on RFC1459. The author has used it to create irc-message-stream, which is a transform stream.

That means you can take a socket connection to an IRC server and pipe it through your own stream handlers:

var net = require('net');  
var MessageStream = require('irc-message-stream');  
var messageStream = new MessageStream();

messageStream.on('line', function(line) {  
  console.log('Raw line:', line);

messageStream.on('data', function(message) {  
  console.log('Parsed message:', JSON.stringify(message));

var socket = net.connect(6667, 'irc.freenode.net');  

I think this is a great way to handle IRC in Node -- taking advantage of the newer streams API seems a lot more idiomatic than other approaches that I've seen (and made!).

Towards 100% Uptime with Node

William sent in his slides for a talk called Towards 100% Uptime with Node. The slides cover the difficulties of handling uncaught exceptions in a cluster of Node processes, and ensuring that every request has a response, even if it's to report an error.

One of the tips he mentions is to be able to generate errors on demand for development and staging. I do this in my tests -- if critical paths are expected to throw exceptions, emit 'error' events, or return error objects to callbacks, then all of these eventualities should be hit as part of automated testing.

The Node applications I work on for my day job are hosted on Heroku, and I've found you have to be extremely careful with code that throws errors and causes the process to stop. Sometimes Heroku gets confused about the state of a process and won't gracefully restart it, so a worker just hangs for an undefined amount of time. The way I stopped this was to fix all the bugs, which sounds like an obvious thing to say, but it took lots of log file archaeology. Coincidentally, Heroku's default logging is inadequate, so you have to send logs to a syslog daemon somewhere, or a service like Loggly (which I preferred to Splunk).


google videos chrome talks

Chrome Apps: JavaScript Desktop Development

Posted on .

Evolution of Chrome Apps

June was a month of tech conferences, but it was Google I/O that really stole the thunder of E3 and Apple's WWDC. People are understandably excited about the Nexus 7, Jelly Bean, and Chrome for iOS, but what was there for us JavaScript hackers? All of the Google I/O sessions are available for viewing, and one that caught my eye was The Next Evolution of Chrome Apps.

I saw this video referenced on Twitter by TJ Holowaychuk, and given that his JavaScript aesthetics align with mine I wanted to know why he was talking about it. It turns out there's a lot to like about the future direction of Chrome apps and Chromebooks from a JavaScript developer's perspective. Offline is now being taken extremely seriously -- partly because existing APIs are being adapted to cope with intermittent connections, but also because Chrome apps will be integrated with the OS (whether it's Google Chrome OS, Mac OS, Linux, or Windows). This addresses a key usability problem people have with offline web apps: how are they launched? Rather than digging around in bookmarks or Chrome's Apps page, we'll now be able to launch them from the OS.

After seeing this talk, here's my hyperbolic claim: Google is going to revolutionise desktop development. Watch the talk to see if you agree.

The part of the talk that stole the show was the Arduino demo. The new APIs allow applications to access OS-level features: networking, bluetooth, and even serial IO. Mihai Parparita (Chrome Apps Tech Lead, Google Reader) demonstrated an Arduino board that controlled a motor with a potentiometer, and a Chromebook (on the latest Canary build) was able to read and write data to it.

I've summarised the talk below, but if you're desperate to see sample code then take a look at the GoogleChrome GitHub account and developer.chrome.com/apps.

Breaking out of the Browser

In Breaking out of the Browser, system-level integration is discussed:

  • Launch apps from outside the browser
  • First-class OS windows -- rather than just using the DOM, windows can be created that work with native controls and shortcuts (including cmd/alt-tab)
  • Full window frame without browser chrome
  • Links open in browsers, not the app

The Bizarro World Window Demo demonstrates this. This is all done with JavaScript.

Offline by Default

The Offline by Default section deals with how new packaged apps are better able to cope with offline mode or intermittent connectivity.

  • The interface and application logic are entirely local
  • There's an enforced separation of data and UI to help prevent apps from getting into a broken state
  • An application should work without ever having connected to the network
  • Older APIs have been updated to perform better during poor connectivity
  • The fact apps launch from outside the browser helps people realise they work outside the browser and will function offline

There's a demo of a diff tool that works differently offline. When the connection is lost, it immediately displays an offline notice and only allows local files to be opened. When it's offline remote files can be opened instead.

New APIs

The new APIs are mainly concerned with OS-level integration.

  • System APIs: interacting with the hardware (USB/bluetooth) or OS (TCP)
  • Shared data APIs: interoperating with other apps (photos/contacts/calendar) accessed safely from multiple apps
  • (Google) Web service APIs that run well under poor network conditions: analytics, ads
  • Raw sockets, which Google employees have been using to create things like IRC clients

There's a demo showing an Arduino board interacting with a Chromebook.

Programming Model

Of course, to facilitate all of these changes the programming model has changed somewhat:

  • Applications use a "background page" with a main event
  • The application life cycle is event-based
  • System-level signals are accessible through an event-based API
  • The APIs have bindings to more languages -- Dart is mentioned, but I'm not sure what else they'll ship with
  • Background applications can be created
  • Apps should be single page with no navigation -- basically designed like desktop applications instead of web applications

There's a bigger emphasis on the difference between extensions and apps. Extensions are now seen as something that modifies the browser itself, while apps are more like desktop applications. Some apps on the Chrome Web Store currently use extension-level functionality, but these will have to be changed to become extensions instead. I'm not sure if a package app can be distributed with an extension, because I'm sure there are some cases where the boundary is blurred -- how does 1Password or LastPass fit into this model?

Security Model

The Security Model reviews Chrome's existing sandbox approach, but also details some new features:

  • Storage isolation ensures applications can't modify data they shouldn't have access to
  • Applications can be restricted using a new permission system
  • There's a new <browser> element that allows apps to render a page in a similar way to an iframe, but without the security issues

Systems Applications Working Group

It certainly seems like these changes will open up new possibilities for developers interested in targeting Chrome and Chromebooks, but doesn't this mean we're investing in vendor-specific technology that we can't use elsewhere? Well, Erik and Mihai addressed this by announcing that Google is working with Mozilla, Samsung, and Intel on the System Applications Working Group:

The mission of the System Applications Working Group is to define an runtime environment, security model, and associated APIs for building Web applications that integrate with a host operating system.

They're also in the early stages of looking at adapting this technology for mobile platforms.


language node modules talks

Node Roundup: 0.5.2, OSCON Slides, node-language-detect, d3bench

Posted on .

You can send your node modules and articles in for review through our [contact form](/contact.html) or [@dailyjs](http://twitter.com/dailyjs).

Node 0.5.2

Node 0.5.2 was released last week:

  • libuv improvements; named pipe support
  • #1242 check for SSL_COMP_get_compression_methods() (Ben Noordhuis)
  • #1348 remove require.paths (isaacs)
  • #1349 Delimit NODE_PATH with ; on Windows (isaacs)
  • #1335 Remove EventEmitter from C++
  • #1357 Load json files with require() (isaacs)
  • #1374 fix setting ServerResponse.statusCode in writeHead (Trent Mick)
  • Fixed: GC was being run too often
  • Upgrade V8 to 3.4.14
  • doc improvements

#1357 in particular should prove to be popular. It allows JSON files to be required, so a
JSON configuration can now be loaded like this:

var config = require('./config.json');

OSCON Node 0.5 Slides

Ryan Dahl posted his OSCON 2011 slides to
. The
slides are here: nodejs.org/oscon.pdf.
These slides have more details on the work going into Windows Node

With the support of Microsoft, Cloudkick, and Joyent we have four person team sponsored to complete the project. The ultimate result will be an official node.exe distribution.


Replacing the binding layer is difficult. Everything will be broken for a while. All new code is set alongside existing bindings until it is good enough to be used by default.

It looks like a short talk, but it's encouraging for Windows-based

There's a lot of support growing for libuv:

Only took 1h to make Redis use libuv by @ryah et al. Very usable socket interface sugar coated with platform independence. Love it!

- @pnoordhuis


node-language-detect (npm: languagedetect) by Francois-Guillaume Ribreau is a language detection module:

var lngDetector = new (require('languagedetect'));
console.log(lngDetector.detect('This is a test.'));

  [ [ 'english', 0.5969230769230769 ],
  [ 'hungarian', 0.407948717948718 ],
  [ 'latin', 0.39205128205128204 ],
  [ 'french', 0.367948717948718 ],
  [ 'portuguese', 0.3669230769230769 ],
  [ 'estonian', 0.3507692307692307 ],
  [ 'latvian', 0.2615384615384615 ],
  [ 'spanish', 0.2597435897435898 ],
  [ 'slovak', 0.25051282051282053 ],
  [ 'dutch', 0.2482051282051282 ],
  [ 'lithuanian', 0.2466666666666667 ],
  ... ]

The Hungarian result in the example surprised me, but the library ships
with tests and seems a lot faster than the original module that the
author has ported.


Ryan Dahl posted a little benchmarking app to GitHub recently called
d3bench. It's made using Express, Socket.IO, and D3.

I was more interested in seeing how Ryan builds Node apps than actually
using d3bench, but if anything it'll probably inspire Node developers to take another look at D3.