JS.Next Needs You | Hacker News Reader

JS.Next Needs You

javascriptweblog.wordpress.com

70 pointsjashkenas28 comments

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.

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.

I agree. Supporting both var and let sounds like a good way to maintain code compatibility and transition to something safer.

Exactly.

Most of the rant was idiotic, basically "leave js alone". Well keep programming without the new features if you want, its not like they will force you to use let and co.

And those tired "less is more" and "lets not add features lest we complicate the language" are inane...

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.

What's wrong with function scope? Python has function scope and no one is complaining about it there.

In Python it rarely gets in the way, because you can't accidentally define something as global.

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.

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

oh hey, look at this. Someone on HN found some latent native URI parsing ability in the browser DOM http://www.joezimjs.com/javascript/the-lazy-mans-url-parsing...

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.

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.

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.

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.

Our current goal is to make positive impact on TC39 (the only group working on the spec) and not to create an alternative.

However, your comment is applicable to the whole ES.Next and I share it as well.

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.

Thank you.

The mechanism is this "use strict" directive they added to ES5. This is my understanding.

How about a standard date format for JSON?

Create an issue!

Issues: https://github.com/JSFixed/JSFixed/issues

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

How is that javascript's problem?

how bout a standard name format? phone# format? credit card# format?

Anyone sane just uses ISO 8601 and moves on

https://en.wikipedia.org/wiki/ISO_8601 ?

Reply on news.ycombinator.com