
JS.Next Needs You - jashkenas
http://javascriptweblog.wordpress.com/2012/05/07/putting-the-developer-back-in-es-next
======
ZenPsycho
I am an avid reader of the ES-Discuss mailing list and I have seen these
"disenfranchised" developers this article is talking about, who blunder into
the list with their fabulous ideas without lurking first, or searching the
mailing list archives or bug databases, or the wiki. It's not hard at all to
participate in the ES-Discuss mailing list. You just have to treat it with at
least the same degree of respect you'd treat any other forum full of people
smarter than you.

Now when I say that, I don't mean that just because they are smarter you have
nothing to contribute, but you have to pick up your game a little bit and try
not to be completely ignorant when you make a suggestion- since all that does
is increase the noise level. But getting to that point is not the horrible
insurmountable obstacle the article makes it out to be. It is not hard to not
be ignorant.

------
lucian1900
I don't see how getting proper lexical binding and trying to deprecate
function scope is a bad thing.

Same for the confusing, silly dynamically bound this.

~~~
cpeterso
I agree. Supporting both _var_ and _let_ sounds like a good way to maintain
code compatibility and transition to something safer.

~~~
mbrubeck
And since Firefox has already supported both _var_ and _let_ for several years
now, and most Firefox chrome code uses _let_ exclusively, this approach is
pretty well proven in a large code base. As a Firefox developer, I now find it
quite annoying to write for JS engines that support only _var_.

------
MatthewPhillips
As far as I can tell from looking through the strawmen, none of those are
absolutely necessary and several would just get in the way.

The important stuff has already been added, modules, Object.is, and WeakMaps
especially.

With that being said, the @jsfixed team must think something needs to be done,
I just wish they had spent any amount of time in this blog post explaining
_what_ that is.

I can think of a few things. Today I was needing to get the base domain from a
url string and spent entirely too much time writing a function to do it. I
wound up using a library called URI.js. But it's insane to me that there isn't
a native way to parse a url string in the browser.

~~~
ZenPsycho
It's a hard problem. The reason it is hard is that they have to balance
runtime size against the potential value of an addition, against increasing
the complexity of the language (Combinatorially- for every feature they have
to examine in detail how it interacts with every other feature of the
language, which is a lot of work), friendliness to noobs, friendliness to old
javascript fans, friendliness to java ruby and python people who hate
javascript, etc. etc. For this reason they have focused mainly on features
that can't be added with a library for this edition.

If you are interested, I wrote a URI parser myself, which can resolve relative
URIs <https://github.com/Breton/jsutils/tree/master/uriparser>

------
jashkenas
For what it's worth, the talk alluded to by Angus in the intro 'graf is
available here:

<http://blip.tv/jsconf/jsconf2011-jeremy-ashkenas-5258082>

... you can watch Brendan walk through some of the Harmony proposals.

------
ilaksh
How are you really going to make substantive improvements without breaking a
lot of things, or basically making it into a different language? Seems like
there is a limit to what you can do. Maybe they can add a few optional things,
like require. (Fast forward to 2014: Oh, sorry, Internet Explorer doesn't
support require, app won't run). Maybe all of these geniuses should stop and
instead come up with a way to get rid of Microsoft or Internet Explorer.
That's the real problem. Just kidding (sort of).

As long as CoffeeScript still works in the next major version of JavaScript, I
will be fine.

~~~
ZenPsycho
By using a coffeescript approach of ES.next to ES.prev compilation. There are
several such compilers already, including one from Google called Traceur, and
the one as old as Javascript itself, Narcissus. They have been using Traceur
and Narcissus for something like "reference" implementations of ES.next, to
try out how features work before adding them permanently to the spec.

------
toemetoch
Sorry to sound like a negative Nancy but how will this prevent fragmentation
of JS? I read the weblog, the ecmascript link and the Harmony requirements but
nowhere does it say how to tell whether the runtime supports the JS/Next
script or which of the big names has commited to following it.

~~~
ax
Members of the TC39 committee include representatives from Apple, Google,
Mozilla, and Microsoft. Javascript engines from these vendors will almost
surely implement the standard. Firefox has prototypes for a few new things
already.

~~~
toemetoch
Thank you.

------
stcredzero
How about a standard date format for JSON?

~~~
simanyay
Create an issue!

~~~
toemetoch
Issues: <https://github.com/JSFixed/JSFixed/issues>

New issue: <https://github.com/JSFixed/JSFixed/issues/new>

