Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Garden

bonsaiden.github.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: JavaScript Garden

#31

Post by wvenable »

amadeus wrote: post #30
netghost wrote: post #17

Earlier quoted context omitted.

I 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.

Well 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.

With 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.

Re: JavaScript Garden

#32

Post by alexyim »

One 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' )

Re: JavaScript Garden

#33

Post by CrabDude »

csomar wrote: post #18
tkiley wrote: post #15

Excellent 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 lo…

Be 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…

Just take a page from the book of Resig and force a constructor, 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/Functi...

Re: JavaScript Garden

#35

Post by Tomek_ »

benjisg wrote: post #29
tkiley wrote: post #15

Excellent 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 lo…

There is actually a much better way to make private functions and properties in JavaScript using the module pattern and closure. Since all functions are objects in JS, you can create a function with some internal (private) functions and properties than return a object with some publicly accessible functions. A basic example: https://gist.github.com/866343 Closure gives you a really powerful structure that lets you en…

It's basically the same thing, closure is the name of the game here. Your solution is probably a bit more costly for memory though.

Re: JavaScript Garden

#36

Post by Tomek_ »

mrspeaker wrote: post #2

This 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" ;)

It'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 or that the book advocates extending native objects (including "Object").

Re: JavaScript Garden

#37

Post by BonsaiDen »

amadeus wrote: post #30
netghost wrote: post #17

Earlier quoted context omitted.

I 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.

Well 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.

The statement comes from experience, extended stuff is bad just bad for you. jQuery and others are dropping the use of hasOwnProperty. So if you extend stuff and include one of these libs, they will break. The devs just don't care anymore. Also, there are people who are even more against it that really say NEVER EVER extend them, not even for the sake of backwards compatability.

Also, my guide isn't even need the controversity of some of the statements that Crockford has made ;) In the end it's all advice, I'm not forcing you to write code this way.

In fact, I like it when people question the stuff I write, the worst thing that can happen is that people pick one book/guide whatever and just follow it 100% without ever thinking on their own.

Re: JavaScript Garden

#38

Post by BonsaiDen »

ck2 wrote: post #24

Very 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

We 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.

Re: JavaScript Garden

#39

Post by amadeus »

wvenable wrote: post #31
amadeus wrote: post #30

Earlier quoted context omitted.

Well 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.

With 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.

Actually, 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.

Re: JavaScript Garden

#40

Post by amadeus »

BonsaiDen wrote: post #37
amadeus wrote: post #30

Earlier quoted context omitted.

Well 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.

The statement comes from experience, extended stuff is bad just bad for you. jQuery and others are dropping the use of hasOwnProperty. So if you extend stuff and include one of these libs, they will break. The devs just don't care anymore. Also, there are people who are even more against it that really say NEVER EVER extend them, not even for the sake of backwards compatability. Also, my guide isn't even need the con…

Again, it's not 'bad for you'. You don't NOT use a hammer because it doesn't work well with screws. It works great on nails, so again, context is everything. Supplying best practices that include the words 'always' or 'never', often fall quite short and don't serve people well.
Post reply on HN