evaluates to false because the left-hand false, again coerced to the number 0, is compared to the string 'false', also coerced to a number. Except 'false' is not a number at all so the second conversion yields NaN (Not a Number) and the equality fails. Ah, JavaScript.
She is always up for a little fun. If you declare the function
and call it thus:
JavaScript will let the call proceed with the variable you undefined, just for the fun of watching you try to play with someone who isn't there.
We could go on and on. There are surprising scoping rules, a unique “prototypal” inheritance mechanism, automatic and sometimes incorrect semicolon insertion, the ability of one object to borrow a function from a totally unrelated object, et cetera, et cetera.
With globals popping into existence unbidden, an almost total lack of architectural tradition, a questionable relationship to the truth, and more quirkiness than you'd find at a cosplay convention, it's a wonder that JavaScript has done as well as she has in the world.
Believe it or not, it gets worse before it gets better. Even if you get it right, it can go wrong oh so easily.
THE EASE OF UNINTENTIONALLY BREAKING JAVASCRIPT CODE
JavaScript has a perverse sense of humor. In a staid, compiled language, if you have a line of perfectly correct, debugged code running flawlessly in production like this one
and then accidentally bump the x key on your keyboard so that you now have
the compiler will emit a stern message that you should be more careful next time. JavaScript will happily run the code and give the value of undefined to myVariable. “Let's have fun and see what happens!” she says.
When you want to change the name of a property, JavaScript likes to play hide-and-seek. You might think that searching your entire source tree for
would turn up all the places to change. “No, no, no!” JavaScript says with a grin. “You forgot to search for ['myProperty'].”
Actually, you should search with a regular expression that allows spaces between the brackets and the quotes. Have you ever done that? Neither have we.
And then, depending on her mood, she may or may not let it come to your mind that you should also search for constructs like this:
When it is so hard to accomplish even such a trivial refactoring, you can imagine how easily mistakes can find their way into your code. Code that is not amenable to refactoring almost defines the word “brittle.”
How can you avoid these problems? If there is one concept that we hope to preach and practice in this book, it is test-driven development. In the absence of a compiler, tests are your best defense against error.
JavaScript is also more than amenable to playing by the rules of software engineering. In fact, because of her extremely..um..creative nature, JavaScript may need them more than most languages.
We have met many developers who are open to this message and would like to learn more about how to proceed. We hope you are one of them.
THIS BOOK'S INTENDED AUDIENCE
Because this book isn't a JavaScript primer, we assume you have some JavaScript experience. The following sections outline the attributes of the book's ideal audience.
Developers Who Come to JavaScript from Other Languages
Neither of us started his career as a JavaScript developer, and it's likely you didn't either: JavaScript is a relatively new kid on the block when it comes to large-scale application development.
JavaScript is also quite different from any of the languages that we did have experience in. We come from the comfortable world of the compiled, statically typed language C#.
Our JavaScript got a lot better when we embraced its dynamic nature while maintaining a C# programmer's sense of architecture and discipline.
If you're like us and have a background thinking and programming in a language other than JavaScript, such as C# or Java, this book is for you. Your knowledge of data structures and architecture provide a solid base on which to master JavaScript for large-scale development.
Many of the sections illustrate how language features in C# and Java, such as inheritance and interfaces, correspond to the capabilities in JavaScript. We also highlight many of the major differences between JavaScript and other languages, such as scoping rules and type-coercing equality comparisons. Knowledge of its capabilities and features will improve your ability to think in JavaScript.
Another major focus of this book is how software engineering concepts and practices more commonly associated with C# and Java development, such as design patterns, unit-testing, and test-driven development, may be applied to JavaScript. Sound engineering will temper JavaScript's wild nature, creating reliable and maintainable code.
Developers with Small-Scale JavaScript Experience
In our endeavor to add developers with JavaScript experience to our team, we've encountered many candidates who feel small-scale JavaScript experience, such as input field validation or jQuery element transitions, warrants listing “JavaScript” prominently on a résumé.
In an interview, it doesn't take much time to determine such a candidate has no problem hooking up a button handler, perhaps in the context of an ASP.NET Web Forms application, but would be hard-pressed to create a JavaScript module that has variables that are protected from external manipulation.
As our organization's use of JavaScript has evolved, our definition of what it means to have JavaScript experience has evolved as well. A few years ago, if a developer had a bit of experience with jQuery, we would check our “JavaScript” box with satisfaction.
Now, however, we're looking for a lot more. And we're not alone. It's no longer uncommon for entire applications to be written in JavaScript. In so-called single-page applications (SPAs), the JavaScript code organizes the entire application, bearing vastly more responsibility than the ephemeral click-handlers of the past. In order to participate in the development of a large-scale JavaScript application, developers must know how to use the language in a structured and disciplined way while simultaneously taking advantage of its many unique capabilities and quirks.
Through the examples in this book, we hope to help you, the small-scale JavaScript developer, make it big.
Developers Responsible for Choosing Programming Languages for a New Project
Perhaps you've heard the adage “No one ever gets fired for buying IBM.” The statement reflects the feeling that, when faced with choosing a technology partner for an IT project, it's unlikely that the decision to pick an established, reputable company such as IBM will be second-guessed. The statement implies that IBM is the safe choice. Even if the project experiences cost over-runs, missed deadlines, or complete failure, the choice of IBM is above reproach.
If you're in a position to choose the language or languages used for the development of a new application, you're in the same position as the IT manager choosing a technology partner. There are many tried-and-true programming languages with long histories. For instance, C# and Java, each backed by a large, established technology company, have been used to build both web and desktop applications for over a decade. No one would be fired for choosing C#.
In terms of being a safe choice for a new programming project, especially in the enterprise,