The JavaScript blog.


libraries graphics webgl yeoman architecture

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

Posted on .

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.


node modules yeoman rants

Static Site Generators for Yeoman

Posted on .

I often find myself being the only guy in the team who can make (or wants to make) a good ol' fashioned website. No dynamic stuff, just a simple static marketing site to sell a product. "No problem," I say confidently, dreaming up designs I can implement rapidly with Vim, Bootstrap, and Glyphish.

The problem I've ran into consistently over the last year or so is Yeoman doesn't do what I think it does. This is what it does in my head:

  • Unites Grunt, Bower
  • Runs a little web server so I can see my site without having to run a web server
  • Doesn't install any Ruby nonsense
  • Uses idiomatic Node

Here's what it actually does when I use generator-webapp:

  • Installs loads of weird stuff I don't need to do with testing and image optimisation
  • Make a Gruntfile.js that isn't formatted using the coding style of most community Node projects
  • Seems to need Ruby due to Sass when I make it install Bootstrap

Then I realise generator-webapp might not be for me, so I try starting a project from scratch. Then I get into an incredible mess trying to automate the minimization of each Bower component's JavaScript, CSS, and copying assets to a suitable location with Grunt.

I Miss Makefiles

Here's how you copy a file in the shell:

* cp tmp/*/*.min.js site/js/

Here's how you do it with Grunt:

copy: {  
  dist: {
    files: [{
      expand: true,
      cwd: 'tmp/',
      src: ['*.min.js'],
      dest: 'site/js/',
      filter: 'isFile'

Not only is it a whole bunch of lines to do something that should be simple, it also has weirdly named properties. I see isFile and start an internal monologue about everything being a file because it's Unix.

I could write a Makefile in two lines that does this.

Yeoman Static Site Generators

This time I decided to persevere: I tried a bunch of static site generators for Yeoman.

  • Armadillo: Installed lots of stuff I didn't need, and needed Ruby
  • Go Static: Was more for blogs than simple sites, and seemed to make files indented with tabs

There were more but I only have bad things to say about them. What I ended up with was this:

  • grunt-contrib-connect for running a web server. It was more complex than it needed to be because it defaults to exiting automatically rather than running a server, you need to specify a keepalive setting
  • grunt-contrib-concat for concatenating Bootstrap's CSS, JavaScript, and any other dependencies in bower_components
  • grunt-contrib-copy for copying the files from bower_components to my website's asset directories

The Shit Sandwich

I think the reason I have difficulty with Yeoman and Grunt is I see client-side development as "open source stuff" and "my stuff". I want open source stuff poured out into buckets that I never look at, in a way that's easy for other people to repeat should they want to install the dependencies fresh (I keep the files in the repository), or experiment with upgraded versions of each module.

Conversely, my stuff should be elegantly encapsulated with a module loader like RequireJS, kept separate and decoupled.

Instead of a neatly organized bento box with very clear sections I end up with a shit sandwich.


libraries node browser editors debugging yeoman

Yeoman Configstore, Debug.js, Sublime JavaScript Refactoring

Posted on .


Sindre Sorhus sent in configstore (GitHub: yeoman / configstore, License: BSD, npm: configstore), a small module for storing configuration variables without worrying about where and how. The underlying data file is YAML, and stored in $XDG_CONFIG_HOME.

Configstore instances are used with a simple API for getting, setting, and deleting values:

var Configstore = require('configstore');  
var packageName = require('./package').name;

var conf = new Configstore(packageName, { foo: 'bar' });

conf.set('awesome', true);  
console.log(conf.get('awesome'));  // true  
console.log(conf.get('foo'));      // bar

console.log(conf.get('awesome'));  // undefined  

The Yeoman repository on GitHub has many more interesting server-side and client-side modules -- currently most projects are related to client-side workflow, but given the discussions on Yeoman's Google+ account I expect there will be an increasing number of server-side modules too.


Jerome Etienne has appeared on DailyJS a few times with his WebGL libraries and tutorials. He recently released debug.js (GitHub: jeromeetienne / debug.js, License: MIT), which is a set of tools for browser and Node JavaScript debugging.

The tutorial focuses on global leak detection, which is able to display a trace that shows where the leak originated. Another major feature is strong type checking for properties and function arguments.

Methods can also be marked as deprecated, allowing debug.js to generate notifications when such methods are accessed.

More details can be found on the debug.js project page.

Sublime Text Refactoring Plugin

Stephan Ahlf sent in his Sublime Text Refactoring Plugin (GitHub: s-a / sublime-text-refactor, License: MIT/GPL). The main features are method extraction, variable and function definition navigation, and renaming based on scope.

The plugin uses Node, and has some unit tests written in Mocha. The author is planning to add more features (the readme has a to-do list).