Effective JavaScript Foreword

effective_javascript_foreword.txt

Foreword
As is well known at this point, I created JavaScript in ten days in May
1995, under duress and conflicting management imperatives—“make
it look like Java,” “make it easy for beginners,” “make it control almost
everything in the Netscape browser.”

Apart from getting two big things right (first-class functions, object
prototypes), my solution to the challenging requirements and crazy-
short schedule was to make JavaScript extremely malleable from
the start. I knew developers would have to “patch” the first few ver-
sions to fix bugs, and pioneer better approaches than what I had cob-
bled together in the way of built-in libraries. Where many languages
restrict mutability so that, for example, built-in objects cannot be
revised or extended at runtime, or standard library name bindings
cannot be overridden by assignment, JavaScript allows almost com-
plete alteration of every object.

I believe that this was a good design decision on balance. It clearly
presents challenges in certain domains (e.g., safely mixing trusted
and untrusted code within the browser’s security boundaries). But it
was critical to support so-called monkey-patching, whereby develop-
ers edited standard objects, both to work around bugs and to retro-
fit emulations of future functionality into old browsers (the so-called
polyfill library shim, which in American English would be called
“spackle”).

Beyond these sometimes mundane uses, JavaScript’s malleability
encouraged user innovation networks to form and grow along sev-
eral more creative paths. Lead users created toolkit or framework
libraries patterned on other languages: Prototype on Ruby, MochiKit
on Python, Dojo on Java, TIBET on Smalltalk. And then the jQuery
library (“New Wave JavaScript”), which seemed to me to be a relative
late-comer when I first saw it in 2007, took the JavaScript world by
storm by eschewing precedent in other languages while learning from
older JavaScript libraries, instead hewing to the “query and do” model
of the browser and simplifying it radically.

Lead users and their innovation networks thus developed a Java-
Script “home style,” which is still being emulated and simplified in
other libraries, and also folded into the modern web standardization
efforts.

In the course of this evolution, JavaScript has remained backward
(“bugward”) compatible and of course mutable by default, even with
the addition of certain methods in the latest version of the ECMAScript
standard for freezing objects against extension and sealing object
properties against being overwritten. And JavaScript’s evolutionary
journey is far from over. Just as with living languages and biologi-
cal systems, change is a constant over the long term. I still cannot
foresee a single “standard library” or coding style sweeping all others
before it.

No language is free of quirks or is so restrictive as to dictate universal
best practices, and JavaScript is far from quirk-free or restrictionist
(more nearly the opposite!). Therefore to be effective, more so than is
the case with most other programming languages, JavaScript devel-
opers must study and pursue good style, proper usage, and best prac-
tices. When considering what is most effective, I believe it’s crucial to
avoid overreacting and building rigid or dogmatic style guides.
This book takes a balanced approach based on concrete evidence
and experience, without swerving into rigidity or excessive prescrip-
tion. I think it will be a critical aid and trusty guide for many people
who seek to write effective JavaScript without sacrificing expressive-
ness and the freedom to pursue new ideas and paradigms. It’s also a
focused, fun read with terrific examples.

Finally, I have been privileged to know David Herman since 2006,
when I first made contact on behalf of Mozilla to engage him on the
Ecma standards body as an invited expert. Dave’s deep yet unpre-
tentious expertise and his enthusiasm for JavaScript shine through
every page. Bravo!
—Brendan Eich