23 ms·
Javascript is my favorite language, but building very large systems composed of interdependent modules is still very tricky and everybody does it differently (e
by cbetz 17y ago
Javascript is my favorite language, but building very large systems composed of interdependent modules is still very tricky and everybody does it differently (especially when you leave the browser and talk about the various server-side JS offerings).
The problem is that various ECMAScript standards committees never really considered "programming in the large". The CommonJS project is important because it aims to fill this gap and create a real JS ecosystem by:
1) Creating a standard for interoperable modules that handles scoping (i.e. module X can't mess with module Y) AND dependency resolution.
2) Attempting to define a set of standard APIs for binary data, files/sockets [streams], and anything else that you might want in a good standard library.
I encourage everyone who writes a lot of JS to join the CommonJS discussion group. Currently, the module API spec is mostly complete (and there are a good number of working implementations). The hot topic now is the Binary data API, which is extremely important because it will be used as a base for all subsequent modules that want to manipulate binary data.
- Maciek416 17y agoYou 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.
- siculars 17y agoman, i really hope they borrow a binary api that is already out there. bson, thrift, pb, avro... whatever. just stop reinventing the wheel already.
- tlrobinson 17y agoThe "binary api" the article mentions is for binary data types, which JavaScript lacks, not serialization protocols.
- amalcon 17y agoWhy is Javascript your favorite language? What combination of properties does it have that make it special, apart from the ability to run in the browser? I mean, it's hardly a bad language, but only the browser thing jumps out at me that says "Use this language for this problem!"
- cbetz 17y agoIn short: * It has C-like syntax with cool features like prototypical inheritance, an excellent object-literal format, first-class functions, and closures. * Everyone knows it (or thinks they do). * There are some really smart people in multiple different camps working on making extremely fast interpreters. Still skeptical about JS as a general purpose language? Watch Doug Crockford's "Javascript: The Good Parts". If he can't convince you, no one can. http://video.yahoo.com/watch/630959/2974197 http://video.yahoo.com/watch/630959/2974197
- ThinkWriteMute 17y agoHehe, on a small note I've never thought of C syntax as a positive note.