Closures for Dummies (or why IIFE !== closure)
[Update: this article is bogus! I misunderstood the criteria that determines when a closure becomes a closure! To be clear: in JavaScript, every function effectively creates a closure. Nuf said. Go ahead and read the rest if you’re bored.
There are lots of blog posts and online articles about javascript closures. Many of them are well written. Closures have also been discussed at length with Brendan Eich. I really shouldn’t have to write another blog post. Yet, here I am.
Why? Because I still see many people misusing the term, “closure”. Specifically, I see people confusing IIFEs with closures.
I was going to see if I could craft a twitter-friendly 140-char explanation of the differences between IIFEs and closures. A noble cause, for sure, especially since I suspect that the reason that there’s so much confusion is that many of the explanations are either tl;dr or too technical.
140 characters may have been too ambitious. Let’s see if I can do it in 140 words or less. Starting… now. Well, not including code snippets, mmkay? OK. Starting… now.
Read more…
Javascript
AMD versus CJS. What’s the best format?
JavaScript Harmony will introduce native modules into JavaScript. Finally. And when IE9 finally dies a slow death, we’ll be able to use native modules in the browser. Yay corporate support contracts. In the mean time, there are two competing standards for modules: AMD and CJS Modules 1.1.1. Which one is better? Which one should you be using?
I’ve got an opinion and it may surprise you.
Read more…
AMD, CommonJS, Javascript
AMD Module Patterns: Singleton
This is the first in a series of posts illustrating how common design patterns can be achieved using AMD-style JavaScript modules. We’ll also look at some new patterns that are somewhat unique to AMD, including one that should be called nothing less than the “Alley oop slam dunk”!
No, no, we’re not going to talk about the “Alley oop slam dunk” first! Let’s start at the basics with the simplest of all design patterns: the Singleton.
Read more…
AMD, Design patterns, Javascript
The first annual dojoconf!
I just got back from the first ever dojoconf in Washington DC. I asked Dylan and Chris if they were planning to do it annually and I got something equivalent to “F**K YEAH!”
Good. cuz it was awesome. 
I was honored to present about AMD Module Patterns at dojoconf. My slides are here. A half hour is not nearly enough time to present on even a couple of patterns. It didn’t help that I was high on cold medication, so I think I missed half of the points I wanted to make and missed half my slides at the same time.
To rectify the situation, I will write a blog post on each pattern. My goal is to write about one pattern a day until they’re all done. Wish me luck.
— John
P.S. This was my first time representing a corporation at a conference. I have been a full-time employee at lifeIMAGE in Newton, MA since August 2010. lifeIMAGE sponsored the Hacker Lounge at dojoconf and paid for the awesome dojo minis! (Btw, we’re always hiring javascript engineers!)
AMD, dojo, Javascript
What is the fastest way to load AMD modules?
The AMD format for JavaScript modules was created to allow devs to write elegant, modular code rather than the silly global, name-spaced hackfest we’ve been writing. However, AMD has a hidden benefit: it allows modules to be downloaded in parallel, rather than sequentially. This is a potentially huge performance win.
However, does this really matter for production code?
Read more…
AMD, Javascript, performance
Modules > Frameworks
My slides from JSCONF 2011 in Portland, May 1: unscriptable.com/code/Modules-Frameworks/
Feedback appreciated!
AMD, Javascript
Using AMD loaders to write and manage modular javascript
Recently, I gave a short presentation about AMD (Asynchronous Module Definition) at the Boston JavaScript Meetup Group. Here are the slides:
unscriptable.com/code/Using-AMD-loaders/
There wasn’t enough time to talk about all of the AMD loaders in existence, and certainly not enough time to dig into the many use cases and nuances of AMD-formatted modules. However, I hope I was able to help improve awareness of AMD and javascript modules in general.
Enjoy!
[Update 2011-04-27] If you’re wondering what happened to the “manage” part of the title’s “write and manage”… it’s coming in a future presentation.
AMD, cujo.js, Javascript
curl.js – yet another AMD loader [updated]
Over the past several weeks, I’ve been writing an AMD-compatible javascript loader called curl.js. AMD stands for Asynchronous Module Definition and is a CommonJS proposed standard for writing javascript modules. The module format closely follows the proposed migration path set out by ECMA’s proposed ES-Harmony javascript modules.
curl stands for Cujo Resource Loader since it’s an integral part of the re-engineering of cujo.js.
An AMD-compatible javascript loader is (surprise, surprise) an asynchronous javascript loader that is savvy about AMD-formatted javascript modules.
[update]
Version 0.3.2 is out! fork it!
Read more…
AMD, cujo.js, i18n, Javascript, l10n, performance
OOCSS for JavaScript Pirates
A few weeks back I had the awesome opportunity to speak at the jQuery Conference in Boston. A colleague, Boaz Sender, encouraged me to propose a topic, but I couldn’t help wondering, “What could a dojo enthusiast possibly speak about at a jQuery conference?”
Speak about dojo? Uh, no way. That wouldn’t fly.
How about something about pure JavaScript? Maybe I could extract a feature of cujo.js and turn it into a jQuery plugin! … Nah, that’ll take too long. No time.
Wait! OOCSS! It’s applicable to all JavaScript development!
Read more…
CSS, jQuery, Non-programming, OOCSS
cujo.js — OOJS, OOCSS, and OOHTML — Part 1 (OOCSS for Engineers)
One of the coolest concepts in cujo.js is the introduction of Object-Oriented CSS into the Views and Widgets. I’ve seen several engineer’s eyes glaze over when I mention OOCSS, but don’t dismiss it as just a rehashed retelling of how to structure your CSS. OOCSS is a very powerful and efficient tool, especially when used in conjunction with Object-Oriented JavaScript and inheritable HTML templates.
I’d love to dive right in and show you how it all works in cujo.js, but you’ve got to have a firm understanding of OOCSS for any of it to make sense. Let’s get started…
Read more…
CSS, cujo.js, In-browser MVC, Inheritance, Javascript, OOCSS