If using ES6 `extends`, call `super()` before accessing `this`

I am working on rewriting some code that used an ES5 “Class” helper, to use actual ES6 classes.

I soon stumbled upon a weird error in which apparently valid code would be throwing an |this| used uninitialized in A class constructor error:

class A extends B {
  constructor() {
    this.someVariable = 'some value'; // fails

I was absolutely baffled as to why this was happening… until I found the answer in a stackoverflow post: I had to call super() before accessing this.

With that, the following works perfectly:

class A extends B {
  constructor() {
    super(); // ☜☜☜ ❗️❗️❗️
    this.someVariable = 'some value'; // works!

Edit: filed a bug in Firefox to at least get a better error message!

Publishing to gh-pages from Travis CI

I figured out how to ‘publish to gh-pages’ (i.e. building and publishing a website into GitHub pages) using Travis CI. Instead of messing with the serious repository, I made a simple repository which builds and publishes its web page daily, using Travis CI’s cron feature. You can clone/fork it and read the instructions on the README or you can read on here for why I did it this way.

Continue reading “Publishing to gh-pages from Travis CI”

Don’t force users to install node modules globally when you can avoid that

How often have you seen instructions for installing a project that are something like this?

git clone https://wherever/the/project/is
cd cloned_folder
npm install -g gulp # <-- 😱

(or, instead of gulp, any other utility that the project requires for development)

This is not a good idea. You’re installing the same version of a utility globally, and perhaps the project has not been tested with that version. Things might break or even worse, work not-so-well in a strange, undebuggable way!

Don’t do it.

A better way is to use npm scripts, which belong to the project, and specify development dependencies in package.json, so when you run npm install, it also installs devDependencies locally to the projects’ node_modules folder. This keeps everything under control and does not pollute other people’s computers global space.

So, for example, if a project was asking users to run npm install -g gulp, they should do this instead:

  1. Install gulp locally as a development dependency, saving it to package.json:
    npm install --save-dev gulp
  2. Add a new entry to the scripts array in package.json:
    "build": "gulp"
  3. Ask users to run
    npm install

    the first time. And

    npm run build

    each time they need to build the project

The reason this works is because when npm runs a script, it modifies the current PATH variable to add node_modules/.bin, which contains any binaries that you installed as part of your modules. So your computer will search for binaries starting in the .bin folder, before searching in any other default location for binaries in your computer (e.g. /usr/bin)

You can find more documentation about this behaviour in the run-script page of the npm manual. I really encourage you to read it as it has lots of good stuff and Things You Wished Had Known Before 🙂

And in case it makes things clearer, this is how a hypothetical package.json would look before:

  devDependencies: {}

And after:

  devDependencies: {
    "gulp": "12.34.56"
  scripts: {
    "build": "gulp"

With this, the devDependency is clearly stated on the package.json file, the project developer will be developing with that version, and will not get surprises! (and the users of the module won’t either).

Another advantage of this approach is that you are not tying the project to a specific utility.

If you decide to use grunt instead of gulp later on, you just need to do whatever changes you need (Gruntfile instead of Gulpfile, edit package.json etc), and yet users of the project will still start the build process with npm run build.

It’s invisible to them (except perhaps running npm install again)!

You’re hiding internals that they do not necessarily need to know about, so it’s a good abstraction. Seriously—you won’t even need to update your getting started guide! Good stuff.

Hope that helps!

If you want to learn even more cool npm scripts tricks, I recommend Kate’s talk and accompanying post. Actually, I just realised she explained the same thing I did, so here’s her take, haha!

Using the currentColor CSS keyword

I learnt about this CSS keyword via Glen Maddern’s talk at Cold Front in Copenhagen, back in September, and I was super astonished I hadn’t heard about it before! I guess I do too much JavaScript 😏

Anyway, it represents the current inherited color, so you can use it to create borders and backgrounds and things like that, matching the color of the element, but without actually writing it again! This can help in avoiding repetition and keeping the CSS more manageable, or in Glen’s use case, in writing more responsive components.

Given this HTML code:

<p id="thing">hello <span>world</span></p>

and this CSS code:

#thing {
  color: blue;
  font-size: 3rem;

#thing span {
  padding: 3px;
  background-color: white;
  box-shadow: 0px 0px 20px currentColor;

the color for the box-shadow in the #thing span will be blue, because it uses currentColor, which at that point has inherited blue from #thing. If we change the color of #thing to something else, we do not need to update the code for #thing span. Beautiful!

You could even use CSS variables to set a global colour variable that is used in the document, and currentColor will inherit values set with var. For example:

body {
  --thecolor: red;

#thing {
  color: var(--thecolor);
  font-size: 3rem;

#thing span {
  padding: 3px;
  background-color: white;
  box-shadow: 0px 0px 20px currentColor;

… renders the text red, and the box shadow is red as well.


Unfortunately it seems like calc() doesn’t accept color units yet, which means we cannot do maths on the color values. Otherwise, we could do things such as what CSS pre-processors do, generating new colours using hsla functions, etc.

One demo: two new bugs!

I thought that since I was going to the Web Audio Hack Day here in Singapore, it would be great to have a more Web Audio focused Media Recorder demo, so I built a little demo that essentially asks for audio permission, then records a short clip of audio, decodes it as an audio buffer and uses it to loop a BufferSourceNode in Web Audio.

You wouldn’t believe what happened next… or would you?

Two Things That Happened When Sole Ran This Demo

1. Chrome Canary Just Totally Gave Up

Aw, snap!

I filed a bug, since there wasn’t really much I could do…

2. Nightly Sometimes Insisted In Returning Some Mysterious 596 Samples Length Which Was Totally Not What I Expected, And Did So Without Following Any Meaningful Reproducible Pattern

596 samples for some reason

I tried to dump the contents of the returned blob once read as a buffer, using String.fromCharCode–perhaps looking at binary data while having my breakfast coffee would enlighten me?

I eat hex dumps for breakfast

As it turns out, no. So I filed another bug.

Try this yourself maybe?


The demo is here: instalooper (sources) … just in case you want to play with the code–maybe it will be fixed next month, who knows!!? Or maybe it is just a bug in my machine and it works in everyone else’s!

Disclaimer: I have not tested this anywhere else than Nightly and Canary. So I’ve no idea of how it works (or not) in mobile.

I have a more complicated version that not only loops the sample but also randomly changes its playback frequency. Sometimes the generated sounds are strangely fascinating. It still needs a bit of interface work, but hey… watch out, Steve Reich! 😎

And now… time to prepare to go to the airport and fly to Melbourne for JSConf.AU! More jetlag, YAY!