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

Nintendo Builds Rich HTML5 Experiences

I need to throw a shout out to Nintendo.

I came across a rising subreddit last night about the new site that is built to entertain kids and provide resources for parents about video games and Nintendo games.

Why the attention?

Well, I'm impressed to see Nintendo put some effort into creating engaging experiences using HTML5. My personal favourite is the Mario Kart 8 Party Starter built on a canvas, or the "surprise" that happens when you click the question mark box (see above).

I know it's nothing major for an entertainment company create an interactive HTML5 web site and application, but I feel as though this is something big for a company like Nintendo to do this.

I've loved Nintendo for years, since I was a kid in fact. But (like many other video game companies) websites are not engaging, rather just informative places.

There's nothing wrong with that, as the web is just that a whole whack of documents.

But to see a big player, like Nintendo, take a leap into the rich and engaging modern web, I need to highlight it and applaud them for their effort.

Next Steps for Nintendo

You need to embrace your fan community out there and let things like FullScreenMario and FullScreenPokemon become part of your web presence, rather than killing them off.

Thanks for Playing. ~ DW

Why do you CoffeeScript your JavaScript?

I was asked this the other day: Why don't you just write your code in JavaScript directly? As in, why would you use a langugage that abstracts JavaScript, which doesn't require compiliation?

That second question is also the answer: I want a compiler, because a compiler can optimize my code.

For Example

Remember our script from the last post? Well, let's see that same thing in CoffeeScript.

JS Bin

Now I can compile it and get optimal JavaScript.

coffee --compile

I don't need to worry about the nuiances of the language syntax nor what "optimal" means for JavaScript. There is a whole community of people worrying about it for me which is put into the compiler.

Plus, like I said in the last post, JavaScript doesn't really look like other languages. Sure, it's easy once you get used to it, but so is eating broken glass.

I have a background in C# which is more of a so-called "traditional" OO language, like Java, which I find easier to read.

CoffeeScript, although definitely not like C#, is easier for me read though and understand. The more I worked with it, the easier it became as the whitespace worked in my favour. Plus, I hear people that like indentation languages like VB.NET or Ruby, think CoffeeScript feels familiar**.

**When I say "I hear", refers to of some of the anecdotal I have had over the past couple of years with collegues. So take that as you will.

But JavaScript Has "Normal" Class Definitions and Stuff

You're the ES6 standard. Plus, property modifiers kinda go hand-in-hand with class defintions and that is expected in ES7.

I want to support platforms that are out now, not next year or the year after. These platforms came out before that spec, and so they don't support it. I'd have to use a compiler that abstracts me away from how JavaScript actually works just so I can use language features that will eventually be in CoffeeScript anyway.


"The golden rule of CoffeeScript is: "It's just JavaScript" -

...I don't learn to use features that don't already exist JavaScript. When the compiler supports ES6 JavaScript, the new (more traditional) keywords will be supported there too.

Not that I think abstraction languages that do that are bad (e.g. TypeScript), but I think that CoffeeScript is a nice medium that teaches me JavaScript functionality, with a simpler syntax, while giving me tools that make cleaning up and optimizing my code easy.

For example...

The IE team recently announced the support of ES6 features that are "In Development".

Internet Explorer is something of a major player on the web, so I probably want to support those users too.

The Point

I like CoffeeScript because it still allows me to learn the features JavaScript, while giving me a compiler to write optimal JavaScript, along with a simpler, cleaner syntax, in my opinion.

This is definitely more of a preference when coding JavaScript and isn't really necessary. I just find that writing CS versus JS was just more intuitive with my background.

Thanks for Playing. ~ DW