Indiana Jones and the Temple of DOM Slides

I recently gave a talk at ThatConference 2013 titled "Indiana Jones and the Temple of DOM" in which I received a lot of requests to share the slides from attendees so I figured I'd share them with everyone.  I'll likely turn this into a video that I'll post online but until I get to that please enjoy the slides here:

https://www.dropbox.com/s/ohm5ogutiel77ib/Temple-Of-DOM.pdf

I'd also love to hear your feedback and suggestions how I could make it better!

Sessions I'm Excited to See at ThatConference 2013

With ThatConference right around the corner I thought I'd share what sessions I'm excited about attending.  There is a ton of great content to choose from so making my decisions was quite hard.   I ended up going with with a focus on Angular JS and CSS.

What sessions are you most looking forward to?  

Indiana Jones and the Temple of DOM

me

How could I expect people to want to come to my presentation if I wasn't excited about it myself. I think I've put together a pretty fun presentation that I hope everyone will enjoy.

Angular JS Crash Course

Ian Muir

I've been learning a lot of Ember.js lately and I'm very happy with it, however it seems like a lot of people are turning to Angular lately. I'm really looking forward to seeing what Angular has to offer.

Tubing Down the Asset Pipeline in Node.js

Jacob Gable

I've used Node for a few things, however, I'd love to learn a lot more about it.

**JavaScript broke my heart. And then I met AngularJS.

Joe Eams

While I'm sad that there are no Ember talks at ThatConference, I'm glad that I'll get to take a longer look at Angular. Perhaps I'm missing something and I'll fall in love with it as much as everybody else after I see more of it.

Front End Legos: Better Design with Reusable HTML & CSS

Shay Howe

I've been spending a lot of time properly learning CSS lately. That means less hacks and more of being able to understand and explain what I'm doing. This means immersing myself into CSS as much as I can so this one is a no-brainer for me.

**Adventures in CSS: Advanced Techniques for a Fabulous Front-End

Amelia Marschall-Miller

This one sounds really fun! It sounds like I'm going to learn a lot from this session and hopefully bring back some new tools to use.

Laniard schmaniard! Spruce Up Your Existing Website With HTML5, CSS3, and Responsive Design

Wolf Loescher, Bertine Buchan

Responsive design is so hot right now. I know enough about it, and have worked on a few responsive sites, but I can always learn more. This session

A Look Into How Parameters Are Passed In JavaScript

I recently came across a question on StackOverflow about how JavaScript handles parameters, if they are passed by value or by reference. There seemed to be a lot of confusion and misinformation about what is actually happening behind the scenes.

TLDR; All arguments are passed by value in JavaScript, however, when dealing with non-primitive datatypes like objects and arrays a variable is created that points to the location of the object memory that is then is passed into the function. This means that changes to the variable inside the function will affect the original object's values. Once the argument is reassigned (e.g. arg = {} ) the variable now has the location of the new object in it so the original variable is no longer changed when the value changes.

By Reference vs. By Value

Let's start be defining exactly what by passing a variable reference and by value actually means.

By Reference

If a parameter is being passed into a function by reference it means that only a reference to the variable is being passed into the function is passed as the argument. The variable in the function and the variable that is passed into the function are actually pointing to the same location in memory. Put simply, if the value is modified inside the function the original value is also changed.

By Value

If a value is being passed into a function by value it means that a copy of the variable is being passed into the function. The variable in the function and the variable that is passed into the function are two separate variables. Put simply, if the value is modified inside a function the original value will remain unchanged.

By The Book

According to MDN:

The parameters of a function call are the function's arguments. Arguments are passed to functions by value. If the function changes the value of an argument, this change is not reflected globally or in the calling function. However, object references are values, too, and they are special: if the function changes the referred object's properties, that change is visible outside the function.

Huh?

Let me try to describe this with pictures. First let's create a variable that is a simple object literal:

var obj = { foo : 'foo' };

When we do this the variable obj is really just a reference to a location in memory that holds the actual object:

If a function is invoked and obj is passed into the function as an argument that reference is copied and passed into the function. In other words, the reference is being passed by value:

doSomething( obj );

This is where things start to get interesting. The pointer to the object is passed into the function call by value. In other words, a copy of the pointer is created and passed into the function call. We now have two variables that point to the same object:

At this point if the argument is modified inside the function call the changes will be reflected on the original varialbe outside of the function call. However if the argument is reassigned inside the function the reference will no longer point to the original object and changes inside the function will no longer affect the variable outside the function call:

function doSomething( obj ){

   obj = { baz : 'baz' }; //reassigns the pointer

}

After reassignment our objects in memory look like this:

What about primitives?

At this point you might be asking yourself, what about primitive datatypes like strings and numbers? The truth is that the point is quite moot since primitives are immutable, which means they cannot be changed. When a primitive is changed a new variable is created and reassigned to the original. Since this reassignment happens every time a primitive is changed it doesn't matter, the primitive will never point to the original location in memory once its changed so you'll always end up with the same behavior as if it was being passed by value.

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.