JavaScript: The Important Parts(benlakey.com)
benlakey.com
JavaScript: The Important Parts
http://benlakey.com/2013/05/26/javascript-the-important-parts/
10 comments
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.
* 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.
Having never particularly enjoyed working with JavaScript, this gave me a chuckle:
"‘JavaScript: The Good Parts‘ ... the book is thin".
"‘JavaScript: The Good Parts‘ ... the book is thin".
It's really thin: http://3.bp.blogspot.com/-uPZ2b48viTk/TflhMaivRHI/AAAAAAAABC...
I left this comment in the article, but it hasn't shown up yet.
I 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.
I 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.
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.
http://www.youtube.com/watch?v=Y2Y0U-2qJMs
http://www.youtube.com/watch?v=Y2Y0U-2qJMs
[deleted]
eval is not only dangerous, it is also a very expensive operation. If you put eval inside a for loop you are going to have a very slow program.
And if you do DOM manipulation inside an eval... god help you.
Maybe we should also brand Mozilla's asm.js as "JavaScript: The Fast Parts".
The question burning everyone's lips is: "What's the intersection between the Javascript 'Important' and 'Good' parts?
Why does Object.prototype keep making it on those lists? Hands up please if you have used inheritance in JS (or any language) lately.
raises hand. I'm sure most people building frontend applications in js with MVC patterns are using inheritance.
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...
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...
'All of this means that it doesn’t matter what an object’s lineage is, only what it can do at the moment.'
This made me chuckle for reasons entirely unrelated to JavaScript and prototypal inheritance. :)
This made me chuckle for reasons entirely unrelated to JavaScript and prototypal inheritance. :)
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.