JavaScript Inheritance - HowTo Shoot Yourself In the Foot With Prototypes!

One thing that has long eluded me is a good understanding how JavaScript inheritance works when the parent constructor function has instance properties. The following code has a Widget parent class that has a messages properties. In this case we want each instance to be initialized with an empty messages array:

Before we set SubWidget's prototype to a new instance of our Prototype constructor on line 12 we get an object graph that looks like this:

After the code on line 12 is run the new keyword does its magic and ties everything together creating a new inheritance tree and a new scope.  Our object graph now looks something like this:

Do you see what the problem is yet? Lets create some instances of our subclass to highlight the issue:

Now our object graph looks like this:

Before I talk about the real problem here I'd like to step back and talk about the "type" property on the widget's constructor.  If it is not initialized by assignment each instance's "type" property actually points to the constructor's "type" property.  However, once it is initialized by assigning a value to like so: sub1.type = 'Fuzzy Bunny' it becomes a property of the instance, as shown in the new object graph:

Our bug should start to become clear now.  Let's look at the value of both sub1 and sub2's messages array:

JS Bin

Each object is sharing the same messages array! It would be tempting to fix this by adding another property to the SubWidget constructor like so:

However, what if we wanted to create other objects that extended Widget?  That new object would also need a messages array and pretty soon we have code that is a nightmare to maintain and extend.  Additionally, what if we wanted to add other properties to the Widget constcutor that were initialized when instances of its sub classes were constructed?  This isn't very reusable or flexible solution. 

In order to properly fix this all that needs to be done is  to add a single line of code to our SubWidget constructor that will invoke the Widget constructor with the same scope of our SubWidget constructor:

Now when we create new objects each instance has a new instance of the messages array:

JS Bin

Now our object graph is correct:

Warm and Fuzzies

Be honest, how many times have you looked at someone else's code and said something like, "Who wrote this? They msut be an idiot!" or something to that effect?  I do it all the time, and if my ears aren't deceiving me I hear others doing it all the time as well. Sometimes this kind of response is justified, like the time when I came across a piece of code that queried a table and used a for loop to filter the rows instead of using a WHERE clause. However, sometimes it's our own insecurities and shortsightedness that triggers this reaction and stops us from looking at things more objectively.

Today I found a piece of code that at first appeared to be completely backwards and I started going to the familiar place of negativity. I was ready to rip it out and reactor it till it was perfect, my perfect. Then I'd scour commit logs to find out who wrote such bad code. I'm not sure what happened but something inside me decided to take a step back and look at the code and do a little research first.  After a few minutes I actually learned that the was actually written quite cleverly. I still scoured the commit logs to find out who wrote it but then I took a different approach. I chose to open up my e-mail client and wrote the developer a short e-mail telling them that I really liked the way they wrote that piece of code and that I learned something from it, and you know what, it felt pretty darn good.

It's so easy in the software development industry to focus on the negative, we are surrounded by it most of the time. The users of the software we write rarely communicate with us unless it's to tell us that something went wrong or doesn't work the way they expect. Even our friends and family encourage this sort of reaction by coming to us with their virus-laden computers and never asking to see what cool stuff we've been working on. We also love to look at other people's code and find the slightest problems. Raise your hand if you've scoured someones blog post looking for poorly written code?  I have. It makes me feel like a smarter person when I can find flaws in other people's code, however it still doesn't make me feel any better about the code I've written. My point is, that it's super easy to focus on the negative to make us briefly feel better about ourselves. However, my experience today has taught me that it feels FAR better to focus on the positive aspects of others code and to take a few minutes to tell the other developer that you like what they've written as well. 

cf.Objective() Session: An Introduction to AMD With RequireJS

AMD modules have been the subject of a lot of talk lately, some people really like them, some people hate them. Regardless, there is a lot of AMD JavaScript code being written these days and it would behoove any JavaScript developer to have a working knowledge of AMD and RequireJS in their toolbelt. Personally, what I love about AMD modules is that I don't have to worry about loading my script files in the right order in my markup, I also love that each module's dependencies are clearly defined within its source code. Writing decoupled and reusable "micro" applications within a RequireJS application becomes super easy.

The barrier of entry to AMD and RequireJS can sometimes look a bit high when first exposed to the concepts, and indeed it may be if you are still putting all your code inside your $( document ).ready() function. However, if you've been using a MV* framework, or if you've been using Rebecca Murphey's Object Pattern to organize your code, getting started with AMD will be super easy in most cases.

This session will help you get acquainted with writing AMD modules, adding RequireJS to your project, and using the R.js optimizer to optimize your RequireJS source code. After it you should have a good understanding of how powerful modular JavaScript code can be and have a good working understanding of the moving parts of a RequireJS application so you can go home and start adding RequireJS to your next project.

The best part is, if you attend my session (which is scheduled in the last time slot of the conference) there's a chance we will get to site down one-on-one and talk about Require and AMD.

cf.Objective() Session: The Art of JavaScript, Level Up Your Skills In 60 Minutes

JavaScript is a funny language, many really smart programmers never really take the time to learn it. They learn how to write jQuery code, but never learn the beauty of the language beneath it. I blame JavaScirpts trouble past for this, if you've ever had to debug JavaScript on IE6 you know what I mean.

This session is for developers who know JavaScript but dont really know JavaScript. If you are unsure about attending ask yourself these following questions, if you answer is "no" to any of them, you might want to attend this session:

• What is the difference between var func = function(){} and function func(){}?
• There is a subtle difference between lexical scoping and closures, what is it?
• What [7] == 7 is and why?
  
• What each log statement produces when  running the following code:
  
  
• What undefined || 'foo' returns?
• Why foo.constructor === Foo is false when running the following code:
  
  

If that's not enough to convince you to come to my session maybe this will: I'm giving away a copy of "Effective JavaScript" that is signed by David Herman himself!  

I'll Be Speaking About The DOM At ThatConferenece In August

I'm really excited to have been chosen as a speaker for this year's ThatConference conference in the Wisconsin Dells in August.  If you haven't heard of ThatConference before its billed as "Summer Camp For Geeks" and prides itself on being  a relaxed, fun, and wide-ranging conference.  It's also one of the few conferences where there are specific family friendly activities planned during the conference (being held at an indoor water park doesn't hurt in this regard).

With tracks on mobile, web, cloud, and "other" there each time slot is packed with interesting sessions from some top notch speakers.  I'm extremely honored to be amongst such amazing company.  One session I'd like to draw attention to is Mike Rohde's "Sketchnote Workshop".  I have the pleasure to work with Mike and have been through his workshop.  Even if you are a terrible drawer (like myself) you'll take away a lot of excellent information from this session.

My session is titled "Indiana Jones and the Temple of DOM" and will focus on using the browser's native Document API's to select and manipulate a page's contents without the help of a library like jQuery.  Why is this important?  Here I defer to Remy Sharp's "I know jQuery. Now What?"  TLDR, while jQuery super awesome every project doesn't need to start with immediately adding jQuery for it.  There are many cases where all of the events your project needs are already built right into the web Browser.