The Alternative To Spotify Is Piracy

When it comes to music streaming, Spotify is the leader with over 60 million listeners, 15 million of which are paid listeners.

Over the last year or so, some artists have been VERY vocal about the small amount of revenue that Spotify actually pays out per X amount of listens. It got to the point where Taylor Swift pulled her music down, refusing to put her new album 1989 up for streaming because she felt that Spotify was undervaluing music and underpaying artists, before striking up an undoubtedly profitable deal for herself with Apple for their fledgling music offering.

Even Jay-Z and a bunch of other successful music artists got behind lossless streaming service Tidal claiming to pay artists more than Spotify, irrespective of the fact Jay-Z an already wildly rich and successful artist from a time when people actually still bought CD’s is one of the owners. And numerous other well-established artists like Jack White were also involved.

All of this trash talk about Spotify, you would think that Spotify are pocketing profits for themselves and paying labels/artists nothing, right? Spotify is not a profitable company and they continue to operate in the red every year since their inception (only being kept afloat by investment capital).

Spotify have taken quite a lot of investment to stay afloat and they have yet to make a cent of profit. They pay a lot of money to labels in royalties, around 70%, the rest is divided up between various operating expenditures.

Let that sink in for a moment. Of all of the money that Spotify earns from advertisements and paid subscriptions, around 70% of that goes to labels and publishers, which in turn should be going to artists (we all know how music industry economics work though). The other 30% goes towards the expensive operating costs (hardware, bandwidth, storage and salaries).

The cap table that leaked a few years ago (showing who owns what of Spotify) actually showed that a few of the major record labels own various portions of Spotify. The very thing that is supposedly not paying artists their worth is partially owned by the labels that represent these artists.

If Spotify is so bad, what is the alternative? Is it making people go out and buy music again? Is it jailing your fans because they can’t afford a $20 CD or $100 ticket to come see you in concert? Implementing laws that make it illegal to not buy at least 2 CD’s per month?

The streaming subscription model works, radio in many ways is the original Spotify (except free-to-air radio costs consumers nothing) and way for artists to get promotion. Even so, unless you’re signed to a major or a success story like Macklemore, your only option is to grind and struggle and hope that one day, you too can be repeated on the radio alongside Taylor Swift 30 times a day until people grow tired of your music.

The alternative to Spotify is piracy. Is making a little bit of money better than making no money whatsoever from people torrenting your music? I used to download a lot of music. Everyone my age does, I grew up in the age of; cheap CD singles, Napster, Kazaa, WinMX, Rapidshare and Mediafire.

Since Spotify came to Australia, I rarely ever download music (unless it’s a leak). I actually have found a heap of artists via Spotify I probably wouldn’t have found if I just torrented music. I could not honestly tell you the last album I downloaded that I didn’t just listen to on my Spotify Premium account.

If Spotify has stopped me and my close friends from torrenting, I would be inclined to agree it has for others as well. Sure, those artists are probably making a few cents a month from me, but they’re making nothing if I torrent their music.

So while spoiled little rich girls like Taylor Swift moan they’re not making billions off of Spotify and Jay-Z pushes a music service he has a vested interest in (which is failing), we need to realise that Spotify represents a golden opportunity for artists to reach new audiences and make a little money (without spending a dime of their own money).

As history has shown, there has and continues to be resistance when it comes to innovation in the music industry and shaking up old business models. Dear music industry, innovate or die. When you’ve killed all of the innovation, you will have no scapegoat to blame for declining music sales.


Aurelia and Drag/Drop Using Sortable

Today we are going to be discussing how to use the Sortable Javascript library by RubaXa in our Aurelia applications.

Sortable is a highly configurable, no frills drag and drop library that has zero dependencies. So if you’re not using jQuery or just not a fan of libraries with dependencies, then this is the library for you. I also highly recommend Dragula but this article will be focusing on Sortable.

Getting Started

This article is going to assume you have an Aurelia application already up and running and using JSPM as your package manager. If you do not have Aurelia installed, the recommended and easiest way to get an Aurelia application up and running is to download the Skeleton Navigation application from Github here.

Open up a command line window (Terminal if you’re on a Mac or Command Prompt/PowerShell if you’re on Windows) and navigate to the root directory of your application and type: jspm install sortable=github:RubaXa/Sortable

What this will do is install the Sortable plugin from Github and namespace it under ‘sortable’ – if you take a look in your package.json file you will see the package there and in config.js you will see it has been added there as well.

Linked right at the bottom of this article is the source code and a working demo for everything detailed in this post. So if you’re not the follow along type, go check out the source code and have a play.

That was easy – Now that we have the Sortable plugin installed, we can then proceed to integrate it into our application. In this article we are going to be building a fictional application that inserts random images of cats and dogs into your application.

The Workflow

As always with any application, mapping out the workflow before we build anything is a good idea. An engineer doesn’t build a bridge without the plans for building it and you don’t build a house without a blueprint.

  • User has the choice of multiple elements.
  • Those elements cannot be sorted, but they can be dragged into a special area on the page.
  • When the user drags an item and drops it, we want to cancel the event and handle things ourself.
  • Depending on the type of item dropped into the special area, we will fetch a random image of a cat or dog.
  • Our Sortable needs to play nicely with the Aurelia repeat.for atrribute, including the ability to resort the array items
  • Dropped images will be sortable
  • Dropped items can be removed from the page

Let’s Build

Now that we have our blueprint, lets build this thing.

Creating a View and ViewModel
Using default Aurelia conventions, we are going to be using a named View and ViewModel pair. By default a ViewModel is assumed to have a View aka template of the same name, only with a .html file extension instead.

Lets use the name DragDrop for our application View and ViewFiles. Inside of the “src” directory create two new files: dragdrop.js and dragdrop.html.

Now that we have our two files where all of the action takes place, lets populate them.

The HTML template is going to be quite simple, so lets populate that first. Here we specify an area where elements are dragged from and dragged to. Aptly named, “drag-target” and “drag-source” – items from the “source” area are dragged into the “target” area.

<div id="wrapper">
    <div id="drag-target">
        <div class="dragged-element" repeat.for="item of droppedItems">
            <div class="img-wrap">
                <img src="${item.src}">
                ${item.type === 'cat' ? 'Cat' : 'Dog'}

    <div id="drag-source">
        < a href="javascript:void(0);" data-type="cat">Random Cat< /a>
        < a href="javascript:void(0);" data-type="dog">Random Dog< /a>

This is where we handle our drag and drop logic for our application. There is going to be quite a bit of code, so if you just end up copying and pasting this, I understand.

import {inject} from 'aurelia-framework';
import {EventAggregator} from 'aurelia-event-aggregator';

import sortable from 'sortable';

export class DragDrop {

    droppedItems = [];

    constructor(eventAggregator) {
        this.eventAggregator = eventAggregator;

     * Attached
     * Called when view is attached
    attached() {
        this.setupSource(document.getElementById('drag-source'), false, {
            name: 'catsAndDogs',
            pull: 'clone',
            put: false

        this.setupTarget(document.getElementById('drag-target'), '.dragged-element', true, 'catsAndDogs');


     * Event Listeners
     * This is where event listeners for drag/drop events are registered
    eventListeners() {

        // Event triggered when item is added
        this.eventAggregator.subscribe('dragTarget.onAdd', evt => {
            let src = evt.from;
            let dest =;
            let item = evt.item;

            // When actual dragged item is dropped, we remove it and handle
            // updating the array for our repeater ourselves

            // Dragging widget into new page
            if (item.dataset.type) {
                let animalType = item.dataset.type;

                let itemInstance = {};

                if (animalType === 'cat') {
                    itemInstance.type = 'cat';
                    itemInstance.src  = '';
                } else {
                    itemInstance.type = 'dog';
                    itemInstance.src  = '';

                this.droppedItems.splice(evt.newIndex - 1, 0, itemInstance);

        // Events for when sorting takes place, we need to update the array to let
        // Aurelia know that changes have taken place and our repeater is up-to-date
        this.eventAggregator.subscribe('dragTarget.onUpdate', evt => {
            // The item being dragged
            let el = evt.item;
            // Old index position of item
            let oldIndex = evt.oldIndex;

            // New index position of item
            let newIndex = evt.newIndex;

            // If item isn't being dropped into its original place
            if (newIndex != oldIndex) {
                swapArrayElements(this.droppedItems, newIndex, oldIndex);


     * Setup Source
     * Handles setting the drag source
     * @param el (string)
     * @param sort (boolean)
     * @param group (object)
    setupSource(el, sort = false, group = {}) {
        new sortable(el, {
            sort: sort,
            group: group,
            onStart: evt => {
                this.eventAggregator.publish('dragSource.onStart', evt);
            onEnd: evt => {
                this.eventAggregator.publish('dragSource.onEnd', evt);

     * Setup Target
     * Handles setting the drag target destination for dragged items
     * @param el (string)
     * @param draggable (string)
     * @param sort (boolean)
     * @param group (object)
    setupTarget(el, draggable = '.element', sort = true, group = 'somegroup') {
        new sortable(el, {
            draggable: draggable,
            sort: sort,
            group: group,
            onAdd: evt => {
                this.eventAggregator.publish('dragTarget.onAdd', evt);
            onUpdate: evt => {
                this.eventAggregator.publish('dragTarget.onUpdate', evt);

function swapArrayElements(theArray, a, b) {
    var temp = theArray[a];
    theArray[a] = theArray[b];
    theArray[b] = temp;

See it in action

A working demo can be seen here. The source code can be seen here on Github.


As you can see integrating third party libraries within Aurelia is easy. The bulk majority of our code is actually getting the sorting functionality to place nicely with our Aurelia repeater.

We cancel the original drag event, parse the dragged item for details and then insert our new item manually. We also handle sorting of the items by swapping the positions of the dragged items within the droppedItems class property array.


Perfectly Smoked Steak On A Charcoal BBQ Using Indirect Heat

Cooking steak isn’t difficult and certainly isn’t rocket science. But for some reason, many people screw up cooking the perfect steak. As with anything; patience, attention and the right tools for the job are crucial. You wouldn’t trust a carpenter without a hammer to do a good job.

If you’re not wanting to add a smoke flavour to your steaks, you can ignore the parts that relate to smoking. The difference between barbecuing and cooking on say a frying pan in your kitchen is that smokiness you get from the coal (and from the added wood chips).

Things you’ll need

For The BBQ

  • A coal barbecue (with a lid for smoking)
  • A meat thermometer (for testing temperature of the meat)
  • Natural lumpwood charcoal
  • A charcoal chimney starter (for lighting the charcoal)
  • Newspaper
  • Wood chips (I like Hickory, but Oak can be quite nice and Mesquite if you want a stronger smoke flavour)
  • A stainless steel smoker box (or if you don’t have one, aluminium foil)
  • A bowl of water (to soak your wood chips)

For The Steak

  • Nice non-budget steak (cheaper cuts require longer cooking time and are harder for the inexperienced cook). Avoid supermarkets like Coles or Woolworths, the portions in the trays are generally non uniform and steak quality can be highly varied. Head to your local butcher and get some thick cut steaks (roughly the same size so they cook at the same time).
  • A dry spice rub (this will help reduce the boundary layer and help it smoke better).
  • Olive oil (for rubbing down the steaks)
  • Aluminium foil (for wrapping the steaks afterward while they rest)


  1. Measure out a handful or so of your wood chips. If they’re quite small or you have the pellets, maybe a little more than a handful. Place them into a bowl of water and let them soak for about 30 minutes. Wood doesn’t really absorb water that much, but you’ll moisten the exterior a little to prevent them from burning too quickly. The jury is still out on whether soaking your chips does anything, I do it because it does no harm either way.

  2. Now take your steaks our of the fridge and let them come closer to room temperature (30 minutes minimum). This brings up the middle temperature of the steak and ensures that the exterior isn’t cooked before the interior. Heat indifference can result in really dry steaks and bitter burnt seasoning.

  3. After 30 minutes has passed, rub down your steak in a generous amount of olive oil (or any oil). Some people are a fan of nut oils (and coconut oil) because of their higher smoke point, but use whatever works for you.

  4. Now place generous amounts of steak seasoning on your steaks. If you don’t have any seasoning, this recipe is amazing. Or you can be more traditional and just use coarse salt and peppercorns to season your steak. Be generous with the seasoning.


  1. Now lets get our coals lit using our chimney starter, similar to this one. Do NOT use lighter fluid, lighting gel or even the flammable lighting cubes (they will taint the flavour of your meat). Roll up some newspaper and place it beneath the starter, then leave the coals to heat up for about 15 to 20 minutes. The instructions on the starter should tell you what to do (and recommend paper).

  2. You’ll know your coals are ready when the utmost top pieces are white and the pieces beneath are glowing orange. I like to place some additional unheated coal into the bottom of the barbecue on my coal tray and then pour the hot coals on-top to prolong the cooking time (coals stay hot for a long time). But before you pour anything into the barbecue lets explain offset grilling or indirect heat as it is also known.

  3. Indirect heat is where you have one side comprised of the heat source (a mound of hot coals) and the opposite side has no coals. You can also place coals on either side of the grill and leave the middle vacant. Eventually the hot plate will heat up and both sides will be hot, but because of the residual heat from the hot side this gives you a medium heat side and a high heat side. Place your hot coals on your coal tray beneath the hot plates to one side. I place the hot coals up on the far right side on my barbecue, evenly distributed and a slight mound.

  4. Now let everything get nice and hot. Also make sure your damper is fully open as to not choke the coals. A closed damper means your coals won’t get any oxygen and without oxygen they will eventually extinguish. Place your wood chips into your smoker box, or if you don’t have one: wrap them in aluminium foil and seal them. Then poke holes into the pouch using a fork all over so the smoke can escape easily to flavour your meat. Depending on your barbecue you might place the box beneath the grill or on-top of it. Either way, it doesn’t matter. You just want your wood chips to start smoking. If you have the smoker box you can place it beneath the grill (right beneath your food source).

  5. Once the wood chips start smoking (it will be a white smoke), hold your hand over the direct heat side and if you can’t hold your hand there for more than 2 seconds before feeling the burn, you’re ready to start grilling.

The Cook

  1. Place your steaks down onto the high heat side to sear them, seasoned side face down first. You’ll want to cook each side for roughly 1 minute, turning the steak at an even consistency ensures both sides cook perfectly. Also ensure you quickly turn the steak on its side and render the fat down as well (if your steak has a strip of fat). The key to a perfect steak is not overcooking, but also ensuring both sides of the steak are cooked on the same heat source for the same amount of time.

  2. Cook side 1 for 3 minutes on the direct heat side, then flip and cook the other side for 3 minutes. Once you’ve cooked for 6 minutes on the direct heat side, we repeat the same process on the indirect heat side for the same amount of time. 3 minutes on one side and then 3 minutes on the other. This will give you a steak cooked roughly medium to medium rare. It depends on the cut of the steak and the thickness (And whether you have a steak with a bone in or no bone), so use a meat thermometer to check your steaks are cooked to your desired doneness. To have your steaks cooked a little more, increase the indirect cooking time by one or two minutes.

  3. Once your steaks are done, let them rest for about 5 minutes in a warm area. If your barbecue has a warming rack, wrap your steaks in aluminium foil and then let them rest. This will allow for the juices in the meat to resettle.

Steak temperatures

Understanding how to cook the perfect steak is knowing the temperatures. Seasoned chefs can use the feel of various parts of the hand to test for doneness, your home barbecue chef and average cook most likely cannot test by feel. The best method is using a meat thermometer and monitoring your steaks internal temperature (the centre point).

  1. Rare – internal temperature should be between 52 to 55 degrees celcius
  2. Medium Rare – internal temperature should be between 55 to 60 degrees celcius
  3. Medium – internal temperature should be between 60 to 65 degrees celcius
  4. Medium Well – internal temperature should be between 65 to 69 degrees celcius
  5. Well Done – internal temperature should be between 71 to 100 degrees celcius

The Template Element Is Finally In Edge

It really does feel like the Microsoft team working on the Edge browser are legitimately trying to put out a decent and truly evergreen web browser.

Today is a glorious day for Edge users and developers alike. Support for the <template> element has now landed in the latest preview release of Edge. This means not too long from now, support for the <template> element will be rolled out to everyone.

After the debacle of Internet Explorer 11 supposedly being evergreen, which turned out to be a nevergreen browser. It seems that the Edge team are actually listening to the community and implementing the latest and greatest of web APIs and specifications into their browser.

Support for the <template> element is crucial to supporting Web Components. As a developer who has been working with Aurelia since it debuted early 2015, I’ve grown accustom to working with Web Components and I am happy to see support is finally coming to Edge.

To the future!


Understanding Aurelia Router Events

Unknown to some is the Aurelia router supports events. Using the Event Aggregator dependency in Aurelia, we can actually listen to various events fired via the router. At the time of writing this the documentation did not list the events, so I had to go digging into the documentation for the router.

It is possible that more events might be added in future and hopefully eventually some documentation around using these. For now, hopefully this helps you. All events can be subscribed to using the Event Aggregator dependency and the subscribe method.

The events the Aurelia router fires are as follows:

  • router:navigation:processing
  • router:navigation:error
  • router:navigation:canceled
  • router:navigation:success
  • router:navigation:complete

Rather than digging through the documentation yourself, here you go. But you’re probably wondering, at what stage do any or all of these get called within the lifecycle of the router? Good question.


This event appears to be fired for anything that relates to the router doing something. Looking in the unit test which has some insights, we can see that when the router successfully navigates, is cancelled or errors out, that this event is always fired. Basically this event is saying, “every time you see this fired, the router is processing a route instruction”


A pretty obvious event. When there is an error, this event gets fired.


Another fairly obvious event. When a routing action is cancelled, such as inside of a custom pipeline step which checks if the user is logged in, this event gets fired.


Once a routing action has been completed, such as a user click a button and being navigated to a particular page and there are no errors, this event fires.


Once everything is complete (not necessarily successful) this event fires. From what I can decipher, the complete event is similar to that of the processing event. The processing event is the first even to always fire before anything else and the complete event is the last event to fire. This event will always fire regardless of if there was an error or success within the routing process.


My Thoughts On Jetbrains Toolbox: SaaS Moneygrab

Recently the makers of Webstorm, Jetbrains announced something called Jetbrains Toolbox. The site describes it as a “new licencing model” marketing speak aside, it is a subscription based model which means users will now rent their software instead of owning it.

If you’re a polyglot developer, then this might appeal to you. If you’re working with C# and love ReSharper and also working with the front-end and using WebStorm, a subscription based all-you-can-eat-as-long-as-you-keep-paying model might make sense to you.

But I like owning my software. I think Jetbrains have seriously underestimated the number of polyglot developers out there who would find value in a subscription model.

I paid $49 for my WebStorm licence initially and every time I want to upgrade I only pay $29. The upgrade schedule is roughly on a yearly basis. So by that logic (forgiving the initial $49 purchase) I pay $29 per year to upgrade WebStorm and perpetually own a copy of it. Meaning if I decide upgrading to the next major version isn’t important, I can happily keep using my old copy.

So if I want to continue using the latest version of Webstorm, I pay the same $29 per year, but I don’t actually own the software. If for whatever reason I can’t afford to renew or there is a billing error, I potentially find myself in a situation where I can’t use my IDE to make money (I could fall-back to Sublime, but that is not the point).

For some a subscription model might make more sense. Being able to rent applications for particular use-cases might be a better business decision, but for developers like me who freelance and use WebStorm at work as well, this irks me.

People like to point out that Adobe has a similar cloud based offering, they were the first to introduce the concept of renting your software on a large scale. But look what happened, crackers managed to pirate Creative Cloud still. Moving to a cloud based offering doesn’t make you immune to piracy or problems as a result of phone home calls.

Jetbrains is basically telling their customers they’ll need to crack their software if they want to “own” it perpetually.

Then there are other unknowns:

  • What happens if the software can’t phone home to verify the user owns the software in a reasonable amount of time?
  • What happens if Jetbrains licencing servers go down and people can’t use their software because it can’t verify?
  • What happens if Jetbrains goes out of business?
  • And perhaps even likely: what happens if Jetbrains is sold or acquired by another company?

I am not saying that a cloud based solution is horrible. I am saying for some, it makes no sense. I only use one Jetbrains product and that is Webstorm. If I were using many of their applications, then I might think a subscription model makes more sense.

There is also the problem of developers (potentially working on large teams) within corporations where budgets are assigned and purchases need to be requested. I know from personal experience a lot of companies hate subscriptions. This is why it is a common occurrence to see companies using older versions of software because it can save the company thousands of dollars.

For many, getting approval for a recurring cost (especially for a large team) is a pipe-dream. This is just going to cost Jetbrains business because developers will flock to other tools because they know it’ll be a nightmare getting approval for a cloud based IDE, if they can even get approval in the first place.

The only compromise here is offering bundles of applications as a cloud offering and allowing perpetual licences to be purchased for individual applications like you can now. You just want WebStorm, buy a perpetual licence. You want; PHPStorm, WebStorm, ReSharper or other tools in a bundle: get a subscription.

I would prefer to actually have the piece of mind knowing I am not going to be locked out of my IDE, especially half way through a project with a tight deadline. Poor form Jetbrains.


Aurelia + JSPM: Deployment Best Practices & Unknowns

If you’re using the JSPM Package Manager with Aurelia, then this post is for you. There is a lot of uncertainty about bundling an Aurelia application and what deploying to production actually looks like. Until Aurelia comes with a proper bundling solution (the Aurelia CLI has been dropped), then we’re left to scratch our heads and use snippets from blog posts. There is now an official Aurelia bundler released which means we don’t have to glue together bundling solutions anymore.

Even after you have bundled your application, what does the rest of the workflow look like? What files get deployed, what folders and what needs to change?

Some questions you might have:

  • What do I bundle in my Aurelia application and do I bundle everything or just Aurelia dependencies?
  • Do I commit the config.js file into my repository?
  • Do I commit my app-bundle.js file into my repository?
  • Should the jspm_packages folder be committed into my repository?
  • Does the jspm_packages folder get deployed to production?

Don’t bundle everything

My initial approach in my Aurelia application was to bundle everything. Not just Aurelia’s dependencies, but absolutely everything in my project. Some examples from a current project I am working on; Moment.js, Dexie.js, Select2, To Markdown, Showdown, jQuery, Sortable and a couple of other dependencies.

This is the incorrect approach to take. While JSPM supports creating multiple bundles, I could never find the right medium to have multiple dependency bundles within Aurelia.

I soon realised that bundling up just Aurelia and its dependencies first (because they’re global to the entire application) made a lot of sense. But bundling in jQuery or Select2 (when it might not always be needed), made zero sense. Why include everything when the user might only ever use 50% of your bundle?

Not bundling all of your dependencies also makes a lot of sense if you’re using HTTP/2 with its multiplexing features which basically render the need to minify or combine files useless.

However, support isn’t completely there yet, but when it is, having your jspm_packages folder there ready to switch everything over will be a lot easier.

What to commit

The config.js file is made to be committed to your Git repository. In-fact, if you look at any Aurelia dependency (or the Skeleton Navigation application), you will see a config.js file in the root directory of the repository.

JSPM is a smart package manager in that it selectively replaces parts of your application (map and bundles), whilst allowing you to specify configuration options that don’t get overwritten.

You might be tempted to also commit your bundled Javascript file into your repository. Do NOT do this. You will encounter a mountain of migraines courtesy of Git conflicts if you commit a dynamically generated bundle.

If someone were to remove a package and commit the bundle, it would most certainly cause merge conflicts. This file is made to be built as part of your application build process, not within your codebase.

As is always a rule of thumb with any package manager, under no circumstances should you commit your jspm_packages folder. This gets built when you run the jspm install -y command.

The same also applies to any package manager like Bower or NPM, do NOT commit the packages folder. If you’re experiencing issues with your build server and cannot generate a Github token (or whatever) for JSPM, commit your jspm_packages folder as a last resort.

How to bundle

Previously I detailed a custom way of bundling your Aurelia application into bundles, but since publishing the official Aurelia bundler has been released.

Before you copy or configure anything, make sure you install the bundler by opening up your console and typing: npm install aurelia-bundler --save-dev

To bundle your existing applications, you’ll want to copy over the build/tasks/bundle.js Gulp task file within the Aurelia Skeleton Navigation repository to your build/tasks folder.

If you are not using Bootstrap in your application, you’ll want to remove the line which includes the CSS into the bundle or you’ll run into some errors: 'bootstrap/css/bootstrap.css!text' — If you’re also not using the aurelia-animator-css dependency, you’ll want to remove the line that tries to bundle it as well: 'aurelia-animator-css'

If you’re planning on bundling CSS, you’ll need the text plugin to do so. The original blog post didn’t detail this step for those wanting to bundle existing applications. Simply install it by running in your console: jspm install text

To generate a bundle simply type: gulp bundle or if you want to unbundle type: gulp unbundle

When your application is loaded, JSPM will first look in your bundle when a dependency is requested. If it is not found, it will load it using the map and get it from the jspm_packages folder. And because we specified we wanted to inject our bundle, we don’t need to do anything as config.js already knows about it.


There are many different approaches you can take to deploy an application. You might be using a build deployment/continuous integration platform like TeamCity or you might be working directly on the server. You need to make sure your jspm_packages folder is on the deployed server.

As mentioned above: do NOT commit your jspm_packages folder into your Git repository. This is a dynamically created folder that is built and modified during installation, updating and removal of JSPM packages.

Because we’re not bundling all of our dependencies, we will need this folder. But more importantly, we need system.js which is inside of this folder to handle loading everything.


You probably were aware of some of the things mentioned here. This is to clear up some confusion around using JSPM and bundling an Aurelia application. This applies to even non-Aurelia applications using JSPM as well.

While tools like JSPM improve our workflow and processes on the front-end, sometimes it can be difficult to know where things sit within the overall flow and structure of a modern front-end application.


Aurelia Configuration

One of the most important aspects of a web application (besides the application itself) is how configurable it is. Where you define key global pieces of data accessible to whatever part of the application needs them; name, version number, API endpoints, API keys and more.

This is why I created Aurelia Configuration. A simple plugin for the Aurelia Javascript framework that allows you to have a configuration file for your application and then pull out values (with support for temporarily overriding values).


Using Aurelia Configuration

Rather than repeating what has already been said, head over to the repository (link above) and install the plugin into your applications bootstrap process.

After you have installed the plugin, you then want to create a configuration file. By default the plugin will assume you have a configuration file called application.json in a folder called config located in your root directory. These values are of course, configurable.

Lets populate our application.json file with some example values for testing:

    "name": "My Application",
    "version": 1.2,
    "api": {
        "key": "12380198230918jlfkjsdfs",
        "endpoint": ""

Now to use the plugin within a ViewModel, you merely have to import then inject it like you would any other Aurelia dependency then use the few API methods.

import {Configure} from 'aurelia-configuration';
import {inject} from 'aurelia-framework';

export class ViewModel {
    constructor(config) {
        this.config = config;

    sampleMethod() {
        let applicationName = this.config.get('name');
        let apiKey = this.config.get('api.key');
        let apiEndpoint = this.config.get('api.endpoint');

        // Get all config values
        let theConfig = this.config.getAll();

    anotherMethod() {
        // Values only persisted temporarily and not written to file
        this.config.set('name', 'Changed Application Name');
        this.config.set('api.key', 'kjlkcjfsd9f8d8fsdklfjlsk2');
        this.config.set('api.endpoint', '');

        // Override the config object completely (not recommended)
                "newProp": "sdaksjdlkasjdas"


No plugin would be complete without being configurable, right? Every aspect of the plugin can be configured during the bootstrapping phase. Examples on dynamic environment configuration and manual environment configuration are documented in the repository README itself here.

Rather than repeat what has already been said, the README is rather concise and has code examples to easily follow.


There isn’t a whole lot to this plugin. Its goal is to help you configure your Aurelia applications using a config file instead of changing values in a Javascript class. If your app is user-focused and configurable, it means splitting out your configuration from your application logic and that could save you many headaches.

As always, if you spot any bugs or have improves; please fork and submit a PR.


Privates In ES2015 Javascript Classes

One feature missing in ES2015 (formerly ES6) classes is the concept of a private variable or function. However, thanks to ES2015 modules we can actually easily define private properties and functions that can only be accessed within our class.

Private Properties in ES2015 classes

Using a WeakMap which we have discussed before, we are going to implement the concept of private class properties.

Because classes are just objects, we can use WeakMaps on them. Then by specifying getter and or setter methods on the class, we can control access to these private properties. The beautiful thing about this is that using the export keyword, we are only exposing the class Person. This is akin to the revealing module pattern where we choose what is exposed to the client.

Using something like an ES2016 Decorator, we can probably easily create the concept of a decorator which will allow us to define variables as private and even control access to them. Just some food for thought.

const privateProps = new WeakMap();

export class Person {
    constructor(name, dob) {
        privateProps(this, {name: name, dob: dob});

    get name() {
        return privateProps.get(this).name;

    get dob() {
        return privateProps.get(this).dob;

Private Methods

We are going to be borrowing the above example and introducing the concept of a private method. The goal of our private method is to only be used within the class itself, but not available to the client by any other means.

Traditionally the revealing module pattern allowed us to selectively choose what is exposed, we can achieve the same thing using ES2015 modules (like above).

const privateProps = new WeakMap();

// Private function for lowercasing a string
function _convertToLowercase(val) {
    return val.toLowerCase();

export class Person {
    constructor(name, dob) {
        privateProps(this, {name: name, dob: dob});

    get name() {
        return _convertToLowercase(privateProps.get(this).name);

    get dob() {
        return privateProps.get(this).dob;

In our example above we create a rather redundant private method for lowercasing a string. The function _convertToLowercase is only accessible from within the class itself. Because we are exporting the class, it doesn’t get exposed. This allows us to have the concept of a private method very easily.

I realise the private method is not on the class itself and that would be the ideal situation to be in. But given how classes actually operate, any method you currently define in the class gets added to the prototype of your class so it can be called from anywhere.


While ES2015 Javascript lacks the concept of visibility keywords, we can still achieve the same thing without them. This is why I really like Javascript, it doesn’t give you one way or the highway, but lets you implement hacks creative solutions to problems.

Supersets like TypeScript while they have concepts of visibility keywords, they’re not for the resulting output but only for the compiling stage where your code is checked. It will stop you if you are trying to illegally reference a private property or method.


Convert Javascript Prototype Name From PascalCase to file-case

At my day job, I am currently building a pretty complex Aurelia application. One such component of the application is a widget system which allows ES2015 classes to define new widgets and then the system can load them in. I ran into an instance where I needed to convert the class prototype name value to file-case (all lowercased and hyphen separated).

What this will essentially do is take the value in PascalCase and convert it. So a classname value of: MyClassName would be converted into my-class-name instead. There isn’t much to the code to be quite honest.

The Gist below has both ES2015 class and traditional prototypal inheritance examples to show its use. Enjoy.

// ES2015 classes
class MyClass {
    // Would return: my-class
    toFileCase() {
        var className =;
        var normalised = className.replace(/((?!^)[A-Z])/g, '-$1').toLowerCase();
        return normalised;

// ES5 prototypal inheritance
function MyClass() {
// Would return: my-class
MyClass.prototype.toFileCase = function() {
        var className =;
        var normalised = className.replace(/((?!^)[A-Z])/g, '-$1').toLowerCase();
        return normalised;