You are previewing JavaScript: The Good Parts.

JavaScript: The Good Parts

Cover of JavaScript: The Good Parts by Douglas Crockford Published by O'Reilly Media, Inc.
  1. JavaScript: The Good Parts
    1. SPECIAL OFFER: Upgrade this ebook with O’Reilly
    2. A Note Regarding Supplemental Files
    3. Preface
      1. Conventions Used in This Book
      2. Using Code Examples
      3. Safari® Books Online
      4. How to Contact Us
      5. Acknowledgments
    4. 1. Good Parts
      1. Why JavaScript?
      2. Analyzing JavaScript
      3. A Simple Testing Ground
    5. 2. Grammar
      1. Whitespace
      2. Names
      3. Numbers
      4. Strings
      5. Statements
      6. Expressions
      7. Literals
      8. Functions
    6. 3. Objects
      1. Object Literals
      2. Retrieval
      3. Update
      4. Reference
      5. Prototype
      6. Reflection
      7. Enumeration
      8. Delete
      9. Global Abatement
    7. 4. Functions
      1. Function Objects
      2. Function Literal
      3. Invocation
      4. Arguments
      5. Return
      6. Exceptions
      7. Augmenting Types
      8. Recursion
      9. Scope
      10. Closure
      11. Callbacks
      12. Module
      13. Cascade
      14. Curry
      15. Memoization
    8. 5. Inheritance
      1. Pseudoclassical
      2. Object Specifiers
      3. Prototypal
      4. Functional
      5. Parts
    9. 6. Arrays
      1. Array Literals
      2. Length
      3. Delete
      4. Enumeration
      5. Confusion
      6. Methods
      7. Dimensions
    10. 7. Regular Expressions
      1. An Example
      2. Construction
      3. Elements
    11. 8. Methods
    12. 9. Style
    13. 10. Beautiful Features
    14. A. Awful Parts
      1. Global Variables
      2. Scope
      3. Semicolon Insertion
      4. Reserved Words
      5. Unicode
      6. typeof
      7. parseInt
      8. +
      9. Floating Point
      10. NaN
      11. Phony Arrays
      12. Falsy Values
      13. hasOwnProperty
      14. Object
    15. B. Bad Parts
      1. ==
      2. with Statement
      3. eval
      4. continue Statement
      5. switch Fall Through
      6. Block-less Statements
      7. ++ −−
      8. Bitwise Operators
      9. The function Statement Versus the function Expression
      10. Typed Wrappers
      11. new
      12. void
    16. C. JSLint
      1. Undefined Variables and Functions
      2. Members
      3. Options
      4. Semicolon
      5. Line Breaking
      6. Comma
      7. Required Blocks
      8. Forbidden Blocks
      9. Expression Statements
      10. for in Statement
      11. switch Statement
      12. var Statement
      13. with Statement
      14. =
      15. == and !=
      16. Labels
      17. Unreachable Code
      18. Confusing Pluses and Minuses
      19. ++ and −−
      20. Bitwise Operators
      21. eval Is Evil
      22. void
      23. Regular Expressions
      24. Constructors and new
      25. Not Looked For
      26. HTML
      27. JSON
      28. Report
    17. D. Syntax Diagrams
    18. E. JSON
      1. JSON Syntax
      2. Using JSON Securely
      3. A JSON Parser
    19. Index
    20. About the Author
    21. Colophon
    22. SPECIAL OFFER: Upgrade this ebook with O’Reilly

Analyzing JavaScript

JavaScript is built on some very good ideas and a few very bad ones.

The very good ideas include functions, loose typing, dynamic objects, and an expressive object literal notation. The bad ideas include a programming model based on global variables.

JavaScript's functions are first class objects with (mostly) lexical scoping. JavaScript is the first lambda language to go mainstream. Deep down, JavaScript has more in common with Lisp and Scheme than with Java. It is Lisp in C's clothing. This makes JavaScript a remarkably powerful language.

The fashion in most programming languages today demands strong typing. The theory is that strong typing allows a compiler to detect a large class of errors at compile time. The sooner we can detect and repair errors, the less they cost us. JavaScript is a loosely typed language, so JavaScript compilers are unable to detect type errors. This can be alarming to people who are coming to JavaScript from strongly typed languages. But it turns out that strong typing does not eliminate the need for careful testing. And I have found in my work that the sorts of errors that strong type checking finds are not the errors I worry about. On the other hand, I find loose typing to be liberating. I don't need to form complex class hierarchies. And I never have to cast or wrestle with the type system to get the behavior that I want.

JavaScript has a very powerful object literal notation. Objects can be created simply by listing their components. This notation was the inspiration for JSON, the popular data interchange format. (There will be more about JSON in Appendix E.)

A controversial feature in JavaScript is prototypal inheritance. JavaScript has a class-free object system in which objects inherit properties directly from other objects. This is really powerful, but it is unfamiliar to classically trained programmers. If you attempt to apply classical design patterns directly to JavaScript, you will be frustrated. But if you learn to work with JavaScript's prototypal nature, your efforts will be rewarded.

JavaScript is much maligned for its choice of key ideas. For the most part, though, those choices were good, if unusual. But there was one choice that was particularly bad: JavaScript depends on global variables for linkage. All of the top-level variables of all compilation units are tossed together in a common namespace called the global object. This is a bad thing because global variables are evil, and in JavaScript they are fundamental. Fortunately, as we will see, JavaScript also gives us the tools to mitigate this problem.

In a few cases, we can't ignore the bad parts. There are some unavoidable awful parts, which will be called out as they occur. They will also be summarized in Appendix A. But we will succeed in avoiding most of the bad parts in this book, summarizing much of what was left out in Appendix B. If you want to learn more about the bad parts and how to use them badly, consult any other JavaScript book.

The standard that defines JavaScript (aka JScript) is the third edition of The ECMAScript Programming Language, which is available from The language described in this book is a proper subset of ECMAScript. This book does not describe the whole language because it leaves out the bad parts. The treatment here is not exhaustive. It avoids the edge cases. You should, too. There is danger and misery at the edges.

Appendix C describes a programming tool called JSLint, a JavaScript parser that can analyze a JavaScript program and report on the bad parts that it contains. JSLint provides a degree of rigor that is generally lacking in JavaScript development. It can give you confidence that your programs contain only the good parts.

JavaScript is a language of many contrasts. It contains many errors and sharp edges, so you might wonder, "Why should I use JavaScript?" There are two answers. The first is that you don't have a choice. The Web has become an important platform for application development, and JavaScript is the only language that is found in all browsers. It is unfortunate that Java failed in that environment; if it hadn't, there could be a choice for people desiring a strongly typed classical language. But Java did fail and JavaScript is flourishing, so there is evidence that JavaScript did something right.

The other answer is that, despite its deficiencies, JavaScript is really good. It is lightweight and expressive. And once you get the hang of it, functional programming is a lot of fun.

But in order to use the language well, you must be well informed about its limitations. I will pound on those with some brutality. Don't let that discourage you. The good parts are good enough to compensate for the bad parts.

The best content for your career. Discover unlimited learning on demand for around $1/day.