BackstopJS release 0.7.0: Test your CSS on a CLI!

Announcing BackstopJS release 0.7.0 with a speedy new command line reporting option. Now you can test your CSS layouts even faster with an all-text inline report in the terminal window of your choice.

The new reporting option is configurable: you can select the detailed browser-based GUI report, the simple text-based CLI report, or both depending on your needs.


Also in this release: an enhancement for smarter handling of missing or hidden DOM selectors – a nice addition for really complex responsive web-apps.

Many thanks to Klaus Bayrhammer for his effort in this release — also thanks to Benedikt Rötsch for his help with the roadmap.

Thinking of contributing to developer happiness? Check the issues section for a list of feature ideas. Help build one or suggest your own!

BackstopJS 0.6.2: The HTML5 update – with added support for flexbox and web fonts!

Responsive CSS regression testing just got slimed!

Backstop now has built-in support for the CasperJS/SlimerJS rendering stack. This means your tests will render in Gecko instead of the default PhantomJS/Webkit library (which still has HTML5 bugs).

If want more accurate tests for your flexbox or web font CSS this update is for you! (If this isn’t for you, please excuse the interruption, you may return to watching your cat video.)

Bower & NPM Install and upgrade info here!

Now go break stuff!

BackstopJS 0.6.0: Now plays nice with source control!

Announcing BackstopJS 0.6.0 Beta available now on GitHub!

Some great news for BackstopJS users – Screenshot paths are now configurable!

This update enables two highly requested use-cases…

1) BackstopJS now plays nice with source control
Pointing your reference file paths to a location that GIT or SVN can pick it up means that reference data generated across branches will always stay in sync.

2) Easy upgrading
Now, blowing away your node_modules or bower_components directories won’t trash your test data.

This is a beta release so, as always, please direct questions, comments or issues here.

Thanks to all the contributors for their support!

Be groovy.

TremulaJS 1.1.0 — the crossAxis enhancement

Two new features


Announcing a TremulaJS version update, 1.1.0. This version adds two important features, first, Mocha.js tests and second, by popular request, native crossAxis event passing.

About crossAxis event passing

The TremulaJS scroll axis is configurable as horizontal or vertical. Internally, this is referred to as the scrollAxis while the orthogonal axis is termed the crossAxis.

To the browser, any TremulaJS DOM object looks like a plain old static page element. (These are manipulated around at 60 frames per second for our UX benefit). When a native touchmove or scrollwheel micro-event happens, the default browser behaivior in many cases is to move the viewport contents around. This also includes our parent TremulaJS instance which in our case, is not (always) what we want.

In prior versions, all micro-events are shunted by TremulaJS — thus preventing any counteractive native behaivior. TremulaJS is mainly concerned with a macro-event stream emitted by the awesome Hammer.js library. This delegation strategy works great if you have a Tremula view which occupies the entire page. But what if you have content stacked before and/or after one or more TremulaJS modules? In the past you’d be stuck with no way to scroll to other page level content on the crossAxis.

In 1.1.0 this is resolved. TremulaJS now assigns each micro-event a directionality ratio. Events that move (more or less) perpendicular to the scrollAxis are trapped while events moving along the crossAxis are passed — and passed events are free to bubble up the DOM in a native kind of way.

So, to the developers requesting this feature, please give it a try — espically for iOS applications. I hope the response feels natural to you, even in cases where the user is not quite scrolling perfectly side-to-side or up-and-down.

Download, Fork, Contribute on GitHub

Send some feedback! @garris

SleepyHollow enables events between Node and PhantomJS

John Weis recently posted a pretty fancy jig for setting up events between node and PhantomJS. I wanted to share it because I think it deserves some props…

In a nutshell, sleepyhollow spawns a Phantom instance in your node app and implements a bare-bones event buss over stdin/stdout/stdErr channels.

Installation: I already have a global installation of PhantomJS

  $ phantomjs --version

and sleepyhollow is installed in two parts…

$ npm install sleepyhollow-node
$ npm install sleepyhollow-phantom

I prototyped Sleepyhollow as a route inside an express project. Here is the script for that…

'use strict';

var request = require('request');
var stampy = require('stampy');//<-- bare bones time stamping object

module.exports = function (router) {

	//===========SLEEPYHOLLOW EXAMPLE=============
	router.get('/', function (req, res) {

		var ts = new stampy();//get perf object 
		ts.start('reqIn');//log start time

		var sleepyhollow = require('sleepyhollow-node');
		//this module spawns a PhantomJS process and sets up events
		//also names the script Phantom will run it's local scope
		//arg1: is phantoms config argument
		//arg2: named script that runs in the Phantom scope
		//arg3: a node config object, used in the node child-process spawn() method
		var drjekyll = sleepyhollow(

		//by default sleepyhollow publishes any Phantom console.log messages 
		//as an error event.  This sets up a node echo of that.
		drjekyll.on("error", function(data) {
			console.log("STDOUT --> "+data);

		//this event is called when PhantomJS is loaded and asked to call a page
		drjekyll.on("loading", function(data) {

		//called after a successful load
		drjekyll.on("loaded", function(phantomOut) {
			console.log("PAGE WAS LOADED vvv n" + phantomOut);

		//this publishes a load to Phantom
		drjekyll.emit("load", "http://localhost:8000");



So, the above runs when a call comes in for data. On the PhantomJS side we have this… ./phantom/phantom_job.js which runs in the Phantom context. Since you can’t share objects directly, all communication is done with events.

// NOTE:  this is PhantomJS code, not Node.js!

console.log('INSIDE PHANTOM!')

var timeout = 10000;//ms


//relative to the calling script
var sleepyhollow = require('../node_modules/sleepyhollow-phantom/index.js');

var mrhyde = sleepyhollow();

mrhyde.on('load', function(url) {
	mrhyde.emit("loading");//just before loading a page
	var page = require('webpage').create();, function(status) {
			//page is loaded
			console.log("PhantomJS: SUCCESS");

//this timeout will cleanup any hanging PhantomJS instances in case of an unhandeled situation
var doTimeout = setTimeout(function(){
	console.log("PhantomJS: TIMEDOUT");
}, timeout);

Here’s the result…



<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><title>WTF krak'd</title></head><body><div id="wrapper"><h1>Hello, Mr. Garris @ Sat Jul 12 2014 11:40:52 GMT-0700 (PDT)!</h1></div><script data-main="/js/app" src="/components/requirejs/require.js"></script></body></html>

[ { id: 'reqIn', run: 0, diff: 0, ts: 1405190450689 },
  { id: 'phantom_page_loading', run: 2040, diff: 2040, ts: 1405190452729 },
  { id: 'resOut', run: 2110, diff: 70, ts: 1405190452799 } ]


Screen Shot 2014-07-12 at 11.50.00 AM

There is a lot of room for iteration here — for starters, you may have noticed the 2 second bootstrap time for Phantom. In general though, there is a lot of activity in this server-side DOM rendering space. I think SleepyHollow is a novel approach worth looking at for those of us working on the Node-PhantomJS problem.

Introducing TremulaJS

Content Streams + Momentum Engine + Bézier Paths + Multi-Device

TremulaJS is a client-side javascript UI component enabling responsive, Bézier-based content-stream interactions with kinetic scrolling & physics effects for trackpad, pointer and touch UIs.

Put another way, TremulaJS can be thought of as an extremely bad-ass image slider.

While there are some monumental physics-based JS animation frameworks out there — most notably,, gsap and velocity.js — TremulaJS was built with a very specific end in mind: to enable the kind of long-running, low-friction user interactions one might enjoy when navigating large sets of visual data.

See TremulaJS in the wild: currently in production on

TremulaJS is compatible with all recent versions of iOS Safari, Chrome, OS X Safari, FF, IE.

TremulaJS was developed by Garris Shipon at Labs.

Licensed under GPLv3

More info…

follow @garris