Secrets of the JavaScript Ninja: Chapter 6 Review

Object-Orientation with Prototypes

This chapter goes into object prototypes and how they can be used for inheritance and sub-classing. It also includes a sample method that can be used to instantiate sub-classes easily. This is almost identical to the same method John Resig had posted on his blog.

All of this brings JavaScript closer to something that would make a developer with mostly object-oriented experience more comfortable.

Finally, he makes his first touch on regular expressions, which is the basis of the next chapter. I’ll be reading this with the following quote in mind:

You have a problem, so you use a regular expression to solve it. Now you have two problems.

What I Learned in this Chapter

John went more in depth (and more plainly) about why extending the prototype of native objects could be bad. He also showed a clever way for a function to detect whether is was called as a direct invocation vs. as a constructor.

Secrets of the JavaScript Ninja: Chapter 5 Review

Closing in on Closures

Closures are how you can maintain scope and context in your application. Without them, far too much ends up cluttering the global scope. With them, you can truly have modular code. There are several things in the language that mark the passage of a person’s skill to the next level: closures are a huge one. I would argue that until you get the hang of closures you will forever remain at a novice/beginner level of JavaScript skill.

This chapter covers closures and how they are used to control scope/context. It also covers their use as immediate functions (fire and forget). The primary example tracked through the chapter is currying, but there is also a good memoization example.

What I Learned in this Chapter

I’ve known about (and heavily used) closures for many years. It was good to get a professional refresher with a batch of simple examples, but I can’t honestly say I learned much in the particular chapter. Some of the examples used some interesting styles that I pondered (like returning an equality statement as a shortcut).

Secrets of the JavaScript Ninja: Chapter 4 Review

Wielding Functions

This chapter covers anonymous, inline, recursive, and overloaded functions in JavaScript. Their overloading method is based on matching behavior to a number of arguments (I personally prefer a single object as an argument, then acting on the properties).

What I Learned in This Chapter:

Nothing was really new to me in this chapter, but an example of handling overloaded functions was interesting (the author created layers of anonymous functions that end up acting as a pseudo-recursion). There was an explanation of this method of identifying functions:

This is used to work around bugs/odd behaviors in Firefox, IE, and Safari where they will incorrectly report certain objects as functions. I hadn’t known about these…good to know!

Secrets of the JavaScript Ninja: Chapter 3 Review

Functions are Fundamental

The concept of functions as first-class objects is central to this chapter, as it is the foundation of the rest of the book. It is this fact that allows them to be treated as variables, objects, and classes. It also covers the five ways to call a function (function, method, constructor, call, and apply) and what each means in terms of arguments and scope.

What I Learned in This Chapter:

There was something here that I knew intuitively, but not with succinct consciousness until this book spelled it out plainly. A function invoked as a function is always in the window scope:

In both of the above cases, the functions will run in the window context, regardless of where they were defined or called. Scope/context are one of the most important things to understand in JavaScript, so a clearer understanding is a better understanding.

Secrets of the JavaScript Ninja: Chapter 2 Review

Arming with Testing and Debugging

JavaScript development has come a long way since I started, back when Netscape and AOL were king. The days of sprinkling alert statements into your code is long past (and thank the gods for that).

Mr. Resig does make a brief mention of the old ways, with the same sentiment, and goes on to mention the basic tools we have for debugging today. All of the major browsers have excellent tools for developers built into them now. Like me, he thanks the developers of Firebug for starting us down this road. They set the bar for the browser makers to reach, and continue to do so.

Debugging essentially breaks into three areas: logging, breakpoints, and inspection.


The book suggests a possible unified logging function to support all browsers (handling the different methods Firefox/Webkit/IE and Opera use, and falling back to actual alerts if needed).


These are consistent in browsers, and good logging tells you where you need to put them. Further, these days you can set conditions on your breakpoints so they’ll only stop when you need them to.


The book doesn’t mention inspection, which I consider at least as important as logging and breakpoints. Being able to inspect the rendered state of a DOM element or explore the structure of an object in JavaScript is invaluable. But inspection is mostly to benefit the DOM, which is outside the scope of the book.


Resig spends most of the chapter making the case for Unit Tests in JavaScript. There are multiple unit testing frameworks available for free, and many are quite good. I disagree about the universal importance of unit testing, but it’s very important to Resig. It’s also very useful for the study of JavaScript, to test how things work.

What I Learned In This Chapter:

It’s hard to be in the business this long without picking up the information in this chapter, but I still managed to hear about a testing framework or two I didn’t know about.

Secrets of the JavaScript Ninja: Chapter 1 Review

As an exercise in self-improvement, I’m reading Secrets of the JavaScript Ninja (by John Resig and Bear Bibeault). I further intend to post/comment/review every chapter therein. And all in a decent timeframe! So without further adieu:

Enter the Ninja

This short chapter talks mostly about aspects of cross-browser development. Mostly in pointing out that it’s hard. Definitely harder than most people (including developers) think. The authors encourage the obvious: a cost/benefit analysis per project to determine browser support. Unsurprisingly, IE 6 is considered horrendously expensive to support by any measure. Of all the benefits of finally migrating away from legacy IE versions, cost savings had never really occurred to me. It’s obvious it retrospect. Firefox, Chrome/Safari, and IE 9+ are considered low-cost for development.

Chapter 1 briefly mentions unit and performance testing, with promises to cover that later. I’m a little intrigued with the prospect of actually developing these as part of the book itself.

The last point of the chapter is to make the case that the best way to learn is to study the masters. This might be a little redundant, as most people purchasing this book are likely familiar with the authors already. I know that’s why I bought the book.

 What I Learned in This Chapter:

It would be surprising to actually learn much from an introduction. I was not surprised.

The Deep Blue: Design Document

The first step in creating a new game is to describe your world and how it works. The way you do this is with a Design Document, often referred to as a Bible. Here you put down as much information as you can muster. Laws of physics, geography, culture, legends, history…it all goes in here. Some or most of it may never be visible or directly apply to the game. It’s there so you know how to implement everything. The information directly influences the design, code, and gameplay.

The Deep Blue is to be a casual, browser-based game of sea piracy on an alien world. The first step to make it happen is its design document.

Continue reading “The Deep Blue: Design Document”

Decision 2013

Well, so much for that last plan. Even then, I apparently underestimated the happy time-sap that is a child.

When I finally sat down to really, seriously start looking at Mutant Freaks of Nature again, I realized I couldn’t remember half the PHP I’d used to write it. It was daunting, and old…and unexciting. Sadly, I had to admit I’d been ready to move on for quite a while. It just took me a while to admit it.

Continue reading “Decision 2013”

Indecision 2011

So back in early 2009 I had decided there were several (mostly little) things I didn’t like about Mutant Freaks of Nature. I started the process of making some smallish changes, which eventually touched every file in the game. Then I decided that since I’d gone that far, I should really just rewrite from the ground up to give it a better code base. Then I changed my mind about the interface, then this thing, then that thing.

Continue reading “Indecision 2011”

Custom HTML Tags

I have to mention that “Custom HTML” is really an oxymoron. When you start adding tags that aren’t part of the official standard, then you really have an XML document that the browser attempts to interpret as HTML. Think of this as a technical exercise. Two things led me to this exercise.

New HTML 5 tags

I’ve been doing a lot of reading about HTML5 and some of the new tags that are specified (my favorite such article is here). In this article, Mark Pilgrim suggests going ahead and using the new tags now, even though browser support is limited. Most of the new tags don’t display as anything special, and are only semantic (such as the header, footer, article, or nav tags) and will render the same as a normal span tag. And just like a span tag, you can apply CSS to them as you wish. Except for Internet Explorer, which requires a little JavaScript tricker to make it work:

John Resig goes over this trick in detail in one of his excellent blog postings.

Evented Programming

The second piece of this puzzle was an article/video that came along with the 1.4 release of jQuery, where Yehuda Katz discusses his approach to creating widgets on your web pages. He reasons we should make these widgets to function as if they were built into the browser in the first place. For example, say you’d like a tabbed control on your page. The usual approach would be to draw the individual tabs and panels as divs or spans, and attach code to each tab to hide and show their associated panel when clicked. Something like this:

Continue reading “Custom HTML Tags”