Posts

Showing posts with the label jshistory

Why are there so many array-like objects in the DOM?

Tweet by Leon Arnott: #TIL the reason the DOM has so many "array-like objects" that aren't functional arrays… is because in Javascript 1.0, there were no arrays. Explanation: ECMAScript 1 does have arrays, but it corresponds to JavaScript 1.3. JavaScript version numbers apply to the JavaScript engines implemented by Netscape/Mozilla. The cross-engine way of referring to the capabilities of the language are thus ECMAScript versions. Arrays were indeed added after JavaScript 1, as this page shows, which lists the additions for version 1.1. More information on array-like objects and arrays: JavaScript quirk 8: array-like objects Arrays in JavaScript

Why all objects are truthy in JavaScript

In JavaScript, all objects are truthy [1] , even new Boolean(false) , empty arrays and empty objects: > Boolean(new Boolean(false)) true > Boolean([]) true > Boolean({}) true That is different from how objects are converted to number and string, where you can control the result by implementing the methods valueOf() and toString() [2] . Why converting to boolean is different The conversion to boolean is different for historic reasons: For ECMAScript 1, it was decided to not allow objects to configure that conversion. The rationale was as follows. The boolean operators || and && preserve the values of their operands. Therefore, one may have to coerce the same object several times. That was considered a performance problem and led to the rejection. As an example, let’s assume that new Boolean(false) coerces to false and use it in an expression: new Boolean(false) && 1 && true That expression is evaluated in two steps: ...

JavaScript history: undefined

Two tweets by Brendan Eich shed light on the history of JavaScript having both undefined and null [1] . The first version of JavaScript did not have exception handling, which is why JavaScript so often converts automatically [2] and/or fails silently ( tweet ). JavaScript copied Java’s approach of partitioning values into primitives and objects [3] . null is the value for “not an object”. The precedent from C (but not from Java) is to convert null to 0 (C has pointers, not references and lets you perform arithmetic with pointers). Remaining problem: In JavaScript, each variable can hold both primitives and objects. In Java, a variable’s static type limits it to either kind of value. We therefore need a value for “neither a primitive nor an object”. That value could be null , but at the time, Eich wanted something that wasn’t “reference-y” (associated with objects) and did not convert to 0 ( tweet ). Now you know why undefined and null are converted to different numbers: ...

Ecma wasn’t always Ecma

Most people know that ECMAScript is the language standard behind JavaScript [1] . Fewer people know that its name comes from Ecma International , the organization managing this standard. Interestingly, that organization started as “European Computer Manufacturers Association (ECMA)”, but renamed itself to “Ecma International” in 1994. That was done to reflect its increasingly international focus. Ecma is now not considered an acronym, any more. Ecma International is located in Geneva. In contrast, TC39 [1] , the Ecma-hosted committee evolving ECMAScript, is rather USA-centric (true to where JavaScript was created and who created it) and usually meets somewhere in California. This little bit of history also explains why it’s spelled ECMAScript and not EcmaScript: That’s a remnant from when Ecma was still ECMA. Reference: ECMAScript: ES.next versus ES 6 versus ES Harmony