Stampit 0.2 Released

Stampit lets you create objects from reusable, composable behaviors. Instead of pretending that JavaScript is class-based, stampit embraces the power and flexibility of prototypes (see “Three Different Kinds of Prototypal OO”). It produces object factories which you can then compose to create more factories. When it’s time to instantiate your objects, just call the function that stampit returns. Out pops an object, with all the properties, methods, and private state you composed.

But it gets even better. Now Stampit makes it even easier to compose exactly the factory you want. You can chain `.methods()` and `.state()`, and it will combine the last object you passed into them with all the previous objects you’ve passed in.

For example:

var obj = stampit().state({
  foo: {bar: 'bar'},
  stateOverride: false
}).state({
  bar: 'bar',
  stateOverride: true
}).create();

obj.foo.bar; // bar
obj.bar; // bar
obj.stateOverride; // true

Download the latest:

$ npm install stampit

You can also grab it directly from Github.

Day Against DRM – 50% Off Programming JavaScript Applications Today Only!

Buy Now!

This sale is now over.

Get 50% off of “Programming JavaScript Applications” and every other DRM-free E-Book from O’Reilly! Just apply the coupon code DRM2013 to your order!

You’re Optimizing the Wrong Things

It seems like every time somebody suggests to the JavaScript world that there’s a different (often better) way to do things than the status quo, the knee-jerk response is to say that the old way is faster, and start pulling out perf scores. That’s all well and good, but by that standard, we should all be writing everything in C. The perf differences between one technique and another in JavaScript is just one of many considerations you should weigh while you’re working. Other major factors that should not be cast asside include developer productivity, code readability, application flexibility, and extensibility. Think about the trade off before you make it.

Don’t get me wrong, it’s essential that we keep performance in mind while we’re developing web applications, but your app isn’t going to be noticeably impacted by your choice of switch…case vs method lookup, or your choice of inheritance patterns.

Maybe you’ve read Nicholas Zakas’ “High Performance JavaScript (Build Faster Web Application Interfaces)”, or Steve Sauder’s “High Performance Websites: Essential Knowledge for Front-End Engineers” and “Even Faster Websites: Performance Best Practices for Web Developers”. You know all the perf tricks. You have a good understanding of which constructs are faster than others in JavaScript. That’s a really good start. You’re doing better than most.

The bottom line is this:

Know what to optimize. If you work too hard for a 1% gain, you miss 99% of your potential.

Concentrate on the big time wasters, first.

What slows down a typical modern web application?

For typical applications, your bottlenecks will be I/O or render-bound, or sometimes memory (a lot more a couple years ago, but even mobile devices are starting to pack a lot more RAM these days). Here’s my web application performance hit-list, in order of priority:

Too many network requests

Hitting the network comes with a high cost. If you’re having performance problems, look here first, beginning with your initial page load.

Your application start-up sequence is unavoidably going to leave a strong first impression with your users. If you make them wait, they may not stick around long enough to see all the results of all your hard work, and even after they have used your app, created an account, and made a time investment, every time you make them wait, you run the risk of driving them to your competitors.

The more separate requests you have to make, the worse it gets, because each request introduces latency. Lots of tiny requests basically turn into a latency queue. Who cares how you instantiate your objects if your page never gets to finish loading before the user hits the back button or closes your app before it’s done booting? YSlow is a great resource to help you optimize page load times.

Inefficient API endpoints can force a lot of separate requests. For example, I recently created a service that delivers a few different types of loosely related data. Sometimes, you may want to fetch each different type individually. You may need one type, but not another. And then there are times that you need more than one type. It’s good to let consumers request all the data they need with one request, or limit data by querying for the specific data that they need. Whether you’re working the full stack, or working along side API specialists, make sure that the needs of the API consumers are driving feature development in the API such that you’re optimizing to trim the number and size of requests based on actual API use cases.

API payload size is also a big factor. I’ve seen a lot of APIs that send down a lot of duplicate data, because they in-line objects that are shared between a potentially large number of parent objects. If you run into that situation, consider referencing those duplicated objects by ID, instead, and sending down a separate hash that you can look them up from. Consider including both object sets in a single request. It makes the client code a little more complicated, but if your API has an SDK (which I recommend), you can smooth that over, too.

It’s harder to say what’s faster for page loads – injecting data into the initial HTML page-load, or building a configuration endpoint that you can asynchronously fetch data with. The former can hurt page caching, and the latter will introduce another request, and add latency overhead. That’s a question you’ll need to answer based on the needs of your particular application. Most of the time I inject data into the initial HTML page-load, but that doesn’t mean that’s the right choice for everyone. However, it could be easy to profile both methods and go with the one that works best for you.

Solutions

• Compile and compress scripts to deliver a single JavaScript payload. See Browserify for Node-style modules in the browser, or r.js for AMD modules, and UglifyJS for compression. You’ll find Grunt tasks to automate all of that.
• Compile and compress CSS.
• Consider a web font instead of a bunch of small image icons. Bonus – those web fonts can be styled and scaled a lot better than .png files.
• Make sure expires headers and ETags are set correctly on your servers.
• If there are parts of your app that relatively few users take advantage of in a typical session (for instance, administration consoles, settings, or user profile sections), consider splitting the assets for them into separate payloads, instead of loading them all at startup.
• Optimize API endpoints to minimize number of requests and payload size.

Page reflows

Page reflows can cause your app to feel unresponsive and flickery. This can be especially problematic on low-powered mobile devices. There are various causes of reflows, including late-loading CSS, changing CSS rules after page render, image tags without specified dimensions, render order in your JavaScript, etc…

Solutions

• Load your CSS in the head (avoid reflows as CSS gets loaded).
• Specify image tag dimensions to avoid reflows as images load in the page.
• Load (most) JavaScript at the bottom (less important with client-side rendering).
• When rendering collections in JavaScript, add items to the collection while the list DOM is detached, and attach it only after all items have been appended. The same goes for collections of sub-views if many sub-views are used to build your complete page.

Too many DOM selections

The top jQuery newbie sin: failing to cache a selection that’s being used repeatedly. Raw metal people, you’re not off the hook. This also stands for direct consumers of the DOM Selectors API, like Document.querySelector() and Document.querySelectorAll().

$('.foo').doSomething();
$('.foo').doSomethingElse();
$('.foo').whyIsThisSoSlow();

Solution

Try to minimize your DOM access. Cache your selection at the beginning, and then use that cache for further access:

var $foo = $('.foo');
$foo.doSomething();
$foo.doSomethingElse();
$foo.muchBetter();

You can also reduce your reliance on selections by separating more of your logic from your DOM interactions. Once you move from building basic websites to building full fledged applications, you should probably be using something like Backbone.js to help you keep concerns decoupled. That way, you won’t have your data collection algorithms dependent on DOM selections, and vice verse — a common issue that slows down a lot of poorly organized applications.

Too many event listeners

You’ve probably heard this a million times already, but infinite scrolling is getting really popular, so you’d better pay attention this time: Stop binding event listeners to every item in a collection. All those listeners consume resources, and are a potential source of memory leaks.

Solution

Delegate events to a parent element. DOM events bubble up, allowing elements earlier in the hierarchy to hook up event handlers.

Blocking the event loop (for the less common CPU-bound cases)

Once in a while you’ll need to do some processing, number crunching, or collection management that could take some time. JavaScript executes in a single event loop, so if you just dive into a loop, you can freeze up everything else until that processing is done. It’s particularly distressing to users when the UI stops responding to their clicks.

Node programmers should go to lengths to avoid any blocking I/O or collection processing that would happen on every connection. It can cause connection attempts to go unanswered.

Solutions

• First, make sure you’re using an efficient algorithm. Nothing speeds an application up like selecting efficient algorithms. If you’re blocking in a way that is impacting the performance of your application, take a close look at the implementation. Maybe it can be improved by selecting a different algorithm or data structure.
• Consider timeslicing. Timeslicing is the process of breaking iterations of an algorithm out of the normal flow control of the application, and deferring subsequent iterations to the subsequent loop cycles (called ticks). You can do that by using a function instead of a normal loop, and calling the function recursively using setTimeout().
• For really heavy computations, you may need to break the whole job out and let it execute in a completely separate execution context. You can do that by spawning workers. Bonus — multi-core processors will be able to execute that job on a different CPU. Be aware that spawning workers has an associated overhead. You’ll want to be sure that you’re really getting a net win with this solution. For Node servers, it can be a great idea to spawn as many workers as you have CPU cores using the cluster module.

Conclusion

First, make sure your code works, it’s readable, flexible, and extensible. Then start optimizing. Do some profiling to figure out what’s slowing you down, and tackle the major choke points first: network and I/O, reflows, DOM selections, and blocking operations.

If you’ve done all of that, and you’re still having problems, do some more extensive profiling and figure out which language features and patterns you could swap out to gain the most from your efforts. Find out what’s actually causing you pain, instead of changing whatever you happen to know (or think) is faster.

Happy profiling!

Self Invoked Anonymous Function? Sounds iffy…

<strongIIFE stands for Immediately Invoked Function Expression (Coined by Ben Alman, circa 2010). It was once widely known as a self-invoked (or self-executing) anonymous function, but that name was not accurate, because:

1. It’s not self invoked (that would be recursion), and
2. they don’t have to be anonymous.

Before we get into detail, let’s see what we’re talking about:

(function () {
  console.log('do some stuff...');
}());

The outer parens around the whole thing turn the function into a function expression (as opposed to a function declaration). There are other ways to do that, but the parens are the common convention. The () at the end of the function expression is what triggers the immediate function invocation.

This is not a self-invoked anonymous function, though many would call it that. The pattern is called an IIFE (pronounced “iffy”). It’s commonly used in the module pattern, but it’s also used relatively often to assign the result of a small, inline function to a variable. Regular old invoked-later function expressions (without the () at the end) are also commonly passed as callbacks or assigned to variables, or used inline in object literals to define methods.

What is a function expression?

An expression in computer science is a bit of code that is evaluated in order to produce a value. In the case of the function expression, evaluated does not mean invoked! Instead, the function itself is the value. JavaScript functions can be passed around just like any other value. You can assign them to variables, pass them to functions, return them from functions, and assign them to object literals or array elements. Any time you’re treating a function like a value in-line, you’re using a function expression.

setTimeout(function () {
  console.log('done');
}, 1000);

var doSomething = function () {
  console.log('done');
};

var dog = {
  bark: function () {
    console.log('woof!');
  }
};

Remember how I said they don’t have to be anonymous? The way it’s written now, dog.bark(); won’t show up properly in the call stack. It will say “Anonymous function”. Not very helpful. You can define it this way, instead:

var dog = {
  bark: function bark() {
    console.log('woof');
  }
};

Now it has a name, and it’ll appear properly in the call stack. Just make sure not to duplicate another function name that has already been defined in the same scope, or IE8 will behave badly (a bug which has been corrected in later versions of IE).

The real self-invoked anonymous function (don’t ever do this, it’s deprecated)

An example of a real self-invoked anonymous function is the inner function in this fibonacci implementation:

function fib(n) {
  return function (n,a,b) {
    return n>0 ? arguments.callee(n-1,b,a+b) : a;
  }(n,0,1);
}

The inner function calls itself from within (self-invocation / recursion), and the function is anonymous, using the deprecated arguments.callee() to call itself. I don’t recommend doing that. Instead, you can name the inner function. This version does the same job with a named function expression:

function fib(n) {
  return function iterate(n,a,b) {
    return n>0 ? iterate(n-1,b,a+b) : a;
  }(n,0,1);
}

Note, both versions are IIFEs. The first is a genuine self-invoked anonymous function, but the latter is not. When people say “self invoked anonymous function”, they’re really talking about IIFEs.

JavaScript Constructor Functions vs Factory Functions

My previous blog post, Stop Using Constructor Functions in JavaScript has been a bit controversial, so I decided to break down the benefits vs drawbacks (or pros and cons if you prefer). Since everybody is already familiar with constructors, we’ll start there.

If you need more information and examples about factory functions, click the link above. There are also a lot more examples of factory function use in the source code from my talk, Fluent JavaScript Part One: Prototypal OO. I hope this sheds more light on the subject.

What is a Constructor?

Before we go any further, it’ll probably help to review the basics of the constructor function.

They’re pretty simple:

function Foo() {
  this.bar = 'baz';
}

The call signature looks something like this:

myFoo = new Foo();

The capital letter doesn’t have any meaning to JavaScript. It’s just there to alert you that you’re calling a constructor, so you don’t forget new and break something. The special keyword, new is what matters. It sets the context of this to mean the newly created object (an instance of Foo()).

That is what this is all about. (See what I did there?)

Other than that, the constructor is just like any other function. Almost. If you return something falsy you’ll get back a new, empty instance of Foo() instead of the value you returned. However, if you return any object, including a function or array, you’ll get back whatever you returned. (Hat tip: Chris Hernandez)

The point is, you can return any arbitrary object you want, just like you can with a factory function. Try it out:

function Foo() {
  this.bar = 'baz';
  return { baz: 'bif' };
}

console.log(new Foo()); // Object {baz: "bif"}

Notice how it returns the object literal instead of `this`? Cool, huh? A constructor is just a factory function with `this` glued to the new object for your “convenience”. In other words, it’s a less flexible subset of a factory function.

The problem is, it’s not really convenient. Read on!

Benefits of using constructors

• Most books teach you to use constructors and new

• this refers to the new object

• Some people like the way var myFoo = new Foo(); reads.

Drawbacks

• Details of instantiation get leaked into the calling API (via the new requirement), so all callers are tightly coupled to the constructor implementation. If you ever need the additional flexibility of the factory, you’ll have to refactor all callers (admittedly the exceptional case, rather than the rule).

• Forgetting new is such a common bug, you should strongly consider adding a boilerplate check to ensure that the constructor is called correctly ( if (!(this instanceof Foo)) { return new Foo() } ).

• If you do the instanceof check, it leaves ambiguity as to whether or not new is required. In my opinion, it shouldn’t be. You’ve effectively short circuited the new requirement, which means you could erase drawback #1. But then you’ve just got a factory function in all but name, with additional boilerplate, a capital letter, and less flexible this context.

What is a factory?

Simple – just a regular function that returns a new object. It behaves just like any other function would:

function foo() {
  return { bar: 'baz' };
}

For more examples, check out the Prototypal OO source code mentioned already.

Benefits of using factories

• Less code – no boilerplate required.

• You can return any arbitrary object, and use any arbitrary prototype – giving you more flexibility to create various types of objects which implement the same API. For example, a media player that can create instances of both HTML5 and flash players, or an event library which can emit DOM events or web socket events.

• You’d never have a need to convert from a factory to a constructor, so refactoring will never be an issue.

• No ambiguity about using new. Don’t. (It will make this behave badly, see next point).

• this behaves as it normally would – so you can use it to access the parent object (for example, inside player.create(), this refers to player, just like any other method invocation would. call and apply also reassign this, as expected. If you store prototypes on the parent object, that can be a great way to dynamically swap out functionality, and enable very flexible polymorphism for your object instantiation.

• No ambiguity about whether or not to capitalize. Don’t. Lint tools will complain, and then you’ll be tempted to try to use new, and then you’ll undo the benefit described above.

• Some people like the way var myFoo = foo(); or var myFoo = foo.create(); reads.

Drawbacks

• new doesn’t behave as expected (see above). Solution: don’t use it.

• this doesn’t refer to the new object (instead, if the constructor is invoked with dot notation or square bracket notation, e.g. foo.bar() – this refers to foo – just like every other JavaScript method — see benefits).

Conclusion

Stop Using Constructor Functions in JavaScript

How to Conduct a Better Coding Interview

Yesterday a blog post on Geekli.st made the social media rounds. It was called “How to Crack the Toughest Coding Interviews”, by Gayle Laakmann McDowell.

It was a great post, and it will probably help you get your next programming job.

That said, if you’re conducting an interview like this, you’re doing it wrong. The whole reason that we need a post like that is because the programmer interview process is fundamentally broken at most organizations. The fact is, if you’re conducting interviews like that, you’re probably turning away a lot of great candidates. In a market that is saturated with jobs, and lacking qualified talent, that’s not something you want to be doing.

Whiteboards Suck for Coding

You’re not testing the skills that the interviewee is actually going to use on the job. If you want to see how a person architects a solution, sure, give them a whiteboard and let them diagram. That’s actually instructive. Do they know UML? Can they draw a diagram that would be useful documentation for the next developer? Is their thinking process clear and lucid? Are they good at communicating their ideas visually? Those are all good questions to answer with a whiteboard.

How a candidate codes is certainly not a good question to answer with a whiteboard. For that, you’ll need a computer. Why? Because when we code, it doesn’t come out fully formed from top to bottom. It takes shape more like a 3d sculpture. We might start by implementing some data structures. Then we’ll compose a method or two, and arrange that into a fully fledged object, and then piece objects together and wire up the object interactions. There’s a lot of copying, pasting, backspacing, deleting.

Whiteboards are great for sketching out diagrams, but they suck for moving around blocks of code and developing a clear, concise, bug free implementation. If your candidate slops out diagonally slanted dribble on a whiteboard, all you’ve proven is that a whiteboard is a terrible coding medium. We’ve all been frustrated by it at one time or another while we’re spitballing designs for new APIs, or discussing the best way to implement a tough algorithm.

“I’m going to state (what should be) the obvious: the only way to hire good programmers reliably is to program with them.” ~ Rob Mee, Founder of Pivotal Labs from “What’s Your Startup’s Bus Count? 7 Myths of Entrepreneurship and Programming” on the Tim Ferriss blog

Whiteboard programming is nothing like real programming on a real computer. Instead of thinking about code, the candidate is worried about handwriting, space remaining, how their lines are curving downward at the end, and “OMG it’s taking so long to draw each character one at a time I’m never gonna finish fast enough!” – and interviewers are actually looking at these things like they mean something interesting. News flash: They don’t.

Those are all distracting concerns that have absolutely nothing to do with how they will perform on your team. Zip. Nada. Whiteboard coding tells you jack all about the strength of a candidate as a programmer.

If you really want to see how a candidate codes, sit them in front of a computer. Have the problem description ready — perhaps written up as stories as they might see them in your project tracker. Have some unit tests pre-written and watch as the candidate makes the unit tests pass. If you have more time, ask the candidate to implement their own unit tests before they start to solve the problem. This will force them to think through the problem and be sure they really understand it, and what it means to prove that they’ve implemented a working solution.

If you have even more time, have them pair up with another employee on some real code. See how they interact, communicate, and mesh with the team. Evaluate in a real situation whether or not they’re making a productive contribution.

Ask the Right Questions for the Job Opening

While I’m ranting, here’s another pet peeve. Don’t just pull some sample interview problems or dig out your old CS text book to come up with good interview questions. Think about the role you expect the candidate to play. Is the candidate a front end developer, or will they be digging deep into big data and messing around in Hadoop?

If it’s the former, you’ll want to ask them how they manage asynchronous communication with AJAX, or how they might speed up a browser page load. If it’s the latter, make sure they know how to sift through large amounts of data efficiently without causing stack overflows, or how they can implement a data mining algorithm where the source data is scattered across a cluster of servers.

In other words, ask candidates about problem domains that they’re likely to encounter on the job.

Are you making games, or working on a mapping app? They’d better have some path finding skills. Ask them to plot the least expensive route across the country in Google Maps based on gas station prices.

Some of the best programmers in the world will have specialized for several years, and might be extremely good at coming up with great big data algorithms, or they might flat out suck at that, but really excel at managing UI architecture and orchestrating complex dances of asynchronous operations.

Ask a Stumper and Pass them for Failing Gracefully

Of course, you want to ask them a question or two that they probably won’t know the answer to, but that shouldn’t be to stump them and then reject them if they don’t know the answer — it should be to see how they think about an unfamiliar problem. Do they ask the right questions? Do they admit when they don’t know the answer? Are they likely to ask for help when they’re stumped instead of wasting hours of time on something that should be solved in minutes?

If the candidate answers your important questions well, and knows how to fail gracefully, make an offer before they leave the office! Every team could use a few more of those guys. They’re good at their job, they encourage collaboration, and they soak up new information like a sponge.

Bottom Line

Stop turning away great candidates just because they haven’t learned how to fake their way through yet another broken whiteboard interview. If they’re any good at their job, that’s not what they’ve spent their career learning how to be good at — and that’s a good thing!

Debugging Node with node-inspector

If you’re developing with node, and you’re not using node-inspector, you should start right now.

Getting started is a breeze:

$ npm install -g node-inspector

$ node --debug your/short/node/script.js

I like to start with a break on the first line.

$ node --debug-brk your/short/node/script.js

I created a short script so I don’t forget:

#!/bin/bash
node --debug-brk $1

Then run:

$ node-inspector

The output should give you a url you can hit with any webkit browser to pull up the same in-browser debugging console that you get when you’re debugging your JavaScript in webkit inspector (I use Chrome’s debugger).

Interactive stack traces with TraceGL

Tracegl – interactive stack traces. (Worth every penny)

TraceGL gives you interactive access to your full stack trace, including variable values, as the program is running. You can scroll up and down, zoom in and out, click through the callstacks, explore function bodies, and even see clearly which branches executed, and which didn’t. It has changed the way I debug JavaScript. Highly recommended.

More Node debugging resources

• Node Debugger (Built in command-line debugger)
• Debugging Production Systems (video talk)
• DTrace Your Node.js JS (slides)
• node-panic – Instrumentation for debugging your JS code
• Node Segfault Handler – For debugging native code

Thanks

mscdex

Introducing Applitude – Simple Module Management

This slideshow above was first presented at SFJS #29.

Applitude is a simple event-driven application architecture and module management framework that serves the following needs:

• Namespacing
• Sandbox
• Environment
• Loading performance boost
• Mixins
• Deferred utilities

The guiding philosophy of Applitude is “Less is more.” Applitude sets up the sandbox and then gets out of the way of your modules. Hence the subtitle, “Simple Module Management.”

Check out the Applitude homepage for documentation and examples.