{"id":21232,"date":"2023-02-14T05:38:30","date_gmt":"2023-02-14T05:38:30","guid":{"rendered":"https:\/\/www.booksofall.com\/tw\/?post_type=product&p=21232"},"modified":"2023-02-14T05:39:07","modified_gmt":"2023-02-14T05:39:07","slug":"javascript-bible","status":"publish","type":"product","link":"https:\/\/www.booksofall.com\/tw\/javascript-bible\/","title":{"rendered":"JavaScript Bible"},"content":{"rendered":"

As JavaScript<\/a>\u2019s creator, I would like to say a few words about where JavaScript has been, where it is going, and how the book you\u2019re holding will help you to make the most of the language.<\/p>\n

JavaScript was born out of a desire to let HTML<\/a> authors write scripts directly in their documents. This may seem obvious now, but in the spring of 1995 it was novel and more than a little at odds with both the conventional wisdom (that HTML should describe static document structure only) and the Next Big Thing (Java applets, which were hyped as the one true way to enliven and extend Web pages). Once I got past these contentions, JavaScript quickly shaped up along the following lines:<\/p>\n

\u2726 \u201cJava-lite<\/a>\u201d syntax. Although the \u201cnatural language\u201d syntax of HyperTalk<\/a> was fresh in my mind after a friend lent me The Complete HyperCard Handbook<\/a> by some fellow named Goodman, the Next Big Thing weighed heavier, especially in light of another goal: scripting Java applets. If the scripting language resembled Java, then those programmers who made the jump from JavaScript to Java would welcome similarities in syntax. But insisting on Java\u2019s class and type declarations, or on a semicolon after each statement when a line ending would do, were out of the question \u2014 scripting for most people is about writing short snippets of code, quickly and without fuss.<\/p>\n

\u2726 Events for HTML elements. Buttons should have onClick event handlers. Documents load and unload from windows, so windows should have onLoad and onUnload handlers. Users and scripts submit forms: thus the onSubmit handler. Although not initially as flexible as HyperCard\u2019s messages (whose handlers inspired the onEvent naming convention), JavaScript events let HTML authors take control of user interaction from remote servers and respond quickly to user gestures and browser actions. With the adoption of the W3C DOM Level 2 event handling recommendations, JavaScript in modern browsers has fully flexible control over events.<\/p>\n

\u2726 Objects without classes. The Self programming language proved the notion of prototype-based inheritance. For JavaScript, I wanted a single prototype per object (for simplicity and efficiency), based by default on the function called using the new operator (for consonance with Java). To avoid distinguishing constructors from methods from functions, all functions receive the object naming them as the property that was called, in the this parameter. Although prototypes didn\u2019t appear until Navigator 3, they were prefigured in Version 2 by quoted text being treated as an object (the String object prototype, to which users could attach methods).<\/p>\n

\u2726 Generated HTML. Embedding JavaScript in HTML gave rise to a thought: Let the script speak HTML, as if the emitted text and markup were loaded in place of the script itself. The possibilities went beyond automating current or last-modified dates, to computing whole trees of tables where all the repeated structure was rolled up in a scripted loop, while the varying contents to be tabulated came in minimal fashion from JavaScript objects forming a catalog or mini-database.<\/p>\n","protected":false},"excerpt":{"rendered":"