JavaScript 2015?

Andrea Giammarchi andrea.giammarchi at
Thu Jan 22 17:10:55 PST 2015

btw, just to answer your picks, I think this ML and ECMA in general has
done a very good job last few years.

I've heard the "delivery, delivery, delivery" story before and I haven't
seen a single case where that translated into more quality as outcome.

The label behind the year-name convention is not convenient for anyone:

  1. books will look either older than they actually are or crystal-ball
oriented (at least for less familiar users eyes)
  2. for years we'll have to explain how to convert an ES version to the
year and why at the beginning this was not a year-based thing
  3. some year might be the alignment year where only one major feature
goes out but it goes out the right way ... how'd you explain that ES 20XX ?
  4. you mentioned ES 3.1 instead of ES5 ... that's just **good** ... if we
need intermediate changes why not, we have officially a 5.1 too I don't
remember anyone complaining there

Having major release forced on year basis feels far away from agile or
continuous integration principles, so yeah: year-name to define deadlines
is bad because of the year-label thing, and because of the concept behind.

We have numerous sites showing the current implementation status of current
specs or even future one ... it's already difficult to understand who
supports what, having "must release this year" versions out there will make
the scene look like a bingo.

This is probably just me playing the crystal-ball rant part but what
bothers me the most is that until today I've never heard about this new

I don't think I've missed notes or threads, if so, please point them out,
if not, please explain where these decisions come from if that's possible.
Maybe me or others could follow that channel too? Or maybe not, but it
would be nice to eventually know it.

Best Regards

On Fri, Jan 23, 2015 at 12:39 AM, Brendan Eich <brendan at> wrote:

> Andrea Giammarchi wrote:
>> I particularly don't like the idea that things could be dropped or rushed
>> last minute just because the new years eve is coming ... this feel like
>> those stories with tight deadlines where management could easily fail due
>> over-expectations on all possible 3rd parts alignment ( you know, like
>> those 12 different JS engines out there .... + spartans )
> No last minute slips -- that's a schedule-chicken outcome (where the cars
> do not collide but one veers and drives off a cliff!).
> The new stuff has to board its "release train" or its champions and fans
> will be sad, and perhaps take a credibility hit. This doesn't mean larger
> work must be broken down into too many pieces, but that is a risk.
> Larger work that can track across multiple years is always risky -- in my
> experience it very often aims for a target near Alpha Centauri at sublight
> speed, when the real action was over at Tau Ceti due to an FTL
> breakthrough, but no one knew at first that (a) FTL was possible; or (b)
> the Centauri systems were uninhabitable. If you get what I mean ;-).
> (Spartan uses Chakra, last I heard.)
> Mature projects can do rapid-er release more easily than young ones, for
> sure. I recall 4.2BSD Unix, then 4.3, and a bit of 4.4.
>  I do like the idea of having more frequent rolling releases, but yet I
>> don't know why year-naming would be the choice.
> Does the name matter? You seemed to be objecting on more substantive
> grounds. Don't back off to mere quibbling about labels!
>  Anyway, please consider keeping ES6 exactly ES6, we will have time to
>> align the ESX where X = previous ESX +2009 concept.
>> to Doctor Alex, at this point I think you should really stick with ES6 or
>> avoid the ES at all and use JS 2015
> This reminds me: Axel (not Alex) cannot recommend "JavaScript 2015" to
> anything near the Ecma standard, because trademark. :-/
> /be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list