JavaScript MESS and the Internet Archive

27 Dec 2013 | By Alex Young | Comments | Tags games emulators emscripten

Atari 2600

if you program and want any longevity to your work, make a game. all else recycles, but people rewrite architectures to keep games alive. – Why the Lucky Stiff has a section dedicated to software. Inside you’ll find The Internet Archive Console Living Room, which has details on some major games consoles from the late 70s and 1980s, including the Atari 2600 and the ColecoVision.

The great thing about this project is they’re trying to keep old software alive. You can browse through titles and play them in a browser. This is powered by jsmess (GitHub: jsmess / jsmess), an Emscripten-based emulator derived from MESS:

The JAVASCRIPT MESS project is a porting of the MESS emulator, a program that emulates hundreds of machine types, into the JavaScript language. The MESS program can emulate (or begin to emulate) a majority of home computers, and continues to be improved frequently. By porting this program into the standardized and cross-platform JavaScript language, it will be possible to turn computer history and experience into the same embeddable object as movies, documents, and audio.

Running a game binary requires a suitable BIOS, but the groundwork for lots of systems has been added to MESS:

MESS and MAME were started over a decade ago to provide ubiquitous, universal emulation of arcade/gaming machines (MAME) and general computer hardware (MESS). While specific emulation implementations exist that do specific machines better than MAME/MESS, no other project has the comprehensiveness and modularity. Modifications are consistently coming in, and emulation breadth and quality increases over time. In the case of MAME, pages exist listing machines it does not emulate.

Over the last two years there’s been a flood of new browser-based emulators, supporting everything from the Amiga to the Game Boy Advance. Part of what makes these project possible is recent technologies like Canvas, WebGL, WebAudio, and FileReader. But even seemingly less buzzwordy APIs like typed arrays can help get old games running smoothly.

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

26 Dec 2013 | By Alex Young | Comments | Tags node modules security talks slides irc

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, '');

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).

2013 Recap

25 Dec 2013 | By Alex Young | Comments | Tags node

This year we saw Node 0.10 released, Bootstrap 3, and jQuery 2.0. People are getting increasingly excited about WebGL gaming, and client-side frameworks like AngularJS and Backbone.js are maturing and growing in popularity.

The highlight of 2013 for me was speaking at the Great British Node Conference. I’d been researching Node’s internals for the book I’m working on, so it felt like all that work culminated in a talk that got people thinking more about Node’s JavaScript and C++.

Over the next year I expect ECMAScript 6 to become more widely used. If you want to keep track of this standard, I find @esdiscuss to be the most digestible way to keep track of things.


Happy holidays to everyone who reads DailyJS, and I look forward to writing more over the next year!

Switchery, circles

24 Dec 2013 | By Alex Young | Comments | Tags browser ui iOS graphs



Switchery (GitHub: abpetkov / switchery, License: MIT, bower: switchery) by Alexander Petkov is a checkbox replacement, inspired by iOS 7, complete with animations.

The basic usage is new Switchery(elem). You can pass extra options for the disabled state, the colour, and the animation speed.

Switchery is written using CommonJS modules, but Alexander builds a standalone version that doesn’t need require.



Circles (GitHub: lugolabs / circles, License: MIT) by Artan Sinani is a small script for creating circular graphs. It doesn’t have any dependencies, and can be used like this:

  id:         'circles-1',
  percentage: 43,
  radius:     60,
  width:      10,
  text:       7.13,
  colors:     ['#D3B6C6', '#4B253A']

Read Only References, Getting MEAN

23 Dec 2013 | By Alex Young | Comments | Tags node books harmony es6

Creating Read-Only References

I was working on an API where the desktop developers were worried I could break their code if my server had a typo in one of the API responses. The server was returning JSON objects, and some of the properties were important, so if they were spelled incorrectly it could be dangerous.

I wrote unit tests to ensure the API responses were the ones they expected, and used Object.defineProperty to make the API response properties read only. But what if you wanted some objects to have read/write access to an object, and others to be set as read only?

Sergey Bolshchikov sent in his post about this topic, called Creating Read-Only References. He suggests using Object.observe, so certain objets can subscribe to changes.

Object.observe is basically the future standard way to do databinding. Sergey mentions some polyfills for it, so you can use it in browsers.

Getting MEAN with Mongo, Express, Angular, and Node

Simon Holmes is writing a book about Mongo, Express, Angular, and Node. I’ve used exactly this cocktail of technologies for some of my commercial work over the last two years, but I’d never thought of the acronym MEAN before. The marketing spin is it’s the new LAMP.

You can download the first chapter free, but the book is currently being written. If you buy it early you can contribute to its development by providing the author with feedback. The publisher calls this process MEAP (Manning Early Access Program).

Metawidget, Mozilla Holiday Gaming Competition

20 Dec 2013 | By Alex Young | Comments | Tags mozilla games webgl libraries ui


Richard Kennard sent in Metawidget:

Metawidget is a smart widget that populates itself, either statically or at runtime, with UI components to match the properties of your business objects.

I originally replied to him and said that something that talks about “business objects” and Java Struts might not be the type of thing I usually write about on DailyJS. He responded in good spirits with this:

Metawidget is a lightweight UI generator that can turn a JSON object into a UI widget in one line of code:

Or three lines if not using AngularJS:

Also supports JQuery UI and JQuery Mobile:

If you come from a C# or Java background, the style of this project might appeal to you. The introductory tutorial explains the idea of transforming data into UI elements based on types (which reminds me of my XSLT days).

Mozilla Holiday Gaming Competition

Kevin Attfield sent in a competition being run by Mozilla and Goo Technologies with $45,000 worth of prizes up for grabs.

To create your games, you will be using the Goo platform consisting of Goo Engine - a 3D JavaScript gaming engine entirely built on WebGL/HTML5 - and Goo Create - a visual editing tool running on top of the engine. For inspiration, check out this video tutorial on how to create an interactive scene in Goo Create.

Kevin works for Goo Technologies, and said they’re also looking for developers.

Choosing an MVC Framework, lrNotifier

19 Dec 2013 | By Alex Young | Comments | Tags mvc angularjs

Choosing a JavaScript MVC Framework

Deciding on a client-side MVC framework can be tough – you don’t want to invest too much time on something that isn’t the right fit for your project. Craig McKeachie sent in his article, Choosing a JavaScript MVC Framework, which reviews the most popular libraries like AngularJS and Backbone.js. He takes into account things like the community following, maturity, and code size:

How many real-world production apps are using these frameworks and how many users do these apps have? How good is the documentation and how many examples/tutorials are available? Are the examples up to date? How stable is the API? Do other developers know or are getting to know this technology?

He notes that these frameworks actually fall into subcategories, so it’s hard to directly compare each of them.

After looking at the projects by features it became clear to me that I wasn’t really comparing “apples to apples.” A more fair comparison might be to compare full frameworks like AngularJS and EmberJS with stacks that include great but less broad libraries like Backbone and KnockoutJS.

The article also introduces the main concepts used by these libraries, so if you’re confused about data binding or models then this should get you started.


lrNotifier (GitHub: lorenzofox3 / lr-notifier, License: MIT) by Laurent Renard is an AngularJS directive for showing notifications. Notifications can be split into channels, allowing you to control where info, debug, or error messages will be displayed.

app.controller('myCtrl', ['lrNotifier', function(notifier) {
  var channel=notifier('channelName');

  channel.pushNotification({ message: 'hello channel', otherProp: 'other' });'a great message');
  channel.warn('a great message');
  channel.error('a great message');

Node Roundup: 0.10.23, 2013, Bull

18 Dec 2013 | By Alex Young | Comments | Tags node modules queue redis

Node 0.10.23 Released

Node v0.10.23 is out. This release upgrades uv, npm, and has patches for several core modules. I particularly liked “events: avoid calling once functions twice”. This would happen when emitting an event from inside the event hander. The fix involves using a boolean to track if the event has fired, so it’s not too drastic.

Node in 2013

If I think back over 2013, all I can remember is being punched in the face a lot by my son. He’s a year old, so I’m hoping this sort of thing stops before he gets much bigger. For those of you who still have brain cells, Gergely Nemeth sent in a timeline of Node in 2013. This includes news like Ghost getting funded,’s release, and the ScaleNPM funding drive.

Bull Job Manager

Manuel Astudillo sent in Bull Job Manager (npm: bull, License: BSD). It’s a job queue manager that uses Redis and has an API inspired by LearnBoost’s Kue.

Manuel says it’s designed with atomicity in mind. Looking at the source, it uses atomic increments and blocking operations (BRPOPLPUSH), so it should be as atomic as Redis is.

Dynatable, nanoGallery, jQuery Audit

17 Dec 2013 | By Alex Young | Comments | Tags jquery tables ui galleries chrome



Dynatable (GitHub: JangoSteve / jquery-dynatable, License: AGPL or commercial) by Steve Schwartz is a library for displaying JSON data as friendly and efficient HTML tables. It provides a framework for searching, sorting, and filtering data. It uses jQuery, and can be invoked with $.dynatableSetup.

Dynatable can convert plain HTML tables into JSON. The properties for the JSON can be camelCase, but other styles are supported, including dashed and underscore. This is set with the table.defaultColumnIdStyle option.

JSON can also be fetched from a server. In this case you can use the dataset option:

  dataset: {
    ajax: true,
    ajaxUrl: '/dynatable-ajax.json',
    ajaxOnLoad: true,
    records: []

It expects a corresponding skeleton table node, with thead and tbody.

The documentation is thorough and includes examples for each of these things, and the other features provided by the library.


Nobody’s sent me a jQuery gallery for a while. nanoGALLERY (GitHub: Kris-B / nanoGALLERY, License: CC BY-NC 3.0) by Christophe Brisbois supports Flickr and Google+, and supports responsive layouts. You can get a gallery going with a Google account like this:

  kind: 'picasa',
  userID: ''

It comes with CSS, but you can theme it. It displays a gallery navigator using folders, so it could scale up quite well to a large collection.

Documentation for the main options and expected markup can be found in the project’s readme file.

jQuery Audit

jQuery Audit (GitHub: zertosh / jquery-audit, License: MIT) by Andres Suarez is a Chrome Developer Tools extension for auditing jQuery. It adds a sidebar (under Elements) that includes details of delegated events and internal data.

The documentation has explanations of the main features, and instructions on how to use the extension properly. For example, you can dig into bound functions for event handlers which can be bound differently based on the library.

UIkit 2.0, bitcoinprices.js

16 Dec 2013 | By Alex Young | Comments | Tags ui libraries bitcoin


UIKit 2.0

UIKit 2.0 (GitHub: uikit / uikit, License: MIT) is a frontend framework that provides components for layout, navigation, and more complex UI widgets like dropdown replacements. It uses jQuery and FontAwesome. Version 2 has just been released, which has some new features including a Markdown editor that supports syntax highlighting and an extensible toolbar.

There’s extensive documentation and a theme tool, so you can have a look at the main features quite easily.


bitcoinprices.js (GitHub: miohtama / bitcoin-prices, License: MIT) by Mikko Ohtamaa is a client-side library for fetching Bitcoin prices. It supports currency selection, and uses BitcoinAverage as the price API.

BitcoinAverage itself is an open source Python project that monitors multiple exchanges for prices:

Price is a weighted average. Meaning that for every exchange the last trade price and last 24h trading volume is taken, each exchange contributes to the final price only to the extent of it’s current trading volume. For a more detailed arithmetics explanation check here.

It’s got a nice and simple Bootstrap-based website with graphs and tables.


13 Dec 2013 | By Alex Young | Comments | Tags vim emscripten editors
Surely the very reason Emscripten was created?

Finally, my worlds have collided! In case you didn’t know, I regularly write a Vim blog. It’s surprisingly easy to find things to say about this 22 year old text editor, and it’s been my main tool for writing code and articles for a long time. Vim.js (GitHub: coolwanglu / vim.js) by Lu Wang is an Emscripten port of Vim, allowing you to use Vim in a browser.

It runs pretty well on my computer – it seems fast, and the commands I typically use work. It’s not like these Vim layers for IDEs and other editors that miss certain motions, registers, and so on: it’s basically Vim. Split windows and tabs work, but the help files aren’t available (or I can’t find them). The way it works in the browser is to use a <span> for each terminal character, which means for the 43x115 example window there are 4945 spans!

From a JavaScript point of view, I found the Sync to Async Transformation document interesting. The author is trying to figure out how to deal with JavaScript’s asynchronous nature, given that Vim expects to have a non-busy synchronous sleep() function:

Most works are automatically done by web/transform.js, read the comments inside for more detail. But there are a few left, mainly function pointers, which cannot be automatically identified. Whenever vim.js crashes and you see callback function is not specified! in the browser console, congratulations, you have found one more async function at large.

I wonder if there are any Node developers or ES6 experts that can help with this? If you’re interested in the project, there’s a TODO which has some Emscripten issues and client-side work that needs doing.

JavaScript Developer Survey 2013: Results

12 Dec 2013 | By Alex Young | Comments | Tags community surveys

The JavaScript Developer Survey has now closed. As always the results are available to the community for further analysis:

Most people write client-side code.

51% of readers write client-side code, while 28% said they write server-side code. Last year client-side was at 98%, so I imagine this is partly due to a changing audience on DailyJS, but it’s interesting how strong server-side development is becoming.

Where do you write JavaScript? 54% said “at work”, and 45% said “side projects”. This is probably a case of people doing both – I find it’s common for programmers to be both hobbyists and professionals.

The majority of readers have been writing JavaScript for three to five years (34%). I can’t help but feel this is thanks to the growth of Node – people rediscovering JavaScript after using other languages for server-side web development, or the growth of client-side frameworks like AngularJS and Backbone.js. I can’t imagine doing design without some JavaScript skills.

78% of readers said they don’t use a language that compiles to JavaScript. I’ve noticed some of the influential members of the Node community are vocal about these languages, so it seems like our readers agree. I try to keep some coverage of these languages on the blog, but in general the focus is on JavaScript.

CoffeeScript was the most popular “compile-to” language (64%), and TypeScript was up from last year to 19%.

The style question caused much confusion. Semicolons, commas at the end, and methods with one space were popular options. It’s interesting to see 9% using tabs and 11% using spaces. Unlike some languages, JavaScript can survive a little bit of variance in tab size, so I’m not too bothered either way. Client-side veterans seem to use four spaces, though, and 8% of respondents selected this option.

The results for testing amused me:

  • Yes: 25%
  • No: 26%
  • Sometimes / Not enough / Not too much / When needed: 50%

I like your honesty. “Not enough” could be just modesty, so I’m going to read this as “a lot of readers write tests but think they could be doing better”.

Jasmine is hugely popular, with 30%. I still think tap is the best approach, but it only received 2% of your clicks. Mocha’s doing well with 27%, and QUnit is down to 16%. I think this is more evidence of a large number of Node developers doing the survey, but it could also be the fact that people see Mocha as a browser/Node module, and QUnit as something just for jQuery (which it isn’t really).

CI servers? 36% said yes. Node is definitely CI server friendly – I’ve recently been setting up a TeamCity server for Objective-C projects and it’s surprisingly hard work. Compared to switching on Travis CI for an open source Node project it’s a joke. However, Jenkins is the most popular CI server (44%), and TeamCity got 13%, so perhaps people find it easy to slot client-side or Node tests into an existing CI server in companies that use multiple languages.

AMD is extremely popular.

It turns out people like AMD! However, if we break down the stats for CommonJS, we see 17% using CommonJS and 12% using Browserify. For a long time I advocated CommonJS, but substack’s Browserify argument is convincing…

Grunt is winning at build scripts (60%). Fortunately, “npm scripts” had a good response (17%), which is encouraging because I feel like lots of tasks are simple enough to work that way, rather than needing a confusing 200 line Gruntfile.

I was surprised to see AngularJS and Backbone.js both get 25% for client-side frameworks. They have mindshare, but I can’t help but feel they solve very different problems.

The common wisdom seems to be IE support should start at IE 8 (37%). I’m going to guess that’s to support corporates, which has been the bane of my web development existence for over a decade now.

Do you use ES6 features? 85% said “No”, so you’re OK if you don’t. I probably only do to write DailyJS articles, but we’ll see this start to grow over the next year.

PHP is the most popular primary development language (24%), and C# got 17%. Hello .Net folks!

Thanks to everyone who took part in the survey! If you can use the data for something cool, I’d love to hear about it.

Node Roundup: parse5, redis-timeseries, request-as-curl

11 Dec 2013 | By Alex Young | Comments | Tags node modules curl html parsing redis statistics


parse5 (GitHub: inikulin / parse5, License: MIT, npm: parse5) by Ivan Nikulin is a new HTML5 parser, based on the WhatWG HTML5 standard. It was built for a commercial project called TestCafé, when the authors found other HTML5 parsers to be too slow or inaccurate.

It’s used like this:

var Parser = require('parse5').Parser;
var parser = new Parser();
var document = parser.parse('<!DOCTYPE html><html><head></head><body>Hi there!</body></html>')
var fragment = parser.parseFragment('<title>Parse5 is &#102;&#117;&#99;&#107;ing awesome!</title><h1>42</h1>');

I had a look at the source, and it doesn’t look like it was made with a parser generator. It has a preprocessor, tokenizer, and special UTF-8 handling. There are no dependencies, other than nodeunit for testing. The tests were derived from html5lib, and include over 8000 test cases.

If you wanted to use it, you’ll probably need to write a “tree adapter”. Ivan has included an example tree adapter, which reminds me of writing SAX parser callbacks.

Ivan also sent in mods, which is a module system designed to need less boilerplate than AMD-style libraries.

Redis Time Series

Tony Sokhon sent in redis-timeseries (GitHub: tonyskn / node-redis-timeseries, License: MIT, npm: redis-timeseries), a project for managing time series data. I’ve used Redis a few times as a data sink for projects that need realtime statistics, and I always found it worked well for the modest amounts of data my projects generated. This project gives things a bit more structure – you can create instances of time series and then record hits, then query them later.

A time series has a granularity, so you can store statistics at whatever resolution you require: ts.getHits('your_stats_key', '1second', ts.minutes(3), callback). This module is used by Tony’s dashboard project, which can be used to make a realtime dashboard.


request-as-curl (GitHub: azproduction / node-request-as-curl, License: BSD, npm: request-as-curl) by Mikhail Davydov serialises options for http.ClientRequest into an equivalent curl command. It also works for Express.

// http.ClientRequest:
var req = request('', {method: 'POST', json: data}, function (error, response, expected) {
  curlify(req.req, data);
  // curl '' -H 'accept: application/json' -H 'content-type: application/json' -H 'connection: keep-alive' --data '{"data":"data"}' --compressed

// Express:

app.get('/', function (req) {
  // curl 'http://localhost/pewpew' -H 'x-real-ip:' -H etc...

I imagine Mikhail has been using this so he can replicate requests based on logs to aid in debugging.

Feathers, Angular Snap.js, File-size.js

10 Dec 2013 | By Alex Young | Comments | Tags frameworks libraries modules node angularjs


Feathers (GitHub: feathersjs / feathers, License: MIT, npm: feathers), sent in by Matthew Phillips, is an Express-based web framework for creating RESTful services that use Socket.IO.

Because it’s based on Express, you can use existing Connect middleware. That means you could drop in an authentication module like everyauth, and your preferred client-side framework (like Backbone.js or AngularJS), and then use the Feathers conventions for CRUD-style server-side code and Socket.IO events.

Matthew wrote a glowing email about it – he’s been using it for client project. I had a look at the source, and it’s actually pretty lightweight: it’s basically based around events that bridge between Express routes and Socket.IO.

The main author, David Luecke, has built it with Rubberduck and Uberproto, two of his other modules. Uberproto is basically inheritance sugar, and Rubberduck allows methods to be wrapped with events.

Angular Snap.js

Angular Snap.js (GitHub: jtrussell / angular-snap.js, License: MIT) by Justin Russell is a Snap.js directive for AngularJS. Snap.js makes mobile-style “shelf” layouts a lot easier, and is intuitive to use – touch gestures work as expected, and click-dragging the mouse opens the drawer as well.

The directive can be used as an attribute, or event an element:

<div snap-drawer>
  <p>I'm a drawer! I maybe I've got some sweet navigation links.</p>

  <p>I'm a drawer! I maybe I've got some sweet navigation links.</p>


File-size.js (GitHub: Nijikokun / file-size, License: MIT, npm: file-size) by Nijiko Yonskai is a module for generating human-readable file sizes. For example, filesize(186457865).to('MB') returns 177.82.

It supports various specifications, including JEDEC and IEC, and it works in browsers and Node.

Lazy Module Declaration, Mozilla Funds Hoodie

09 Dec 2013 | By Alex Young | Comments | Tags frameworks libraries

Lazy Module Declaration


Lazy Module Declaration (GitHub: azproduction / lmd, License: MIT), or LMD, is a module “assembler”. Modules are written with CommonJS, then you add a JSON file that describes the build process. This file can be generated by the lmd command-line tool. The command-line tool can selectively include client-side specific functionality, so you can do things like build with IE optimisations.

It can also load CSS, and has Node integration. Interestingly, require seems to be decorated rather than overloaded:

require() is not overloaded:

  • require.css() for css
  • require.js() for js (non LMD-modules)
  • require.async() for async LMD-modules (objects, strings, modules)

The main contributor (Mikhail Davydov) works at Yandex, and is writing some interesting features for it. For example, there’s a screenshot of a Mac-style GUI tool for LMD that looks impressive.

Mozilla Funds Hoodie

I wrote about Hoodie a few weeks ago, and the project recently had some good news: Mozilla donated $25,000.

Team Hoodie is proud to announce that Mozilla is supporting Hoodie with a $25,000 donation. Mozilla has interest in Hoodie with their Appmaker initiative. The donation will ensure that Hoodie development will commence faster and some early goals are support for Persona authentication in Hoodie, as well as a Docker-based “Hoodie as a Service” setup. In the spirit of both Mozilla and Hoodie, all this work will be available as Open Source software.

That’s encouraging because there are many projects similar to Hoodie vying for wider adoption, so this seems like a much needed feather in Hoodie’s cap.

Notch and WebGL, npm_lazy

06 Dec 2013 | By Alex Young | Comments | Tags webgl npm games node

Notch, WebGL, Dart

Brandon Jones wrote a summary of Notch’s WebGL and-Dart related activity: Notch, WebGL, Dart, and ramping up quickly:

I can’t tell you how many time I see hobby developers saying ”I’m building a game!” and what they actually have to show for it is a really complicated system for loading meshes and shaders. It’s all well and good to think about long term goals and engine structure and such, but if you’re going to build a game then please build a freaking game! Don’t build an engine that you will someday build a game on top of, because you will never get past step one.

Dart seems to appeal to Notch, maybe because of his Java background. It’s cool seeing his work come together on Twitter, from the initial ideas to working code with screenshots.


Sometimes npm goes down (which is why you should donate to npm). But there’s a solution: mirror it! If you’re too lazy to mirror the whole thing, how about just caching the modules you need to deploy your projects? That’s where npm_lazy by Mikito Takada comes in.

This is a local cache for npm. It has a configuration file that allows you to tailor it to your needs – you can set the cache lifespan, HTTP timeout, and so on. Once you’ve set that up, you can run it as a server. Then you just use npm --registry to set the server as your npm registry.

It has some caching logic – anything that isn’t local will be fetched, and metadata is updated when a module is requested the first time after a restart.

Multiprocess Firefox

05 Dec 2013 | By Alex Young | Comments | Tags firefox browsers

Multiprocess Firefox

I know a lot of DailyJS readers who use Chrome and Safari as their main browsers, partly due to iOS and Android’s popularity, and partly because Chrome’s initial performance gains enticed them away from Firefox. The big issue over the last few years has been the fact browsers are switching to using multiple processes, the idea being that resources can be shared better and fallout from crashes can be mitigated.

If Firefox isn’t your main browser, you probably use it for testing or just try it out every few months to see what’s been going on. The thing most of us have been looking for is Chrome (and apparently IE)-style multi-process support. Bill McCloskey has written a post about this very topic: Multiprocess Firefox. Bill is a programmer at Mozilla, and you may remember his post about incremental GC in Firefox.

Although the work so far sounds promising, there are some major technical hurdles. These partly relate to the nature of how JavaScript interacts with the DOM, and how Firefox handles add-ons:

JavaScript execution and layout happen on the main thread, and they block the event loop. Running these components on a separate thread is difficult because they access data, like the DOM, that are not thread-safe. As an alternative, we’ve considered allowing the event loop to run in the middle of JavaScript execution, but doing so would break a lot of assumptions made by other parts of Firefox (not to mention add-ons).

Like the threaded approach, Firefox is able to run its event loop while JavaScript and layout are running in a content process. But unlike threading, the UI code has no access to content DOM or other content data structures, so there is no need for locking or thread-safety. The downside, of course, is that any code in the Firefox UI process that needs to access content data must do so explicitly through message passing.

You might not realise it, but Firefox itself uses a lot of JavaScript:

Content scripts. IPDL takes care of passing messages in C++, but much of Firefox is actually written in JavaScript. Instead of using IPDL directly, JavaScript code relies on the message manager to communicate between processes.

We decided to do the message passing in JavaScript instead, since it’s easier and faster to prototype things there. Rather than change every docshell-using accessor to test if we’re using multiprocess browsing, we decided to create a new XBL binding that applies only to remote <browser> elements. It is called remote-browser.xml, and it extends the existing browser.xml binding.

If you’re an add-on author, you’ll be pleased to hear add-ons are being taken seriously. However, Mozilla may need your help in the future:

We realize that add-ons are extremely important to Firefox users, and we have no intention of abandoning or disrupting add-ons. At the same time, we feel strongly that users will appreciate the security and responsiveness benefits of multiprocess Firefox, so we’re willing to work very hard to get add-ons on board. We’re very interested in working with add-on developers to ensure that their add-ons work well in multiprocess Firefox.

It’s hard to imagine Firefox OS not using multiple processes, and Bill mentions this early on in the post:

Firefox OS relies heavily on the multiprocessing and IPC code introduced during Electrolysis.

Electrolysis was a project to use multiple processes, but the focus was tighter than changing the desktop browser. Firefox’s layout engine, Gecko, supports multiple threads, and the “Gecko platform” supports multiple processes. But, as the Electrolysis wiki page points out, the Firefox frontend does not currently use multiple processes.

Will we see a browser share increase when Firefox is updated to support multiple processes? I don’t know, but as a front-end developer I’m excited about seeing this feature released sooner rather than later.

Node Roundup: Ben Noordhuis,, Infect.js

04 Dec 2013 | By Alex Young | Comments | Tags node modules objective-c di

Ben Noordhuis

Every time I write about a new Node release, I notice how much work Ben Noordhuis has done. He’s been an important contributor to Node and libuv, and has always seemed patient and polite on the mailing list.

Ben Noordhuis decided to leave Node and libuv. If you’re not familiar with his work, take a look at the Node ChangeLog – Ben’s commits go back to summer 2010. Ben will be missed! (GitHub: node-app / Interpreter, License: MIT) is a project to bring Node’s API to JavaScriptCore. The aim is a drop-in replacement that’s compatible with Node’s master branch, and to reuse the JavaScript in Node’s lib/ directory (the core modules).

It needs the latest iOS or Mac OS X, and if you check out the source you’ll need to get the submodules (git submodule update --init --recursive).

The list of currently working modules includes partial fs support, util, url, events, path, stream, querystring, and assert. The process object is also supported.

I’ve only had a brief look at the source in node-app / Nodelike, but it looks like they’re writing Objective-C to add the necessary libuv bindings. This is the code you’ll find in src/ in joyent / node.


Infect.js (GitHub: amwmedia / infect.js, License: MIT, npm: infect) by Andrew Worcester is a dependency injection module. It’s not specifically for Node, but I was intrigued by the idea of bringing AngularJS-style DI to Node projects.

Registering a dependency. A simple call to infect.set() with the name you want to use, and the mutable object you’d like to register will do the trick. In the example below we are using a function, but you can register any type of mutable value (Functions, Arrays, Objects, etc).

infect.set('Logger', function(str) {
  // prepend a time to every log line
  console.log((new Date()).toLocaleTimeString() + ' ==> ' + str);

It supports function injection (infect.func) and class injection (infect.func with a constructor function). Andrew has included jsFiddle examples in the readme, so you can play around with the code.

AngularJS D3 Charts, Yo three.js, TinyCore.js

03 Dec 2013 | By Alex Young | Comments | Tags libraries webgl architecture graphics yeoman

AngularJS D3 Charts

Chinmay sent in Angular-charts (GitHub: chinmaymk / angular-charts, License: MIT, bower: angular-charts), a set of AngularJS directives for graphs that use D3. To use it, include angular-charts.min.js and then inject the dependency with angular.module('yourApp', ['angularCharts']).

Configuration options for graphs can be included using directives, or passed as options in JavaScript. There are also events for mouseover, mouseout, and click. The charts have animations, tooltips, and the values will be adapted to the graph’s size as necessary.

A Yeoman Generator for three.js

If you’re looking for a friendly way to get started with three.js, then Timmy Willison’s Yeoman generator (GitHub: timmywil / generator-threejs, License: MIT, npm: generator-threejs) may be what you’re looking for.

The template it outputs renders a red cube, and it includes the usual Yeoman stuff like a Grunt build script and a web server for development.


TinyCore.js (GitHub: mawrkus / tinycore, License: MIT) by Marc Mignonsin is a library for organising projects around modules:

We use dependency injection to provide the modules the tools they need to perform their job. Instead of having a single sandbox object with a lot of methods, a module defines explicitly the tools it needs. The mediator, that provides a way of communication for the modules, is one of the default tools that has already been implemented (located in the “tools/mediator” folder).

Modules have an extensible, event-based API. There’s also a factory class, called “Toolbox”:

In order to provide the modules the tools they need to perform their job, TinyCore uses a tools factory, TinyCore.Toolbox. A tool can be registered at any time for later use. Whenever a module is instantiated, the tools specified in the module definition will be requested and injected as parameters of the creator function.

TinyCore is written with testing in mind, and has an extension for Jasmine.

connect-cache-manifest, pushnot

02 Dec 2013 | By Alex Young | Comments | Tags express node apps


connect-cache-manifest (GitHub: dai-shi / connect-cache-manifest, License: BSD, npm: connect-cache-manifest) by Daishi Kato is Express middleware for generating a HTML5 cache manifest file. Manifests basically list the files needed by the application when it’s offline, so any essential client-side assets can be cached by the browser.

Daishi’s middleware takes an object and then generates a suitable manifest file. It can recurse through directories so including lists of JavaScript, CSS, and images is easier.

  manifestPath: '/application.manifest',
  files: [{
    file: __dirname + '/public/js/foo.js',
    path: '/js/foo.js'
  }, {
    dir: __dirname + '/public/css',
    prefix: '/css/'
  }, {
    dir: __dirname + '/views',
    prefix: '/html/',
    ignore: function(x) { return /\.bak$/.test(x); },
    replace: function(x) { return x.replace(/\.jade$/, '.html'); }
  networks: ['*'],
  fallbacks: []



pushnot (GitHub: dtinth / pushnot, License: MIT) by Thai Pangsakulyanont is a push notification server based on ØMQ, Express, and Zephyros. It supports notification encryption and can be hooked up to Growl.

Pushnot consists of three major components: The server that clients can send a notification to, and subscribers can subscribe to these notifications. The client is any application that wants to send a notification to the user. The subscriber waits for the server to push the notification and notifys the user.

It’s got an interesting mix of technologies, if you’re looking for an Express application that uses pub/sub, and it has a command-line interface as well.