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

61–70 of 115 posts

Re: The Future of JavaScript

#61

Post by substack »

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 introduce a frustrating correspondence between the lexicals of your own program and the export names of the module you're trying to use which is really terrible if you're using as many modules as I typically do. I presume ES.next will invent even more specific syntax for some sort of `as` like keyword to side-step this but it seems so unnecessary when javascript already has a module system that is so very good as is exploding in popularity and use (>7000 modules now on http://search.npmjs.org/).

I understand what they're trying to do with static analysis too but you can already pretty much do that and I've done it. It's not hard at all, just ignore require() statements that don't contain strings when you walk the AST, like this: https://github.com/substack/node-detective

Inventing more syntax instead of just adopting a far better module system that has seen actual use in practical situations is such a shame and ES.next is rife with this kind of prescriptivism. It irritates me to no end and I sometimes want ES.next to die a quiet death in obscurity because of it.

http://wiki.ecmascript.org/doku.php?id=harmony:modules

Re: The Future of JavaScript

#62

Post by herge »

jashkenas wrote: post #53
herge wrote: post #47

Earlier quoted context omitted.

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.

CoffeeScript's got you covered. Here's forEach ... for item, index in list ... here's the same over an object ... for key, value of object ... here's the map() ... mapped = for item in list ... here's the filter() ... filtered = for item in list when item.isActive ... and so on.

Exactly. The number one thing javascript should take from coffeescript is the iteration syntax.

Re: The Future of JavaScript

#63

Post by [deleted] »

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…

[deleted]

Re: The Future of JavaScript

#64

Post by tjholowaychuk »

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 agree. In general unless there is very good reason to do so I think adding to the grammar is the least elegant thing you could possibly do. Like you say it's often very helpful to effectively assign a new name to something you want to require, I do it all the time too. I really prefer the implicit scoping that we have too, not wrapping things in "module Foo { module Bar {} }" blah blah.

Re: The Future of JavaScript

#65

Post by mcantelon »

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…

Attempts to create big iterations on successful languages seem to consistently fail to win adoption.

Re: The Future of JavaScript

#66

Post by gjm11 »

mcantelon wrote: post #65
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…

Attempts to create big iterations on successful languages seem to consistently fail to win adoption.

C++ seems like a pretty obvious counterexample, even though it didn't call itself "C". Others: Fortran 90. Common Lisp. Visual Basic. [EDITED to add: Perl 5.]

ANSI C was quite a big change from K&R, even.

Re: The Future of JavaScript

#67

Post by azakai »

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

Re: The Future of JavaScript

#68

Post by batista »

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

Re: The Future of JavaScript

#69

Post by batista »

grannyg00se wrote: post #22
mbrubeck wrote: post #7

Earlier quoted context omitted.

Another problem with objects-as-dictionaries is that the keys must be strings. If you use a different type as a key, it is implicitly converted to a string, which can lead to some surprising problems for programmers who don't expect it. Maps/Set/WeakMap properly support arbitrary objects as keys.

Again, this is something that is simple to learn and understand. And you would learn this in a beginner tutorial. Why go through trouble to change it and complicate the language even further? I undeerstand weakmap may have some real advantage as far as GC, at least.

Again, this is something that is simple to learn and understand. And you would learn this in a beginner tutorial. Why go through trouble to change it and complicate the language even further?

For one simple to understand != intuitive or easy to use. Chess rules are easy to understand too, you can learn all of them in an hour, but try to play the game with any quality. So this being simple to understand does not mean its simple to code around and debug.

You are also misguided in that this addition "complicates the language". It's not like adding generics or monads or some crazy new feature. It's one of the most fundamental datatypes, implemented properly for the first time.

So, instead of saying Object foo; foo.x = "a"; when you need a dict, and having to guard against all consequences, you get to use Map foo; foo.x = "a"; and there is nothing you have to think about anymore.

Re: The Future of JavaScript

#70

Post by batista »

btilly wrote: post #51
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 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 some edge cases and still falls prey to others.

However they are likely to create traps like making these 2 different: my_dict[5], my_dict['5']

Those two ARE different.

Post reply on HN