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

The Future of JavaScript

blog.chromium.org

Post reply on HN
Print view View original

41–50 of 115 posts

Re: The Future of JavaScript

#41

Post by agscala »

grannyg00se wrote: post #35
agscala wrote: post #29

Earlier quoted context omitted.

The extra keywords aren't going to reduce the "errors and weird behavior", the fact that they will be block-scoped and not function-scoped is what will eliminate the confusion.

It doesn't though. Because how are you ggoing to know that they operate that way? You will have to learn that somehow. And you couldve just as easily learned how var works instead. What's worse.... now you still need to learn how var works anyway! It isn't gone. I see 0 reduction in confusion and +3 increase in cognitive load.

I understand what you're saying, but I'm under the impression that once these new keywords are introduced, everyone will encouraged to use 'let' exclusively and 'var' will be suggested as an advanced feature for special cases.

Re: The Future of JavaScript

#42

Post by eurleif »

geuis wrote: post #30

I'm probably alone in saying this, but I hope most of this stuff never sees the light of day. What makes JS powerful is its simplicity. "var" or no "var" gets you local or global scope. Done. Want a constant? Make a global variable and don't change it. Want to really make sure its unchangeable? Make an accessor function. Scope in JS is very simple to understand and quite versatile once understood. Adding more layers…

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.

Re: The Future of JavaScript

#44

Post by thaumaturgy »

ireadzalot wrote: post #34
geuis wrote: post #30

I'm probably alone in saying this, but I hope most of this stuff never sees the light of day. What makes JS powerful is its simplicity. "var" or no "var" gets you local or global scope. Done. Want a constant? Make a global variable and don't change it. Want to really make sure its unchangeable? Make an accessor function. Scope in JS is very simple to understand and quite versatile once understood. Adding more layers…

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.

Re: The Future of JavaScript

#45

Post by winteriscomming »

fourstar wrote: post #39
winteriscomming wrote: post #27

Is it really not out for 2 years? Really? That seems like a long time for not that much changes. Any improvement is welcome, but still. I don't know if this will keep pace with Dart and other options. It seems way too slow.

Really? You seriously think Dart is anywhere close to taking over Javascript?

No I don't but my point is that 2 years seems a bit slow as far as evolution of JS is concerned.

Re: The Future of JavaScript

#46

Post by elehack »

grannyg00se wrote: post #25

"Now "let" is the new "var" – traditional "var" declarations are complemented with "let" and "const". Both are properly block-scoped bindings, eliminating a common source of errors and weird behaviour." Somehow going from one keyword for variable declaration to three doesn't seem like a good way to reduce errors.

JavaScript's 'var' behavior is a bug codified in specification. It is counter to pretty much any other C-style language; the difference is particularly acute because it breaks closures. So while other languages (e.g. C) could optimize their variable implementation to be like JavaScript's and still make sense, the fact that JS has closures means this breakage becomes visible on a routine basis.

However, they cannot change var's semantics and retain backwards compatibility. So they did the next best thing: introduce a new keyword for variables that work like they should. That keyword is 'let'.

As far as I am concerned, if your JS is known to execute in an environment with 'let', 'var' might as well not exist. Too many subtle errors — “what do you mean, braces don't actually delimit scope?”

Re: The Future of JavaScript

#47

Post by herge »

tikhonj wrote: post #38
herge wrote: post #14

> (Caveat: Iteration over collections is not yet specified) Is this a joke? Is not iterating over dictionaries and arrays javascript's most glaring weakness? How hard would it be to agree on something like foreach, that, you know, actually works the way you think it should work.

There is a foreach that works: .forEach(). And when you're not just iterating over an array but transforming it, you have map(), reduce() and filter().

Is it really too much to ask to have some syntactic sugar. Is

    for i,v in blah
, where i is an index of an array, or a key (not a property!) of a dictionary really too much to ask in 2012?

No wonder people are using coffeescript.

Re: The Future of JavaScript

#48

Post by tolmasky »

grannyg00se wrote: post #40
haberman wrote: post #24

Earlier quoted context omitted.

You might not write: dict["valueOf"] since that's obviously a bad idea, but you might write: dict[user_provided_string] Since user_provided_string could be anything, you are susceptible to unexpected behavior if the string ends up being "valueOf".

But even if you use an arbitrary object....if it comes from a user supplied value you are going to have to validate it somehow. It would be great if the post included good examples of how these things are going to produce better code. Maybe my imagination or experience is just insufficient to see the great win here.

Validated or not there are still many cases where this is a valid key and thus completely breaks the object. For example, this might be a login name, most people would consider it unreasonable to not allow js keywords as logins. For a simpler example, imagine a dictionary of syntax highlighted words for js ;)

There are workarounds of course, but the ironic result is that when you want to use a js object as an actual hash/dictionary (something we are repeatedly told js is great at), your code devolves into a defensive programming mess, requiring constructions like Object.prototype.hasOwnProperty.apply, etc.

Re: The Future of JavaScript

#49

Post by tlrobinson »

geuis wrote: post #30

I'm probably alone in saying this, but I hope most of this stuff never sees the light of day. What makes JS powerful is its simplicity. "var" or no "var" gets you local or global scope. Done. Want a constant? Make a global variable and don't change it. Want to really make sure its unchangeable? Make an accessor function. Scope in JS is very simple to understand and quite versatile once understood. Adding more layers…

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

Re: The Future of JavaScript

#50

Post by wingo »

ams6110 wrote: post #32
agscala wrote: post #29

Earlier quoted context omitted.

The extra keywords aren't going to reduce the "errors and weird behavior", the fact that they will be block-scoped and not function-scoped is what will eliminate the confusion.

I agree with geuis above, JavaScript scope is simple to understand now. There is global scope, and there is function scope. That's it. And there's a certain elegance to that.

There are more scopes than that: free variables versus locals; eval-introduced bindings; "with"; the exception identifier in "catch"; the function name in named function expressions; argument names; etc.

And the scoping rules are quite tricky in practice, to real programmers. To take an example from today:

https://bugs.webkit.org/show_bug.cgi?id=27226#c4

Post reply on HN