3 ms·
You bring up some good points. The next ECMAScript standard seems to be aiming for some programming-in-the-large goals (though the new features may not be enoug
by Maciek416 17y ago
You bring up some good points. The next ECMAScript standard seems to be aiming for some programming-in-the-large goals (though the new features may not be enough to satisfy everyone).
A couple months ago I saw some discussion about CommonJS on es-discuss which signaled that there is actually some influence flowing from CommonJS towards the new ECMAScript standard, with Brendan Eich briefly mentioning some of CommonJS' features. The ES committee is watching and learning from what is going on in the wild, and there is some overlapping consensus now on how JS can improve with regards to programming-in-the-large. This is a very good thing.
I'm curious how well and how quickly all these new server-side JS systems (nodejs, commonJS, V8, etc) will react to the upcoming new ES5. It now seems likely that JS coders will get to try out ES5 a lot sooner on the server-side than on the client-side, given how long it will take (forever-ish) for ES5 to be adopted in browsers.
- kriskowal 17y agoCommonJS is tracking ES5. For the time being, we vaguely suggest that all compliant implementations must support all features of ES5 that are implementable or stubbable with existing JavaScript features. For example, Object.freeze can be implemented as a stub no-op so people are free to use the API in their modules, and get the feature when it's supported. The intent is to eventually make ES5 compliance a requirement.