Moonjs, jQuery Removes Sourcemap Comments

18 Nov 2013 | By Alex Young | Comments | Tags jquery space simulation

Moonjs

Moonjs (GitHub: siravan / moonjs, License: GPL) by Shahriar Iravanian is a port of the Apollo Guidance Computer using Emscripten.

AGC was the main computer system of the Apollo program that successfully landed 12 astronauts on Moon. There was one AGC on each of the Apollo Command Modules and another one on each Lunar Module. There was also a second backup computer system called Abort Guidance System (AGS) on the Lunar Modules, which is simulated by Virtual AGC, but not the current version of Moonjs.

Recent advances in the JavaScript language - such as optimized engines, ahead-of-time (AOT) compilation, and asm.js - make it possible to write computationally extensive applications in JavaScript. My previous experience with online JavaScript-based simulation (svtsim and hemosim) was very positive and convinced me of the suitability of the HTML5/JavaScript combination in writing portable, easy-to-use simulators.

I was going to try figuring it out, but it reminded me of Kerbal Space Program and I got distracted…

jQuery 1.11.0/2.1.0

jQuery 1.11.0/2.1.0 Beta 2 were released last week. The beta includes AMD support, which is still the headline feature.

Something that I found interesting was the removal of the sourcemap comment:

One of the changes we’ve made in this beta is to remove the sourcemap comment. Sourcemaps have proven to be a very problematic and puzzling thing to developers, generating scores of confused questions on forums like StackOverflow and causing users to think jQuery itself was broken.

We’ll still be generating and distributing sourcemaps, but you will need to add the appropriate sourcemap comment at the end of the minified file if the browser does not support manually associating map files (currently, none do). If you generate your own jQuery file using the custom build process, the sourcemap comment will be present in the minified file and the map is generated; you can either leave it in and use sourcemaps or edit it out and ignore the map file entirely.

That fact sourcemaps generate so much confusion is worth thinking about, because it’s one of those things that people cite as making compile-to-JavaScript languages easier to work with.

Negative Array Indexes

15 Nov 2013 | By Alex Young | Comments | Tags node modules es6 code-review

Sindre Sorhus sent in negative-array, a module for supporting negative array indexes. It’s built using ES6’s Proxy.

Proxies allow you to run methods when certain conditions are met, which means things like profilers become easier to implement. They’re created with var proxy = Proxy(target, handler), where target is an object that will be wrapped with the proxy, and handler is an object that implements the proxy API.

The handler can include methods like has, defineProperty, getPrototypeOf, and more, for controlling access to an object. For more details on how this works, see the Direct Proxies page on the ECMAScript Harmony Wiki.

Sindre’s module allows you to do this:

var negativeArray = require('negative-array');

// adds negative array index support to any passed array
var unicorn = negativeArray(['pony', 'cake', 'rainbow']);

// get the last item by using an negative index
console.log(unicorn[-1]);

It’ll work in Node 0.8+ with the --harmony flag, and Chrome with Harmony enabled. Visit chrome://flags/#enable-javascript-harmony to set it up.

The implementation is what will probably become a classic pattern: Proxy is used to wrap the array instance with get and set methods that dynamically map the requested array index to something native JavaScript can handle.

Proxy(arr, {
  get: function (target, name) {
    var i = +name;
    return target[i < 0 ? target.length + i : i];
  },
  set: function (target, name, val) {
    var i = +name;
    return target[i < 0 ? target.length + i : i] = val;
  }
});

I like this example because it adds new functionality that feels like a language feature without changing built-in prototypes. It’s clean and fairly easy to understand once you know what Proxy does. If you wanted to learn about proxies but couldn’t find any good examples, then check out the source on GitHub.

Assertion Counting in Mocha

14 Nov 2013 | By Alex Young | Comments | Tags node libraries testing mocha

A few weeks ago I wrote about node-tap, in Why Don’t You Use Tap?. I usually use Mocha for my tests, and one thing I liked about node-tap was the idea of test plans:

test('Check out my plan', function(t) {
  t.plan(1);
  t.ok(true, "It's ok to plan, and also end.  Watch.");
  t.end();
});

Test plans help in situations where you want to put assertions inside asynchronous events. For example, if you’re testing a web application and it makes HTTP requests in the test cases, but you also intercept events that indicate various lifecycle events. These could be things like ensuring a notification email was sent when a user signs up, and also checking that their account was saved to the database.

In Mocha, such a test might look like this:

describe('Account creation', function() {
  it('should allow users to sign up', function(done) {
    app.on('notify:accounts:create', function(account) {
      assert(account, 'expected a user account object');
      done();
    });

    request(app).post('/accounts').send(userDetails).expect(200, done);
  });
});

That’s OK, but it has some problems: done will be called twice – once when the web request finishes, and again when the email event is sent (notify:accounts:create).

We could fix this by counting how many assertions have been called:

describe('Account creation', function() {
  it('should allow users to sign up', function(done) {
    var expected = 2;

    function checkDone() {
      expected--;
      if (expected === 0) {
        done();
      }
    }

    app.on('notify:accounts:create', function(account) {
      assert(account, 'expected a user account object');
      checkDone();
    });

    request(app).post('/accounts').send(userDetails).expect(200, checkDone);
  });
});

Seeing checkDone all over my tests made me create something more generic. In the following example I use instances of an object called Plan that allows assertions to be counted, and done to only get called once the specified number of assertions have passed. This example can be run with the mocha command-line script.

var assert = require('assert');

function Plan(count, done) {
  this.done = done;
  this.count = count;
}

Plan.prototype.ok = function(expression) {
  assert(expression);

  if (this.count === 0) {
    assert(false, 'Too many assertions called');
  } else {
    this.count--;
  }

  if (this.count === 0) {
    this.done();
  }
};

describe('Asynchronous example', function() {
  it('should run two asynchronous methods', function(done) {
    var plan = new Plan(2, done);

    setTimeout(function() {
      plan.ok(true);
    }, 50);

    setTimeout(function() {
      plan.ok(true);
    }, 25);
  });
});

This code could be expanded to tie in with Mocha’s timeouts to display the number of missed assertions, if any. Otherwise it does the job: if any of the asynchronous callbacks don’t fire, Mocha will raise a timeout error. It also protects against calling assertions too many times, which can actually happen if you’re making your own asynchronous APIs: I’ve had cases where I’ve triggered callbacks twice by mistake. And, it ensures done is only called when needed.

The question of ensuring assertions were actually called was brought up in this issue for Chai.js: Asserting that assertions were made. And, the Mocha wiki has this assertion counting snippet: Assertion counting.

Outside of Mocha, I found QUnit has asyncTest which allows assertions to be planned like TAP-style tests. With this approach we don’t need to broker calls to done because it uses start instead.

I’ve never quite found the perfect solution to this problem, however. How do you ensure assertions are triggered in Mocha, and how do you handle calling done in tests where there are multiple asynchronous operations?

Node Roundup: 0.10.22, genome.js, Bellhop

13 Nov 2013 | By Alex Young | Comments | Tags node modules biology streams

Node 0.10.22

Node 0.10.22 was released this week. This version has fixes for process, the debugger and the repl, and a memory leak on closed handles.

There’s also a fix for Mac OS 10.9: apparently “Not Responding” was displayed in Activity Monitor for Node processes.

genome.js

DNA card

genome.js is an interesting project that proclaims “Welcome to the OpenDNA movement”:

genome.js is a fully open source platform built on Node.js that utilizes streams for high-performance analysis of DNA SNPs

There are currently several related repositories for the overall project on GitHub:

Why is this useful? Perhaps you’ve had your genome sequenced by a site like 23andMe, and want to do something with the data. Apparently the cutting edge in web-based DNA browsing isn’t particularly great, so there may be room for innovation.

Bellhop

Bellhop (GitHub: mscdex / bellhop, License: MIT, npm: bellhop) by Brian White is a stream for Pub/Sub and RPC. It can serialize data types that aren’t supported by JSON. Bellhop streams should work over any transport, from HTTP to TCP sockets.

The project has tests, and the readme includes API examples.

Recreating core.async with ES6 Generators, JSON Mask

12 Nov 2013 | By Alex Young | Comments | Tags tutorials node json es6 generators clojure

Recreating core.async with ES6 Generators

Recreating core.async with ES6 Generators is a post by Andrey Popp inspired by Clojure’s core.async. He uses Browserify with a transpiler module that allows ES6 generators to be used in browsers:

function *listen(el, evType) {
  while (true)
    yield function(cb) {
      var fire = function(ev) {
        el.removeEventListener(evType, fire);
        cb(null, ev);
      }
      el.addEventListener(evType, fire);
    }
}

The tutorial goes on to use JSONP to fetch data from the Wikipedia API. The full source is available as a gist: andreypopp / index.html.

JSON Mask

JSON Mask (GitHub: nemtsov / json-mask, License: MIT, npm: json-mask) by Yuriy Nemtsov is a module that provides a DSL for filtering JSON. It works in browsers, includes unit tests, and there’s also Express middleware that can help you filter responses in your Express applications.

One use-case is when you have an HTTP service that returns {"name": "mary", "age": 25} (for example), and you have two clients: (1) that needs all of that information, and (2) that just needs the name.

Now, if the server uses JSON Mask, it would accept a ?fields= query-string. The (2)nd client would then add the following query-string to the request: ?fields=name; after which the server would respond with {"name": "mary"}, and filter out the rest of the information.

This saves bandwidth and improves performance; especially on large objects.

Although trivial in the simplest cases, the task of filtering objects becomes a difficult one quickly. This is why JSON Mask is actually a tiny (and highly optimized) language that is loosely based on XPath, and has support for filtering parts of objects, arrays, wild-card filtering and combinations of the three. So, here’s a less trivial example and usage (note how p/a/b is filtered out):

Getting Started with Hoodie

11 Nov 2013 | By Alex Young | Comments | Tags tutorials node couchdb
Fast ship?

Hoodie (GitHub: hoodiehq / hoodie.js, License: Apache 2.0, npm: hoodie) is a noBackend framework that uses Node, with a focus on client-side development.

noBackend is an approach to decouple apps from backends, by abstracting backend tasks with frontend code. This allows frontend developers to focus on user experience and gives backend developers more flexibility on the implementation side.

Hoodie applications are based around documents, and are backed by CouchDB. It embraces event-based APIs, JSON across the whole stack, and uses npm for plugins. It’s also designed to be easy to deploy to Nodejitsu.

Applications are instances of Hoodie objects. This provides the entry point to most functionality, including user accounts – Hoodie comes with a baked-in account system. Data is stored per-user through hoodie.store, which is accessible from client-side code. In this respect it’s reminiscent of Meteor.

Data lifecycle stages trigger events, so you can easily see when data is changed in some way:

hoodie.store.on('add:task', function(event, changedObject) {
  // Update the view with the changedObject
});

The API is chainable and will remind client-side developers of jQuery.

As a teaser, here are some of the account handling method calls:

hoodie.account.signUp('joe@example.com', 'secret');
hoodie.account.changeUsername('currentpassword', 'newusername');
hoodie.account.resetPassword('joe@example.com');
hoodie.account.destroy();

To start your own project you’ll need CouchDB installed locally. Then you can npm install -g hoodie-cli, which will allow you to run hoodie new to create a new project. The process is straightforward if you’re already using Node and don’t mind running CouchDB, and it’s fully documented on Hoodie’s website.

The documentation for Hoodie is solid, and I’ve found it easy to follow so far. Although I only learned about it at the Great British Node Conference, the developers have been working on it for over a year. It has sponsors, and is looking for more. It’s a well-presented, open source project, with momentum behind it.

Talking to Sven Lito at the Great British Node Conference I got the impression that the team are treating it as a commercial project, while believing in the open source model. This made me want to get on board and use it myself, so I suggest you give it a try.

Socket.IO Debugging

08 Nov 2013 | By Alex Young | Comments | Tags npm node websockets

How do you debug WebSockets, other than inserting console.log all over the place? One technique is to look at the Frames tab, under Network, in WebKit Inspector.

The Frames tab in WebKit Inspector.

The term “frames” refers to the data that is sent in a WebSocket connection. Unfortunately, I’ve been doing some work with WebSockets inside a desktop application, so I can’t easily see WebKit inspector.

Diego Costantino sent in ThreePin (GitHub: dieguitoweb / ThreePin, License: MIT, npm: threepin, bower: dieguitoweb/ThreePin), a tool for developing and testing software that uses Socket.IO and Node:

ThreePinJS is a stress-free test environment for Socket.IO allows you to test your WebSocket server code before you write the client code.

It uses a configuration file called threepin.json that sets up a server, and a list of events to listen for and send. The readme has a full example.

Once the server is configured, you can use any local HTTP server you want to serve a simple HTML file that connects and runs through the event list. It means you can focus on the server-side logic before worrying about the client-side code.

I’m still looking for options to help test and debug Socket.IO projects, but I thought ThreePin was an interesting stab at the problem.

Should You Share Client-Side Projects on npm?

07 Nov 2013 | By Alex Young | Comments | Tags npm node browser

Should you share your client-side projects with npm? Or, as a client-side developer, should you be using npm and a package.json to organise your project’s dependencies?

People are already using npm for distributing client-side code for many types of projects:

  1. Generic JavaScript that is sometimes used on the server but often used in the client (Underscore.js, Backbone.js)
  2. Client-side libraries that are so popular they’ve ended up npm out of convenience (jQuery)
  3. Client-side plugins for Backbone.js, AngularJS, jQuery (check out peer dependencies if you want to do this in a clean way)

If you decide to share a module using npm, you don’t necessarily need to wrap it in Node’s module system, but I would argue that you should, and you should also supply tests that can be run with Node. In an ideal world all modules on npm would include tests, and I believe this extends to client-side projects.

A recent client-side workflow pattern that has emerged, perhaps most notably from Substack, is to use Node in the browser, using something like Browserify. This means you can use require, so you can organise client-side code with Node’s module system. What I think is amazing about this is you can use Node’s core modules, so if you’re used to using EventEmitter and streams then you can bring these patterns over to the browser.

However, as Substack notes in this post on reddit, require is incompatible with RequireJS. It might seem surprising if you’re a Node developer, but the naming of require and RequireJS causes serious confusion to client-side developers who are just discovering module systems.

The Question

So, the question is, should you use npm for sharing client-side projects, or something like Bower? Do you prefer using Browserify or similar pre-processors, or is using AMD good enough?

Node Roundup: Mongovi, hoquet

06 Nov 2013 | By Alex Young | Comments | Tags node modules templating clojure mongodb

Mongovi

I’ve been working on a project that uses MongoDB, and one of the problems I have is with Mongo’s REPL. For one thing, I keep hitting CTRL-C because I expect it to cancel the current line rather than exit the whole REPL, but a bigger problem for me is they’ve switched to linenoise. I’m used to Vim’s shortcuts, which readline can use. When dealing with programs with non-readline REPLs, I often invoke rlwrap (or write an alias to use rlwrap), but when it comes to Mongo a better solution might be Tim Kuijsten’s Mongovi.

Mongovi (GitHub: timkuijsten / node-mongovi, License: MIT, npm: mongovi) is a REPL for MongoDB with Vi keys. It uses readline-vim and node-mongodb-native, so it isn’t a wrapper around the command-line mongo tool but instead a reimplementation in Node.

Several high-level commands work: show dbs lists databases, use db switches to a different database, and the usual commands like c.collectionName.find, update, and insert work. The author has included Mocha tests, and documentation can be found in the readme.

hoquet

I had a brief love affair with Clojure. It was a romance that lasted a few months, but work got in the way and we had to break up. However, thanks to Tom Brennan I can relive those days with hoquet (GitHub: tjb1982 / hoquet, License: MIT, npm: hoquet). This is a templating library based on Clojure’s Hiccup. It uses a structured language based on arrays for generating HTML:

var http = require('http'),
    h = require('hoquet');

function layout(c) {
  var out =
    ['html',
     ['head',
      ['title', c.title],
      h.styles('/css/reset.css',
               '/css/style.css'),
      c.head],
     ['body', {'ng-app':'MyApp'}, c.body]];

  return out;
}

var index = layout({
  title: 'My Page',
  body: ['div', {'ng-view':''},
         ['h1', 'Hello world']],
  head: [['meta', {'name':'description',
                   'content':'Templating'}],
         h.scripts('/js/lib/angular.min.js',
                   '/js/lib/jquery.min.js')]
});

http.createServer(function(q,s) {
  s.writeHead(200, {'Content-Type': 'text/html'});
  s.end( h.doc('html5', index) );
}).listen(8080);

Tom also notes that hoquet can be used in browsers, because the underlying implementation is plain ol’ JavaScript:

You create your own functions/literals to pass in whatever you want and call render, which stringifies it. You can also render inner portions at any time and insert them as Strings so you don’t have to worry about when render is called.

stickUp, Backbone.js Guide

05 Nov 2013 | By Alex Young | Comments | Tags books backbonejs jquery plugins ui

stickUp

stickUp (GitHub: LiranCohen / stickUp, License: LGPL) by Liran Cohen is a plugin for handling navigation bars that stick at the top of the page when it’s scrolled:

stickUp is a simple plugin that “sticks” an element to the top of the browser window while scrolling past it, always keeping it in view. This plugin works on multi-page sites, but has additional features for one-pager layouts.

It can detect the vertical position of the element and automatically fix it to the right position:

$('.navbar-wrapper').stickUp({
  marginTop: 'auto'
});

Backbone.js Guide

Julio Cesar Ody’s Backbone.js Guide is a freely available and somewhat opinionated book about Backbone that he’s currently in the process of writing. There are five chapters so far, and two more should be coming soon. The source is on GitHub at juliocesar / backbone-book.

The rule of thumb is get the hell away from the DOM. You won’t read from it ever (e.g.: getting an element’s class name, or the length of a list counts as that), because your data layer knows what has what value and in what state anything is at any given time. You’ll write to the DOM only by rendering views. If you like this approach, it’s totally ok to use just regular JS or jQuery.

Grasp, Optimizing AngularJS

04 Nov 2013 | By Alex Young | Comments | Tags angularjs search productivity optimisation

Grasp

George Zahariev sent in his latest project, Grasp (GitHub: gkz / grasp, License: MIT, npm: grasp). Grasp allows you to search and replace JavaScript code based on its abstract syntax tree.

Unlike programs such as “grep” or “sed”, it searches the structure behind your code, rather than simply the text you’ve written - this allows for much more powerful searches.

It uses a language inspired by CSS selectors for creating intuitive search expressions. For example, given this code:

var obj = {
  toEven: function(x) {
    if (isEven(x)) {
      return x;
    } else {
      return x + 1;
    }
  }
};

assert.equal(false, isEven(7));

Searching for obj.props func! #isEven would match the call to isEven inside the property toEven on the object obj. References outside, like the assertion at the bottom, will not be matched.

My preferred solution for searching code is The Silver Searcher, but I like the idea of combining an AST with search and replace – it seems like a potentially fertile ground for experimentation.

Optimizing AngularJS: 1200ms to 35ms

In Optimizing AngularJS: 1200ms to 35ms, optimisations for AngularJS are discussed. It’s actually a lot deeper than you might expect: it goes from caching DOM elements to bypassing watchers for hidden elements, and deferring element creation:

A straightforward AngularJS implementation of the log view took 1.2 seconds to advance to the next page, but with some careful optimizations we were able to reduce that to 35 milliseconds. These optimizations proved to be useful in other parts of the application, and fit in well with the AngularJS philosophy, though we had to break few rules to implement them. In this article, we’ll discuss the techniques we used.

The conventional wisdom for AngularJS says that you should keep the number of data-bound elements below 200. With an element per word, we were far above that level.

Using Chrome’s JavaScript profiler, we quickly identified two sources of lag. First, each update spent a lot of time creating and destroying DOM elements. Second, each word had its own change watcher, which AngularJS would invoke on every mouse click. This was causing the lag on unrelated actions like the navigation dropdown.

The post got a huge amount of interest, so the authors are working on open sourcing their AngularJS directives.

WDS2013, flyLabel.js

01 Nov 2013 | By Alex Young | Comments | Tags animation jquery webgl

Web Directions South 2013 Opening Titles

WDS2013

Hugh Kennedy sent in the Web Directions South 2013 Opening Titles (GitHub: smallmultiples / south.im, MIT, MPL and Creative Commons). This is an extremely impressive WebGL animation complete with a cool soundtrack. It’s partly demoscene inspired, but also reminds me of Darwinia.

The code’s open source, mostly MIT with a couple of files under the Mozilla Public License and assets under Creative Commons.

Done in collaboration with Small Multiples’ (http://small.mu) Jack Zhao and François Robichet, it’s pushing some of the newer browser APIs quite a bit - WebGL, IndexedDB, Web Audio, Web Workers, etc.

flyLabel.js

flyLabel.js (GitHub: athaeryn / flyLabel.js, License: MIT) by Mike Anderson is a jQuery plugin that adds fancy animations to form labels. It uses CSS animations, and has a simple JavaScript API. Mike’s example uses Modernizr:

if (Modernizr.input.placeholder) {
  $('body').flyLabels();
}

New Features in npm: Part 2

31 Oct 2013 | By Robert Kowalski | Comments | Tags node npm
Node has one of the best package managers around: npm. Every month a lot of features are added to npm. Here are some new features as of 1.3.12.

Default Homepage URLs

Many projects use the same URL for their homepage and GitHub page. As of 1.3.12, you do not have to define the homepage property in your package.json – if you have a GitHub URL as the repository field the homepage will default to the GitHub page.

For example, this:

"repository": {
  "type": "git",
  "url": "git@github.com:robertkowalski/npm-registry-mock.git"
},

will result in the homepage field being set to http://github.com/robertkowalski/npm-registry-mock.

Outdated Upate

npm outdated shows the latest compatible version of each module according to your package.json definition. The updated version of this command, which you can use with npm 1.3.12, will also show the very latest version, even if it is not compatible with your package.json definitions.

These will show as latest:

underscore node_modules/underscore current=1.3.1 wanted=1.3.3 latest=1.5.1

Conclusion

With a new version of npm (and also Node) a ton of features and bug fixes arrive, so you should always be up to date. Fortunately, you just have to to get the latest Node version each time, as the latest npm versions are bundled into each node release.

You can find me on Twitter @robinson_k and GitHub at robertkowalski.

Node Roundup: 0.11.8, tabby, Nixt

30 Oct 2013 | By Alex Young | Comments | Tags node modules substack node-web testing command-line

Node 0.11.8

The core developers are cranking the handle again and firing out releases. Today Node 0.11.8 was released, which upgrades uv and V8. There’s a new buf.toArrayBuffer API, debugger improvements, and core module fixes.

I saw 0.11.8 announced on Twitter, and the author hinted at more frequent unstable releases.

tabby

If it’s not TJ Holowaychuk it’s Substack. I don’t believe it’s possible to write a weekly column about Node without mentioning one of them at least once. Substack just released a client-side project called tabby (GitHub: substack / tabby, License: MIT, npm: tabby), a module for creating web applications with tabs using progressive enhancement techniques.

Why is this notable? Well, Substack has been ranting about Node’s module system and client-side code. He wants you to stop mucking about and require(). Tabby blends the browser and Node by using WebSockets, and makes judicious use of Node’s core modules and streams.

For something focused on client-side code, it uses an interesting cocktail of modules. The inherits module provides browser-friendly inheritance, whilst still being compatible with util.inherits. And trumpet is used for parsing and transforming streaming HTML using CSS selectors. In the documentation, Substack recommends using hyperspace for rendering.

Looking through the examples, it definitely feels like idiomatic Node. I can imagine this style scaling up well to a larger web application.

Nixt

Nixt

Test code readability can bring huge gains when maintaining projects. Tests should communicate intent, and the longer they don’t need heavy modification the happier everyone will be. I generally find myself writing DSL-like methods for tests that reduce code duplication, particularly in the set-up phase.

With that in mind, it’s interesting to see Nixt (GitHub: vesln / nixt, License: MIT, npm: nixt) by Veselin Todorov. This is a module for testing command-line applications. It’s based around expectations, which reminds me of good old Expect.

Nixt works well asynchronously because it supports middleware for ordering execution. It can be used with a test harness like Mocha, and allows you to define custom expectations, which is where your application-specific DSL-like test helpers come in.

Although I’m probably guilty of using Node for command-line scripts that could be done with a shell script (I write my share of shell script too though), Nixt seems like a great way to test them, particularly as people often forget to test such scripts.

Script Roundup: jWebAudio, Scrolling Component

29 Oct 2013 | By Alex Young | Comments | Tags jquery plugins browser audio scrolling
Note: You can send your scripts and articles in for review through our contact form.

jWebAudio

jWebAudio (GitHub: 01org / jWebAudio, License: Apache 2.0) by Wenli Zhang and published by Intel’s Open Source Technology Center is an audio library focused on games:

Web Audio seeks to process and synthesize audio in web applications. jWebAudio keeps the technical details of Web Audio under the hood and makes it easier to control your audio.

It has a jQuery API and also a framework-agnostic JavaScript API. Playing a set of sounds looks like this:

$('.sound').each(function() {
  var $this = $(this);
  var url = $this.data('sound');
  $(this).jWebAudio('addSoundSource', {
    url: url,
    preLoad: true,
    callback: function() {
      $this.jWebAudio('play');
    }
  });
});

jWebAudio also supports synthesis and effects:

Sound effects include telephonize and cathedral currently. And you may create new sound effects using the combination of LOWPASS, HIGHPASS, BANDPASS, LOWSHELF, HIGHSHELF, PEAKING, NOTCH, ALLPASS.

There’s a demo here: jWebAudio demo.

Wenli also writes about JavaScript. Here’s a post about the gruesome details of Number, parseFloat, and parseInt: Converting To Numbers In JavaScript.

Scrolling.js Component

Guille Paz sent in Scrolling.js Component (GitHub: pazguille / scrolling, License: MIT, component: pazguille/scrolling). It allows you to decouple scrolling from callbacks to avoid generating too many scroll events (the old debouncing issue):

var scrolling = require('scrolling');

scrolling(document.querySelector('#box'), callback);

The project is distributed as a component, and has a demo on the homepage.

HiDPI Canvas Polyfill, formatter.js

28 Oct 2013 | By Alex Young | Comments | Tags browser canvas polyfills

HiDPI Canvas Polyfill

Don’t you just hate it when a cool canvas animation suddenly goes blurry? HiDPI Canvas Polyfill by Jonathan Johnson scales the canvas so the PPI is right, avoiding unsightly blurring. Jonathan notes that Safari is currently the only browser that does this properly.

I don’t know if the author was inspired by How do I fix blurry text in my HTML5 canvas? on Stack Overflow, but the solution looks similar to MyNameIsKo’s answer.

Jonathan has gone further by including tests, and he’s included a Grunt build script as well.

Jonathan also sent in BubbleChart (GitHub: jondavidjohn / bubblechart, License: Apache 2.0, npm: bubblechart) which is an interactive visualisation for two dimensional data.

formatter.js

formatter.js (GitHub: firstopinion / formatter.js, License: MIT) by Jarid Margolin helps you to define custom form fields. The examples given are a credit card form and a telephone number entry. The script can insert text as the user types, so the credit card form inserts hypens, and the telephone number uses the US-style format with brackets and a single hyphen.

The API looks like this, but there’s a jQuery wrapper as well:

new Formatter(document.getElementById('credit-input'), {
  pattern: '9999-9999-9999-9999'
});

The project includes tests that can be run with npm, and there are examples here: formatter.js demos.

How Apple Could Fix iWork: JavaScript

25 Oct 2013 | By Alex Young | Comments | Tags apple essays embedding

Apple and JavaScript

Apple recently updated iWork and removed a whole bunch of features. The company where I work makes a popular Mac application, and the removal of AppleScript from iWork caused a backlash from customers who rely on this feature for integration between our program, and Pages and Numbers.

AppleScript wasn’t ideal, but it did the job. Now we’re left in the dark, and as Apple are being typically opaque about adding it back we’re not sure what to do. The way it worked before was with scripting bridge, and although SBApplication is still around, Pages and Numbers no longer have it.

Scripting Bridge

Scripting Bridge provides an Objective-C API for sending and receiving Apple events, so you can take control of applications in Objective-C. It can be used to bridge another scripting language. JSTalk is one such example:

JSTalk is a scripting language for Mac OS X built on top of JavaScript, with a bridge to Apple’s Cocoa libraries. You can use it to communicate with other applications just like AppleScript does

JSTalk is built on top of Apple’s JavaScriptCore, the same JavaScript engine that powers Safari. So when you write in JSTalk, you are really writing JavaScript.

There’s also JavaScript Bindings for C and Objective-C. This uses SpiderMonkey to interpret your JavaScript, and bindings for Objective-C. You can even subclass native objects with JavaScript.

From my perspective as a JavaScript and Node specialist who does some Objective-C on the side, these projects have their appeal. It would be better if JavaScript was the default, though.

JavaScriptCore

Apple makes JavaScriptCore available to Mac and iOS developers with an Objective-C API. This quote is from Owen Mathews at Big Nerd Ranch:

JavaScriptCore gives developers deep access to the full JavaScript runtime from Objective-C. You can syntax-check and execute scripts, access variables, receive callbacks, and share Objective-C objects, making possible a wide range of interactions. (One caveat: on iOS, there is currently no way to access the UIWebView’s runtime, so unfortunately it’s not possible to tie into web apps at this level.)

Post Scripting Bridge

Now Apple have removed Scripting Bridge from iWork, it made me want to rethink application scripting. What would it be like to run JavaScript in an application? It would be much like browser DOM scripting, except the document would be a Keynote or Pages file.

When we wrote AppleScript in the past we wanted to modify a document without having to understand how to parse its format. There’s an element of driving the application, but also handling an abstracted version of the document rather than the underlying proprietary format. It’s probably easier to say “make words that match this regular expression bold” than it is to write a parser for Pages documents.

I recently wrote about the importance of embedded JavaScript, and I think Apple could gain a lot by adding JavaScript APIs to their applications. It would be more agnostic than AppleScript or VBScript, which can be used with Microsoft Office. If I could somehow insert myself into the nexus of all Apple development and advocate JavaScript I would, but I don’t have that kind of power, so perhaps someone reading this will!

Introduction to ChocolateChip-UI

24 Oct 2013 | By Robert Biggs | Comments | Tags browser tutorials ui
This post is a tutorial about ChoculateChip-UI from Sourcebits Inc.

We’re going to look at how to throw together a simple navigable app with the ChocolateChip-UI framework. This will require familiarity with HTML. You don’t need to be good with CSS or even know how to write JavaScript. ChocolateChip-UI provides functionality out of the box to provide functionality for Web apps.

ChocolateChip-UI uses a particular combination of simple tags to define the structures that make up a mobile app. These are: nav, article, section, ul, li, div, aside, span, p and h1 through h5.

To follow along, download the framework and grab the folder “chui”. This contains the files that comprise ChocolateChip-UI. We’re going to use three files: chocolatechip-3.0.4.min.js, chui-3.0.4.min.js and chui-ios-3.0.4.min.js.

To make a Web page behave like an app in the browser, we need to first provide some meta tags. Here is the basic skeleton with appropriate meta tags and links to the ChocolateChip-UI resources:

<!doctype html>
<html lang="en">
<head>
  <meta name="viewport" content="initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
  <meta name="apple-mobile-web-app-capable" content="yes">
  <meta name="msapplication-tap-highlight" content="no">
  <meta charset="UTF-8">
  <title>Document</title>
  <link rel="stylesheet" href="chui/chui.ios-3.0.4.min.css">
  <script src="chui/chocolatechip-3.0.4.min.js"></script>
  <script src="chui/chui-3.0.4.min.js"></script>
</head>
<body>
</body>
</html>

The app will reside inside of the body tag. When you look at the screen of a mobile devices, you notice that most apps use two main parts to present everything on the screen: a nav bar and everything below that. ChocolateChip-UI uses a combination of a nav tag and an article tag to create each screen of the app. Since we’re going to make a navigable app, we’ll need to put together a number of screen, each consisting of a nav and article.

The first screen will be the current view, and all others with be upcoming. ChocolateChip-UI designates this navigation status using two classes: “current” and “next”.

Every nav will have at least an h1, which is the title that appears in the navigation bar. Let’s start building this. We’ll need to create a navigation bar and an article. ChocolateChip-UI forces the article to fill the screen. Every article should have one child – a section tag. All the content will go in the section. It will automatically provide inertia scrolling when the user swipes.

Every article tag must have a unique id. This is used during navigation so that ChocolateChip-UI knows where to go and where to return to. If you find at some time that your app is not going to where you want or not returning properly, check that your articles have the ids they need and that you have all uses of them spelled identically.

Here is the basic app shell.

<!doctype html>
<html lang="en">
<head>
  <meta name="viewport" content="initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
  <meta name="apple-mobile-web-app-capable" content="yes">
  <meta name="msapplication-tap-highlight" content="no">
  <meta charset="UTF-8">
  <title>Document</title>
  <link rel="stylesheet" href="chui/chui.ios-3.0.4.min.css">
  <script src="chui/chocolatechip-3.0.4.min.js"></script>
  <script src="chui/chui-3.0.4.min.js"></script>
</head>
<body>
  <nav class="current">
    <h1>Fruits</h1>
  </nav>
  <article class="current" id="fruits">
    <section></section>
  </article>
</body>
</html>

You’ll notice that when it loads in the browser, the title appears in a nav bar, but there is nothing below that. ChocolateChip-UI uses unordered lists with the class list to display tabular data. We can give the list a title by putting an h2 right before the list. To display data in each list item, we use an h3 as the title and an h4 as the subtitle and a paragraph tag as the item detail. If we put the class nav on a list item, we get the right facing caret that iOS uses to indicate a navigable item.

Source code, part 3

To make this list able to navigate to other articles, we need to indicate where each list item should go. We do this using an HTML5 data attribute: data-goto. We give it the id of the article to which it will go. This will result in automatic navigation when the article that it points to exists.

This example includes the data- attributes:

Source code, part 4

Here’s what the navigation list should look like so far:

Navigation list

Now we need to add an article with the id for each fruit: apples, oranges, bananas, mangos and avocados. We’ll also want to provide a nav with an h1 with the title of each fruit. Because these navs and articles are not current in navigation, we need to explicitly give them the class next. This will put them out of view until the navigation occurs.

Source code, part 5

This creates a navigable app, except for one problem. After the user selects a fruit and the app navigates to that screen, there is no way to get back. We can provide a way back by adding a back button in each nav bar right before the title.

Source code, part 6

Detail page of Navigation list

To complete our simple app we just need to add a list to each of the fruit articles. We can use the same pattern we used on the main article.

Source code, part 7

To support Android or Windows Phone 8, you just need to switch out the reference in the CSS link: chui/chui.ios-3.0.4.min.css. Change ios for android or win.

Of course, this is just the most basic setup for an app. In real life you would want to get data dynamically through Ajax requests and output it to your app using templates. Sounds like another article.

Node Roundup: HTTP DoS Fixed, Flocon, Trans

23 Oct 2013 | By Alex Young | Comments | Tags node modules uuid json

Node DoS Fixes

This week two maintenance releases of Node were rolled out to fix a DoS vulnerability in the HTTP module.

Flocon

I seem to find myself generating a lot of unique IDs lately. Flocon (GitHub: Yosee / flocon, License: MIT, npm: flocon) from Yosee is a 64-bit unique ID generator, written in C++. It’s currently considered experimental by the authors but comes with unit tests.

Flocon returns IDs synchronously as strings with flocon.snow(), and the algorithm used is based on Twitter’s Snowflake service.

There are also some benchmarks of the flocon module so you can compare it to other projects.

Trans

Gabriel Adomnicai sent in “trans” (GitHub: gabesoft / trans, License: MIT, npm: trans), a module for transforming objects. Given some JSON, trans can group and modify objects by using a chainable API:

var trans = require('trans');
var data = [
  { a: { b: 'fbc' }, c: 1 }
, { a: { b: 'foo' }, c: 3 }
, { a: { b: 'fde' }, c: 2 }
, { a: { b: 'def' }, c: 3 }
, { a: { b: 'ghk' }, c: 4 }
];

trans(data)
  .group('a.b', 'c', ['charAt', 0], 'toUpperCase')
  .sortf('value')
  .sort('key')
  .value();

/*
[ { key: 'D', value: [ 3 ] },
  { key: 'F', value: [ 1, 2, 3 ] },
  { key: 'G', value: [ 4 ] } ]
*/

Each of the methods is documented in the readme, and Gabriel has included tests as well.

Script Roundup: Handpicked jQuery, Firepoker, Enyo 2.3

22 Oct 2013 | By Alex Young | Comments | Tags jquery plugins angular apps cdn
Note: You can send your scripts and articles in for review through our contact form.

Handpicked jQuery Plugins

The Handpicked jQuery Plugins site by David Higgins has been updated to the third version. He’s also released code.jque.re, which has links to resources served from MaxCDN. All of the plugins have MaxCDN links as well.

The site gets increasingly lean and mean over time. Outdated plugins get removed, and new ones take their place. The colors change, the CDN gets better, and more new fans download the repo each day to experiment with the plugins.

Firepoker

Firepoker

Firepoker (GitHub: Wizehive / Firepoker, License: MIT) by Everton Yoshitani is a “Scrum poker” game used for estimating user stories.

In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.

It’s built with AngularJS and Firebase. It comes with a Grunt build script, so you can run a local development server to check it out easily.

The Firebase integration seems lightweight and easy to follow – if you look at main.js you can see how AngularFire is used.

If you’re looking for an AngularJS/Firebase example app, then take a look at the source for Firepoker.

Let’s Make a Framework Chronological List

Uri sent in a chronological list of the Let’s Make a Framework posts, because DailyJS is really just a static site so sometimes it’s a bit hard to make sense of long running article series:

http://jsbin.com/AduboCI/2

Enyo 2.3.0

Ben Combee sent in a post about Enyo 2.3.0-pre.10:

If you’ve been following Enyo, you’ve probably noticed that it has been a while since our last public release. From the outside it may appear that the pace of Enyo development has slowed, but appearances can be deceiving — it has actually been an exceptionally busy, productive year for the Enyo team.

So what have we been up to? For starters, we’ve been doing some exciting UI work to support an upcoming LG product release. We can’t share this work with you just yet, but it will ultimately be open-sourced alongside our other Enyo libraries. We’ve also been pushing forward on the Ares IDE, with our HP team members playing a leading role.

Enyo 2.3 should improve data bindings, data layers, and adds the enyo.Application kind which is an entry point that can be used to organise data and functionality across the entire application.

The blog post explains how to get the prerelease and start using it.