8 ms·
JavaScript Garden
- mrspeaker 16y agoThis looks like an excellent resource for when you are too lazy to get up out of your chair and pick up your copy of "JavaScript: The Good Parts" ;)
- gregory80 16y agoI thought the exact same thing, especially when I caught the "the evil eval" header. Still, handy to have the reference online.
- Tomek_ 16y agoIt's a great book but one has to note that not everything there is "how things should be done" these days, Crockford himself has changed his mind on some of the things he wrote there. Take this as for example: http://www.bolinfest.com/javascript/inheritance.php http://www.bolinfest.com/javascript/inheritance.php or that the book advocates extending native objects (including "Object").
- senorpedro 16y agosimilar: http://wtfjs.com/ http://wtfjs.com/
- csomar 16y agoDoes anyone have an idea of what happened to "The secrets of the JavaScript ninja"? I'm impatiently waiting for this book to be released.
- grigy 16y agoSame here. Meanwhile you can run through this tutorial if you haven't done yet: http://ejohn.org/apps/learn/ http://ejohn.org/apps/learn/
- halostatue 16y agoIt's in review (I'm an occasional Manning reviewer and have looked at this recently).
- Charuru 16y agoThis is like a prettier version of JavaScript in ten minutes. Thanks!
- koraybalci 16y agogreat design (in addition to the content). How did you make it? I like the right contents column changing topic as I read.
- pistoriusp 16y agoThe position of the articles are stored in an array when the dom is loaded. When the document scrolls it compares the scroll position to the stored offset positions. If an article is close enough to the scroll offset it's highlighted.
- simpsond 16y agoVery good job.
- andreyf 16y agoIn the prototype example [1], could someone explain the point or at least the effect of setting Bar.prototype.constructor = Bar? 1. http://bonsaiden.github.com/JavaScript-Garden/#prototype http://bonsaiden.github.com/JavaScript-Garden/#prototype
- nfriedly 16y agoA couple of lines up you see this: Bar.prototype = new Foo(); Then, Bar.prototype.constructor == Foo() So when you create a new instance of Bar, it's constructor still appears to be Foo even though it really isn't. Setting the prototype.constructor fixes that.
- Ruudjah 16y agoWell written, clear syntax highlighted examples. Upboat.
- extension 16y agothe native prototypes should never be extended unless it is for the sake of compatibility with newer JavaScript features A bit controversial, don't you think?
- netghost 16y agoI think it's more of an issue of who is doing the extending. If it's your own code in a non shared library, then it's up to you. If it's in a shared library, it is probably nicer to avoid. For instance, if you override a function on a native prototype, you might be overwriting some future function that browsers will implement. I've seen this done with Array.map for instance.
- random42 16y agoThis is the case with extensions/inheritence in all the OO languages. You are supposed to verify that your extended library works, once you upgrade the base library.
- amadeus 16y agoWell that's why the statement is controversial. This person flat out says, NEVER extend native prototypes except for 1 single case. Sorry, but blanket statements like that are complete B.S. It all depends on context; it makes me dubious of the rest of this article if they can get away with statements like this.
- wvenable 16y agoWith JavaScript, it's still extremely good practice -- you don't know what code you might break by extending the native prototypes. You may make it hard to integrate your code with libraries or other code. It's really not that controversial.
- amadeus 16y agoActually, that's still the point though. If you are building a library to be used in a variety of contexts, with no prior knowledge of the environment, it's probably not a good idea to extend native prototypes. If however, you are building a site or web app (like the majority of Javascript developers, I would assume), then the benefits of extending prototypes within your app can provide great advantages and keep your code much cleaner. So again, I am not saying don't extend, and I am not saying extend, I am simply saying, that I agree that one should err on the side of caution and asses the situation for which they are coding for and make a decision regarding those circumstances. Simply saying a best practice is to 'never' do it to me is quite short sighted and is not properly educating new developers on how to write good Javascript. For the record, I have often extended natives within my applications, and have never once had a conflict.
- tkiley 16y agoExcellent write-up! I've learned most of these things the hard way :/ I'm filing this away to recommend to any developers who are setting out to use Javascript extensively for the first time. One quibble: In the "common pitfalls" section regarding the "this" object, they say that locally-defined functions within other functions never have any practical use. I might disagree: with a little coaxing, you can convince locally variables inside the constructor (both functions and other variables) to serve as private properties of an object; this is the only technique I know that allows for private properties. (I haven't actually done this in code that has been maintained/used anywhere, I just did it as an experiment and filed it away as a "that's cool" for future reference) Edit: Here is an example of what I'm talking about: https://gist.github.com/866103 https://gist.github.com/866103
- csomar 16y agoBe careful of that. There is a trap right there. Your example is using the "new" keyword and not executing the function. So what happened? 1. If you use the "new" keyword, and don't execute the function. "x = new foo()". X becomes an "object". "foo()" is behaving like a class. You got to define the properties and methods of this class with the "this" keyword. Once you create your object with the "new" keyword, these variables got assigned to the object. And better, you can access them with the prototype. 2. If you execute the function in your code, that is you put "foo()": Open your FireFox with FireBug and notice two new global variables in the Windows object "get_my_private" and "set_my_private". So it depends on the usage. "this" insides of a function is useful, if your intent is to use the function as a class. If not, it's dangerous, as the variables becomes global and may interfere with other variables.
- Groxx 16y agoThere's an easy way to fix that, though: function Foo(){ if (this == window) throw "USE NEW!"; // continue with object creation } Or use the standard practice of having class-creating function names capitalized, and let people know to follow it.
- CrabDude 16y agoJust take a page from the book of Resig and force a constructor, http://ejohn.org/apps/learn/#36 http://ejohn.org/apps/learn/#36 : function User(first, last) { if ( !(this instanceof User) ) return new User(first, last); // constructor logic } Or a more robust slightly less "performant" version: function User(first, last) { if ( !(this instanceof arguments.callee) ) return new arguments.callee(arguments[0],...); // constructor logic } Note: arguments.callee is less "performant" than using a named function, but it does allow the 2 lines to be copied and pasted without alteration. Also, in case someone mentions it, arguments.callee is not deprecated (arguments.callee.caller and Function.arguments.callee are though). Documentation: https://developer.mozilla.org/en/JavaScript/Reference/Functions_and_function_scope/arguments/callee https://developer.mozilla.org/en/JavaScript/Reference/Functi...
- hanifvirani 16y agoLooks helpful and is neatly presented. It would be great to have something like this replicated for other languages.
- ck2 16y agoVery well done. I'd add under setTimeout and setInterval that anything below 8ms may not work as expected across different browsers/hardware. Even setting 1ms to indicate "as soon as possible" may not occur as expected when repeatedly called. also: the font size is a little small for my eyes in the code boxes - I can fix it of course with stylish but maybe that can be addressed directly on the site
- BonsaiDen 16y agoWe have a newer version of the website in the works, but it's getting delayed to my new job. I hardly have anytime at the moment to work with Yi Jiang on the style since I spend 5 hours a day sitting in a train. But that will change as soon as I manage to move.
- btipling 16y agoShould probably also mention the Function constructor in the eval section. Also object keys are always are type cast into strings so object[1] = "moo" becomes object["1"], this is rarely a problem but can be.
- sawyer 16y agoLove it; I'll definitely switch to strict equality comparisons from now on!
- Kilimanjaro 16y agoEveryday you learn something new Number.prototype.times=function(fn){ for(i=0;i<this;i++){ fn(i); } } 3..times(alert)
- atuladhar 16y agoBut then, "native prototypes should never be extended unless it is for the sake of compatibility with newer JavaScript features."
- zoul 16y agoIf somebody’s wondering about the double dot like me: “A common misconception is that number literals cannot be used as objects. That is because a flaw in JavaScript’s parser tries to parse the dot notation on a number as a floating point literal.”
- alexyim 16y agoOne gotcha I've noticed a lot is when people forget to check for Console object. Or they might do this (doesn't work): if(!console) instead of if(!window.console) or if( typeof console === 'undefined' )
- amadeus 16y agoI have to plug my console wrapper which takes care of problems like these :) https://github.com/amadeus/dbg https://github.com/amadeus/dbg
- wkasel 16y agoVery useful.
- tomelders 16y agoI've seen so many people insist that Javascript code should be Semicolon free recently. It always felt wrong to me, mainly because I code in several languages and getting into the habit of not using semicolons felt dangerous. It's nice to know there's a genuine reason to continue using them.
- kifou1 16y agoThanks for the tips, very intresting
- roryokane 16y agoThis site is too light on details for me to trust its conclusions. Under “The evil eval”, it concludes that you should never use eval simply because it sometimes executes in global scope. That does not seem like an obvious conclusion to me. Yes, it’s a mistake to use it on user input, but that is easily avoided. I think the site should give an example of a situation where you think you need eval, the problems eval necessarily brings in that case, and how to write that without eval. Otherwise, I don’t trust that the site writer has actually explored why people use eval or what eval might be able to provide that nothing else can. Also, under “Automatic semicolon insertion”, the site does not mention the alternative to using semicolons everywhere, which is not using semicolons but remembering to put a semicolon before each line starting with parentheses. That is a valid alternate practice, and the site ignores the possibility without even discussing its problems. The fact that each of those two sections contain grammar mistakes (comma splices) also signals a lack of attention to detail.
- roryokane 16y agoWhy the downvote? I thought I gave ample justification for my criticisms of the article, and my criticisms were constructive.
- kaffiene 16y agoThis site, and Crockford's book both read to me like "numerous reasons not to use Javascript" It's like JS is trying to rival C++ for having the most cases where sensible looking syntax will do something completely batshit insane. I don't care if it's the lingua franca of the net, I hate it. And I code in JS all the time.