Permalink
Browse files

Move to markdown and readme idiomatic.js-style. Adding content

  • Loading branch information...
DavidBruant committed Jul 22, 2012
1 parent 4ba4210 commit 9c3e1089cf2b9de6bf243fae1f00f09e3726f074
Showing with 129 additions and 74 deletions.
  1. +0 −6 README.md
  2. +0 −68 index.html
  3. +129 −0 readme.md
View
@@ -1,6 +0,0 @@
-ECMAScript-regrets
-==================
-
-Remembering the mistakes of the past to avoid reproducing them
-
-Go to http://davidbruant.github.com/ECMAScript-regrets/
View
@@ -1,68 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
- <head>
- <meta charset="utf-8">
- <style></style>
-
- <title> ECMAScript regrets </title>
- </head>
-
- <body>
- <article>
- <section>
- <h1>Foreword</h1>
- <h2>Web technology ugliness</h2>
- <p>Web technologies follow this path: they are implemented, some content
- use some technology. Whether the technology (language, API...) is good or not,
- consistent or not does not matter, people use them as they are. And consequently
- rely on the technologies as they are. This makes impossible to change the
- technology afterward without breaking the content that relies on the technology
- (a.k.a. "breaking the web"), so all technologies stay mostly as they are.
- It doesn't mean they are good. It just means it prevents some content to break.
-
- <h2>There is no way back, but there is a way forward</h2>
- <p>Existing web technologies cannot be changed, but new technologies can be created.
- Recently, to "work around" JavaScript, we've seen the rise of languages that compile
- down to JavaScript like <a href="http://coffeescript.org/">CoffeeScript</a> or
- <a href="http://roy.brianmckenna.org/">Roy</a>.
- ECMA TC39 is also making an excellent work at improving the language by adding things
- (since nothing can be removed). Progress can be followed on the
- <a href="wiki.ecmascript.org/">wiki</a> or on
- <a href="https://mail.mozilla.org/listinfo/es-discuss">es-discuss</a>.
-
- <h2>Documenting history and educating those who arrived late to the party</h2>
- <p>This page aims at listing things that experienced JavaScript developers wish were
- removed or different in the language. The goal here is to explain to newcomers why
- things are as they are and what are the traps to avoid. For those who'd be tempted
- by creating a language that compiles down to JavaScript, this page aims also at
- listing errors that should not be reproduced.
-
-
- </section>
-
- <section>
- <h1>typeof null shouldn't be "object"</h1>
- <p>It is 'object' because first implementation (citation needed)
-
- </section>
- <section>
- <h1>==</h1>
- <p>It is considered as a bad practice to use it.
-
- </section>
- <section>
- <h1>wrong 'this' callback scoping</h1>
- <p>Often leads to declaring 'self' of 'that'. Lexical scoping would solve this problem.
-
- </section>
-
-
-
-
-
-
-
-
- </article>
- </body>
-</html>
View
129 readme.md
@@ -0,0 +1,129 @@
+ECMAScript Regrets
+==================
+
+Learning from mistakes of the past.
+
+# Foreword
+
+## Web technologies are ugly and there is no way back...
+
+Web technologies follow this path: they are implemented, some content use some technology. Whether the technology (language, API...) is good or not, consistent or not does not matter, people use them as they are. And consequently rely on the technologies as they are. This makes impossible to change the technology afterward without breaking the content that relies on the technology (a.k.a. "breaking the web"), so all technologies stay mostly as they are. It doesn't mean they are good. It just means it prevents some content to break.
+
+
+## ...but there is a way forward
+
+Existing web technologies cannot be changed, but new technologies can be created.
+
+The ECMA TC39 committee is also making an excellent work at improving the language by adding things (since nothing can be removed). Progress can be followed on the [wiki](http://wiki.ecmascript.org/) or on [es-discuss](https://mail.mozilla.org/listinfo/es-discuss).
+
+Recently, to "work around" JavaScript, we've seen the rise of languages that compile down to JavaScript like [CoffeeScript](http://coffeescript.org/) or [Roy](http://roy.brianmckenna.org/).
+(Add a list like http://altjs.org/ or https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS )
+
+
+## Documenting history and educating those who arrived late to the party
+
+This page aims at listing things that experienced JavaScript developers wish were removed or different in the language. The goal here is to explain to newcomers why things are as they are and what are the traps to avoid. For those who'd be tempted by creating a language that compiles down to JavaScript, this page aims also at listing errors that should not be reproduced.
+
+
+# Regrets
+
+## ````typeof null```` shouldn't be ````"object"````
+
+The first implementation of JavaScript, name-coded "Mocha" represented value with a type tag and the value itself. The type tag was in 3 bits to discriminate the 6 types. The type tag value for objects was 0. Meanwhile, the ````null```` JavaScript value was represented in C++ as the ````NULL```` pointer, which in most architectures is represented as the 0 value (all bytes at 0x00), mistakenly making the ````null```` value having a type tag of 0.
+[Mocha was never open sourced](https://twitter.com/BrendanEich/status/226310723691741185), so there is no trace of this explanation besides people sharing this story.
+
+### In your code
+
+To discriminate whether a value is ````null```` or an object, ````typeof```` is unreliable.
+
+````javascript
+// test whether a value is equal to null:
+value === null
+
+// test whether a value is of type object
+value === Object(value) // this test doesn't differentiate functions and non-callable objects.
+
+// to test whether a value is a function:
+typeof value === 'function'
+
+````
+
+
+## ````==```` as a comparison operator
+
+This operator does type coercion before comparing. Conversions are implicit and rules are not always obvious or consistent. Using the ````==```` is consequently considered as a bad practice. Always use ````===````. The only case where ````==```` is tolerated is in the following case:
+
+````javascript
+val == null // Test whether value is undefined or null
+````
+
+
+## Wrong 'this' in callbacks
+
+Consider the following case:
+````javascript
+function Person(){
+ this.age = 0;
+
+ setInterval(function growUp(){
+ this.age++;
+ }, 1000);
+}
+
+var p = new Person();
+````
+
+In the ````growUp```` function above, we'd expect ````this.age```` to refer to the person's age. It is not the case; in JavaScript, the value used for ````this```` is not lexical, but dynamic.
+
+In non-strict mode, by default, ````this```` refers to the global object (with implicit conversion which makes the bug hard to track down in this case). In strict mode, the default value is ````undefined````, so the above code will throw a TypeError when trying to access the ````age```` property of ````undefined````.
+
+
+### In your code
+
+To work around this problem, two solutions are usually used:
+````javascript
+// 1) lexical alias to |this|
+
+function Person(){
+ var self = this; // some choose 'that' instead of 'self'. Choose one and be consistent
+ self.age = 0;
+
+ setInterval(function growUp(){
+ // the callback refers to the self variable which value is the expected object
+ self.age++;
+ }, 1000);
+}
+
+
+// 2) bind the callback function
+
+function Person(){
+ this.age = 0;
+
+ setInterval(function growUp(){
+ this.age++;
+ }.bind(this), 1000);
+}
+
+// The setInterval function is bound and its |this| value is the |this| value
+// of the enclosing context.
+// Function.prototype.bind has been introduced in ECMAScript 5 and is available
+// in Internet Explorer 9+.
+// Documentation and polyfill on MDN: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/bind
+````
+
+
+### ES.next to the rescue
+
+(Talk about arrow functions)
+
+
+# See also
+
+Axel fluent talk http://www.youtube.com/watch?v=ifFCZQlndGw
+
+
+
+
+
+

0 comments on commit 9c3e108

Please sign in to comment.