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

71–80 of 115 posts

Re: The Future of JavaScript

#71

Post by batista »

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…

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.

Re: The Future of JavaScript

#72

Post by Andi »

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 (and substack is talking)

Re: The Future of JavaScript

#73

Post by btilly »

batista wrote: post #70
btilly wrote: post #51

Earlier quoted context omitted.

But instead if you write: dict[ "_" + user_provided_string ] then nothing can ever go wrong. This does have an annoyance around the leading underscores. But you can get around that by adding simple accessor methods. And now you have a real dictionary. But native dictionaries have the ability to store complex objects as keys. This is kind of nice. However they are likely to create traps like making these 2 different:…

then nothing can ever go wrong. Yes, let's add some arbitrary personal convention you have to follow and keep track of, because it's so much easy than a proper Map type... But you can get around that by adding simple accessor methods. And now you have a real dictionary. You still don't have a real dictionary, keys are only strings for example. You just have another lame-ass implementation of a dict in JS that avoids…

Those two are different, but JavaScript does not encourage clarity about when you'll have one versus the other, thereby leading to traps for unwary beginners.

Re: The Future of JavaScript

#74

Post by erichocean »

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…

Totalyl agree. The lack of a module system in JavaScript has been an enormous benefit to the developer community, because it has allowed us to develop idioms that make sense in the context of JavaScript.

Adopting a hard-coded, python-esque module system is a step backwards from what we have now, and I doubt will be used much, if at all -- why give up features that already exist (and will continue to work)?

sigh

Re: The Future of JavaScript

#75

Post by firefoxman1 »

After reading many of really great comments on this post, I think that additions to a language deserve community input. Not just a couple of the "Best" programmers sitting around a table deciding.

This is the Web, after all. An interconnected world-wide community. Why isn't there some sort of voting process that anyone can give their input for ECMAScript's drafts? Right now it's an Oligarchy. At the very least, an electoral college-like system would be nice.

Re: The Future of JavaScript

#76

Post by ootachi »

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…

You haven't considered optimization -- with closed modules, the compiler can statically know, for instance, that "Math.sin" is actually the sine function and can compile that straight down to the hardware instruction. No speculation or guards are necessary.

Additionally, your static analysis must be unsound if modules are mutable. The problem is not figuring out which module is being imported, it's figuring out whether the bindings are mutated. CommonJS cannot guarantee that modules haven't been mutated.

And yes, you can rename imports. Why is "var { foo: bar } = require('baz')" so much better than "import { foo: bar } from baz;"? They look the same to me, except that the ES6 one is better for static analysis and better for optimization.

Re: The Future of JavaScript

#77

Post by cmf028 »

herge wrote: post #47
tikhonj wrote: post #38

Earlier quoted context omitted.

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.

ecmascript 6 will also introduce for of loops which is said to fix for in. checkout wiki.ecmascript.org for all the ecmascript 6/harmony niceness

Re: The Future of JavaScript

#78

Post by stewbrew »

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…

    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.

Re: The Future of JavaScript

#79

Post by marknadal »

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.

Re: The Future of JavaScript

#80

Post by vectorjohn »

batista wrote: post #71
grannyg00se wrote: post #54

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

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

Post reply on HN