Re: [w3c/webcomponents] HTML Modules (#645)

> So I'm not all convinced that we need to put JS into HTML as done in the HTML import. In fact, we'd likely oppose to such an approach on the basis that popular JS frameworks such as React have gone to the completely other direction of embedding HTML inside JS.

I would be very curious to hear opinions from some framework authors - e.g @sebmarkbage (React), @developit (Preact), @yyx990803 (Vue) and @igorminar (Angular) on the direction of embedding resources like styles and HTML inside JS.  I acknowledge this is an increasingly popular pattern, however I'm curious if the availability of HTML Modules where colocated resources (including ES Modules) are a first-class citizen would actually be something they would find useful. 

In particular for the final bundles that get generated from their tools/Webpack.

Vue, at least during the dev/iteration workflow appears to have shifted closer to a HTML Imports-type thing while preserving some of the options for authoring in JSX or styles-in-JS if you really want to. It still converts everything to JS during the build cycle.

> Furthermore, for various performance reasons, we really need to have a mechanism to define an in-file ES6 module; a mechanism which allows multiple modules to be defined within a single JS file. Once we have that, then it's very natural to define three modules: one with HTML, one with CSS, and one with JS in a single JS file.

Do you see the need for a mechanism offering multiple ES modules in a single JS file being much different to a HTML module being the container enabling that? e.g

bundle.1.html
```
<script type="module">...</script>
<script type="module">...</script>
<script type="module">...</script>
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/645#issuecomment-310695716