- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
More on Crockford’s and Flanagan’s approaches to JavaScript
In my recent review of "JavaScript: The Good Parts," I compared this new Douglas Crockford treatise with David Flanagan's canonical "JavaScript: The Definitive Guide." I subsequently stumbled upon a perfect example of the authors' divergent approaches to my native programming language.
Here's Flanagan discussing the dreaded with statement:
Despite its occasional convenience, use of the
withstatement is frowned upon. JavaScript code that useswithis difficult to optimize and may therefore run more slowly than the equivalent code written without thewithstatement. Furthermore, function definitions and variable initializations within the body of awithstatement can have surprising and counterintuitive behavior.* For these reasons, it is recommended that you avoid thewithstatement.* This behavior, and the reasons behind it, are too complicated to explain here.
And here's Crockford:
JavaScript has a
withstatement that was intended to provide a shorthand when accessing the properties of an object. Unfortunately, its results can sometimes be unpredictable, so it should be avoided.The statement:
with (obj) { a = b; }does the same thing as:
if (obj.a === undefined) { a = obj.b === undefined ? b : obj.b; } else { obj.a = obj.b === undefined ? b : obj.b; }So, it is the same as one of these statements:
a = b; a = obj.b; obj.a = b; obj.a = obj.b;It is not possible to tell from reading the program which of those statements you will get. It can vary from one running of the program to the next. It can even vary while the program is running. If you can't read a program and understand what it is going to do, it is impossible to have confidence that it will correctly do what you want.
Simply by being in the language, the
withstatement significantly slows down JavaScript processors because it frustrates the lexical binding of variable names. It was well intentioned, but the language would be better if it didn't have it.
The difference between these approaches to the same topic can't help but remind me of a favorite episode of "Buffy the Vampire Slayer":
Oz: [to Faith] I'm wondering about your position on werewolves.
Willow: [proudly] Oz is a werewolf.
Buffy: It's a long story.
Oz: I got bit.
Buffy: Apparently not that long.
There's value in exhaustively documenting a language. But without concrete examples of why something's bad, programmers - obstinate autodidacts that they are - probably won't heed your advice. The Crockford book doesn't always provide such persuasive logic, but it usually does, making it ideal for JavaScript noobs who need to understand how to use the language safely and effectively.
Topics: Ajax, Javascript
Leave a comment
About Pathfinder
Recent
- iPhone SDK: UIViewController Testing & TDD
- Icons are evil; so are menus - unless you do them right
- The Truth About Designing For Security
- GWT, Gadgets and OpenSocial, Part 2
- Has Many has_many: A Refactoring Story
- The Hidden Power of Canvas
- Review of fixture_replacement2 plugin
- Chess Game Viewer in GWT
- From JSP to Ruby on Rails: First thoughts on front-end coding conventions
- Helpers and Partials
Archives
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006


