I'm sure it's been considered, but since this is es-discuss and open to any
gadfly:
Has it been considered that, regarding modules, all that developers need is
(1) a way to inform the engine, at compile time, that certain external
scripts are needed, and (2) a way to return a value from a script?
I have a bunch of experience with CommonJS modules and module loaders
(having written a couple myself), and have yet to see a case where anything
more than this is required. In fact, for my own work I use a system very
similar to a subset of AMD and have found CommonJS's "exports" and "module"
variables to be unnecessary. I have yet to see a case where a design that
includes a circular dependency could not be improved by eliminating the
circular dependency. Taking a (very) unscientific sampling of Node.js
packages, I see most of them just returning a value via the "module.exports
= " idiom.
The proposed module system is really nice; kudos to those working on it.
But might not a small change to the language, as described above, serve
the community just as well? Would this small change not be easier to learn
and easier to adopt?
khs
I'm sure it's been considered, but since this is es-discuss and open to any
gadfly:
Has it been considered that, regarding modules, all that developers need is
(1) a way to inform the engine, at compile time, that certain external
scripts are needed, and (2) a way to return a value from a script?
I have a bunch of experience with CommonJS modules and module loaders
(having written a couple myself), and have yet to see a case where anything
more than this is required. In fact, for my own work I use a system very
similar to a subset of AMD and have found CommonJS's "exports" and "module"
variables to be unnecessary. I have yet to see a case where a design that
includes a circular dependency could not be improved by eliminating the
circular dependency. Taking a (very) unscientific sampling of Node.js
packages, I see most of them just returning a value via the "module.exports
= " idiom.
The proposed module system is really nice; kudos to those working on it.
But might not a small change to the language, as described above, serve
the community just as well? Would this small change not be easier to learn
and easier to adopt?
khs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120125/752ef919/attachment.html>
I'm sure it's been considered, but since this is es-discuss and open to any gadfly:
Has it been considered that, regarding modules, all that developers need is (1) a way to inform the engine, at compile time, that certain external scripts are needed, and (2) a way to return a value from a script?
I have a bunch of experience with CommonJS modules and module loaders (having written a couple myself), and have yet to see a case where anything more than this is required. In fact, for my own work I use a system very similar to a subset of AMD and have found CommonJS's "exports" and "module" variables to be unnecessary. I have yet to see a case where a design that includes a circular dependency could not be improved by eliminating the circular dependency. Taking a (very) unscientific sampling of Node.js packages, I see most of them just returning a value via the "module.exports = " idiom.
The proposed module system is really nice; kudos to those working on it. But might not a small change to the language, as described above, serve the community just as well? Would this small change not be easier to learn and easier to adopt?
khs