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 crazyshort schedule was to make JavaScript extremely malleable from the start. I knew developers would have to “patch” the first few versions to fix bugs, and pioneer better approaches than what I had cobbled 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 complete 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 developers edited standard objects, both to work around bugs and to retrofit 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 several 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 biological 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 developers must study and pursue good style, proper usage, and best practices. When considering what is most effective, I believe it’s crucial to avoid overreacting and building rigid or dogmatic style guides.
(c) Brendan Eich,
Foreword to "Effective JavaScript" by David Herman
Apart from getting two big things right (first-class functions, object prototypes), my solution to the challenging requirements and crazyshort schedule was to make JavaScript extremely malleable from the start. I knew developers would have to “patch” the first few versions to fix bugs, and pioneer better approaches than what I had cobbled 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 complete 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 developers edited standard objects, both to work around bugs and to retrofit 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 several 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 biological 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 developers must study and pursue good style, proper usage, and best practices. When considering what is most effective, I believe it’s crucial to avoid overreacting and building rigid or dogmatic style guides.
(c) Brendan Eich,
Foreword to "Effective JavaScript" by David Herman
No comments:
Post a Comment