intentions, she was always getting into trouble.
THE EASE OF WRITING TRULY DISASTROUS CODE IN JAVASCRIPT
Part of the problem, which she has only recently begun to outgrow, was her years spent as a page-scripting language. In that limited sphere, there was no harm in making a variable or function global. If a variable was misspelled, the effects were limited and easy to track down. (By the way, the effect would likely be to create yet another global.) If the architecture was sloppy.. well, how much architecture can there even be on just one web page?
Compounding the potential for error was the lack of a compiler. Server-side programs in C# or Java are guaranteed to be at least syntactically correct before they are run. JavaScript must start and hope for the best. A misspelled variable, or a call to a non-existent function, can lurk in the code for months until a particular execution path is followed.
And then there are the quirks. Ah, those endearing, maddening quirks.
At the top of the list must be the distinction between == (equality with type coercion) and === (without). A great idea, but so hard for programmers primarily trained in other languages to get used to!
Never is JavaScript more coquettish than when it comes to truth and falsehood. She has a notion of “truthy” and “falsy” that confuses all but the most determined suitors. Zero is a falsy value so, thanks to type coercion, the expression
is true. But not for the reason you think. The value false is coerced to a number, which is 0 (true would convert to 1). Next, the string '0' is also coerced to a number. That is also 0, so the result is true.
However,
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
