On Fri, Dec 19, 2014 at 8:55 PM, caridy <caridy at gmail.com> wrote:
> Yeah, the idea is to get engines (V8 maybe) to implement what is spec’d in ES6 today, and get a very basic implementation of <script type=module>. Remember, the goal is to get this out there asap to start gathering feedback from the community, and this seems to be the minimum requirements.

It would be fascinating to know why this is the prioritization. To me,
this looks like trying to rush something to be implemented to claim
some sort of progress. However, it is so limited and has so many
questions around it. It is hard to see how it is worth the swirl in
the community to introduce it.

The <module> tag is really a distraction. It is not needed to build a
working system. If the following pieces were worked out, it can be
skipped completely, and in the Worker case, needs to be skipped (I am
sure you are aware of the coming Service Worker bliss, so not just a
curious side issue):

* What has been referred here as “module meta”. This also includes
being able to dynamic import into the loader instance that loaded the
module.
* A loader.
* Module inlining.

Those all exist in some form in existing ES5-based module systems, and
all contribute to full module system. They do not need a <module> tag
to work. The browser use case definitely needs some new capabilities
to allow a loader to work harmoniously with CORS/Content Security
Policy, but that does not mean a <module> tag.

I would much rather see people’s time spent on those other items
instead of swirling on a <module> tag.

On Fri, Dec 19, 2014 at 8:55 PM, caridy <caridy at gmail.com> wrote:
> Yeah, the idea is to get engines (V8 maybe) to implement what is spec’d in ES6 today, and get a very basic implementation of <script type=module>. Remember, the goal is to get this out there asap to start gathering feedback from the community, and this seems to be the minimum requirements.

It would be fascinating to know why this is the prioritization. To me,
this looks like trying to rush something to be implemented to claim
some sort of progress. However, it is so limited and has so many
questions around it. It is hard to see how it is worth the swirl in
the community to introduce it.

The <module> tag is really a distraction. It is not needed to build a
working system. If the following pieces were worked out, it can be
skipped completely, and in the Worker case, needs to be skipped (I am
sure you are aware of the coming Service Worker bliss, so not just a
curious side issue):

* What has been referred here as “module meta”. This also includes
being able to dynamic import into the loader instance that loaded the
module.
* A loader.
* Module inlining.

Those all exist in some form in existing ES5-based module systems, and
all contribute to full module system. They do not need a <module> tag

to work. The browser use case definitely needs some new capabilities
to allow a loader to work harmoniously with CORS/Content Security
Policy, but that does not mean a <module> tag.

I would much rather see people’s time spent on those other items
instead of swirling on a <module> tag.