Installing Games JavaScript Style

I bought the Humble Mozilla Bundle earlier this week and I wanted to take a moment to show people what it looks like to install a JavaScript game in the browser.

When I login to my Humble Bundle account, I get this at the top of the page.

Now, I click play and it installs.

Then I play freaking FTL: Advanced Edition in the freaking web browser!

Room For Improvement

Games are big pieces of software. Making them playable inside the browser isn't a short order. Loading all the resources, like graphics, audio, and all that fun, is big.

When I tried to play FTL in the browser, it took a few hours to load the first time. I mean, it's downloading the whole thing. The second time around, it up within a few minutes, and I this time I noticed that "This page is requesting more than 50MB of space message" as I didn't leave it overnight to load.

Clearly there is room for improvement, but this is still a huge step forward for the way we can distrubute games and other software.

The Point

This is a real use case of companies taking their non-JavaScript software and making it accessible via the browser.

Take any LOB application that you want to port forward, and consider that you could make it accessible through a web portal, or inside of SharePoint, or whatever.

Now, you just worry the the game works in the browser and not the specific platforms.

Thanks for Playing. ~ DW

Humble Bundle Games Go JavaScript

Last week, I noticed a playable game on the Firefox start page. The link at the base of the page lead me to this:

You can buy games on Steam and play them in the browser or on your desktop through Steam.

That. Is. Amazing.

I've bought the bundle already as I was already eyeing Democracy 3. But being that we can compile game code into optimized JavaScript that runs in the browser is a game changer.

My Point

This is complex code, requiring high performance, running in the browser that wasn't written in JavaScript. In my mind, it proves that JavaScript is the official connective tissue for all languages to all platforms.

Have an app in C++? Compile it to JavaScript and try it in the browser before you buy it. Have a C# app? Compile it to JavaScript and make a web-based version. Prefer Java over JavaScript? Compile it to JavaScript and you're back in the browser.

My worlds are colliding, and it is freaking awesome.

Thanks for playing. ~ DW

ThatOneVideoGamer Brought To You By: Me

Yep, that's me. It's all me. It's awesome!!!!

Let me explain.

The Completionist

During my bit of professional soul searching, I rediscovered my true passion for video games. In that time, I found ThatOneVideoGamer on YouTube and really started to look at YouTube and web-based video as a serious entertainment medium.

That lead me to the rest of their shows (links below) which are all professionally done, funny, and genuine. They've set a high standard for web-based videos, and I look forward to them continuing!

Long story short, I wanted to put my money where my mouth is and support this group that make shows that lead me to cancel my cable subscription.

The Point

No real point other than the team at ThatOneVideoGamer is great and if you like video games and video game humour, you should check out their shows.

If you really like them, then support them, like me.

Thanks for Playing. ~ DW

What is Bower?

I mentioned Bower last time when talking about npm.

If you haven't heard of it, neither of many people.

So, I'm going to fix that now.

Bower is an open-source client-side HTML package manager from the people that brought you Twitter Bootstrap and..well, Twitter I suppose. If you're a Ruby or Rails person, it's like Gems. If you're a .NET person, it's like Nuget. If you're a NodeJS person, it's like the npm.

In other words, it's nothing new.

But here's what makes it awesome: HTML and client-side JavaScript are BFFs within the world of HTML5. So, if you're using HTML or JavaScript in your client, Bower is going to make remembering and setting up development environments easy.

Here's what you do....

First you install it using npm. Oh, we're using the command line for this.

npm install -g Bower --save-dev

We covered this last time, except this time the -g flag is installing it globally, so I'll have access to it from in folder.

Next navigate to the root folder for your HTML/JavaScript project and do:

bower init

Answer all the questions, and now you'll have a bower.json that looks something like this.

Now it's all configured. Next time you pull your code from source control into a new location, you can just bower install and your dependencies will be installed into the bower_components file.

Don't want the devDependencies? Then use bower install --production and you're good to go.

You can even define a different installation directory with a .bowerrc file in your project. There are other options too you can configure too, but that one is the only one I use for my projects.


Package managers like Bower are nothing new, but for some reason, Bower remains moderately hidden to many that I talk to.

Oh, and because it's using NodeJS, it's platform agnostic, just like JavaScript and how I like my coding tools.

Thanks for playing. ~ DW

Always Use Node (Even on Non-Node Projects)

That's right. I said it: Always use Node, no matter what! Even if your server isn't going to be a Node server, just have it installed because you'll use it.

Why? That's what I'm going to tell you.

Before we start...

I know there are plenty of other package managers for all the different languages out there.

I'm not saying that NodeJS is better or worse than those. I am saying that npm is freaking fantastic for HTML developers.

So let's start.

Why do I need it?

When I start an HTML project there are always different tools I need. Not just script libraries, but things like compilers, or minifiers, or just something easier than Apache and IIS to run my code locally.

Back in the day, we would have a "developer setup document" that the new person would get on day one, and work their way through it over the course of the week.

Not only was the document a pain for the person to understand most of the time, but the content became out of date pretty quickly as the technology that we used changed throughout the project.

Photo credit: jppi from

Enter Node and npm.

Instead, I can define my development dependencies with Node, and my setup document would be:

  1. Clone source code onto your local machine
  2. From the command line, navigate to root directory
  3. Type npm install
  4. Build it (Post coming soon)
  5. Type npm start
  6. Project is now running.
  7. Start debugging things.

That's it. The configuration is defined in the package.json file, like so:

  "name": "awesome-sample-project",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node ./build/index.js"
  "dependencies": {
    "nconf": "~0.6.9",
    "azure": "~0.8.1",
    "express": "^4.0.0",
  "devDependencies": {
    "grunt": "^0.4.3",
    "grunt-contrib-coffee": "^0.10.1",
    "bower": "~1.3.8"

You can get the full scoop on package.json files here at

Making it Easier

In the beginning, writing the file yourself is necessary but as I add dependencies, I don't want to always go into the file and tinker with it.

So, npm has a solution for that:

npm install bower --save-dev

For example, I always use Bower (I'll talk about that next time). The --save-dev flag adds to the devDependencies section of package.json. I can just commit the file to source control, and now everyone that gets the source code can use the tools I want them to.

Not that they are installed, those tools are available to me. The tools work on Node, and Node works on all platforms.

I am platform agnostic. I win. Roll credits.

The Point

The point is simple: use a package manager. If not npm, then something that works for you and your project. Many people seem to skip Node, but as an HTML developer Node and the npm can easily keep your dev environments in sync, regardless of operating system.

Oh, I skipped over Bower on purpose. That's coming next time.

Thanks for Playing. ~ DW

Why do you RequireJS?

Get it? RequireJS is a dependency management framework I use in JavaScript to manage...well my dependencies. But, the title is a play on words cause...of course you require JS...cause...JavaScript is required to...


Yeah...well, I think I'm funny. (Sad Trombone)

Here's why I use RequireJS: it ensures that the JavaScript I need to run my code is loaded. I don't need to worry about the order of the <script> tags in the HTML. I don't need to do any sort of checking or onload event stuff, I just know it's good to go.

See demo at JSBin

Second reason: It defines a single point to start the application with the definition of the data-main JavaScipt file. So, when I load an HTML page, I know the first line of JavaScript that will be executed and can build from there. Again, not worrying about multiple files loading at the same time and executing in parallel or anything.

<!DOCTYPE html>
        <script data-main="path/to/main" src="path/to/require.js"></script>

The path/to/main is a reference to a main.js file. RequireJS doesn't need the JS, as it's implied.

Plus, because of the whole "knowing that my JavaScript is already loaded", I know that the libraries that I leverage (e.g. jQuery, Bootstrap, whatever...) will already be loaded and setup before I start running my application code.

Ha! What about your library dependencies?

I define and configure those in the RequireJS config JSON that gets run before we start the application.

        # dummy path for demo
        'jquery': '' 
        # This is a sample of defining dependencies
            deps: "jquery"
            exports: "Bootstrap"

Double "Ha"! What about your text file dependencies?

I don't usually need it, but if I do there is a plugin.

Plus, if you're using text files to localize your site, there is another plugin to help that that too.

The Point

When I start a project, I make sure I wire up RequireJS first before I start writing any code. Because:

  • I don't need to worry about libraries and other script not being loaded
  • I know where my application will start every time the page loads

Ultimately, it gives me less things that could go wrong while I'm focusing on writing code. Plus, as a keep building the application, it forces me to think about what my "new" code needs to depend on as I go making it cleaner and easier for someone to get into.

Learn about it here. Given, it's a steep learning curve with that documentation, but I guarantee it's worth it.

Thanks for Playing. ~ DW