A few module ideas

[dante federici]

   - Unable to load classic scripts (and other types of resources
   statically e.g. conditional modules) as part of the module graph

How are conditional imports static? In both examples I see the module as
being async, and therefore every dependent module is async. Your "dynamic
but static" is explicitly using "then" -- or are you implying a module
exporting async resources is a better solution than an async module?


   - Unable to specify more specific behavior for a module to prevent
   duplication

By passing arguments in, what do you expect to occur? Do you expect the
module itself to be run with those arguments, exporting a set of things?
How is that any better than just importing a constructor function from the
module/library? This problem sounds like designing the library in a better
way would make more sense than affording config to be passed into import,
which would mean each import would re-run the module, so no caching.


   - Either have to have lots of almost duplicate import declarations or
   have to load unnecessary files

I can see a benefit for reducing files in the static export -- that
suggestion has been a good example of existing problems with tree shaking
d3, to which the response has been "design better exports". As for the
multiple fetch part of the problem, HTTP/2 spec addresses the performance
hit for that, and it's effectively what you're asking the "static" prefix
to assert. Out of curiosity, how would you expect static to work in the
first place? Who would do the assertion that it doesn't depend on any other
symbol in the module it is a part of?

I feel like out of these, the solution is much closer to "Better library
design". I'm still not 100% on how your dynamic example addresses "turns my
code async".  Static export is an interesting one -- effectively asking for
pure symbols. Maybe identify an entire file as "load only these symbols,
ignore other source"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170820/cac8fcc3/attachment.html>