4 ms·

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

by geuis 15y ago

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 of complexity does not help. 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. One of the strengths of object literals is that you can use them as dictionaries. obj.foo === obj['foo']. I love getters/setters and some other improvements like strict mode. However I am very much against what seems like an unnecessary cluttering of the language without fixing some of the long standing problems like ==/===. For me, I almost never use == so it should be gotten rid of. Make == === === for example.

ireadzalot 15y ago
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.
- thaumaturgy 15y ago
  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.
  - chc 15y ago
    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.
    - telent 15y ago
      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
eurleif 15y ago
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.
tlrobinson 15y ago
> 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.
azakai 15y ago
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.
batista 15y ago
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.
- vectorjohn 15y ago
  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.
  - tomjen3 15y ago
    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.
stewbrew 15y ago
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.

by geuis 15y ago

ireadzalot 15y ago

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.

thaumaturgy 15y ago
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.
- chc 15y ago
  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.
  - telent 15y ago
    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

eurleif 15y ago

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.

tlrobinson 15y ago

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

azakai 15y ago

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.

batista 15y ago

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.

vectorjohn 15y ago
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.
- tomjen3 15y ago
  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.

stewbrew 15y ago

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.