I think a stand-up fight about this sounds wonderful.
I am not at all convinced that typo-checking is anywhere near worth
the price tag, or is even a problem. Most of the alleged needs for
type-checking are a bit dubious to me; that's not really what JS is
all about.
It would be great for one of the static-export proponents to catalog
some current problems in the wild today that this would address, with
code examples that use modern module systems.
Re: Conditional Importing
Only allowing `import` at the top level sounds like an ok idea, but
I'm not so sure it's necessary. Consider the current require() style:
if (some_rare_condition()) {
foo = require('foo')
}
In requirejs and browserify the 'foo' module will be *defined*, but
never loaded (ie, prefetched, evaluated for deps, bundled, etc). In
Node, it won't be read from the disk or evaluated (but if it's not
there ON the disk, you'll have problems eventually, which is
conceptually equivalent to having already been fetched, but without
the pre-run safety check.)
if (some_rare_condition()) {
foo = import 'foo'
}
could be treated similarly. There is an import statement, so resolve
it and define it. However, it's never actually evaluated/run until
the first time the condition is hit, so the program text will be
parsed for `import`s, but never actually executed.
I am not aware of this being a surprise to many people in the current systems.
> It's true you can use today's JQuery as is, but why would you use a new
> client API or syntax and require only new browsers or else trans-compilation?
> What's the benefit?
I'm confused. Isn't `module "jquery" { ... $teh.Codez() ... }`
already going to require only new browsers, as well as code editing or
trans-compilation? Why is that less onerous than a new API or html
tag, especially when the tag can desugar to the API?
But, that being said, as I mentioned in the cited blog post,
auto-exporting the global is a bit weird, at least. Making changes to
old libraries is costlier than we tend to think, but usually not
prohibitively so (and when it is, we just write new libraries).
I definitely agree that speculating about the future is hazardous,
which is exactly why I think that the module specification (and all ES
specs, actually) should focus on the problems we have today, and aim
to deliver value to today's programs. We should look at current
common problems, and ask, "What is the minimum change to the
language's semantics and syntax that will make *this problem* go away,
without causing new problems, or preventing other solutions?"
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
