<meta name="msapplication-TileColor" content="#FF0000" />
<meta name="msapplication-TileImage" content="/windows8-icon.png" />

The image size should be 144×144 and you’ll want to define a custom background color with the META tag above.  Tags like these are invaluable — very little HTML to add but a giant convenience to users.  Remember that the easier it is to get to your site, the more likely they will come back often!

Read the full article at: Windows 8 Pin METAs

The middle element is an INPUT and the others are your basic A element.  You can see that the INPUT element is just slightly bigger — enough that it annoys anyone with a sharp eye.  This StackOverflow post mentions a solution that includes ::-moz-focus-inner:

input::-moz-focus-inner { 
	border: 0; 
	padding: 0; 
}

This snippet helps but doesn’t completely fix the problem — the INPUT is still just a tad too big.  The Stackoverflow post mentions box-sizing but that doesn’t help.  After trying a few different solutions, I finally found one that works:

input::-moz-focus-inner { 
	border: 0; 
	padding: 0; 
	margin-top:-2px; 
	margin-bottom: -2px; 
}

Setting negative margins within the ::-moz-focus-inner brings the buttons down to correct height, and as a bonus, the text sits the proper position:

The ultimate solution is a bit vomit-inducing, and you may need to adjust the negative margins to your specific use case, but the solution works and doesn’t cause problems for other browsers!

Read the full article at: Firefox Button Height Fix

Initializing the CSS Counter

For the sake of semantics, let’s displays a series of slides using <OL> and <LI> elements for our counter example.  The first step is resetting the counter, providing the specific counter a name initializing it to 0:

ol.slides {
	counter-reset: slideNum;
}

The counter name slideNum will be used throughout the example.

Incrementing the CSS Counter

To increment the counter, use the counter-increment property and the counter name created in the first step:

ol.slides > li {
	counter-increment: slideNum;
}

Each counter-increment call continues to increment the counter.  Be aware that you must use > in your selector if you have nested lists so that your list numbering doesn’t get incremented at the wrong points.

Using the Counter Value

Counters aren’t much good if you can’t display them (just like in 1995!), so the counter() command will output the counter value when used with the content property:

ol.slides li:after {
	content: "[" counter(slideNum) "]";
}

Oddly enough, counters can also be nested by using a second argument to counter, which will act as a separater:

/* assume this HTML:

<ol class="toc">
	<li>Intro</li>
	<li>Topic
		<ol>
			<li>Subtopic</li>
			<li>Subtopic</li>
			<li>Subtopic</li>
		</ol>
	</li>
	<li>Topic
		<ol>
			<li>Subtopic</li>
			<li>Subtopic</li>
			<li>Subtopic</li>
		</ol>
	</li>
	<li>Closing</li>		
</ul>
*/

ol.toc, ol.toc ol {
	counter-reset: toc;
}
ol li {
	counter-increment: toc;
}
.toc li:before {
	content: "(Item " counters(toc, ".") ")";
}

/* visible page "output"

<ol class="toc">
	<li>(Item 1)Intro</li>
	<li>(Item 2)Topic
		<ol>
			<li>(Item 2.1)Subtopic</li>
			<li>(Item 2.2)Subtopic</li>
			<li>(Item 2.3)Subtopic</li>
		</ol>
	</li>
	<li>(Item 3)Topic
		<ol>
			<li>(Item 3.1)Subtopic</li>
			<li>(Item 3.2)Subtopic</li>
			<li>(Item 3.3)Subtopic</li>
		</ol>
	</li>
	<li>(Item 4)Closing</li>		
</ul>
*/

As you can probably tell, counters could be incredibly helpful when it comes to basic count display up to a table of contents display.

After you get over the initial giggle of the the word counter, you start to realize that they can be quite useful.  In most cases, you’ll use counters with :after and :before pseudo-elements, unless you dedicate empty elements to their contents.  I’ve seen counters used in broadcast slides, slideshows, and documentation.  Do you use counters for anything else?

Read the full article at: CSS Counters

• CSS Variables
• Nested style blocks (a la SASS, LESS, etc.)
• Macros / routines

We know we need these things but still don’t have them yet, and likely wont for years.  That got me to thinking about another problem:  the constant need to do the prefixing of properties for every browser, like this mess:

#someElement {
	-moz-animation-name: myAnimation;
	-webkit-animation-name: myAnimation;
	-ms-animation-name: myAnimation;
	animation-name: myAnimation;
}

Firefox has un-prefixed a majority of previously prefixed properties, but we still can’t get away from this mess for other browsers.  So how can we fix this in the short term, besides making browser vendors unprefix?  One idea is doing something kind of like JavaScript’s use strict;  we start our CSS file with something like this comment:

/*autoprefix*/



/* and then somewhere in the CSS file */
#someElement {
	animation-name: myAnimation;
}

If a CSS file started with this CSS comment, the browser would automatically prefix properties that required prefixing.  Since browsers know which properties need prefixing, and they only need to account for their prefix, this type of system would reduce code (and thus smaller/quicker file downloads) and, in theory, be much faster to implement.

Now this isn’t a perfect solution by any means.  It should still be standardized at some point and unfortunately some prefixed properties act differently than unprefixed.  Just a thought that I wanted to share, get some feedback on.  Let me know if you think something like this would work!

Read the full article at: CSS Idea: /*autoprefix*/

The CSS

So multiple background images on an element is something we’ve been able to do for quite a while now, simply separate them with commas:

.animate-area	{ 
	background-image: url(twitter-logo-bird.png), url(treehouseFrog.png), url(bg-clouds.png);
	background-position: 20px -90px, 30px 80px, 0px 0px;
	background-repeat: no-repeat, no-repeat, repeat-x;
}

Note that the background image that you want at the top of the stack should go first in the image list.  Animating the backgrounds requires moving the background-position, also separated by commas:

@keyframes animatedBird {
	from { background-position: 20px 20px, 30px 80px, 0 0; }
	to { background-position: 300px -90px, 30px 20px, 100% 0; }
}
		
.animate-area	{ 
	animation: animatedBird 4s linear infinite;
}

The result is three moving pieces inside one element!

Of course this isn’t an ideal case because you can’t separately change background-positions and thus you need to work with the same duration for each background image.  Multiple animations can be set on selectors with CSS, but since it’s the one property being changed, we’re just out of luck!

Read the full article at: Multiple Background CSS Animations

<!-- Traditional Dojo config -->
<script src="//ajax.googleapis.com/ajax/libs/dojo/1.8.3/dojo/dojo.js"
               data-dojo-config="async: true"></script>

<!-- Sample Prism config -->
<script src="prism.js" data-default-language="markup" data-manual></script>

So how are these projects getting the correct SCRIPT tag with which to look for attributes?  Assuming a top-down (not async) load of scripts, the following will get a script its own tag:

/* From in side the script.... */

// Reliably grab my script tag
var script = document.getElementsByTagName("script");
script = script[script.length - 1];

// Check for an attribute/config
if(script.hasAttribute('data-something')) {
	// Do something!
}

Collect the SCRIPT elements up to that point and reference the last one — that’s all you need to do.  Of course we’re living in a mostly async world right now, so to accommodate for those cases, you may need to stick an ID on the SCRIPT element, take a chance matching the SCRIPT by path (a really bad idea), or use a different type of configuration system.

Read the full article at: Referencing a Script’s Own Tag

Working Setup

The working process starts with each developer cloning Mozilla’s kuma repository.  The kuma repository includes developer instructions for getting setup with vagrant (recommended) or without.  Kuma is a Python/Django app with a MySQL database backend.  The kuma repository doesn’t include all of MDN’s documentation but that can be provided to developers who ask for it.  The MDN team resides in the #mdn IRC room for questions and planning.  Filed bugs for MDN can be found on Bugzilla.  This information is all you need to know to get started.

Working on Bugs/Enhancements

Let’s say you’re set up and it’s time to work on a bug or enhancement.  The first step is to create a separate feature branch for working on the bug:

# Ensure we're on master
git checkout master

# Create and check out feature branch
git checkout -b bug-title-123456

Putting the bug number in the branch name is especially useful if there are long periods between working on the bug.  With the branch created and checked out, make your updates, additions, and removals.  It’s also important to run tests as you work on the bug.

Submitting Pull Requests

Before submitting a pull request, it’s important to squash commits and rebase on master branch:

# Ensure master is up to date with Mozilla's remote
git checkout master
git pull mozilla master

# Go back to feature branch, squash commits
git checkout bug-title-123456
git merge master
git rebase -i master
git push origin bug-123456

(Note:  I’m not a git legend so there’s a good possibility I’m taking the long route to accomplish this task — if so, let me know)

The code above turns all commits into one commit, so it’s easier to back out if necessary.  We also start commit messages with “fix bug {bug number}” — this allows out post-merge hook to automatically RESOLVED:FIXED the bug in Bugzilla.  If all looks good, submit the pull request via GitHub.

PR and Code Review

Upon submission of the pull request, the code is automatically run through Mozilla’s Jenkins test suite.  If the tests pass, the pull request is technically able to be merged.  At this point, however, a different member or members of the team review the submitted code, making comments on possible improvements or problems that may be come up along the way.  If the submitter needs to make more changes, they should make their commits, squash and rebase again, and push:

git push -f

So that’s the MDN team’s process for managing code on GitHub.  It all seems pretty standard and straight-forward but let me know if you have suggestions or questions.  I like the way things work and the rest of the team seems to as well!

Read the full article at: GitHub and Mozilla Work Process

When little Jackson London Walsh was born, I pondered whether we should give him his own Facebook account or simply have my wife and I post to our personal accounts.  We decided to get Jack his own account because:

1. we want to be able to have photos all go to the same account
2. we want all of his stuff to be private
3. we didn’t want to add a bunch of noise to our private accounts for those heartless bastards who don’t care about seeing baby photos all the time
4. we hope to hand the account over to him one day

Facebook is now baked into iOS’ settings but iOS presently only allows for one Facebook account to be stored.  This initially presented a problem, as we had hoped to quickly take photos and upload to Facebook.  I did, however, find a method to manage multiple Facebook accounts within the app itself.

The key is opening the Facebook app and swiping to the main menu on the left.  Scroll down to the bottom and there’s a “Log Out” item.

Tap that, confirm, and you’ll be presented with a screen that has a “Continue” button (to log in as the Facebook account tied to your iOS install) an a “(Not You?)” link;  tap that.

You can then sign in with a different email address and password:

What a relief that signing in with multiple accounts is possible.  Now we get to post photos of our little prince whenever we’d like!

Read the full article at: Multiple Facebook Accounts on iOS

# Prepend the file
php_value auto_prepend_file "/dir/path/utilities.php"

# Append file to bottom of page
php_value auto_append_file "/dir/path/templates/footer.php"

Now don’t mistake this post as me telling you to use this strategy;  using this functionality creates a layer of indirection that could confuse a team of developers if they don’t all have a grasp of where automatically included files are coming from.  Just wanted to let you know this was possible!

Read the full article at: Prepend and Append Files with .htaccess

If you didn’t already know, I’m a massive fan of Kyle Simpson, also known as @getify.  He’s one of those JavaScript legends you don’t hear nearly enough about.  He’s a pioneer of JavaScript loaders and all around JavaScript badass.  He recently did a series of guest posts for me, centered around JavaScript objects, prototypes, and inheritance:

• Part 1: JS Objects: Inherited a Mess
• Part 2: JS Objects: Distractions
• Part 3: JS Objects: De”construct”ion

His posts got loads of attention, feedback, and praise, and that can be nailed down to one reason:  Kyle knows his shit.  Like…he’s really, really good.  Like…if he were a doctor, he could do that can’t-breathe-poke-a-hole-in-their-neck-with-a-hollow-pen-casing thing. Anyways, Kyle has started a You Don’t Know JS Kickstarter project in which he’ll create a series of awesome JavaScript books.  Let him explain:

“You Don’t Know JS” is an exploration of the mysterious, confusing, complex, and controversial parts of JavaScript.

If you write JavaScript for your primary job, odds are, you’re pretty good at it. But honestly, how well do you really know the language? Most of us, myself included, spend years writing JS and never really going beyond a surface understanding. And then we blame our WTF moments on “the bad parts”.

This book series will examine the things that trip up or confound even the most seasoned of JS devs. And I was one of them until (recently) I spent enough time poking at the tough parts to understand them. Now I want to help others see the light, too.

What if you could really deeply know how JS works? Would that change how you view the language? I think so. Really, I do. A big part of why I love JS is that I finally “get it”.

If you liked his awesome JS Objects posts, consider backing his Kickstarter.  You’re guaranteed to learn a lot and every bit helps toward making his books a reality!

Read the full article at: Kickstart Kyle Simpson

var ಠ_ಠ = false;

if(someVar === ಠ_ಠ) { // If someVar is false...
	// ...
}

Hilarious.  The evil eyes signal a negative result.  What about saving a few byes on true?  The Beatles once said that “All You Need is Love”, so let’s use a heart:

var ❤ = true;

if(someVar === ❤) {
	// ...
}

You can do the same with function names.  Functions can be named after unicode symbols:

function ಠ(arg) {
	// ...
}

Of course all of this is a bit … insane, and you should never use unicode symbols, but nonetheless it’s possible.  Imagine starting a new job and seeing those symbols as meaningful variables — you’d quit immediately!  Hilarious!

Read the full article at: Unicode JavaScript Variables and Functions

Step 1:  App Manifest

The manifest.webapp file is arguably the only real step you need to turn your website into a Firefox OS app.  This manifest should be placed at domain root level:

{
	"version": "0.1",
	"name": "Your App",
	"description": "Your new awesome Open Web App",
	"launch_path": "/index.html",
	"appcache_path": "/offline.appcache",
	"icons": {
		"16": "/img/icons/appicon-16.png",
		"48": "/img/icons/appicon-48.png",
		"128": "/img/icons/appicon-128.png"
	},
	"developer": {
		"name": "Your Name",
		"url": "http://yourawesomeapp.com"
	},
	"installs_allowed_from": ["*"],
	"locales": {
		"es": {
			"description": "Su nueva aplicación impresionante Open Web",
			"developer": {
				"url": "http://yourawesomeapp.com"
			}
		},
		"it": {
			"description": "Il vostro nuovo fantastico Open Web App",
			"developer": {
				"url": "http://yourawesomeapp.com"
			}
		}
	},
	"default_locale": "en",
	"permissions": {
		"systemXHR": {}
	}
}

And make sure to pronounce it properly within your .htaccess file:

AddType application/x-web-app-manifest+json .manifest

This manifest serves as the real app glue — add this manifest and your app is mostly complete.

Step 2:  Offline Cache

The ignorant press has sometimes laughed at Firefox OS because they believe Firefox OS apps need a connection to properly function — not so.  The (admittedly ugly) offline cache API works beautifully on Firefox OS.  Add the following to your HTML:

<html manifest="offline.appcache">

With the pointer in place, you can create your offline.appcache with the list of files to download:

CACHE MANIFEST
# v0.1
/index.html
/css/app.css
/css/install-button.css
/img/offline.png
/img/online.png
/img/glyphicons-halflings-white.png
/img/glyphicons-halflings.png
/img/gradient.png
/js/app.js
/js/init.js
/js/install-button.js
/js/lib/install.js
/js/lib/require.js
/js/lib/zepto.js

Allowing app files to download to the device allow portions of the app to work even when the device is not connected to the internet.

Step 3:  Submit to Marketplace

As Paris Hilton can attest to, overexposure is 90% of success.  Submitting an app to the Firefox Marketplace showcases the app to millions of users around the world!

Stop the clock — that’s all you need to do to make your web application a Firefox OS mobile app.  There’s a Twitter account, “Always Bet on JS”, that makes me think “Always Bet on the Web.”  During every talk I give, I ask attendees “If it works in the device’s browser, why shouldn’t it be a first class app?”  No one is able to tell me otherwise…and they’re right.  We’ve built careers and billion dollar websites for thing long, and they work so incredibly well, why should that change now?  Mobile is a place to extend the traditional model  and Firefox OS makes that easier than ever before!

Read the full article at: Turn Your Web Application into a Firefox OS App in 5 Minutes

The CSS

We’ll use CSS animations instead of transitions for this effect:

@keyframes animatedBackground {
	from { background-position: 0 0; }
	to { background-position: 100% 0; }
}

With the animation code in place, now it’s time to apply it to an element with a background image:

#animate-area	{ 
	width: 560px; 
	height: 400px; 
	background-image: url(bg-clouds.png);
	background-position: 0px 0px;
	background-repeat: repeat-x;

	animation: animatedBackground 40s linear infinite;
}

The cloud background image within the sample element will elegantly scroll from left to right over a duration of 40 seconds, seamlessly repeating an infinite number of times.

How epic is it that we don’t need to use JavaScript to manage these animations anymore?  Of course the mess of vendor prefixes to accomplish the animation sucks, but at least the animations are much more efficient and more easily configurable!

Read the full article at: CSS Background Animations

The HTML and CSS

There’s only one way to add a classname with HTML so you’ll do it that way, of course:

<-- place this within the document head -->
<meta charset="UTF-8" />

<-- error message -->
<div class="ಠ_ಠ">You do not have access to this page.</div>

<-- success message -->
<div class="❤">Your changes have been saved successfully!</div>

…and there’s only one way to declare styles for a given class:

.ಠ_ಠ {
	border: 1px solid #f00;
	background: pink;
}

.❤ {
	background: lightgreen;
	border: 1px solid green;
}

Wild that you can use unicode classnames for elements, right?  Of course I don’t recommend doing so, but you can if you’d like to!

Read the full article at: Unicode CSS Classes

There are quite a few tech video tutorial websites on the internet but Treehouse is the web’s best.  Of course it’s easy to make that claim but here are some of the numerous reasons why that can only be true.

Trying Treehouse is FREE

Treehouse’s sponsorship of this site provides developers a free month of Treehouse.  A free month with access to all that Treehouse has to offer:  video tutorials, quizzes, code challenges, and more.  There’s no real reason not to try Treehouse — give it a shot!

Expansive Topic Library

Treehouse doesn’t specialize in one or two topics;  Treehouse offers courses in HTML, CSS, jQuery, JavaScript, Ruby, Ruby on Rails, WordPress, PHP, Business, iOS, and Android.  These topics cover servers side, client side, and mobile.  In essence, Treehouse provides a complete development stack experience so the barrier of entry is as low as possible.  You don’t even need to be a Developer to sign up — start from scratch and become a Developer!

Quality Picture

The quality of Treehouse videos is outstanding.  No pixelated capture and no wonky feeds — Treehouse videos are shot in glorious HD.  Even code samples presented within videos are crystal clear.  Essentially there is no detail missed regardless of current video focus.  Consistency in quality is what Treehouse provides.

Relatable, Expert Instructors

Treehouse’s instructors and presenters aren’t simply actors or relics from programming past — they’re knowledgable, engaging hosts that present with the enthusiasm that every developer has.  That simple difference in host keeps you learning.  Even when I’m focused on developing, I’ll play a Treehouse video in the background to catch a few tips on whichever language I choose.

Interactive Quizzes and Code Challenges

It’s easy to read a tutorial or watch an instructional video and say “Yeah, I got it.”  But until you get put into the position to need to know it, you can’t say you know it.  Treehouse provides loads of interactive quizzes and code challenges to help you remember aspects of a given language, or simply jog your memory about important concepts.  That reinforcement will come in handy even when you already have a job and good knowledge of a topic.

Job Search Assistance

Many sites provide the basic tech training but don’t tell you where to go afterward.  Treehouse bucks that trend, providing job placement assistance after you’ve completed a given program.  You aren’t simply left looking in the rearview to see Treehouse waving — Treehouse helps you get to your desired destination.  What a comfort it is to not be seen off, but rather helped to your dream job.

There’s no tech video tutorial service quite like Treehouse.  Treehouse truly takes you from your first day learning a new technology to helping you land that dream job you’ve been working so hard for.  Give Treehouse a try — it’s free to start, cheaper and more convenient than college, and its expansive library will teach you just about everything you need to know.  You really can’t lose with Treehouse — go for it!

Read the full article at: 6 Reasons to Go Treehouse

JS Objects: TL;DR

JavaScript has been plagued since the beginning with misunderstanding and awkwardness around its “prototypal inheritance” system, mostly due to the fact that “inheritance” isn’t how JS works at all, and trying to do that only leads to gotchas and confusions that we have to pave over with user-land helper libs. Instead, embracing that JS has “behavior delegation” (merely delegation links between objects) fits naturally with how JS syntax works, which creates more sensible code without the need of helpers.

When you set aside distractions like mixins, polymorphism, composition, classes, constructors, and instances, and only focus on the objects that link to each other, you gain a powerful tool in behavior delegation that is easier to write, reason about, explain, and code-maintain. Simpler is better. JS is “objects-only” (OO). Leave the classes to those other languages!

Due Thanks

I’d like to thank the following amazing devs for their generous time in feedback/tech review of this article series: David Bruant, Hugh Wood, Mark Trostler, and Mark McDonnell. I am also honored that David Walsh wanted to publish these articles on his fantastic blog.

Complete Series

• Part 1: JS Objects: Inherited a Mess
• Part 2: JS Objects: Distractions
• Part 3: JS Objects: De”construct”ion

In part 1 of this article series (which you should totally go read if you haven’t yet!), I revisited an idea not original to me: JS doesn’t have “inheritance” in the traditional sense, and what it does have is more appropriately labeled “behavior delegation” — the ability of one object to delegate a method or property access which it cannot handle over to another object which can handle it.

Then, in part 2, I addressed several distractions which I think obfuscate JS’s true object-oriented identity, including “custom types”, “mixins”, “polymorphism” (which we’ll come back to again later), and even the new “class syntax” coming in ES6. I suggested that to understand (and leverage) better the [[Prototype]], we needed to strip away the cruft. Here, I will attempt to do that.

Turtles Objects all the way down up

The key realization, the punchline to this entire article series, is that [[Prototype]] is really only about linking one object to another object, for the purposes of delegating, if the first object cannot handle a property or method access but the second can. In other words, it’s only objects, linked to other objects. That’s really all JS has.

In a sense, JS is the purest essence of a “object-oriented (OO)” language, in that it really is all about objects. In contrast to most other languages, JS is somewhat unique that you can actually create objects directly without the notion of classes or other abstractions. That’s a powerful and brilliant feature!

People often bash JavaScript, but it’s one of the few prog languages that let you directly create objects. Others: Lua, Dylan, Cecil.

— Axel Rauschmayer (@rauschma) April 9, 2013

JavaScript legitimately is ”object-oriented”, and perhaps we shouldn’t have used that term for the other languages which imply a lot more than just ”objects”. Maybe “class-oriented” would have been more accurate, which would have freed us up to use “object-oriented” for JS. Of course, as I argued in part 1, what everybody means when they use some term, matters, so it’s far too late to redefine or bend the commonly accepted “object-oriented” to my own purposes, much as I’d like to.

I’m mildly tempted, however, to just hijack the abbreviation of “OO” to mean “objects-only” instead of “object-oriented”, but I bet that probably wouldn’t get anywhere, either. So, for our purposes here, let’s just sayJavaScript is “object-based (OB)” to clarify against “object-oriented (OO)”.

Whatever we call it, we normally tap into this object mechanism by following the “OO way”: we create a function which we use as a “constructor”, and we call that function with new so that we can “instantiate” our “class”, which we specify with the constructor function together with its subsequent .prototype additions… but all that is like a magician’s sleight of hand that dazzles you over here to distract you from what’s really going on over there.

What really matters, at the end of the trick, is that two objects end up linked to each other via the[[Prototype]] chain.

Codez Plz

Before we can derive and understand that simpler view of “objects-only” or “object-based”, we need to understand what actually gets created and linked when we build up some “inherited” objects in JavaScript. Not only are we going to see what happens by default, but what doesn’t happen.

Take this code for our main example:

function Foo(who) {
    this.me = who;
}

Foo.prototype.identify = function() {
    return "I am " + this.me;
};

function Bar(who) {
    Foo.call(this,who);
}

Bar.prototype = Object.create(Foo.prototype);
// NOTE: .constructor is borked here, need to fix

Bar.prototype.speak = function() {
    alert("Hello, " + this.identify() + ".");
};

var b1 = new Bar("b1");
var b2 = new Bar("b2");

b1.speak(); // alerts: "Hello, I am b1."
b2.speak(); // alerts: "Hello, I am b2."

Note: Some people write Bar.prototype = Object.create(Foo.prototype); as Bar.prototype = new Foo();. Both approaches end up with the same linked objects, where Bar.prototype is an object linked via its[[Prototype]] to Foo.prototype. The only real difference is whether or not the Foo function is called during the creation of Bar.prototype. Depending on your circumstances and intent, you may or may not want that to happen, so let’s consider them roughly interchangable but with different purposes.

What we have is an object labeled Foo.prototype with an identify() method, and another object calledBar.prototype with a speak() method. Bar.prototype is a new empty object that is [[Prototype]]-linked to Foo.prototype. Then we have two objects b1 and b2, who each are each respectively linked via their own [[Prototype]] to Bar.prototype. b1 and b2 also have an “owned property” directly on each of them called me, which respectively holds the values “b1″ and “b2″.

Let’s take a visual look at the relationships implied by the above code snippet:

Note: All the [[Prototype]] links in the diagram also mention a “.__proto__” property. __proto__ is a formerly non-standard property (which exists in most but not all JS environments) to expose the internal [[Prototype]]chain. As of ES6, however, it will be standardized.

I left a whole bunch of detail out of that diagram, intentionally, so it was even remotely digestable. But of course, since JS is all objects, all the linkages and ancestry of each item can be fully traced. We’ll come back to all the omitted parts of this diagram in a little bit.

Note in this diagram that the function constructors all have a .prototype property pointing at an object. As we’ve been suggesting, the object is what we really care about, and in this way of viewing the JS object mechanism, the way we get that object is to look at a constructor function’s .prototype. The function doesn’t really serve any particularly important role.

I know a whole bunch of you just screamed out, “sure it does! it runs constructor code to initialize the new object!” OK, you’re technically right. Foo() has some code in it which is ultimately run against b1 and b2.

But the devil’s always in the details. First, we don’t need a constructor function to run such code. That’s just one way of getting that outcome. And I’m going to suggest it’s a more distracting approach.

Secondly, unlike C++, the base-class/superclass Foo() ”constructor” doesn’t automatically get called when you run the child-class Bar() ”constructor” to make b1 and b2. So, like Java, we have to manually call theFoo() function from Bar(), but unlike Java, we have to do so with a variation of the explicit “mixin” pattern (I’d probably call it “implicit mixin” here) to make it work like we expect. That’s an ugly detail that is very easy to forget or get wrong.

So, where you’d probably argue with me that “constructor” functions are useful being automatically called at the construction of an object, I’d point out that this is true for only the immediate level, not for the entire “chain of inheritance”, which means that automatic behavior is pretty limited/shallow in utility.

Polymorphism redux

Moreover, we see here the first hint of the problems with relative polymorphism in JS: you can’t do it! I can’t tellBar() to automatically and relatively call his ancestor constructor(s), via a relative reference. I have to manually call (aka, “borrow”) the Foo() function (it’s not a constructor here, just a normal function call!) from inside ofBar(), and to make sure the this is bound correctly, I have to do the slightly more awkward .call(this)style of code. Ugh.

What may not be obvious until you go back and look closer at the diagram above is that the Foo() function isnot related in any useful/practical way to the Bar() function. The Foo() function does not even appear in the “inheritance” (aka “delegation”) chain of Bar.prototype object. The fact that there are some lines you can follow on the graph for indirect relationships doesn’t mean that those relationships are what you’d want to rely on in your code.

The problem with polymorphism we’re seeing here is not only for “constructor” functions. Any function at one level of the [[Prototype]] chain that wants to call up to an ancestor with the same name must do so via this manual implicit mixin approach just like we did inside of Bar() above. We have no effective way of making relative references up the chain.

Importantly, this means that not only do we establish the link between Bar and Foo once at “class” definition, but every single polymorphic reference also has to be hardcoded with the direct relationship. This significantly decreases the flexibility and maintainability of your code. As soon as you make a function hard-coded with implicit mixin to an “ancestor”, now your function can’t be “borrowed” as easily by other objects without those possible unintended side effects.

OK, so let’s say you agree with me at this point that polymoprhism in JS is more trouble than it’s worth. Using constructor-based coding to wire JS objects to each other forces you into the problems of polymorphism.

.constructor

Another detail that’s easy to miss is that an object’s .constructor property really doesn’t behave like we’d probably expect. It’s correct at the Foo() level of the graph, but below that, at Bar() and b1 / b2, notice that the implied linkage there shows .constructor references, strangely, still pointing at Foo.

Actually, what this means is that the only time a .constructor property is added to an object is when that object is the default .prototype attached to a declared function, as is the case of Foo(). When objects are created via new Fn() or Object.create(..) calls, those objects don’t get a .constructor added to them.

Let me say that again: an object created by a constructor doesn’t actually get a .constructor property to point to which constructor it was created by. This is an extremely common misconception.

So if you reference b1.constructor for instance, then you’re actually going to delegate up the chain a few links, to Foo.prototype. Of course, Foo.prototype has a .constructor property and it’s pointing at Foo like you’d expect.

What’s that mean? In the above snippet, right after you perform Bar.prototype = Object.create(Foo) (or even if you’d done Bar.prototype = new Foo()), if you plan to rely on the .constructor property (which many do), you need to perform an extra step, right where I put the JS “Note:” comment:

//...
Bar.prototype = Object.create(Foo.prototype);
Bar.prototype.constructor = Bar; // <-- add this line!
//...

Then b1.constructor references will delegate to that Bar.prototype level, and will “correctly” point at Bar()as you’d probably have expected. Ugh…**more syntax gotchas** that user-land libs always have to “fix” for us.

Furthermore, the fact that Foo.prototype has a .constructor property pointing at Foo is strange, when you think about “constructor” the way most people do. It’s nice that it gives objects created by new Foo() a way to delegate to a .constructor property access and find Foo(), but it’s bizarre where .constructor actually lives.

It implies that Foo() constructed Foo.prototype, but that’s nonsense. Foo() had nothing to do with creating the default Foo.prototype. Foo.prototype defaults to an empty object that was actually constructed by the built-in Object() constructor.

So we have to change how we think of what the .constructor property means. It does not mean “the constructor this object was created by”. It actually means “the constructor which creates any objects that end up getting [[Prototype]] linked to this object.” Subtle but super important difference to get straight.

Point? These confusions only happen/matter if you’re using constructor-style code, so it’s the choice of this style of code that opts you into the problems. You don’t have to live with that pain. There’s a better, simpler way!

The Whole Pie

Now let’s look at everything that’s actually implied by the above snippet of code. Ready for the whole messy thing?

Take a few minutes to just take all that in. Why show you such a complex diagram?

This diagram actually shows you where some of JavaScript’s functionality comes from, where before you might have just never considered how it all worked. For instance, have you wondered how all functions are able to use behavior such as call(), apply(), bind(), etc? You may have assumed each function has that behavior built-in, but as you can see from this diagram, functions delegate up their [[Prototype]] chain to handle those behaviors.

While the behavior delegation part is sensible and useful, consider all the implied complexity of constructor-style coding as visualized here. It’s pretty tough to trace all the different entities and diagrams and make much sense of it all. A lot of that complexity comes from the function constructors. (here’s the same complete graph but with the implied relationship lines omitted, if that helps to digest)

If you take that diagram, and remove all the functions and any associated arrows (which we’ll see in just a moment), you’re left with “objects-only”, and you’ll have a much more simplified view of the JS objects world.

Simpler: Object -> Object

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. –Antoine de Saint-Exupery

For refresher, the same prototype-style code from above:

function Foo(who) {
    this.me = who;
}

Foo.prototype.identify = function() {
    return "I am " + this.me;
};

function Bar(who) {
    Foo.call(this,who);
}

Bar.prototype = Object.create(Foo.prototype);
// NOTE: .constructor is borked here, need to fix

Bar.prototype.speak = function() {
    alert("Hello, " + this.identify() + ".");
};

var b1 = new Bar("b1");
var b2 = new Bar("b2");

b1.speak(); // alerts: "Hello, I am b1."
b2.speak(); // alerts: "Hello, I am b2."

Now, let’s instead consider this alternative snippet of code, which accomplishes exactly the same, but it does so without any of the confusion/distraction of “constructor functions”, new, .prototype, etc. It just creates several objects and links them together.

var Foo = {
    init: function(who) {
        this.me = who;
    },
    identify: function() {
        return "I am " + this.me;
    }
};

var Bar = Object.create(Foo);

Bar.speak = function() {
    alert("Hello, " + this.identify() + ".");
};

var b1 = Object.create(Bar);
b1.init("b1");
var b2 = Object.create(Bar);
b2.init("b2");

b1.speak(); // alerts: "Hello, I am b1."
b2.speak(); // alerts: "Hello, I am b2."

Let’s try to take some comparison looks between this snippet and the previous one. They both accomplish the same thing, but there’s some important differences in how we get there.

First of all, Bar and Foo are now just objects, they’re not functions or constructors anymore. I left them as capital letters just for the symmetry and because some people feel better with them. They make it clear that the objects being linked are what we cared about all along, so instead of the indirectness of linking Bar.prototype toFoo.prototype, we just make Foo and Bar objects themselves and link them. AND, we only need one line of code to link them, instead of the extra ugly polymorphic linkage. Bam!

Instead of calling function constructors like new Bar(..), we use Object.create(..), which is an ES5 helper that allows us to create a new object and optionally provide another object to [[Prototype]] link it to. We get the same outcome (object creation and linkage) as a constructor call, but without needing the constructor. BTW, there’s a simple non-ES5 polyfill for Object.create(..), so you can safely use this style of code in all browsers without concern.

Secondly, notice that because we’re not worried about constructors anymore, we have eliminated any concerns about awkward polymorphisms forcing us to do manual implied mixins to call Foo() from Bar(). Instead, we put the code we wanted to run to initialize our objects into a init() method, on Foo, and we can now callb1.init(..) directly via the delegation chain and it “magically” just works like we want.

So, we have a tradeoff here. We don’t get automatic constructor calls, which means we create the object likevar b1 = Object.create(Bar) and then we have to additionally call b1.init("b1"). That’s “more code”.

But the benefits we get, which I think are much better and well worth it, are no awkwardness with the linkage between Foo and Bar – instead we leverage [[Prototype]] delegation to get at the code reuse ininit(). Also, no more verbose/repetitive .prototype references, and neither do we need to use.call(this) nearly as often (especially if we avoid polymorphism!).

Looks are everything

And to visualize the simplicity this approach brings us, here’s the diagram when we remove the functions entirely and focus only on the objects:

I don’t know about you, but I just think that mental model is so much cleaner, and the bonus is that its semantics perfectly match the code.

I have shown you simple enough code using only core JS syntax, that I don’t need any helper libraries to wire up my objects. Of course, I could use one, but why? Simpler is better. KISS.

Any fool can make something complicated. It takes a genius to make it simple. –Woody Guthrie

For the record, I’m not even remotely the genius here. Brendan Eich, creator of our language, was the genius for making something so powerful yet so simple.

Object self-reflection

Last thing to address: how does this simplification affect the process of reflecting on an object? In other words, can we inspect an object and find out about its relationships to other objects?

For prototype-style code, reflection looks like this:

b1 instanceof Bar; // true
b2 instanceof Bar; // true
b1 instanceof Foo; // true
b2 instanceof Foo; // true
Bar.prototype instanceof Foo; // true
Object.getPrototypeOf(b1) === Bar.prototype; // true
Object.getPrototypeOf(b2) === Bar.prototype; // true
Object.getPrototypeOf(Bar.prototype) === Foo.prototype; // true

Notice that you’re using instanceof and having to think in terms of the constructor functions that made your objects, and their .prototypes, rather than just reflecting on the objects themselves. Each of those reflections comes with slightly more mental tax as a result.

And when there’s only objects?

Bar.isPrototypeOf(b1); // true
Bar.isPrototypeOf(b2); // true
Foo.isPrototypeOf(b1); // true
Foo.isPrototypeOf(b2); // true
Foo.isPrototypeOf(Bar); // true
Object.getPrototypeOf(b1) === Bar; // true
Object.getPrototypeOf(b2) === Bar; // true
Object.getPrototypeOf(Bar) === Foo; // true

By contrast, reflection on objects is only about the objects. There’s no awkward references to a constructor’s.prototype property for the checks. You can just inspect if one object is related via [[Prototype]] to another object. Same capabilities as above, but with less mental tax.

Moreover, as I mentioned in part 2, this sort of explicit object reflection is preferable and more robust/reliable than implicit detection through duck typing.

Object.wrapItUpAlready()

Take a deep breath! That was a lot to take in. If you’ve followed all 3 parts of the article series, I hope by now you see the bottom line: JS has objects and when we link them, we get powerful behavior delegation.

There’s just no need to pile on class-orientation on top of such a great system, because it ultimately just leads to the confusion and distraction that has kept JS’ object mechanism shrouded and covered up by all these helper libraries and misunderstandings about JS syntax.

If you stop thinking about inheritance, and instead think with the arrows headed the other way: delegation, your JS code will be simpler. Remember: it’s just objects linked to objects!

Read the full article at: JS Objects: De”construct”ion

JS Objects: TL;DR

JavaScript has been plagued since the beginning with misunderstanding and awkwardness around its “prototypal inheritance” system, mostly due to the fact that “inheritance” isn’t how JS works at all, and trying to do that only leads to gotchas and confusions that we have to pave over with user-land helper libs. Instead, embracing that JS has “behavior delegation” (merely delegation links between objects) fits naturally with how JS syntax works, which creates more sensible code without the need of helpers.

When you set aside distractions like mixins, polymorphism, composition, classes, constructors, and instances, and only focus on the objects that link to each other, you gain a powerful tool in behavior delegation that is easier to write, reason about, explain, and code-maintain. Simpler is better. JS is “objects-only” (OO). Leave the classes to those other languages!

Due Thanks

I’d like to thank the following amazing devs for their generous time in feedback/tech review of this article series: David Bruant, Hugh Wood, Mark Trostler, and Mark McDonnell. I am also honored that David Walsh wanted to publish these articles on his fantastic blog.

Complete Series

• Part 1: JS Objects: Inherited a Mess
• Part 2: JS Objects: Distractions
• Part 3: JS Objects: De”construct”ion

In part 1 of this article series, I went into great detail (aka, wordiness) about the differences between what the traditional definition of “inheritance” means and how JS’s [[Prototype]] mechanism works. We saw that JS operates oppositely to “inheritance”, being better labeled as “behavior delegation”. If you haven’t read it and you have any twinges of doubt or confusion about that statement, I’d encourage you to go read part 1 first.

Inheritance implies, to an extent, copying of behavioral definition down the chain, whereas behavior delegation implies delegating behavior up the chain. These aren’t just word semantics, but an important distinction that, when examined, can de-mystify a lot of confusing stuff around JS objects.

I’m by far not the first dev to realize this truth about JS. What differs here is in my reaction to that realization. The response usually is layering on other concepts to smoothe out the rough edges or unexpected consequences of how “prototypal inheritance” can surprise us, to try to make JS feel more like classical OO.

I think those attempts just distract us from the plain truth of how JS works.

I would rather identify the things which are merely distractions, and set them aside, and embrace only the true essence of how JS’s [[Prototype]] works. Rather than trying to make JS more “inheritance friendly”, I’d rather rip out everything that confuses me (and others) into thinking JS has “inheritance” at all.

Types

It’s often cited that in JavaScript, if you declare a function and add things to that function’s prototype, then that alone makes a definition of a custom “type”, which can be instantiated. If we were in a traditional OO language, that sort of thinking might be more appropriate, but here in JS land, it’s just one of many distractions.

You’re not really creating a new type in any real sense of that word. It’s not a new type that will be revealed by thetypeof operator, and it’s not going to affect the internal [[Class]] characteristic of a value (what would be reported by default via Object#toString()). It is true that you can do some self-reflection to check if an object is an “instance of” some function’s construction (via the instanceof operator). But importantly,foo1 instanceof Foo is just following the internal [[Prototype]] chain of your object foo1 to see if at any level of that chain it happens to find the .prototype object attached to the Foo function.

In other words, the reflection you’re doing is not about checking if the value is a specified type at all, nor is it about the function constructor. It’s only about asking if one object is in another object’s [[Prototype]] chain. The name and semantics of the instanceof operator (referring to “instances” and “constructor functions”) are layering on extra and unnecessary meaning, which only confuses you into thinking there’s anything more than simple [[Prototype]] chain checking going on.

Some developers frown on the usage of instanceof, and so an alternate form of determining the “type” of some object is called duck typing, which is basically inferring a value’s “type” by inspecting the object for one or more charateristic features, like a specific method or property.

Either way, these aren’t really “types”, they’re just approximations of types, which is one part of what makes JS’s object mechanism more complicated than other languages.

Mixins

Another distraction is trying to mimic the automatic “copying” of inheritance by using the “mixin” pattern, which essentially manually iterates through all the methods/properties on an object and makes a “copy” (techically just a reference for functions and objects) onto the target object.

I’m not saying that mixins are bad — they’re a very useful pattern. However, mixins have nothing to do with the[[Prototype]] chain or inheritance or delegation or any of that — they rely entirely on implicit assignment ofthis by having an “owning object” at the call-time of a function/method. They are, in fact, completely circumventing the [[Prototype]] chain.

Take any two independent objects, call them A and B (they don’t have to be linked via [[Prototype]] at all), and you can still mixin A‘s stuff into B. If that style of code works for your situation, use it! But just note that it has nothing to do with [[Prototype]] or inheritance. Trying to think of them as related is just a distraction.

Another related distraction is when the inevitable desire to create “multiple inheritance” comes up, because JavaScript only allows an object to be [[Prototype]] linked to one other object at a time. When we read about the lack of multiple inheritance in JavaScript, several problems come up, and various “solutions” are often proposed, but we never actually solve them, we just do more fancy hand-waiving to distract us from the difficulties that JS poses at the syntax/semantic level.

For example, you basically end up doing some form of “mixin” to get multiple different sets of properties/methods added into your object, but these techniques don’t, without elaborate and inefficient work-arounds, gracefully handle collision if two of your “ancestor” objects have the same property or method name. Only one version of the property/method is going to end up on your object, and that’s usually going to be the last one you mixed-in. There’s not really a clean way to have your object reference the different versions simultaneously.

Some people choose another distraction to resolve these problems, by using the “composition” pattern. Basically, instead of wiring your object C to both A and B, you just maintain a separate instance of each of A andB inside your C object’s properties/members. Again, this is not a bad pattern, it has plenty of goodness to it.

Parasitic Inheritance is another example of a pattern that works around this “problem” that [[Prototype]] doesn’t work like classes by simply avoiding [[Prototype]] altogether. It’s a fine pattern, but I think it’s a confusing distraction because it makes you feel like you’re doing OO when you’re not.

Whatever technique you use here, you basically end up ignoring the [[Prototype]] chain, and doing things manually, which means you’ve moved away from JavaScript’s “prototypal inheritance” mechanism altogether.

Polymorphism

One particular distraction that ends up creating some of the most awkward code patterns we deal with in JS is polymorphism, which is the practice of having the same method or property name at different levels of your “inheritance chain”, and then using super-style relative references to access ancestor versions of the same.

The problem is mechanical: JavaScript provides a this property, but importantly it is always rooted at the bottom of the [[Prototype]] chain, not whatever level of the chain the current function was found at. While it’s true that this.foobar() might end up resolving (finding) foobar() at an ancestor level of the chain, inside that call, his this will still be the original rooted this object.

Put more simply, this is not relative, but absolute to the beginning of the call stack. If JS had a super or acurrentThis (as I proposed recently), then those references would be relative to whatever the currently resolved link in the [[Prototype]] chain was, which would allow you to make a relative reference to a link “above”. But, JS does not currently have any such mechanism. And this being absolute rooted makes it an ineffective (or inefficient at best, thus impractical) solution to these relative references that polymorphism requires.

Most of the OO helper libraries try to provide a way for you to make super calls, but all of them end up having to do inefficient things under the covers to make that kind of relative call work.

class { .. }

Lastly, I think the long and hotly debated topic of class { .. } syntax that is coming to the language in ES6 represents more of the attempt to cover up what JS actually does with what people wished JS did. These sorts of distractions are not likely to make understanding JS’s actual mechanisms better. Some speculate that it will make JS more approachable from traditional OO devotees, which may be true at first, but I suspect the ultimate result is that they’ll quickly become frustrated about how it doesn’t work as they’d expect.

What’s important to understand is that the new class syntax we’re getting is not introducing radically new behavior or a more classical version of inheritance. It’s wrapping up how JS [[Prototype]] delegation currently works, in a syntax and semantics which come pre-loaded with lots of baggage understanding and expectation, which run quite contradictory to what you’ll really get with JS classes. If you currently do not understand, or don’t like, JS object “inheritance”, the class {..} syntax is pretty unlikely to satisfy you.

Yes, the syntax takes away some of the boilerplate of explicitly adding items to a “constructor” function’s.prototype object, and goodness knows we all will love not having to type the function keyword as many times. Hooray! If you already fully understand the awkward parts of JS “classes”, and you can’t wait forclass {..} to sugar up the syntax, I’m sure you’re happy, but I also think you’re probably in the minority. It’s made far too many compromises to even make it into the language to fully please a broad range of totally opposite opinions.

The underlying [[Prototype]] system isn’t changing, and almost none of the difficulties we just outlined are getting measurably any better. The only exception is the addition of the super keyword. That will be a welcome change I suppose.

Although, as a side note, the engine won’t actually bind super dynamically (at call time) to the appropriate link in the [[Prototype]] chain, but will instead bind it statically (at definition time) based on the owning object of a function reference. This is going to possibly create some weird WTF’s because the engine is going to have to create new function references on the fly as functions that use super are assigned around to different owning objects. It’s possible (unconfirmed suspicion) that it may not work in all cases as you’d expect if super were instead bound dynamically.

Simplificationizing™

We’ve just examined a variety of ways that many JS devs try to layer on extra abstractions and concepts on top of JS’s core object mechanism. I argue that this is a mistake that takes us further from the beauty of core JavaScript. Rather than adding complexity to smoothe out the rough edges, I think we need to strip things out to get to the good stuff.

In part 3, I will address exactly that, taking JS from the more complex world of classes and inheritance back to the simpler world of objects and delegation links.

Read the full article at: JS Objects: Distractions

In 2009 I caught the attention of Mozilla (or a Moz recruiter) and I was flown to Palo Alto for an interview.  Mozilla was relatively small in those days;  the offices were rented across from Google, the building was old, there were many fewer employees, and many fewer projects.  I was devastated to not get hired back then but I kept a Mozilla employee’s business card in my car to remind me, when I drove to work each day, that my goal was to represent the dinosaur and that I was on the fringe of being “good enough.”  There’s no better reminder of a goal like that then seeing the dino on the way to a job you dislike.

Three years later, in April of 2012, I was again summoned to Mozilla and I was blessed enough to make the cut.  My second week was spent in Santa Clara getting tipsy meeting with my coworkers, proposing new ideas, improving my team skills, playing beach soccer, and winning that work week’s hack contest.  When you wake up in a hotel overlooking the ocean in your second week…you know you’re doing OK.

My primary responsibility has been and continues to be the Mozilla Developer Network.  I’ve been working with legends like Luke Crouch, Les (“Is More”) Orchard, James Bennett, Eric Shepard, Ali Spivak, and numerous other quality developers and documentation gods.  I’ve worked for an incredible manager, James Socol, who has been the best manager I’ve ever worked for;  quick to get answers, honest in criticism, and never afraid (even motivated) to jump into a code review.  Even the WebDev boss, Mike Morgan, listens to my hoops smack talk.  The atmosphere and developers I’ve found myself around are unbelievable.  Inspired to do legendary things every day.

Since joining Mozilla, I’ve been able to:

• Help launch kuma, the new MDN platform
• Implement new features on MDN
• Travel to Brazil to speak about MDN and Firefox OS
• Travel to Toronto, Mountain View, and Austin to talk about Firefox OS and MDN
• Dip my hand into gaia (Firefox OS), X-Tags, Firefox Marketplace, Mozilla Hacks
• Be a test drive for the Firefox OS phone
• Make acquaintances with hundreds of incredible developers

That’s one hell of a year, man.  This first year at Mozilla has been a blast, and look forward to many more years helping to keep an open web!

Read the full article at: One Year At Mozilla

JS Objects: TL;DR

JavaScript has been plagued since the beginning with misunderstanding and awkwardness around its “prototypal inheritance” system, mostly due to the fact that “inheritance” isn’t how JS works at all, and trying to do that only leads to gotchas and confusions that we have to pave over with user-land helper libs. Instead, embracing that JS has “behavior delegation” (merely delegation links between objects) fits naturally with how JS syntax works, which creates more sensible code without the need of helpers.

When you set aside distractions like mixins, polymorphism, composition, classes, constructors, and instances, and only focus on the objects that link to each other, you gain a powerful tool in behavior delegation that is easier to write, reason about, explain, and code-maintain. Simpler is better. JS is “objects-only” (OO). Leave the classes to those other languages!

Due Thanks

I’d like to thank the following amazing devs for their generous time in feedback/tech review of this article series: David Bruant, Hugh Wood, Mark Trostler, and Mark McDonnell. I am also honored that David Walsh wanted to publish these articles on his fantastic blog.

Complete Series

• Part 1: JS Objects: Inherited a Mess
• Part 2: JS Objects: Distractions
• Part 3: JS Objects: De”construct”ion

year 2013: Haskell people are still writing monad tutorials, JavaScript people are still trying to explain inheritance.

— Vyacheslav Egorov (@mraleph) April 12, 2013

As sad a criticism on JS as that quote is, it’s quite true. (I have no perspective on Haskell or Monads, so I’m only talking about the JS and inheritance part). Of all the confusing and, depending on your biases, “bad”, parts of this JS language, the behaviors of this and the [[Prototype]] chain have remained some of the most elusive to explain and use accurately.

As a bit of background, I’ve been developing JS full time since 2007. The first major epiphany I had back then was the understanding of how closures work, and how they enable the classic module pattern. The first open-source project I wrote (early 2008) was flXHR, a cross-domain Ajax prollyfill using the standard Ajax (XHR) interface (via a hidden flash element) that relied heavily upon the module pattern.

It’s quite possibly my “ah-ha!” moment around the module pattern that satisfied me enough that I never really felt a strong need to also apply the “inheritance” pattern to my JS design.

Nevertheless, like most JS developers, I’ve read lots of blogs and books over the years that have tried (and mostly failed) to explain the appeal and mystery that is “JavaScript inheritance” (aka, “prototypal inheritance”).

But if it’s so hard to understand, and even harder to actually do correctly, the point yet eludes me. And apparently I’m not alone in that frustration.

OO in JavaScript

In traditional Object-oriented languages, the syntax of classes matches the semantics. You can express the object-oriented concepts of classes, inheritance, and polymorphism directly and explicitly using the language’s syntax. There’s no need to use some helper library to fake your way into OO-like behavior through work-arounds of other language facilities.

JavaScript on the other hand has a set of syntax that looks somewhat OO, but which behaves in frustratingly different ways (which we will cover throughout this article series). As a result, the common way that you implement OO patterns in JS is through any of a variety of user-land helper libraries which let you express the desired semantic relationships between your “objects”. The reason most JS developers use them is because the underlying JS syntax makes those semantic expressions awkward. It’s nice to just let a library handle paving over the confusing syntax hiccups.

Libraries like jQuery are useful because they hide the ugly details of dealing with cross-browser differences in JS engines. But these OO-helper libraries are different: they’re going to great lengths to hide the true nature of JavaScript’s OO mechanisms, instead masking them in a set of patterns that are more familiar to other languages.

At this point of understanding, we should really ask ourselves: is the difficulty of expressing classes and inheritance in pure JavaScript a failure of the language (one which can temporarily be solved with user librariesand ultimately solved by additions to the language like class { .. } syntax), as many devs feel, or is it something deeper? Is it indicative of a more fundamental disparity, that we’re trying to do something in JS that it’sjust not meant to do?

Not everyone drank the JS classes kool-aid, so the rest of this article series will favor a different perspective.

Blueprint

One of the most common metaphors used in traditional class/inheritance OO is that the class represents a “blueprint” for a house to be built, but once you instantiate that class, you are basically copying all the characteristics from the blueprint into the actual built house. This metaphor partially matches, to an extent, what actually happens at a language level when the code is compiled, in that it sort-of flattens the definition of a class (sans “virtual” methods) inheritance hierarchy into the instance.

Of course, a main pillar of inheritance-oriented coding is overriding and polymorphism, which allows an object toautomatically access the most descendant definition for a method, but also to use super-style relative references to access ancestor (aka “virtual”) versions of the same-named method. In those cases, the compiler maintains lookup tables for the virtual methods, but it flattens out the non-virtual parts of the class/inheritance definition. The compiler can determine a lot about what needs to be preserved and not and highly optimize the definition structure it creates in the compiled code.

For our purposes, we can think of traditional class-inheritance as basically a flattening “copy” of behavior down the chain to the instance. Here’s a diagram to illustrate the inheritance relationship between a parent/base classFoo, and child class Bar, and then instances of each, respectively named foo1, foo2, bar1, andbar2. Visually, the arrows (aka, “copying”) point from left-to-right and top-to-bottom:

What’s in a name?

Despite the borrowed implications of the common name “prototypal inheritance”, JavaScript’s mechanism works quite differently, which we’ll see in just a moment.

Both definitionally (“…characteristics transmitted from parent to offspring”) and behaviorally (as described above), “inheritance” is most closely associated with the idea of “copying” from parent to child.

When you then take “inheritance” and apply it to a mechanism which has some very different behavior, you are asking for the confusion which has plagued “JavaScript inheritance” documentation, education, and usage for nearly 2 decades.

To try to wade through this mess, let’s set aside the label “inheritance” and its implications for JS, and hopefully we can arrive at something that is both conceptually more accurate and functionally more useful.

A.B.D’s: Always Be Delegating

JavaScript’s OO-like property mechanism for objects is notated by [[Prototype]], which is the internal characteristic of any object called its prototype-chain — a special link to another object. It’s kind of like a scope mechanism, in that the [[Prototype]] linkage describes which alternate object should be referred to if you request a property or method on your object which doesn’t exist.

In other words, you’re indicating an object to delegate behavior to if that behavior isn’t defined on the object in question.

The above class-oriented Foo and Bar example, expressed in JS, relates object Bar.prototype toFoo.prototype, and then the foo1, foo2, bar1 and bar2 objects to their respective [[Prototype]]s. The arrows (not copies but live-links) point in a right-to-left, bottom-to-top fashion in JS:

“Behavior delegation” is a more accurate term to describe JavaScript’s [[Prototype]]. This is not just a matter of word semantics, it’s a fundamentally different type of functionality.

If you try to illustrate behavior delegation in terms of the “blueprint” metaphor, you quickly see how it totally breaks down. There’s no way that my home, lacking a guest bedroom, could simply refer to another house, or to the original blueprints, to provide a bedroom for my mother-in-law when she comes to visit. Though the outcomes you can achieve have some respective similarities, the concepts of “inheritance” and “behavior delegation” are quite different.

Some devs insist that “delegation” is just the dynamic version of “inheritance”, like two sides of the same coin, but I see them as orthagonal systems.

How to delegate?

We’ll revisit this later in the article series, but Object.create(..) was added to ES5 to assist with creating an object and then optionally linking its [[Prototype]] to another object. The link that is created is a delegation link, as opposed to an inheritance-by-copy.

Note: Once an object has its [[Prototype]] chain set at its creation, it should for the most part be considered set in stone and not changeable. Technically, browsers which support the __proto__ property, a public representation of the internal link, allow you to change at any time where an object is linked to. However, this practice is littered with landmines and generally frowned upon — it’s almost certainly something you’d want toavoid in your code.

Spade a Spade

You’ve seen how the mechanisms in JavaScript are comparitively different from the mechanisms in other languages. But is it ok to just hand-waive over these differences so we can keep using the term “inheritance” for JS?

The fact is, it’s just not an accurate usage of the term. By insisting that JavaScript has “inheritance”, we’re really saying that the meaning of the word “inheritance” doesn’t matter, or is rather soft.

JS doesn’t statically analyze what parts of an inheritance chain it can safely flatten out and copy, it maintains links to the entire delegation chain throughout runtime, as distinct objects, which means our code can take advantage of a variety of powerful “late binding” dynamic patterns.

If we keep trying to mimic inheritance in JavaScript (syntax hurdles be damned), we get distracted and miss out on all that power that was built into our language from the start.

I say: let’s call it what it is, and stop trying to pile on JavaScript these other concepts that the “inheritance” label implies.

So What?

So far, I’ve tried to identify some misconceptions about JS’s [[Prototype]] mechanism and how “inheritance” is not a helpful label.

You may still be skeptical why it actually matters what we call this OO-like mechanism in JS? In the next part of the article series, I’m going to address many of the trappings of traditional “class-based” programming which I think are distractions that lead us to missing out on the essence of how JS objects interoperate. In fact, we could even say that classes/inheritance are a premature optimization for JavaScript.

Clearing those distractions out of the way leads us to part 3, where we’ll see a simpler and more robust pattern for our JS code, and more importantly, our code will actually match our semantics without us having to jump through hoops to hide the ugly mismatches.

Read the full article at: JS Objects: Inherited a Mess

Signup

Crazy Egg is a paid service with plans starting at $10/month.  Since Crazy Egg is a sponsor, I can extend my visitors one free month to give it a try!

Creating Snapshots

Once signed into your Crazy Egg account, the first step is creating a snapshot.  Snapshots are a moment in time for a given page — think of snapshots as a virtual screenshot.

Upon creation of a screenshot, a small code snippet is provided to enable stat tracking for that given snapshot:

setTimeout(function(){var a=document.createElement("script");
var b=document.getElementsByTagName("script")[0];
a.src=document.location.protocol+"//dnn506yrbagrg.cloudfront.net/pages/scripts/0014/4786.js?"+Math.floor(new Date().getTime()/3600000);
a.async=true;a.type="text/javascript";b.parentNode.insertBefore(a,b)}, 1);

Add the code snippet to the footer of your site and Crazy Egg starts doing their thing!

Statistical Visualization

Once the snapshot code is in place and you let your uberpopular site rake in the visitors, you’re ready to analyze the result.  The following image shows a heatmap of my homepage for the day I published my epic CSS @supports post:

This imagery communicates to me that my demo pages are very popular (both in the menu and post list buttons), visitors search my site frequently, the “More Posts” button is incredibly popular, and PHP, HTML5, and jQuery are the most popular subjects clicked in the topic sidebar.  In knowing my goals, I can also see that the Forums and Deals pages are not as popular as I’d like, so I may try and promote them more in the future.  It’s incredible what a heatmap can show you!

Crazy Egg doesn’t just provide you heatmaps though.  Crazy Egg also provides ScrollMap, confetti, overlay, and list visualizations of visitor interaction.  If there’s another statistical visualization of web visitor data, I don’t know what it is.  Crazy Egg has given me a completely different perspective on my visitor interactions and what web developers should expect from analytics apps.  No wonder Amazon, eBay, Dell, and Zappos use Crazy Egg. The visual data that Crazy Egg provides me is easier to read and more useful than what Google Analytics provides me!

Go Crazy!

Crazy Egg is offering a free month to my visitors, so if you’re looking for a more intelligent and visual statistics system, go crazy with Crazy Egg.  Crazy Egg has changed my expectation of site analytics and very much for the better.  If you like what I’ve presented here, give Crazy Egg a try — it may change the way you view your web results.

Read the full article at: Incredible Analytics with Crazy Egg