On Fri, Dec 19, 2014 at 8:55 PM, caridy <car...@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. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss