[CommonJS] Baseline ECMA version

[Dean Landolt]

On Thu, Aug 27, 2009 at 9:02 AM, Wes Garland <w...@page.ca> wrote:

I am seriously dubious as to whether JSGI should require JavaScript 1.7.  This is not an ECMA standard, and AFAIK is not implemented outside of Mozilla.

While I'm a huge Mozilla fan, I don't think making CommonJS specific to Mozilla implementations of JavaScript is wise.

I agree. I only brought up destructuring to prompt this very conversation.
 

It would be nice to be able to implement the standards in any ES3-compliant JavaScript engine, and there are LOT out there.   ES5 should be adopted quickly as well -- after ratification -- although I would suggest thinking long and hard about making use of ES5 features in core libraries.

ES3 compliance seems like a good, objective baseline.

[Mark Porter]

What about a shim to implement as much of ES5 as can be monkey-patched on to ES3? Especially the array extras and the JSON stuff. Is this an unreasonable requirement?

[Wes Garland]

Mark:

ES5-which-can-be-implemented-in-ES3 is pretty reasonable: it means you can still use an ES3 interpreter.

Things like destructuring assignment, generators, etc -- new syntax -- will pose problems, however.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Mark S. Miller]

On Thu, Aug 27, 2009 at 8:28 AM, Mark Porter <dm4...@gmail.com> wrote:

What about a shim to implement as much of ES5 as can be monkey-patched on to ES3? Especially the array extras and the JSON stuff. Is this an unreasonable requirement?

I would go further and advocate that CommonJS use ES5 as a base, not ES3. In that context a shim would be tremendously valuable as it would allow us to proceed well while waiting for ES5 engines to become available.

 

On Thu, Aug 27, 2009 at 7:17 AM, Dean Landolt <de...@deanlandolt.com> wrote:

On Thu, Aug 27, 2009 at 9:02 AM, Wes Garland <w...@page.ca> wrote:

I am seriously dubious as to whether JSGI should require JavaScript 1.7.  This is not an ECMA standard, and AFAIK is not implemented outside of Mozilla.

While I'm a huge Mozilla fan, I don't think making CommonJS specific to Mozilla implementations of JavaScript is wise.

I agree. I only brought up destructuring to prompt this very conversation.
 

It would be nice to be able to implement the standards in any ES3-compliant JavaScript engine, and there are LOT out there.   ES5 should be adopted quickly as well -- after ratification -- although I would suggest thinking long and hard about making use of ES5 features in core libraries.

ES3 compliance seems like a good, objective baseline.

--
   Cheers,
   --MarkM

[Daniel Friesen]

I believe we already require JSON. And jsgi requires array.forEach.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

[Wes Garland]

> I believe we already require JSON. And jsgi requires array.forEach.

JSON is no big deal: it can be implemented in ES3.

If JSGI requires array.prototype.forEach() -- that's fine, you can implement that in ES3 too (https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Array/forEach)

If JSGI required for-each loops, though, that would be a problem: for-each is E4X, not ES3.

Wes

[Kris Kowal]

On Thu, Aug 27, 2009 at 9:37 AM, Daniel
Friesen<nadir.s...@gmail.com> wrote:
> I believe we already require JSON. And jsgi requires array.forEach.
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> Mark Porter wrote:
>> What about a shim to implement as much of ES5 as can be monkey-patched
>> on to ES3? Especially the array extras and the JSON stuff. Is this an
>> unreasonable requirement?

This is what Narwhal does. We're targetting "ES5" compliance, to the
extent that it is possible to monkey-patch future-ready functions onto
ES3 with the addendum that compliant code may not use for(var iterand
in array) notation.

For the migration between ES3 and ES5, this requires a more nuanced
approach than one or the other. I would rather not waste time
enumerating what portion of ES5 we support, but that is what the
situation calls for in the interim. Perhaps we can save some time and
absorb some headache for the time being in hope of a brighter future
by suggesting that "compliant" implementations must be ES5, and in so
far as that our current implementations fall short of ES5, we are not
compliant.

Narwhal's Object.freeze transparently returns the same object without
modification. That allows us to write code that will work when
Object.freeze works, as long as we make no promises that our code is
secure on our current implementations. We have a stub for
Object.defineProperty that uses engine specific means of defining
properties, but has to ignore most of the traits.

Kris Kowal

[Tom Robinson]

I don't think it's been made official, but my understanding was any of
the ES5 methods we could implement easily via JS would be required
(namely the Array methods and JSON, as you mentioned).

-tom

[Marco Rogers]

The only thing I would bring into this discussion is browser support.
It seems like the viability of CommonJS in the browser is on a
separate thought thread right now. And it's not slowing down the
progress of standards and server-side development (and that's good).
But there won't be a fully viable cross-browser ES5 environment for
longer than 2-3 years. To me this means that if you settle on ES5 now
and use it in core features, then CommonJS in the browser won't see as
much adoption.

This thread actually started with regard to JSGI/Jack, which isn't
targeted towards browsers. So maybe this is a moot point. But my
$0.02 cents is that CommonJS should be fully compatible with ES3 for a
while yet. That being said, implementing features of ES5 that are ES3
compliant is a good idea.

:Marco

On Aug 27, 12:48 pm, Kris Kowal <cowbertvon...@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 9:37 AM, Daniel
>

[Dean Landolt]

On Thu, Aug 27, 2009 at 12:37 PM, Daniel Friesen <nadir.s...@gmail.com> wrote:

I believe we already require JSON. And jsgi requires array.forEach.

And array.forEach can obviously be implemented in ES3. Syntax changes like destructuring assignment cannot.

[Mark Porter]

By that, I mean to say that if that shim is required, then coding to ES3 ain't so bad. Most of us have been doing that for years. The new stuff is dreamy but if I have to develop middleware in ES3 for compatibility, that isn't a very big restriction. In any case I can require ES5/JS1.7 for my particular app, if I'm doing something that just won't work without iterators/generators for instance.

So I guess I'm saying I agree with you that we shouldn't limit CommonJS/JSGI to ES5/JS1.7 engines

The more accurately, I think we should require ES3 +  defined list of ES5 back-ported features.

--
---------------------------------------------
Mark Porter

Myna JavaScript Application Server
Easy server-side JS on a Java plaform
http://www.mynajs.org

[Dean Landolt]

On Thu, Aug 27, 2009 at 1:08 PM, Tom Robinson <tlrob...@gmail.com> wrote:

I don't think it's been made official, but my understanding was any of
the ES5 methods we could implement easily via JS would be required
(namely the Array methods and JSON, as you mentioned).

If it's not already official: +1

[Dean Landolt]

On Thu, Aug 27, 2009 at 12:18 PM, Mark S. Miller <eri...@google.com> wrote:

On Thu, Aug 27, 2009 at 8:28 AM, Mark Porter <dm4...@gmail.com> wrote:

What about a shim to implement as much of ES5 as can be monkey-patched on to ES3? Especially the array extras and the JSON stuff. Is this an unreasonable requirement?

I would go further and advocate that CommonJS use ES5 as a base, not ES3. In that context a shim would be tremendously valuable as it would allow us to proceed well while waiting for ES5 engines to become available.

But as Wes and I pointed out, how do you shim syntax changes (without a preprocessor at least)?

[Joshaven Potter]

I'd love a standard library "shim".... and while your at it make as much of it as possible portable to the browser environment!

--
Sincerely,
Joshaven Potter

"No man making a profession of faith ought to sin, nor one possessed of love to hate his brother. For He that said, “Thou shalt love the Lord thy God,”  said also, “and thy neighbor as thyself.”  Those that profess themselves to be Christ’s are known not only by what they say, but by what they practice. “For the tree is known by its fruit.”" -- Ignatius

[Mark S. Miller]

You don't. But ES5 has very few syntax changes. Just ignore those
until we can ignore ES3. Likewise with other more interesting features
of ES5 that cannot be practically emulated in ES3. For the moment, as
a practical matter, rely only on the parts of ES5 that can be
implemented in ES3. But as soon as enough ES5 implementations are
available, drop that constraint. This is a transitional issue only.

--
Cheers,
--MarkM

[Mark S. Miller]

On Thu, Aug 27, 2009 at 9:48 AM, Kris Kowal<cowber...@gmail.com> wrote:
> Perhaps we can save some time and
> absorb some headache for the time being in hope of a brighter future
> by suggesting that "compliant" implementations must be ES5, and in so
> far as that our current implementations fall short of ES5, we are not
> compliant.

+1

--
Cheers,
--MarkM

[Adam Peller]

You don't.  The JS1.7 stuff like iterators is not part of the ES5 spec.

[Dean Landolt]

I love it. But again, what about syntax changes? To say "ES5 compliance" is to say all current implementations should implement new ES5 syntax, e.g. generators and destructuring. Would it be more productive to say CommonJS 1.0 (or whatever) compliance is ES5 sans new syntax. That doesn't preclude devs from using the shiny newness when they know they can (or provide fallbacks).

[Ash Berlin]

On 28 Aug 2009, at 00:10, Dean Landolt wrote:

>
> I love it. But again, what about syntax changes? To say "ES5
> compliance" is to say all current implementations should implement
> new ES5 syntax, e.g. generators and destructuring. Would it be more
> productive to say CommonJS 1.0 (or whatever) compliance is ES5 sans
> new syntax. That doesn't preclude devs from using the shiny newness
> when they know they can (or provide fallbacks).

Next time go read the spec before quoting things about it. Last time i
checked ES5 didn't have destructuring assignment or generators - those
remain Mozilla only extensions.

http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
http://wiki.ecmascript.org/doku.php?id=proposals:iterators_and_generators

[Mark Miller]

On Thu, Aug 27, 2009 at 4:10 PM, Dean Landolt<de...@deanlandolt.com> wrote:
> generators and destructuring

Are not in ES5.

--
Text by me above is hereby placed in the public domain

Cheers,
--MarkM

[Kris Zyp]

-1 for ServerJS requiring ES5. Are there any CommonJS *APIs* (which is
the concern of CommonJS) that necessitates ES5? Of course, array vs
object JSGI requests both work in ES3, and I haven't seen anything
anywhere else that requires ES5. Now obviously module writers are going
to want to code to ES5, and they certainly can, but it just means that
their modules require both the CommonJS loader and ES5 (Narwhal
requiring ES5 or some level ES5 emulation is very reasonable). The
desire and motivation to support ES5 is probably much stronger than the
desire to have CommonJS compliance, so I don't understand why CommonJS
feels compelled to add additional strong arming towards implementors if
such a requirement if it is not necessary to define our APIs. APIs
should be the focus.
Kris

[Tom Robinson]

Agreed. I'd like for any ES5 features that can (relatively easily) be
implemented in plain old ES3 to be *required* in CommonJS
implementations. The rest can be optional. For now, at least.

I should be able to assume Array.prototype.map and the rest to are
present. These are very useful and easily implemented methods.

-tom

[Wes Garland]

> This thread actually started with regard to JSGI/Jack, which isn't
> targeted towards browsers.  So maybe this is a moot point

It is NOT a moot point.

What I wanted to run Server-Side JavaScript with the Windows Scripting Host under Microsoft IIS?

Laugh all you want, I'd do it if it was part of a plan to migrate away from an IIS/ASP environment.

Wes

[Daniel Friesen]

I had planned to include these kind of things inside of Wrench.js (which
adds various Array/String/etc... handling methods missing from JS and
acts as most of MonkeyScript's stdlib, a browser side library, and can
be used in any other js environment just by including the file)
I already have it broken up into separate files to break
String/Array/etc... up, and broken up to separate features used in later
languages (ie: Currently it builds a browser wrench15.js a wrench17.js
for Rhino 1.7 and a wrench18.js for SpiderMonkey 1.8+) and separates
extras from moz-compat Array methods (most of which became part of ES5 I
believe) in a clean way (wrench17.js and wrench18.js also don't include
superfluous code when that version already has those implemented).

If anyone wants I can break it down further separating ES5 stuff from
other things and provide the ability to build a simple ES5-only build
that anyone can just include in their CommonJS implementation to include
those.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

[nlloyds]

On Aug 27, 8:42 pm, Wes Garland <w...@page.ca> wrote:
> > This thread actually started with regard to JSGI/Jack, which isn't
> > targeted towards browsers.  So maybe this is a moot point
>
> It is NOT a moot point.
>
> What I wanted to run Server-Side JavaScript with the Windows Scripting Host
> under Microsoft IIS?
>
> Laugh all you want, I'd do it if it was part of a plan to migrate away from
> an IIS/ASP environment.

Please: don't laugh, pray for us! ;) I'm in the process of
implementing such a plan.

+1 on ES3 w/ ES5 extensions that can be implemented in ES3.

Nathan

[Kevin Dangoor]

Before this discussion continues farther, I think we're actually in violent agreement so we may be able to just stop.

 

On Thu, Aug 27, 2009 at 12:48 PM, Kris Kowal <cowber...@gmail.com> wrote:

For the migration between ES3 and ES5, this requires a more nuanced
approach than one or the other.  I would rather not waste time
enumerating what portion of ES5 we support, but that is what the
situation calls for in the interim.  Perhaps we can save some time and
absorb some headache for the time being in hope of a brighter future
by suggesting that "compliant" implementations must be ES5, and in so
far as that our current implementations fall short of ES5, we are not
compliant.

I think this made the discussion veer off in some different directions, but most people on this thread seem to have a common opinion that is different from this.

Let me propose something specific and anyone who dissents please speak up:

1. CommonJS specifically targets the subset of ES5 that can be implemented in ES3
2. This subset should be enumerated
3. Individual implementations of CommonJS are free to require other ES or JS features, but the standard will only require #1.

With the exception of Kris' statement of "we are not compliant" above, I don't think I've seen anyone disagree with the 3 points that I make here. I think we should just move forward with that.

Kevin

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

[Mark S. Miller]

On Fri, Aug 28, 2009 at 6:39 AM, Kevin Dangoor<dan...@gmail.com> wrote:
>> On Thu, Aug 27, 2009 at 12:48 PM, Kris Kowal <cowber...@gmail.com> wrote:

>>> [...] so far as that our current implementations fall short of ES5, we are not
>>> compliant.

> With the exception of Kris' statement of "we are not compliant" above, I

> don't think I've seen anyone disagree with the 3 points that I make here. I
> think we should just move forward with that.

Ironically, the issue hangs on our recent name change. So long as we
were named serverjs, if we imagined that we were writing a standard
purely for server-side use where upgrade to new JS versions can be
quick, I think Kris' original language was the right thing. Now that
our name change has clarified our purpose to include browsers, where
we have to assume the normal 5 year lag, I agree with Kevin's
phrasing.

It's a shame. I was looking forward to libraries that were free to use
all of ES5. Perhaps we should make explicit that the subset of our
libraries intended only for server side use, such as File, can assume
all of ES5?

--
Cheers,
--MarkM

[Mark Porter]

+1 Kevin's summary.

This is exactly what I was suggesting when I when I whacked this hornet's nest. Only much more clearly stated.

I fully intend to extend beyond the spec. Taking advantage of Myna features will make your app non-portable. I imagine everyone else will do the same in their implementations. I think JS1.7/ES5 should be an implementation-specific enhancement.

On Fri, Aug 28, 2009 at 7:39 AM, Kevin Dangoor <dan...@gmail.com> wrote:

Let me propose something specific and anyone who dissents please speak up:

1. CommonJS specifically targets the subset of ES5 that can be implemented in ES3
2. This subset should be enumerated
3. Individual implementations of CommonJS are free to require other ES or JS features, but the standard will only require #1.

With the exception of Kris' statement of "we are not compliant" above, I don't think I've seen anyone disagree with the 3 points that I make here. I think we should just move forward with that.

Kevin

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

[Mark S. Miller]

On Fri, Aug 28, 2009 at 8:03 AM, Mark Porter<ma...@porterpeople.com> wrote:
> I think JS1.7/ES5 should be an implementation-specific enhancement.

Why do you keep lumping these two together?

--
Cheers,
--MarkM

[Paul Prescod]

On Fri, Aug 28, 2009 at 8:00 AM, Mark S. Miller<eri...@google.com> wrote:
>
> ...

>
> It's a shame. I was looking forward to libraries that were free to use
> all of ES5. Perhaps we should make explicit that the subset of our
> libraries intended only for server side use, such as File, can assume
> all of ES5?

Sorry to be a pain, but people also write mobile-client and desktop
applications in Javascript. I would love to see alignment between
CommonJS and Phonegap (which allows you to build native-featured apps
in Javascript).

That said: Phonegap more or less depends on the iPhone's webkit, so if
you're talking about features of ECMAScript that were deployed in
Safari 3 or so, it would be no problem. I admit that I have not been
paying close enough attention to know whether we're talking about
features that are available "everywhere except IE" or whether we're
talking about features that are not even in Safari yet.

Filesystem access is on the Phonegap roadmap:

http://phonegap.pbworks.com/Roadmap

Paul Prescod

[Joshaven Potter]

Libraries have always made assumptions about there environment.  I wouldn't expect to copy a socket.h library from OS X 10.3 on a PPC to a Debian AMD 64 bit system.

The odd duck is that JavaScript lives in environments that are not only different in CPU architecture but also implementation.  (Inside or outside the browser, Mac / Win / Linux, ppc, x86, etc.)

[Joshaven Potter]

phonegap may offer some insight but I most would like to see a definition on what is a proper API for JavaScript not how to encompass popular or even excellent libraries.

[Paul Prescod]

I think you misunderstood my suggestion. Sorry if I was not clear. I
was not suggesting that CommonJS encompass Phonegap. I was suggesting
that CommonJS treat PhoneGap as a likely future consumer of their
APIs, as browsers and servers are. Something like Air would also be a
logical consumer of these APIs on desktop computers.

[Wes Garland]

On Fri, Aug 28, 2009 at 3:54 PM, Joshaven Potter <your...@gmail.com> wrote:

Libraries have always made assumptions about there environment.  I wouldn't expect to copy a socket.h library from OS X 10.3 on a PPC to a Debian AMD 64 bit system.

The odd duck is that JavaScript lives in environments that are not only different in CPU architecture but also implementation.  (Inside or outside the browser, Mac / Win / Linux, ppc, x86, etc.)

What does this have to do with anything? Of course libraries vary from platform to platform, otherwise ... there would only be one implementation. APIs, on the other hand, are expected to be relatively stable.

Concretely, the standard sockets library really has changed since its introduction in .. what, BSD 4.3?  .. and is basically the same everywhere, including Windows.

Wes
 

[Joshaven Potter]

My point is that Phonegap should be a library (or framework if you will) and its ok if it is specific to particular environments...

The JavaScript API should not try to encompass PhoneGap.

The point of a JavaScript API should not be to standardize libraries or frameworks across environments but rather to standardize methods and what they do.

[Mark S. Miller]

On Fri, Aug 28, 2009 at 12:49 PM, Paul Prescod<pre...@gmail.com> wrote:
> [...] if

> you're talking about features of ECMAScript that were deployed in

> Safari 3 or so, it would be no problem. [...]

ES5 is not yet available in any available browser nor any other
Javascript implementation. Within few months I expect the situation to
be different. But as they say, "prediction is always difficult,
especially about the future."

--
Cheers,
--MarkM

[Hannes Wallnoefer]

2009/8/29 Mark S. Miller <eri...@google.com>:

ES5 (minus strict mode, minus bugs) is available in Rhino CVS today,
thanks to the excellent work of Raphael Speyer.

http://raphscallion.com/blog/

Hannes

> --
>    Cheers,
>    --MarkM
>
> >
>

[Daniel Friesen]

As well as a tiny bit of JS 1.8 (namely the shortened var {Foo} form of
destructing) and a fix for the 1.7 iterator bug (for each doesn't pass
the correct argument to iterators in the 1.7 release).
((It's probably a good idea to use Rhino CVS instead of the 1.7 release
if you are using 1.7+ features instead of just ES3/1.5 stuff))

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

[Mark S. Miller]

[+rspeyer, norris, google-caja-discuss, es5-discuss]

On Fri, Aug 28, 2009 at 4:35 PM, Hannes Wallnoefer<han...@gmail.com> wrote:
> ES5 (minus strict mode, minus bugs) is available in Rhino CVS today,
> thanks to the excellent work of Raphael Speyer.
>
> http://raphscallion.com/blog/

Awesome, I had no idea it had gotten this far. Congratulations Ralph!
Speaking as a Cajadores, this will be quite useful to us immediately.
Thanks!

Cajadores, we should check this into third_party *in addition to* the
ES3ish Rhino we've got so that we can test on both.

--
Cheers,
--MarkM

[Kevin Dangoor]

On Fri, Aug 28, 2009 at 11:00 AM, Mark S. Miller <eri...@google.com> wrote:

On Fri, Aug 28, 2009 at 6:39 AM, Kevin Dangoor<dan...@gmail.com> wrote:

>> On Thu, Aug 27, 2009 at 12:48 PM, Kris Kowal <cowber...@gmail.com> wrote:

>>> [...] so far as that our current implementations fall short of ES5, we are not
>>> compliant.

> With the exception of Kris' statement of "we are not compliant" above, I
> don't think I've seen anyone disagree with the 3 points that I make here. I
> think we should just move forward with that.

Ironically, the issue hangs on our recent name change. So long as we
were named serverjs, if we imagined that we were writing a standard
purely for server-side use where upgrade to new JS versions can be
quick, I think Kris' original language was the right thing. Now that
our name change has clarified our purpose to include browsers, where
we have to assume the normal 5 year lag, I agree with Kevin's
phrasing.

The primary focus remains non-browser contexts, and there are certain things (like JSGI) that don't make a whole lot of sense in a browser context. So, if Rhino, SpiderMonkey, v8 and JSCore all implement ES5, then I'd think it very likely that we could specify ES5 for the whole API (or a very large subset of it!)

I just don't want to use language like "not compliant" with respect to a spec that doesn't yet have implementations on the major platforms we're targeting.

[Hannes Wallnoefer]

2009/8/29 Mark S. Miller <eri...@google.com>:

> [+rspeyer, norris, google-caja-discuss, es5-discuss]
>
> On Fri, Aug 28, 2009 at 4:35 PM, Hannes Wallnoefer<han...@gmail.com> wrote:
>> ES5 (minus strict mode, minus bugs) is available in Rhino CVS today,
>> thanks to the excellent work of Raphael Speyer.
>>
>> http://raphscallion.com/blog/

To be more precise, I should have said "conformance test failures"
instead of "bugs", as that is what I was referring to. I've been using
some of the new ES5 features in Rhino and haven't had any problems so
far.

Hannes

> Awesome, I had no idea it had gotten this far. Congratulations Ralph!
> Speaking as a Cajadores, this will be quite useful to us immediately.
> Thanks!
>
> Cajadores, we should check this into third_party *in addition to* the
> ES3ish Rhino we've got so that we can test on both.
>
> --
>    Cheers,
>    --MarkM

> _______________________________________________
> es5-discuss mailing list
> es5-d...@mozilla.org
> https://mail.mozilla.org/listinfo/es5-discuss
>

[Mark Porter]

Not because they are the same, but because they are both extensions of JS1.5/ES3. There could conceivably be other extensions a implementation supports, such as ActionScript's syntax enhancements. My point is our choice is between ES3+shim and some other more advanced combination of syntax features.