Live data from Hacker News

JavaScript Garden

bonsaiden.github.com

21–30 of 51 posts

Re: JavaScript Garden

#21

great design (in addition to the content). How did you make it? I like the right contents column changing topic as I read.

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

Re: JavaScript Garden

#22
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…

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

Might also come in handy if you are into functional programming with Javascript.

Re: JavaScript Garden

#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

Re: JavaScript Garden

#25
post #18
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…

There'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.

Re: JavaScript Garden

#26
Should 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.

Re: JavaScript Garden

#29
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 encapsulate your code and then you don't have to use this and risk clobbering the global window object :)

Re: JavaScript Garden

#30

the 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?

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.

Post reply on HN