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

91–100 of 115 posts

Re: The Future of JavaScript

#91

Post by moonchrome »

jd wrote: post #89
tomjen3 wrote: post #84

Earlier quoted context omitted.

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

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

Re: The Future of JavaScript

#92

Post by samth »

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…

I'll try to separate out the different issues you're raising here, and respond to each individually.

1. What if I want to have my module be a function, the way that $ in jQuery is both a function and a namespace for the rest of the functionality?

This is an important use case, and so we're going to support it in ES6 modules. You'll be able to say:

    module $ at "http://jquery.com/jquery.min.js";
    $(...)
    $.ajax(...)
2. Modules will requiring using names without the prefix.

This isn't true. As you can see in the above example, you can just use $ directly, even though it's a module. You can also say:

   import ajax from $;
but you don't have to.

3. We should just standardize the node module system.

Of course, there are many different module systems being used in JS code right now, and we could just pick one. Unfortunately, we couldn't just pick the node module system, since it's fundamentally synchronous, which is great on the server side but not in the browser.

However, we feel that we can bring real advantages to JS programmers by extending the language -- we can simplify using modules, we can make some patterns direct that currently have to be written using callbacks, we can better support encapsulation, and we can allow engines to use knowledge about modules for optimization.

3. Static analysis is doable even without a static module system.

The static analysis you describe, while useful, isn't going to tell an engine statically where it can go to lookup references to an export from a module. That means it's not useful for many of the optimizations that we want to enable. Additionally, your analysis isn't sound -- it can miss uses of `require` that are generated dynamically, for example. Again, that means that engines can't use it for optimization.

Finally, if you have comments about ES development, I strongly encourage you to make them on es-discuss, rather than on HN, where they are more likely to have an impact on the development of the language.

Re: The Future of JavaScript

#93

Post by samth »

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.

A different way to put it is: "the best way to iterate over collections is still being discussed, because we want to get it right".

Also, for `Map`, how do you think `foreach` should work? Should the function be called with (a) the key, (b) the value, (c) an array with both the key and the value, (d) the key and the value as separate arguments?

Similarly, in the statement:

    for(let x of some_map) { ... }
should `x` range over the keys, values, or key-value pairs of the map?

Re: The Future of JavaScript

#94

Post by samth »

samth wrote: post #92
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…

I'll try to separate out the different issues you're raising here, and respond to each individually. 1. What if I want to have my module be a function, the way that $ in jQuery is both a function and a namespace for the rest of the functionality? This is an important use case, and so we're going to support it in ES6 modules. You'll be able to say: module $ at "http://jquery.com/jquery.min.js"; $(...) $.ajax(...) 2. M…

To make my perspective here clear, I should mention that Dave Herman (of Mozilla Research) and I are the designers of the ES6 module system.

Re: The Future of JavaScript

#95

Post by elehack »

grannyg00se wrote: post #54
elehack wrote: post #46

Earlier quoted context omitted.

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

If var is counter to other C-style languages, that doesn't make it a bug. It just makes it unique. Is there some other reason you're saying it is a bug? How does it break closures? Javascript works with var today and closures are used all the time. Breakage free. "what do you mean, braces don't actually delimit scope?" I would answer, they don't. Because this is not . This is javascript. Nobody should have ever told…

It's a “bug” (and yes, I'm using that deliberately in an opinion-as-fact sense) because it is a blatant violation of the Principle of Least Surprise, especially for those coming from C-style backgrounds. If you are a C-style language (which JS is), and you do something in a non-C-style way, you should have a very good reason (besides implementation artifacts and/or not thinking robustly about scope). I haven't seen anything indicating that var's behavior is a well-reasoned, principled choice - as far as I know, it's just how JS 1.0 worked, and we're stuck with it.

In my opinion, unnecessary surprise as a result of historical implementation artifacts is a design bug.

Yep, need to learn about it. Yep, you can, and write good JavaScript. But that doesn't mean the design is good.

Re: The Future of JavaScript

#96

Post by batista »

vectorjohn wrote: post #80
batista wrote: post #71

Earlier quoted context omitted.

If var is counter to other C-style languages, that doesn't make it a bug. It just makes it unique. Yes, it's not this that makes it a bug, it all the other horrendous stuff it entails... Wouldn't it be easier to just learn how to use var properly? No, it would be easier to fix it. Call it argument by authority, but I trust Brendan Eich more than some random HN dude on this.

It would be easier to just learn the language. JavaScript I not c. JavaScript is not Java. JavaScript is not python. If it was one of those languages it would be named that and there would be no JavaScript books, just dom and browser books. But it is not those languages. It is different. If people don't learn the language they cannot be expected to write code. People always bring up var for some reason. Why var? Why…

It would be easier to just learn the language.

Can you conceive the existence of a language that has got some parts wrong, and maybe awfully wrong?

Well, my point, and that of a lot of others, including Cockford and Eich, is that Javascript is such a language. And that the fucked-up scope it has, is one of such parts.

JavaScript I not c. JavaScript is not Java. JavaScript is not python. If it was one of those languages it would be named that and there would be no JavaScript books, just dom and browser books. But it is not those languages. It is different. If people don't learn the language they cannot be expected to write code.

People don't want Javascript to be Python, C, or Java. The want it to be a better Javascript and shed some of the BS that was added at its' conception due to a tight deadline. Being "different" than other languages is OK. Being brain damaged is not.

People must learn the language, but that doesn't mean they have to put up with mistakes in its' design and not correct them. Just like people corrected bad stuff in K&R C with ANSI C, Python with Python 3, Ruby with 1.9, etc.

You seem to have the wrong impression that people complaining are lazy programmers who don't want to bother to learn the language. They are not. Brendan Eich is a JS guru and implementer. Douglas Cockford invented the damn language! And he admitted that there are bad parts in it, that need to be corrected. He even made a book on how to work around those, called "Javascript, the good parts".

People always bring up var for some reason. Why var? Why not closures? Javascript is often the first place programmers come across this concept and it always causes confusion and bugs at first. Should we get rid of them? Of course not!

Because discussing what must be corrected is not about whether it's confusing to newcomers of not, it's about whether something is nicely designed OR a kludgy disaster.

Closures, while confusing to some, are a standard programming feature and a nice addition to Javascript. In contrast, var (and JS's scope rules) are just things that the JS creator gotten wrong. They need to be corrected.

Re: The Future of JavaScript

#97

Post by batista »

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.

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.

Re: The Future of JavaScript

#98

Post by grannyg00se »

batista wrote: post #96
vectorjohn wrote: post #80

Earlier quoted context omitted.

It would be easier to just learn the language. JavaScript I not c. JavaScript is not Java. JavaScript is not python. If it was one of those languages it would be named that and there would be no JavaScript books, just dom and browser books. But it is not those languages. It is different. If people don't learn the language they cannot be expected to write code. People always bring up var for some reason. Why var? Why…

It would be easier to just learn the language. Can you conceive the existence of a language that has got some parts wrong, and maybe awfully wrong? Well, my point, and that of a lot of others, including Cockford and Eich, is that Javascript is such a language. And that the fucked-up scope it has, is one of such parts. JavaScript I not c. JavaScript is not Java. JavaScript is not python. If it was one of those languag…

"People don't want Javascript to be Python, C, or Java. The want it to be a better Javascript and shed some of the BS that was added at its' conception."

That's a great idea. I'd be all for shedding some of the bs for a better javascript. But the var issue isn't being solved by shedding anything. Var will still be there. But now the language will be even more complicated because of some var workarounds being added in. In the end, you still need to deal with var.

Re: The Future of JavaScript

#99

Post by rdtsc »

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.

> What makes JavaScript popular is how good it is.

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

Re: The Future of JavaScript

#100

Post by batista »

grannyg00se wrote: post #98
batista wrote: post #96

Earlier quoted context omitted.

It would be easier to just learn the language. Can you conceive the existence of a language that has got some parts wrong, and maybe awfully wrong? Well, my point, and that of a lot of others, including Cockford and Eich, is that Javascript is such a language. And that the fucked-up scope it has, is one of such parts. JavaScript I not c. JavaScript is not Java. JavaScript is not python. If it was one of those languag…

"People don't want Javascript to be Python, C, or Java. The want it to be a better Javascript and shed some of the BS that was added at its' conception." That's a great idea. I'd be all for shedding some of the bs for a better javascript. But the var issue isn't being solved by shedding anything. Var will still be there. But now the language will be even more complicated because of some var workarounds being added in…

In the end, you still need to deal with var.

For legacy code, yes.

But now, if you target modern browsers, you can build a whole web app using only let, and not be bothered about var and the old scope system at all.

Post reply on HN