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

How One Missing `var` Ruined our Launch

blog.meloncard.com

Post reply on HN
Print view View original

91–100 of 223 posts

Re: How One Missing `var` Ruined our Launch

#91

Post by bzbarsky »

morsch wrote: post #63
Raticide wrote: post #49

Earlier quoted context omitted.

Yeah, that's all he needed. Making it a comment isn't necessary either. Maybe Node should be strict by default? I can understand it not being the case for browsers that need to support legacy code, but for Node it doesn't really need to care about that.

Huh. On the scale from pragmatic idiosyncrasy to simply bizarre, making a string literal expression change the runtime behaviour in that manner is fairly wide towards the bizarre end of the scale. I think, if anything, requiring it to be in a comment would have been less odd; at least comments imply a sense of "meta"-ness.

Comments are commonly stripped by various source code processors out there, including minifiers and some browser JS engine front-ends.

The string literal doesn't make anyone _happy_, but it was most compatible with the existing widely deployed toolchains, as I understand.

Re: How One Missing `var` Ruined our Launch

#92

Post by rajeshamara »

Actually it is very easy to debug any javascript error. In IE there is a setting where you can uncheck the Disable Script debugging (Internet Explorer) and in the status bar you will see any javascript error. If you check the checkbox IE will not report any errors. In general during your development you should always uncheck the box.If you double click the javascript status this will exactly report the line number where the javscript error is. I exactly don't know if you see these kind of errors in Chrome and firefox. I know people blame IE but there are quite few nice handy features which are very helpful during development

Re: How One Missing `var` Ruined our Launch

#93

Post by bzbarsky »

FuzzyDunlop wrote: post #35

JS is so easy to cock up in, I commonly find myself logging to the console just to make myself sure of the scope and other things. This technique totally went to shit when I came across one of our scripts that gratuitously used `apply()` all over the place. The other common error is array iteration, and I've not quite understood why iterating through one array in the same scope as where it was created works fine, but…

    > also goes through the prototype methods after the
    > elements.
That shouldn't be happening. If you see it happening, your JS implementation is just buggy.

In fact, this testcase:

    
      window.onload = function() {
        var arr = window[0].arr;
        for (var i in arr) { alert(i); }
      }
    
    arr=[1];">
alerts only "0" in WebKit+JSC, Gecko, Presto. Chrome has some sort of bizarre security policy here that keeps the script from working, so no idea what WebKit+V8 does.

Re: How One Missing `var` Ruined our Launch

#94

Post by bzbarsky »

ww520 wrote: post #61
jessedhillon wrote: post #45

Do I understand this right -- global variables are shared across all requests in node.js? If so, that is an insane design.

Well, that's what global variable means, shared among all functions in the process. Since there's only one process to handle all requests, they can access the global variables. All languages used in web server that don't spawn a new process for each request have the same feature.

In JS, "global variable" means "property of the global object". No reference to "process".

It's trivial to have a single-process JS application with multiple JS global objects in it. Case in point: any web browser (and renderer processes don't change this: every iframe on a page has a separate global object).

It's just that Node _chose_ to reuse the same global object for multiple requests instead of using a clean execution environment.

I have to agree with jessedhillon: that sounds insane.

Re: How One Missing `var` Ruined our Launch

#95

Post by bzbarsky »

fennecfoxen wrote: post #53
jessedhillon wrote: post #45

Do I understand this right -- global variables are shared across all requests in node.js? If so, that is an insane design.

Global variables are basically instance variables on the process itself. They're going to be shared across all requests in all environments that handle more than a single request per process. If they had different semantics, they wouldn't really be what normal people call "global variables", would they? So you just don't use them and everything's good. Which brings you to the real problem: JavaScript makes it distres…

    > Global variables are basically instance variables on the
    > process itself.
Not in JS. See my response to ww520 below.

Re: How One Missing `var` Ruined our Launch

#96

Post by bzbarsky »

dbattaglia wrote: post #52
jessedhillon wrote: post #45

Do I understand this right -- global variables are shared across all requests in node.js? If so, that is an insane design.

Node is single-threaded, so yes they are shared. Requests are basically just multiplexed inside the same message loop. In my opinion it wouldn't be quite as scary if js didn't make it so damn simple to accidentally define a global variable (like in this instance, where it was never actually declared in globally-scoped code).

Why does threading matter? You can have multiple JS global objects all running on the same thread. See any web browser.

Re: How One Missing `var` Ruined our Launch

#97

Post by kijin »

morsch wrote: post #63
Raticide wrote: post #49

Earlier quoted context omitted.

Yeah, that's all he needed. Making it a comment isn't necessary either. Maybe Node should be strict by default? I can understand it not being the case for browsers that need to support legacy code, but for Node it doesn't really need to care about that.

Huh. On the scale from pragmatic idiosyncrasy to simply bizarre, making a string literal expression change the runtime behaviour in that manner is fairly wide towards the bizarre end of the scale. I think, if anything, requiring it to be in a comment would have been less odd; at least comments imply a sense of "meta"-ness.

Not to mention that it reeks of VB6's "Option Explicit" and "Option Strict" statements. I hated those.

Re: How One Missing `var` Ruined our Launch

#98

Post by samgro »

crichardson917 wrote: post #11

Very interesting. I've been thinking about delving into Node.js for a while, and I will definitely keep things like this in mind.

Do yourself a favor and use CoffeeScript! You will never have to worry about this or any number of other trivial JS mistakes, plus your code will be more readable and more fun to write. Win/win.

Re: How One Missing `var` Ruined our Launch

#99

Post by startupcto »

"It’s a damn tragedy.  I’m not an expert in JavaScript"

Hell yea, the valley's full of smart kids who don't know what the hell they're doing with JavaScript and thinks they're one hell of a hacker when they discovered that they can do shit with a few lines of JS and trumpeting on the how great NodeJS or whatever the greatest and newest shiny framework out there.

If you don't really understand scoping in JS, please don't use node and hit yourself on your foot and then blog the cool shit out of it.

I'm just saying, no hard feelings. :)

Re: How One Missing `var` Ruined our Launch

#100

Post by rayiner »

MostAwesomeDude wrote: post #69
rayiner wrote: post #48

Why has it become popular for dynamic languages to conflate establishing a binding with assigning it a new value? Ruby, Python, and Javascript are all guilty of this. Scheme got it right sometime in the 1970's. (let ((x initial-value)) ; binding (set! x new-value)) ; assignment Or in infix syntax (Dylan): let x = initial-value ; x := new-value ;

Python doesn't let you write outside of local scope without a special keyword. Exactly the inverse of JS. If you want to write to global state, and you're aware that you're writing to global state, then you use the "global" keyword. That's all.

It still conjures up variables out of thin air.

    sum = 0
    for v in someList:
        smu += v
    print sum # prints 0, doh!
Post reply on HN