How JavaScript Works

How JavaScript Works

Douglas Crockford

Front Matter

Did I hear you right, did I hear you sayin’ that you’re gonna make a copy of a game without payin’? Come on, guys, I thought you knew better. Don’t copy that floppy. MC Double Def DP

How JavaScript Works

Douglas Crockford

Copyright ©2018 Douglas Crockford

ISBN-13 978-1-94-981500-9 Paperback.

ISBN-13 978-1-94-981501-6 Hardcover.

ISBN-13 978-1-94-981502-3 EPUB.

The computer programs in this book are in the Public Domain. The programs are provided as is, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the author or publisher be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the programs or the use or other dealings in the programs. Please use the programs for good, not evil.

The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales which may include customized covers. For more information, please contact [email protected].

QA76.73.J39

005.2762

Chapter List

Raindrops on roses and whiskers on kittens. Not Maria Augusta von Trapp

[

{number:  0, chapter: Read Me First!}

,

{number:  1, chapter: How Names Work}

,

{number:  2, chapter: How Numbers Work}

,

{number:  3, chapter: How Big Integers Work}

,

{number:  4, chapter: How Big Floating Point Works}

,

{number:  5, chapter: How Big Rationals Work}

,

{number:  6, chapter: How Booleans Work}

,

{number:  7, chapter: How Arrays Work}

,

{number:  8, chapter: How Objects Work}

,

{number:  9, chapter: How Strings Work}

,

{number: 10, chapter: How Bottom Values Work}

,

{number: 11, chapter: How Statements Work}

,

{number: 12, chapter: How Functions Work}

,

{number: 13, chapter: How Generators Work}

,

{number: 14, chapter: How Exceptions Work}

,

{number: 15, chapter: How Programs Work}

,

{number: 16, chapter: How this Works}

,

{number: 17, chapter: How Class Free Works}

,

{number: 18, chapter: How Tail Calls Work}

,

{number: 19, chapter: How Purity Works}

,

{number: 20, chapter: How Eventual Programming Works}

,

{number: 21, chapter: How Date Works}

,

{number: 22, chapter: How JSON Works}

,

{number: 23, chapter: How Testing Works}

,

{number: 24, chapter: How Optimizing Works}

,

{number: 25, chapter: How Transpiling Works}

,

{number: 26, chapter: How Tokenizing Works}

,

{number: 27, chapter: How Parsing Works}

,

{number: 28, chapter: How Code Generation Works}

,

{number: 29, chapter: How Runtimes Work}

,

{number: 30, chapter: How Wat! Works}

,

{number: 31, chapter: How This Book Works}

]

Chapter 0

Read Me First!

○○○○○

Few images invoke the mysteries and ultimate certainties of a sequence of random events as well as that of the proverbial monkey at a typewriter. George Marsaglia

JavaScript is not very pretty, but it works.

This book is for people who have had some experience with JavaScript, and want to have a better, deeper understanding of how it works and how to use it well. It is also for experienced programmers who are looking to understand the workings of another language.

This book is not for beginners. I hope to someday write a book for beginners. This is not that book. This is not a light book. If you skim it, you will likely get nothing from it.

This book is not about JavaScript engines or virtual machines. It is about the language itself and the things every programmer should know about it. This book is a radical reappraisal of JavaScript, how it works, how it could be made better, and how it can be better used. It is about how to think about JavaScript and how to think in JavaScript. I am going to pretend that the current version of the language is the only version. I am not going to waste your time by showing how things worked in ES1 or ES3 or ES5. That does not matter. The focus is on how JavaScript works for us now.

This book is not comprehensive. There are large, complex chunks of the language that will be dismissed without a word. If I fail to mention your most favorite feature, that is most likely because that feature is crap. I will not be paying much attention to syntax. I am assuming that you already know how to write an if statement. If you need assistance with those sorts of details, ask JSLint. jslint.com

There are some useful parts of the language that I will spend little time on, such as most of the methods in the primordial prototypes. There are excellent online reference materials for that. My favorite resource is Mozilla Foundation.

developer.mozilla.org/en-US/docs/Web/JavaScript/Reference

An important goal in programming language design is to produce a clean, logical language that composes well and is free of weird corner cases. JavaScript came nowhere close to meeting that goal. It gets worse with each revision as more features are agglutinated. The language is full of weird corner and edge cases. This book illuminates only a few of those corners, just to show that there are monsters there. Stay away from the corners and edges. Do not go into the dark. Stay in the part of the language that is simple and clean. Everything you need to write good programs is there.

Ten years ago I wrote a cranky little pamphlet about JavaScript. The premise was unusual, that whilst JavaScript was obviously a mess, there was buried deep inside of it a very good language. By avoiding the bad parts, you could write good programs.

This was quite at odds with the opinion of some programming experts that mastery can only be demonstrated by exploiting all of a language’s features. They believed strongly, without any need of proof, that features exist for the demonstration of mastery, so there are no bad features.

That opinion still seems to dominate even though it is deeply wrong. True mastery is shown by writing good programs that are readable, maintainable, and free of error. If you ever feel the need to show off, try doing that. Being a humble programmer, I am always looking at myself and my work, seeking to improve my skills. I have learned the hard way that optimizing for feature exploitation is counterproductive.

This is my most powerful tool for improving a programming language:

If a feature is sometimes useful and sometimes dangerous and if there is a better option then always use the better option.

So armed, I am always looking to make the language I use smaller and better, to avoid if I can the features that are more likely to create bugs. I am still refining my ideas about what is good practice and what is not. This book represents my latest thinking about JavaScript. I am able to write about JavaScript’s good parts only because JavaScript has good parts. Compared to a decade ago, I think less of the language is good, but I think that good part is better.

JavaScript has become the most important programming language in the world. That is at least partly my fault. Sorry. The issuing of new editions of the ECMAScript standard has not repaired JavaScript’s deep problems, and sometimes creates new problems. A standards committee has limited power to repair a language. They have almost limitless power to grow the language, increasing its complexity and weirdness. They also have the power to not make things worse, but where is the fun in that?

Aging programming languages suffer from a bad plastic surgery addiction. They are desperately injecting new features in the fevered hope of remaining popular, or at least fashionable. Feature bloat is as big and as deep of a problem as code bloat. I think that we should instead praise JavaScript’s inner beauty.

I also recommend that you get the ECMAScript standard. It can be tough reading, but it is free. www.ecma-international.org/publications/standards/Ecma-262.htm

Reading the ECMAScript standard literally changed my life. Like most people, I started writing JavaScript without first bothering to learn it well. I found the language to be faulty, confusing, and irritating. It wasn’t until I got around to reading the ECMAScript standard for myself that I discovered JavaScript’s brilliance.

Heresy

This book about a programming language will make some people angry. I am a harbinger of the next paradigm, and that is threatening to the keepers of the old paradigm. I am used to this. I was attacked when I discovered that JavaScript has good parts, which turned out to be the first important discovery of the 21st century. I was attacked when I discovered JSON, which is now the world’s best loved data interchange format.

Communities form around shared beliefs, and communities can provide benefits to their members even when those beliefs are wrong. Communities can feel threatened when those beliefs are questioned. I am a heretic. I value the pursuit of truth over the benefits of community. That is offensive to some people.

I am just a programmer who is trying to figure out the best way to write programs. I might be wrong, but I am working really hard to get it right. Many of the patterns of thought in our profession were cemented in the FORTRAN era. I think it is time that we move beyond that. Change is hard, even in the most innovative of professions.

If you are offended by heresy, then put this book back on the shelf and walk away.

Code

All of the code in this book is in the Public Domain. You are free to use it for any purpose, but please do not use it for evil. Try to do some good with it if that is at all possible.

I strongly recommend that you do not copy and paste code that you do not understand, even mine. This seems to have become a standard practice, but it is dangerous and reckless. It is not nearly as stupid as installing packages that you haven’t even looked at, but it is still really bad. Given the current state of the art, the most important security filter is your brain. Use it. This is important.

I make no claim that the programs presented in this book are perfect. I do claim that the programs I am writing now are better than what I was writing ten years ago. I work hard at trying to get better at this. I am hoping that I live long enough to finally get it right. I hope that you do, too. In the meantime, erratums for this book can be found at the book’s website. In Latin, the plural of erratum is errata as is done with second declension neuter nouns in the nominative case. But I am writing in Modern English, and in Modern English we should be forming plural nouns by appending -s, or in cases of excess sibilance, -es. So, yes, erratums. Given a choice between progress and tradition, I am going with progress informed by the lessons of history. That is how things are made better.

Please report my many blunders to [email protected].

Next

This book is about JavaScript, but I sometimes talk about The Next Language, the language that will replace JavaScript. I have to believe that there will be a language after JavaScript, because if JavaScript is the last language, that would be really sad. We must find a way to the next language, if only for our kids. They deserve a better legacy than JavaScript.

I believe that children are our future. And also robots.

The next paradigm will be globally distributed, secure, eventual programming. The Internet demands this. Nearly all of our current programming languages, including JavaScript, are still firmly rooted in the old paradigm of local, insecure, sequential programming. I see JavaScript as a transitional language. Adoption of the best practices in JavaScript will be good preparation for understanding the next paradigm.

English

The word for 1 is misspelled. I use the corrected spelling wun. The pronunciation of one does not conform to any of the standard or special rules of English pronunciation. And having the word for 1 start with the letter that looks like 0 is a bug.

The spelling of wun is unfamiliar to you so it might feel wrong. I am doing this intentionally to give you practice with the idea that a bad feeling about something unfamiliar is not proof that it is wrong.

This is how spelling reform happens. For example, some cat decides that it really would be better if through were spelled thru because it does not make sense that half of the letters in a popular word be silent, being wildly inefficient and putting an unnecessary burden on students of the language. Spelling reform is a struggle between tradition and reason, and sometimes, reason wins. I feel the same way about programming languages. So if wun makes more sense to you than one, then please join me in the effort.

When normal people talk about ranges, like 1 to 10, the range is understood to end with 10. But programmers often mean to to exclude the 10. This confusion is due to the common programming practice of numbering from 0 instead of 1. So I use to to mean what programmers usually mean by to, and thru to mean what normal people mean by to. So 0 to 3 mean the range including 0 1 2 whilst 0 thru 3 mean the range including 0 1 2 3. To implies < less than and thru implies <= less than or equal.

And whilst on the subject of whilst, in this book about programming, while is used for discussion of iteration. When discussing concurrency or simultaneity I use whilst which I take to mean while at the same time.

Both cannot and can not are acceptable spellings, but cannot is much more popular. Hasnot is not acceptable whilst has not is. And willnot is not acceptable whilst will not is. That is why I can not use cannot. But if I am in a great hurry, I can still can’t.

To my many friends for whom English is not your first language: Welcome. Thank you for reading my book. Perhaps unfairly, English has become the language of the Internet and of Software Development. Your ability to read the primary documentation directly is an important and valuable skill. I deeply respect that.

Examples

I use regular expressions. Unfortunately, regular expressions are extremely cryptic and confusing. I will attempt to mitigate that a bit by pumping lots of whitespace into them. JavaScript does not allow that whitespace, so when you see

const number_pattern = /

    ^

    ( -? \d+ )

    (?: \. ( \d* ) )?

    (?:

        [ e E ]

        ( [ + \- ]? \d+ )

    )?

    $

/;

be aware that it should be written all smushed together as

const number_pattern = /^(-?\d+)(?:\.(\d*))?(?:[eE]([+\-]?\d+))?$/;

I do not want to subject you to such unprintable ugliness, so I insert the whitespace.

In many of the chapters I will show examples of JavaScript expressions. I do that by using a special expression statement that ends not with a ; semicolon but instead with // slash slash followed by the result of the expression.

// An example of examples

3 + 4 === 7                                                // true

NaN === NaN                                                // false

typeof NaN                                                  // number

typeof null                                                // object

0.1 + 0.2 === 0.3                                          // false

3472073 ** 7 + 4627011 ** 7 === 4710868 ** 7                // true

Before the end, all will be explained.

Chapter 1

How Names Work

○○○○●

You know my name. John Lennon and

Paul McCartney

JavaScript wants you to give names (or identifiers) to your variables, properties, and sometimes, functions. JavaScript puts no limit on the length of variables names, so be generous. As much as possible, let your programs tell their own stories. Do not use cryptic names.

I was first taught programming by mathematicians and then I went to work for a company that made computers that were programmed in BASIC. At that time, BASIC variable names were a single uppercase letter and an optional digit, like A1. I developed a very bad habit of using wun letter variable names. Decades later, I am still struggling with that. Wunce something wrong gets into your head, it can be really hard to fix it. We should never stop trying to get smarter. Mathematicians like notations that are cryptic and terse. We have learned the very hard way that programming should strive to be literate and self explanatory. Programming is not mathematics. It is a different sort of art.

Start all of your names with a letter, and end them with a letter. JavaScript allows names to start with _ underbar or $ dollar sign or to end with _ underbar or $ dollar sign or a digit. JavaScript allows a lot of things that you really should not do. These tricks should be reserved for code generators and macro processors. Humans should do better.

A beginning or ending _ underbar is sometimes intended to indicate a public property or a global variable that would have been private if the program had been written correctly. So, a dangling _ underbar is a flag indicating that the coder is incompetent.

The $ dollar sign was added to the language for use by code generators, transpilers, and macro processors, so that they could generate names that were guaranteed to not collide with yours. If you are not a program, leave the $ dollar sign alone.

A trailing digit in a name is usually an indication that the programmer failed to give enough thought to the name.

I give my ordinal variables names like thing_nr. I give my cardinal variables names like nr_things.

It is good to have names containing multiple words, but there is little agreement on how to do that since spaces are not allowed inside of names. There is wun school that insists on the use of camel case, where the first letter of words are capitalized to indicate the word boundaries. There is another school that insists that _ underbar should be used in place of space to show the word boundaries. There is a third school that just runs all the words together, losing the word boundaries. The schools are unable to agree on the best practice. This argument has been going on for years and years and does not appear to be approaching any kind of consensus. That is because all of the schools are wrong.

The correct answer is to use spaces to separate the words. Programming languages currently do not allow this because compilers in the 1950s had to run in a very small number of kilowords, and spaces in names were considered an unaffordable luxury. FORTRAN actually pulled it off, allowing names to contain spaces, but later languages did not follow that good example, even though later languages (including JavaScript) followed FORTRAN’s very bad examples of using = equal sign as the assignment operator and requiring ( left paren and ) right paren around the condition of an IF instead of requiring { left brace and } right brace around the consequence.

I am hoping that the next language does the right thing and allows names to contain spaces to improve readability. We measure memory in gigabytes, so language designers are now free to invent better languages. Until then, use _ underbar in multiword names. That will be the easiest transition to the next language.

All names in JavaScript should start with a lowercase letter. This is because of a problem with JavaScript’s new operator. If a function invocation is prefixed with new, then the function is called as a constructor, otherwise the function is called as a function. The functionality of constructors and functions can be quite different. Errors can result from calling a constructor the wrong way. Making this more confusing, constructors and functions look exactly the same, so there is no automatic way to detect problems due to a missing or superfluous new. So we have a convention: All constructor functions should start with an uppercase letter and nothing else should ever start with an uppercase letter. That gives us a visual indication that could help to identify an error.

My solution to this problem is more reliable: never use new. That eliminates the need to have names that start with an uppercase letter. I still recommend avoiding initial caps in this language because there are an awful lot of awful programs out there that still use new, increasing daily.

Reserved Words

This is JavaScript’s reserved word list:

arguments await break case catch class const continue debugger default delete do else enum eval export extends false finally for function if implements import in Infinity instanceof interface let NaN new null package private protected public return static super switch this throw true try typeof undefined var void while with yield

Memorize that list. It is important. None of those words should be used as variable names or parameter names. JavaScript’s rules about reserved words are surprisingly complex, so there might be some exceptional cases where a few of those words can be used. But even in those weird cases, don’t.

The use of reserved words is another misfeature that has its roots in the memory shortages of the 1950s and 1960s. Having reserved words in a language could make things easier for a compiler, allowing it to save a few bytes. Moore’s Law has obliterated those shortages, but that constrained mode of thinking persists. Reserved words are obviously a bad thing for programmers. Have you memorized the reserved word list yet? There might be a word that perfectly describes your variable, but it has already been allocated to a lousy feature that you never use, or that might not ever be implemented. Reserved words are also bad for language designers because the brittle reserved word strategy makes it very difficult to add new features to a popular language in a clean, straightforward way. I am hoping that the next language does not stoop to using reserved words.

Chapter 2

How Numbers Work

○○○●○

Look up the number. John Lennon and Paul McCartney

Computers are machines that manipulate numbers. That is fundamentally all that computers can do. They seem to do that really well. We can map other kinds of information onto numbers. Computers now mediate virtually all human activity.

JavaScript’s numbers were inspired by the real numbers, but they are not real numbers. Many of our mathematical understandings and intuitions can be applied to JavaScript numbers, but not completely or consistently. In order to write good programs in JavaScript, we must understand how its numbers work.

JavaScript has a single number type called number. It was borrowed from the IEEE Standard for Floating-Point Arithmetic (IEEE 754) which was initally developed for Intel’s processors.

JavaScript is often criticized for having only wun number type, but this is actually wun of its greatest strengths. Programmers are more productive if they do not have to waste time selecting from a confusion of similar types with the risk of obscure failures from choosing the wrong wun. Type conversion errors are avoided. The overflow errors caused by the int types are avoided. JavaScript integers are far more reliable than Java ints because overflow can not occur.

    JavaScript: 2147483647 + 1      //  2147483648  exactly right

    Java:      2147483647 + 1      // -2147483648  maximally wrong

How can we have confidence in the correctness of programs that are built on a number system that can go wildly wrong at any time without warning? The int types do not prevent errors, they cause them.

The idea behind floating point is a simple wun: Represent a number as two numbers. The first number (sometimes called the coefficient, significand, fraction, or mantissa) contains the digits. The second number (called the exponent) identifies where the decimal point (or binary point) should be inserted in the first number. Implementations of floating point can be quite complex. The complexity comes from the need to make the best use of the limited number of bits in a fixed format.

JavaScript does not use the entire IEEE 754 standard. It uses a subset of the subset that Java uses. JavaScript’s number is very closely related to Java’s double. It is a 64 bit binary floating point type. A number contains a sign bit, 11 exponent bits, and 53 significand bits. Some clever encoding allows those 65 bits to be packed into a 64 bit word.

IEEE 754, like many floating point systems before it, chose a system with a basis of 2. The first number is split into two parts—the sign and the significand. The sign is placed in the most significant of the 64 bits. It is 1 if the number is negative. The significand is placed in the least significant bits. It normally represents a binary fraction in the range

0.5 <= significand < 1.0

In that form, the most significant bit is always a 1. Since that bit is always a 1, it does not need to be stored in the number. This yields the bonus bit.

The second number is the exponent. It fills the space between the sign and the significand. The value of a number would be

sign * significand * (2 ** exponent)

but there are other complications. The exponent is represented as a biased signed magnitude integer. This allows comparisons to be made pretending that the number is a 64 bit integer. That could provide a significant performance benefit, which was important fifty years ago. The exponent can also encode NaN and Infinity and the subnormals, a special form for representing very small numbers and zero.

Zero

There is no zero but zero. In a correct system, there is only wun zero. The IEEE 754 standard contains two zeros: 0 and -0. JavaScript bravely works hard to hide this abomination from you, and nearly always succeeds. You can safely ignore the existence of -0 except in these cases:

(1 / 0) === (1 / -0)                                        // false

Object.is(0, -0)                                            // false

I do not recommend that you ever divide anything by zero. I do not recommend that you ever use Object.is().

Number Literals

There are 18437736874454810627 immutable number objects built into JavaScript, each uniquely representing a number. A number literal produces a reference to the number object that most closely matches the value of the literal. Sometimes it will be exact. In some cases it can be off by as much as 9.9792015476735990582818635651842e+291.

A number literal for an integer is simply a sequence of decimal digits. It is also possible to form literals for integers in different bases by use of a radix prefix. All of these literals produce references to 2018:

binary:      0b11111100010

octal:      0o3742

decimal:    2018.00

hexadecimal: 0x7E2

JavaScript allows the radix specifier letter to be in uppercase, but putting uppercase letter O in a number literal is certain to cause confusion.

Decimal number literals may contain a decimal point. Very large or very small numbers may be compactly written with e, which multiplies the number by a power of ten. So, 6.022140857747475e23 is short for (6.022140857747475 * (10 ** 23)) and 6.626070040818182e-34 is short for (6.626070040818182 * (10 ** -34)).

Infinity is a value that represents all numbers that are too large to be represented. Do not confuse Infinity with ∞. In mathematics, ∞ is not a value. It is a metaphor.

NaN is a special value that represents numbers that are not numbers.