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

81–90 of 115 posts

Re: The Future of JavaScript

#81

Post by vectorjohn »

batista wrote: post #68
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…

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…

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.

Re: The Future of JavaScript

#82

Post by sirclueless »

grannyg00se wrote: post #55
wingo wrote: post #50

Earlier quoted context omitted.

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

Looking at that example, I would ask ....where exactly is that function definition getting defined? Why would you put a function definition inside a catch block? Do you think it's getting defined when the catch block is called? Are you programming in Javascript, or are you just writing javascript the way you would write code in some other language?

It's a pretty straightforward use-case: you have a function that returns a function, and in the case of an internal error, you want the returned function to have a reference to the error object. And the only reliable way to do that is to declare a variable with function scope, declare a function in function scope, and conditionally return this function? That's absurdly broken.

As for variable scoping rules, if you have never been bitten by loop counters being used improperly, then I assert that you haven't programmed enough javascript. There are so many ways to mess this up: forget a var declaration and it leaks scope -- and since you can only declare it once, you can't just always use "for (var i = ...". If you want to defer access to a loop counter, then you have to remember to explicitly pass it by value to an inner closure. That last one in particular bites me all the time -- JSLint at least warns you about the first one.

Re: The Future of JavaScript

#83

Post by Baggz »

substack wrote: post #61

I really dislike what they're doing with modules because it's such a step back from the commonjs-inspired require() that node uses. In node, require() just returns a value. That value is usually an object but often it's just a function. Why should a module that encapsulates exactly one function return anything else but that one function? In ES.next, you've got to use pythonesque `import y from Bar` statements which i…

+1

Re: The Future of JavaScript

#84

Post by tomjen3 »

vectorjohn wrote: post #81
batista wrote: post #68

Earlier quoted context omitted.

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…

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.

Re: The Future of JavaScript

#85

Post by tomjen3 »

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?

I two years? I hope so (I use Javascript and hate it) but either way 2 years is 17 major releases of Chrome away. Much can happen before then.

Re: The Future of JavaScript

#86

Post by JoshTriplett »

marknadal wrote: post #79

Could somebody clarify, but I feel like I won't ever use this. Older browsers won't understand these new "features", so I still will have to code as I am used to. So I guess in 20 years... I might dabble with them.

You can use this any time you know your target environment. For instance, if you write JavaScript for Firefox addons, Greasemonkey scripts, Chrome extensions, or node.js, you know exactly what JavaScript engine you'll run on, and you can take advantage of new JavaScript features that engine implements.

You can also use new JavaScript features the same way you use other new browser features like WebSocket or cross-domain xmlHttpRequest: when you've determined that all the modern browsers implement the feature you care about. The browser vendors reach a point where they stop supporting older versions with security updates and similar; I'd consider it reasonable to stop supporting a browser when it stops receiving security updates. (You should also evaluate your audience and the browsers they actually use.) At that point, older browsers get the same experience as links or wget: they get the content, but not the enhancements provided by JavaScript or whatever other features you use.

Re: The Future of JavaScript

#87

Post by laktek »

heydenberk wrote: post #10

The post links to an outdated Proxy spec. Here's the right link: http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxie...

It seems Chrome actually implements the old proxy API, not the new direct proxy API.

It has the old Proxy.create() instead of Proxy.for(), which is the way to define a proxy as per direct proxy API.

So if anyone wants to implement proxies in current Chrome, they have to refer to the old proxy API (which is why they have linked to it).

Re: The Future of JavaScript

#88

Post by telent »

chc wrote: post #52
thaumaturgy wrote: post #44

Earlier quoted context omitted.

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 po…

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 go…

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

Re: The Future of JavaScript

#89

Post by jd »

tomjen3 wrote: post #84
vectorjohn wrote: post #81

Earlier quoted context omitted.

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

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

Re: The Future of JavaScript

#90

Post by [deleted] »

tomjen3 wrote: post #84
vectorjohn wrote: post #81

Earlier quoted context omitted.

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

[deleted]
Post reply on HN