Friday, November 20th, 2009
Full Frontal ’09: Robert Nyman on the Javascript Language
Category: JavaScript, Presentation
Comparisons: Understanding identity (===) versus equality (==).
Boolean expressions: Understanding how short-circuit logic (if a && b won’t eval b if a is false);
Types: Type coercion (“1″+2+3); “falsey” (false, null, 0) versus “truthy”; the importance of using operators like parseInt and instanceof.
Functions: Anonymous functions; self-invoking functions – function() { })() ; using the arguments collection to get all arguments to the current function, important to note it’s not a real array with all the array methods, and using arguments to overload arguments.
Objects: Using object literal notation { a:b, c:d } instead of setting up properties individually; equivalence of ben.arms and ben["arms"], and how useful it can be to use the latter in conjunction with a function argument, ie let the caller pass in a variable which will be set; using “in” to check if a property exists (if "arms" in ben).
Inheritance: Using the prototype chain for inheritance from subclass to superclasses up to Object. There are various implementations – e.g. Resig, Edward’s Base, Dan Webb; if you understand these implementations, then you understand Javascript. However, Robert’s arguing for the native way of doing it – as Doug Crockford says, “I now see my early attempts to support the classical model in Javascript as a mistake”.
Global scope: Avoid using global scope where you can. For example, nesting functions. R
obert later points to the Yahoo! module pattern.
Binding this: Using call and apply; these are useful for setting this and also can pass arguments through from the current function to another one without having to manually copy them out.
Sugaring: Adding syntax sugar, e.g. extending String.prototype.
Currying: As illustrated by Doug Crockford’s curry implementation.
Related Content:
Michael –
Is that what you’re referring to:
http://www.slideshare.net/robnyman/javascript-from-birth-to-closure
Paul
Michael,
Shouldn’t “if a && b won’t eval b if a is true” be “if a && b won’t eval b if a is false”?
~Maiku Mori
ummm yeah. fixed, thanks.
this would have been a much more enjoyable and useful article had it contained links to anything you were talking about…
but you did make me go look-up several things, so Google thanks you… :-)
cheers,
Atg