This is from Douglas Crockford's talk, "An Inconvenient API - The Theory of the DOM," which is perhaps the best title ever for a programming lecture. The way he adapted Al Gore's cover art is so inspired, it's just sheer perfection.
A nice article, I have been trying to learn more about javascript recently, and the section about "this" reminded me about a nice moment I had while tring to learn.
I used to get confused about how the "this" binding worked in javascript. My moment of clarity came when I tried to do something like this:
Doing this kind of thing didnt work with the conceptual model of "this" I had from my years of C# where functions are bound to objects.
Then I realised that ofcourse the object referred to by "this" would have to change, how else would it be implemented when you have first-class functions that can be passed around freely without a lexically captured "this"?
Now I see as "this" more of an attempt to keep familiar syntax than something that fits with the semantics of the language. It really seems more of a call-context.
That section on Javascript security is pretty brief, I'd like to add some others from websites that I've tested:
* Take document.location.href and document.location.hash as unsanitised input especially if they're affecting DOM.
* Avoid using innerHTML or jQuery's .append(), they slow down the page with reflow and make it easier to inject code into the page.
* Always write regex to match the minimum it needs to; Javascript code is visible to the client and therefore anyone who wishes to find and abuse exploits, completely avoiding iterative testing to determine regexes that generate links and other code.
* Remember that because jQuery has a lot of syntactic sugar, doing $("#bac" + myString) can do a lot more than just select from a set of similarly id'd nodes.
16 comments
[ 0.18 ms ] story [ 53.1 ms ] threadI don't want to nitpick but DOM is just an API (of W3 origins, which also makes it a standard).
"The DOM is not a JavaScript concept. It is an object model for web browsers"
The first part is correct, but the second is a little off. You might want to say "used _by_ web browsers..." or something along those lines.
http://www.youtube.com/watch?v=Y2Y0U-2qJMs
"‘JavaScript: The Good Parts‘ ... the book is thin".
someObject.someFunc = anotherObject.someOtherFunc;
Doing this kind of thing didnt work with the conceptual model of "this" I had from my years of C# where functions are bound to objects. Then I realised that ofcourse the object referred to by "this" would have to change, how else would it be implemented when you have first-class functions that can be passed around freely without a lexically captured "this"?
Now I see as "this" more of an attempt to keep familiar syntax than something that fits with the semantics of the language. It really seems more of a call-context.
People doing OO-style inheritance in js probably want to go down the ES5 Object.create route, rather than reassigning prototypes.
http://uxebu.com/blog/2011/02/23/object-based-inheritance-fo...
* Take document.location.href and document.location.hash as unsanitised input especially if they're affecting DOM.
* Avoid using innerHTML or jQuery's .append(), they slow down the page with reflow and make it easier to inject code into the page.
* Always write regex to match the minimum it needs to; Javascript code is visible to the client and therefore anyone who wishes to find and abuse exploits, completely avoiding iterative testing to determine regexes that generate links and other code.
* Remember that because jQuery has a lot of syntactic sugar, doing $("#bac" + myString) can do a lot more than just select from a set of similarly id'd nodes.
This made me chuckle for reasons entirely unrelated to JavaScript and prototypal inheritance. :)