Hacker News Reader

> One of the strengths of object literals is that you can use them as dictionaries. obj.foo === obj['foo'].

I believe Harmony sets allow you to use any object as a key, whereas using a plain JavaScript Object instance will coerce the key to a string and use that as a key. There is no non-hacky way to do this in JavaScript currently. You either need to us an array (making lookups O(n)), or give objects a UID to use as the key.

Even if you're just talking about sets with strings as keys, there are lots of edge cases waiting to bite non-experts. For example, what if you want your set to have a key called "toString"? Every JavaScript object already has that method, so if you naively test "set[key] !== undefined" or "key in set" with "toString" as the key you always get true. Ok, so use "set.hasOwnProperty(key)". Now what if you happen to have a key called "hasOwnProperty" and you mask the builtin function? So really you should be using "Object.prototype.hasOwnProperty.call(set, key)". Additionally, now you're making a function call, which could add significant overhead in tight loops.

I don't think this makes scope in JS much more complicated. If you were teaching JavaScript to someone, you'd either not mention let (if old browsers still matter), or not mention "var". You wouldn't ever need to tell a newbie about both. "const" is extra, but is it really so complex?

>One of the strengths of object literals is that you can use them as dictionaries. obj.foo === obj['foo'].

That's not a strength when it means you can't use anything other than strings as keys. It destroys your ability to 'treat functions, types, literals, etc in interesting ways' if those interesting ways involve using them as dictionary keys.

>For me, I almost never use == so it should be gotten rid of.

Backwards compatibility.

In my experience, the charm of simplicity of JS starts fading away when you start moving away from DOM manipulation and start writing complex objects. Just last week I ran into the lexical scoping issue ( I was not aware of it before) that had me scratching my head for hours. Scoping in JS becomes less fun the deeper you start digging. I am glad that they are aware of it and are actively trying to address it.

I agree with geuis, and I've written a personal-use JS framework that's in the same ballpark as jquery. I've run into the lexical scoping issue, but not for a long time. Straightforward naming conventions and Firebug can track down scoping problems really quickly.

I'm not really opposed to the changes to JS that are mentioned on the Chromium blog, but mostly because I don't have to use them. I don't really see the point of any of them -- and practically speaking, they won't see widespread use anyway until IE 9 dies out -- but maybe I'm just not imaginative enough to understand yet.

I very rarely have problems with JavaScript scoping or any of those obvious gotchas, but I still don't agree that they are good. We've just become acclimated to the language's eccentricities, the same way people living in Arizona for a long time think California summers are chilly.

It is true that JavaScript's scoping rules are pretty simple, but less is not always more. Once you have learned all the patterns and gotchas, JavaScript's scoping is quite usable. But the fact that you have to use patterns where you wouldn't in another language means JavaScript is making work for you. If JavaScript had Lispy macros or some other way of altering the language, I might be more inclined to agree that the fundamental simplicity is a good thing, but without that power, the simplicity means that when you're doing complex things, the complexity missing from the language has to be written out explicitly in your code. Right now a lot of JavaScript code is a mix of function pasta and things that should be function pasta but the coder couldn't be bothered.

Yes. "let x=1" is quite clearly syntactic sugar for "(lambda(x) { ... rest of block here ... })(1)" so while you might argue that it's unnecessary (I'd disagree, but it's a respectable argument), you can't realistically claim that it would be adding a layer of complexity. The complexity is there already: the sugar is just encapsulating in a more eyeball-friendly format

I agree that unneeded complexity is bad, but not sure I agree on all the points. "let" for example adds a keyword, but it allows you to avoid a big common cause of bugs in JS (using var in loops with closures, that capture the last value in the loop). If we could, then removing "var" and replacing it with "let" would be better - but that would be a huge change, to remove "var".

> I'm probably alone in saying this, but I hope most of this stuff never sees the light of day.

In any case, this stuff is seeing the light of day. It's been in Firefox for a while, and is now being implemented in Chrome. That means two independent implementations, which is crucial for the standards process, we can expect the other browsers to follow Firefox and Chrome on this.

    So the bit about "no more need to abuse objects as dictionaries" is a bit odd. Since most things are objects, you get the power to treat functions, types, literals, etc in interesting ways.

I think this was about performance of the underlying data structure. In this sense, a specialized collections data structure will be an "object" too.

What makes JS powerful is its simplicity.

Wrong. What makes it powerful is its ubiquity and the fact that it's de facto the only game in town for browser behavior scripting.

Want a constant? Make a global variable and don't change it.

That involved mental overhead (and team co-ordination) that makes it far less simple than "const foo".

Scope in JS is very simple to understand

Simple != intuitive or less prone to bugs. Brainfuck is also simple to understand, just a handful of rules. I wouldn't want to program in it, though...

One of the strengths of js is that every thing is an object(almost). So the bit about "no more need to abuse objects as dictionaries" is a bit odd. Since most things are objects, you get the power to treat functions, types, literals, etc in interesting ways.

Yeah, the only thing you DON'T get is an actual dictionary. Without hidden values coming from prototype, without reserved words, etc.

This proposals retains all that power PLUS gives you an actual bloody dictionary, one of the three more basic data structures in all of programming, without the toil and the million edge cases objects as dicts have.

For me, I almost never use == so it should be gotten rid of.

So what you consider as strengths are the shortcomings, and what you consider as a problem is an actual case that it can be considered a neat feature. The way js is designed, "==" makes more sense, because it lets you use more dynamic equality checking.

Wrong. What makes JavaScript popular is how good it is. You can't explain its mass popularity growth in non browser setting (node js ) with its ubiquity. It is a great language, and perhaps ubiquity was needed to get a lot of people to try out new concepts.

Have you used Javascript? I mean to do real-web apps, not to enhance some webpages with a bit of JQuery (as useful as that is).

Var is broken in js because it does not obey sensible semantics

    for(var i....

does what you think it does. In every language except javascript it would declare i only inside the loop. In js it declares i in whatever function scope the loop is inside.

    A = function(){
        console.log(this);
    }
    A.prototype.q = function(b){
        this.h = b;
    }

    imp = new A();
    setTimeout(100, imp.q)

    //later, in a response to a user event
    console.log(imp.h)

prints undefined. Why? because in Javascript the value of this changes. There is literally no other language where this is dynamically (as opposed to lexically) scoped.

Don't even get me started on the lack of ints, the lack of static types (which means your IDEs suck).

As for why node decieded to go with js? No idea, though it is one of the things I hate most about node. Haskell would have been a better choice, as would Lua.

> Var is broken in js because it does not obey sensible semantics

Scoping is broken in pretty much all modern dynamic languages.

Take Ruby for example:

    i = 10
    [1, 2, 3].map{|i| i * 3}
    [1, 2, 3].map{|j| j * 3}
    puts i # prints 3
    puts j # raises undefined local variable

Or let's look at Python:

    def maybe_append(b=[], n = None):
        if not n is None: b.append(n)
        return b
    print maybe_append(n=20) # prints [20]
    print maybe_append(n=30) # prints [20, 30]

So there's only a single instance of [], so that the default argument "grows" over time.

It's things like this that make me realize how right Clojure gets it (and I've been burned by python on that same "bug").

Your argument makes it pretty clear it is you that have not used Javascript very much.

setTimeout( 100, imp.q) // DOESN'T DO ANYTHING, 100 is not a function

And if you thought about it for more than a few seconds, you would realize that the behavior of "this" makes sense and is less magical than in other languages. Since "imp.q" is not a function call, it is a reference to a function, you are simply passing in a function. Since javascript "classes" are just objects with function references, you can't somehow decide what object "this" should point at unless it is explicit. In the case of "foo.bar()", it is explicitly "foo". In the case of setTimeout( foo.bar, 100), all setTimeout gets is a function pointer with no notion of what this should be.

Anyway, the rest of your gripes just sound like you don't like untyped languages, which is personal preference and I guess I don't share your preference.

I haven't used setTimeout much, but I do use js everyday (it is my fulltime job).

And it may be nice to have 'just objects with function references' when you are writting a few lines of code to validate emails or something like than. When you start pushing 2k lines of code and more than two developers you need much more structure than than that. Anyhow C++, Scala and C# all have reasonable understanding of this. If all you have are function points, don't have this.

> What makes JavaScript popular is how good it is.

If you are trying to be sarcastic, you are not doing it right.

Hah, no reason to get defensive. Javascript is a great language. If you don't like it, you are free to feel that way. But there is a huge number of people who like it. Personally, it is my favorite programming language. It just feels right.

And I've only been using it for a few years. It really isn't hard to get past the bad parts.

Wrong. What makes JavaScript popular is how good it is. You can't explain its mass popularity growth in non browser setting (node js ) with its ubiquity.

Sure you can. Node.js is not even that impressive: similar solutions exist in lots of other languages, Ruby, Python, even Java. The Node guy wrote Node in JS for two reasons: V8 was a good and fast environment, and JS didn't have much existing libraries, so people could start making new async libs.