Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTML Modules #645

Open
justinfagnani opened this issue Jun 20, 2017 · 172 comments
Open

HTML Modules #645

justinfagnani opened this issue Jun 20, 2017 · 172 comments

Comments

@justinfagnani
Copy link
Contributor

@justinfagnani justinfagnani commented Jun 20, 2017

Now that JavaScript modules are on the verge of widespread browser support, we should think about an HTML module system that plays well with it. HTML Imports doesn't have a mechanism for exporting symbols, nor can they be imported by JavaScript, however its loading behavior is quite compatible with JavaScript modules.

@dglazkov sketched out a proposal for HTML modules here: https://github.com/dglazkov/webcomponents/blob/html-modules/proposals/HTML-Imports-and-ES-Modules.md

The main points are that, using the JavaScript modules plumbing, you can import HTML.

Either in HTML:

<script type="module" url="foo.html">

or JavaScript:

import * as foo from "foo.html";

But within the scope of that sketch there are still several questions about the specifics of exporting symbols from HTML and importing to JavaScript.

@justinfagnani
Copy link
Contributor Author

@justinfagnani justinfagnani commented Jun 20, 2017

@TakayoshiKochi made a polyfill (based on the <script type-module> polyfill by @matthewp) that implements one set of choices to the questions, and shows JS and HTML modules working together: https://github.com/TakayoshiKochi/script-type-module/tree/html-module-experiment

@domenic
Copy link
Contributor

@domenic domenic commented Jun 20, 2017

Thanks for starting the discussion, @justinfagnani!

For context for others, I've been involved with @TakayoshiKochi and others trying to firm up what HTML modules means before we present it widely. There's still a variety of possibilities. Here's my high-level overview:


Writing a custom element that authors can include using a single file is a bit tricky. In particular, how do you get your template HTML? (Which is often literally a <template>.)

  • If you want to stay self-contained, and thus friendly to consumers, you're currently forced to inline your HTML into your JavaScript as a template string, then later use innerHTML. This is costly; it requires first parsing it in JavaScript, then later as HTML, and using up extra memory for both representations. It requires all-at-once parsing, instead of streaming, and requires it to be done on the main thread (I think). And it defeats the preload scanner for any subresources.
  • If you want to "use the platform", you'll have to ask your consumers to include the <template> in their index.html, with some well-known ID. Then all of the above disadvantages disappear, but consuming your library is very un-ergonomic.

At a high level, HTML modules wants to solve this problem. I think the case for it being a worthwhile problem would be stronger if we had data on the costs of the HTML-in-a-JS-string solution, but just by inspection it seems pretty bad. Still, I hope we can provide some data.


The next big question then is about developer ergonomics: what should the authoring and consumption experience for web components be?

  • At one extreme, we could just allow importing of inert DocumentFragments via the JS module system. This solves the above problem in a minimal, simple fashion. But, it means you cannot collocate your HTML and JS into a single file. Most modern frameworks seem to aim for a developer experience of collation, from React's JSX, to Vue's .vue files, to Polymer's HTML imports usage, to Angular's HTML-in-a-JS-string approach.
  • At another, we could work to add some opinionated semantics to imported HTML files that make them good as a "container" format for a web component. This is the approach @TakayoshiKochi has gone with, and I think it's a good illustration. It's much less of a primitive, and requires adding new unusual semantics (e.g. executing scripts outside the main document), but that might be OK.

Hope this helps set the stage!

@addyosmani
Copy link

@addyosmani addyosmani commented Jun 20, 2017

Thanks for getting a public discussion going, @justinfagnani!

I see HTML Modules as being a good container format for achieving generic subresource dependency specification. They solve a need for platform-level colocated <template>, <style> and <script>/Module in a similar style to what I would get with something like Vue's .vue files or Polymer's existing HTML Imports. I'd love for them to sufficiently export a JS module - I found this to be a shortcoming of HTML Imports when I last used them.

Some questions:

  • What it is about HTML Modules that makes them specific to Web Components? If a third-party decides to just use HTML + CSS + JS in this container format, that should just work too right? I think we should cater for a few different styles of component to work well with HTML Modules.

  • Are HTML Modules primarily a DX convenience for containment? or do we also foresee trying to bake in a performance carrot (e.g preload scanner benefits) to the design?

  • How do we see HTML Modules fitting with respect to the broader Web Packaging efforts?

@justinfagnani
Copy link
Contributor Author

@justinfagnani justinfagnani commented Jun 20, 2017

I also want to point out that HTML modules would not prescribe how component developers package their libraries, or even prescribe Web Components for that matter.

There are a number of styles that components could be written and/or packaged:

  1. Pure JS, using either template strings, DOM builder libraries, JSX, etc. (no HTML modules)
  2. Logic in JS, template/CSS in HTML: import template from 'template.html'; in the component's module. Maybe event import style from 'styles.css'; is we include CSS modules.
  3. Single-file, like Vue and Polymer: JavaScript, HTML and CSS all in one file.

These styles could all be compatible.

@domenic
Copy link
Contributor

@domenic domenic commented Jun 20, 2017

These styles could all be compatible.

That's a good point. Even if we go with an opinionated container format with new capabilities, like @TakayoshiKochi's prototype, it will likely be possible to opt-out of those new capabilities, e.g. by just making your main element a <template> so that everything inside it is inert.

@matthewp
Copy link

@matthewp matthewp commented Jun 20, 2017

It looks like @TakayoshiKochi's experiment doesn't create a new document for the imported module. Not sure if this is an intentional omission or not, as the @dglazkov sketch does mention there being a new document like in html imports. Here's an example module for those interested.

In the interest of listing problems and not solutions I would say some things I want (in addition to other things mentioned by people above) are:

  1. I want to be able to export JavaScript modules from an HTML module.
  2. I want to be able to query for elements within the HTML module.
  3. I want to be able to "reach in" to an HTML module some how from the outside and use stuff other than the HTML modules within. But maybe if (1) and (2) are satisfied that would mean that an HTML module could make the other parts (like the <template>) accessible?
@TakayoshiKochi
Copy link
Member

@TakayoshiKochi TakayoshiKochi commented Jun 21, 2017

Thanks @justinfagnani for starting this thread! Thanks @domenic for the summary.
I was wondering if this is a good place as @addyosmani mentioned if HTML Modules may not be
specifically for web components. But as it is, this is good starting here in public:)

We're open to any questions / problems for HTML modules.
Feel free to pour your thoughts here.

FYI, here's slide deck I presented in BlinkOn back in February:
https://docs.google.com/presentation/d/1ksnC9Qr3c8RwbDyo1G8ZZSVOEfXpnfQsTHhR5ny9Wk4/edit

@TakayoshiKochi
Copy link
Member

@TakayoshiKochi TakayoshiKochi commented Jun 21, 2017

Re @matthewp (#645 (comment))

It looks like @TakayoshiKochi's experiment doesn't create a new document for the imported module.

Yes, it was intentional. Imported HTML is treated as DocumentFragment (as opposed to Document), so we don't have to bother about various semantics to be satisfied, although it yields some weirdness (e.g. why/how can <script> inside be executed?). I'm interested if you prefer Document (other than that was described in Dimitri's doc) to DocumentFragment.

If you're interested in history, here's record of Document vs DocumentFramgent for HTML Imports:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22305

@TakayoshiKochi
Copy link
Member

@TakayoshiKochi TakayoshiKochi commented Jun 21, 2017

We are interested in hearing requirements from framework authors, as HTML modules is not (should not be?) specific to web components definition (= container for custom elements and shadow DOM definition).

I admit that my experimental polyfill was biased towards HTML Imports + web components, and would be a good fit for Polymer or Vue use cases, but I would be more excited if the resulting HTML modules would be usable for more than these frameworks or libraries.

In my blink-dev thread, a developer from Scirra introduced me his very inspiring blog post:
https://www.scirra.com/blog/ashley/34/html-imports-are-the-best-web-component
The post is long, but I recommend reading it from top to bottom - my interpretation is that HTML Imports fit their product development requirement quite well, even though they do not use Shadow DOM and do use only little Custom Elements. That exemplifies the need for something that supports scalable development on web platform, and HTML Imports is one key primitive for it.

@rniwa
Copy link
Contributor

@rniwa rniwa commented Jun 21, 2017

Here's my take on this. In today's world, developers are putting HTML inside their JS, not JS inside their HTML. The fact that we don't currently preload resources in a string literal, or we end up two string representations of HTML if you used string literal to include HTML in a JS file is a pure implementation detail. There is nothing preventing us from implementing an optimization if there was a well known symbol which was used to tag a HTML in a JS.

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.

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.

@matthewp
Copy link

@matthewp matthewp commented Jun 21, 2017

@rniwa I find this opinion confusing given your interest in template parts. Are you not interested in that feature either, now? Or are you saying you'd prefer to define your <template> (with parts) as a string literal in JS rather than in HTML. Why?

@web-padawan
Copy link

@web-padawan web-padawan commented Jun 21, 2017

the basis that popular JS frameworks such as React have gone to the completely other direction of embedding HTML inside JS.

While not being a framework author nor a browser developer here, just an end-user, I'd like to say that, although it is a widely adopted approach, it still requires tooling and you'll not be able to serve vanilla HTML, CSS and JS unprocessed by stuff like Webpack and so on.

I'd also like to remind you that React was initially built with PHP where including HTML was once widely used. But is such a mixing really considered as a good practice by PHP developers now?

Furthermore, how shall HTML modules work in browsers with disabled JavaScript? If markup stays in HTML, I can imagine them still working somehow. But what if it is placed in string literals?

@AshleyScirra
Copy link

@AshleyScirra AshleyScirra commented Jun 21, 2017

I wrote this blog post. I'm interested in participating in work for HTML modules, and I think our experience is valuable: we have published a commercial PWA using ~300 HTML imports.

As I touched on in the blog, I quite like the idea of being able to import a HTML file and get a Document, much like XHR for type "document". So this:

import * as doc from "./myimport.html"

would be similar to assigning doc the Document resulting from fetching myimport.html. You can then querySelector etc. on doc and use its DOM content in the JS module. (IMHO, this is far better than pasting chunks of markup in to strings in JS)

Then all you need to do is add a HTML tag that can propagate to further dependencies. I suggested changing

<link rel="import" href="import.html">

to be equivalent to

<script type="module">
import * as doc from "./myimport.html"
</script>

It could equally be <script type="module" src="myimport.html"></script> to do the same. This means further scripts/imports/modules are loaded and run, etc.

I have to say style application from imports is a useful feature for us - see my example of a dialog definition for an example. It's possible a framework could work around this (e.g. applyStylesFrom(doc)), but it seems a shame if the dialog definition example can't work natively.

If HTML modules covered that, I'd guess that largely covers everything we use imports for. In our case they're largely just the architectural scaffolding that brings together all the components of our web app, and as I tried to emphasise in my blog, they excel at that, particularly since it covers all three aspects of a web app (markup, style, script, at least until Google roll back style application 😢).

I am strongly against trying to use script for any markup or style content. I know some frameworks are having success with that approach, and so we shouldn't do anything that makes that harder. But if you have 1000 lines of markup, surely nobody wants to paste that in to a script as a giant string? I strongly believe that there should at least be the provision for leaving markup in HTML files, and not orient the spec around doing what one framework does today. Remember frameworks come and go over the years. In our case, our PWA is notable for not using VDOM, has almost no use of markup-in-script, uses plain markup (no Angular-style directives), no templating (like {{this}} in markup), and no two-way data binding. I don't think any other framework on the web today takes this approach, but I believe our PWA proves that you can still build scalable, complex web apps that way. I do worry that people have framework-blindness where they think things should be done like the frameworks do, rather than thinking in terms of providing general-purpose capabilities that frameworks of different designs and approaches can make use of, even in the future when everything likely changes.

Anyway, here's a couple of extra ideas that may be useful to extend the utility of HTML modules as I described them. Perhaps it'd be useful to add a selector to pick out specific elements, e.g.:

import "#elem" as elem from "./myimport.html"

Now elem is the DOM element returned by matching the selector #elem on myimport.html. Not sure how to handle multiple results (e.g. using ".myclass" as a selector) - maybe import ".myclass" as [resultsArray] from ".myimport.html"?

Finally I don't know if it makes sense to export from a HTML module, but perhaps you could have something like:

import myElem from "./myimport.html"

where myimport.html has a special tag like

<export name="myElem">
    <div>This div is an exported element!</div>
</export>

Perhaps that could also be reconfigured to re-export a JS module that the HTML module imports, e.g:

<export name="submodule">
    <script type="module" src="a.js"></script>
</export>

...then allowing import submodule from "./myimport.html", which propagates the exports from a.js through the HTML import and in to another JS module. I feel like I'm shooting in the dark there though!

@domenic
Copy link
Contributor

@domenic domenic commented Jun 21, 2017

Furthermore, how shall HTML modules work in browsers with disabled JavaScript? If markup stays in HTML, I can imagine them still working somehow. But what if it is placed in string literals?

I can answer that, at least: they won't. HTML modules are part of the module system, which is entirely dependent on JavaScript.

Even HTML imports never worked in browsers without JavaScript. (The document would be "imported", but useless, since you need script to access imported documents.)

@justinfagnani
Copy link
Contributor Author

@justinfagnani justinfagnani commented Jun 21, 2017

Even HTML imports never worked in browsers without JavaScript. (The document would be "imported", but useless, since you need script to access imported documents.)

Depending on future developments of course. Declarative custom elements (which we'll talk about at TPAC) presumably wouldn't need script enabled.

@domenic
Copy link
Contributor

@domenic domenic commented Jun 21, 2017

Declarative custom elements (which we'll talk about at TPAC) presumably wouldn't need script enabled.

Uh... let's just say I disagree with you very strongly on that, and we can leave that discussion for another time, instead of derailing the thread.

@justinfagnani
Copy link
Contributor Author

@justinfagnani justinfagnani commented Jun 21, 2017

@rniwa I wouldn't want to encode only what has become most popular today for two reasons:

  1. Because where we are now is largely a consequence of what capabilities the platform has had. JavaScript developed popular user-land module systems and loaders long before HTML Imports, and is now getting widespread native modules before HTML. Given the lack of support HTML Imports has, Polymer has had to carefully weigh it's options for working in browsers without polyfills. If Polymer had decided to support a pure-JS distribution that would have been be a pragmatic choice only and not an indication of what we'd really like to use.

  2. The assertion (developers are putting HTML inside their JS, not JS inside their HTML) might not be so absolute. Polymer and Vue are current examples of libraries that support single-file HTML components with scripts. There would be much more if it were a native capability.

I'm not saying JS shouldn't also gain pre-loading and multi-module support, of course.

@milieuChris
Copy link

@milieuChris milieuChris commented Jun 21, 2017

@AshleyScirra
Copy link

@AshleyScirra AshleyScirra commented Jun 21, 2017

The only way I can imagine HTML modules being useful with script disabled is if they basically inserted their full DOM content at the place they were included. So to use HTML imports as an example, <link rel="import" href="import.html"> would be equivalent to copy-pasting the contents of import.html in place of that tag. I guess it would actually be nice to have a native way to have your header and footer sections defined in one place.

I get that some people are annoyed by the obnoxious things JS does on some pages. But if you're building a web app, it's simply inconceivable to develop it without JS. It would be like writing an Android app with Java disabled - can you still produce a useful app? The web is still an amazing resource for static documents which can work with JS disabled, but on the whole I think modules are aimed very much at the app side of development, where it would naturally pair with JS logic for an app. Still, I don't see any reason to exclude the HTML-only case. Maybe an include attribute, like <script type="module" src="import.html" include> , could specify to just paste in the DOM content there?

@milieuChris
Copy link

@milieuChris milieuChris commented Jun 21, 2017

@rniwa
Copy link
Contributor

@rniwa rniwa commented Jun 22, 2017

Perhaps we need to figure out what the declarative syntax for shadow DOM / custom elements will look like before we can figure out what HTML import should look like.

It's hard to talk about packaging a thing without knowing what the thing looks like.

@TakayoshiKochi
Copy link
Member

@TakayoshiKochi TakayoshiKochi commented Jun 22, 2017

For including HTML into HTML, probably you can imagine there is a <include src="..."> HTML tag that magically does what server-side include did on the client side. It would be nice to have.
However it is a separate problem or use case from HTML Modules - which wants to load HTML as a resource and do something on it with scripting.

@AshleyScirra
Copy link

@AshleyScirra AshleyScirra commented Jun 22, 2017

Yes, I think the include case should be split out in to a separate discussion. Maybe a new issue should be filed for it?

@TakayoshiKochi
Copy link
Member

@TakayoshiKochi TakayoshiKochi commented Jun 23, 2017

@AshleyScirra if you want it to happen, whatwg/html would be more appropriate place to file an issue than here.

@rniwa declarative Shadow DOM / Custom Elements would be nice to have, but we don't have to be blocked on it, because assuming it's all written in HTML and no script then it is just a plain HTML. Although I can imagine that declarative syntax would not be such a simple thing because its semantics would involve hooks into HTML parser and DOM tree construction...

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.

Is this idea presented or discussed anywhere? This is very interesting and I would like to learn more about it.

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.

Real-world web development is constrained by actual implementations of browsers available and used today, and React may be the optimal thing to do modular development on the current web platform, but as we are expanding (relaxing?) the constraints of the platform, we don't have to be trapped in the local optima. (that said, I don't say we should ignore React's popularity)

@addyosmani
Copy link

@addyosmani addyosmani commented Jun 23, 2017

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>
@treshugart
Copy link

@treshugart treshugart commented Jun 23, 2017

declarative Shadow DOM / Custom Elements would be nice to have

I'd like to emphasise that a lack of declarative shadow DOM is a pretty massive complaint from the community and shouldn't be dismissed as a nice to have.

@justinfagnani
Copy link
Contributor Author

@justinfagnani justinfagnani commented Jun 23, 2017

I'd like to emphasise that a lack of declarative shadow DOM is a pretty massive complaint from the community and shouldn't be dismissed as a nice to have.

I don't think it's a dismissal at all. In the context of HTML Modules, the question is whether or not declarative custom elements and shadow roots should block moving forward on modules.

@treshugart
Copy link

@treshugart treshugart commented Jun 23, 2017

👍 just making sure it's being heard is all.

@sebmarkbage
Copy link

@sebmarkbage sebmarkbage commented Jun 23, 2017

@addyosmani I do think this general architecture is valuable. It can be used to import both somewhat static content but also for loading pieces of a server-rendered page out-of-order and inject dynamically. So, I'm all for it for frameworks that are HTML heavy and centric.

However, for React, and I believe this is a more general trend, we're increasingly looking for ways to avoid passing static, or server responses, as HTML as the serialization format. For these use cases we might use custom byte codes like Glimmer or some other format. There's a lot of value in a richer serialization format that can include more data to pass to JS, cheap branching and conditional logic, immediate access to references to nodes etc. I'm asking myself what value HTML, as the serialization format, offers to a JS library once it's already up and running. I see soft value like familiarity, and concrete value like browser specific caching formats. However, those have to be weighed against other things.

Even if you use what seems to happen is that you end up with two modes in the JS library to deal with nodes created from HTML and nodes created from another mechanism. That adds complexity and code.

@justinfagnani
Copy link
Contributor Author

@justinfagnani justinfagnani commented Jun 23, 2017

Can you clarify

you end up with two modes in the JS library to deal with nodes created from HTML and nodes created from another mechanism. That adds complexity and code.

Node in HTML Modules would be standard Nodes in the rest of the DOM, there wouldn't be different types.

@littledan
Copy link

@littledan littledan commented Oct 27, 2018

@dandclark With those * re-export semantics, I guess you'd lose default exports (which don't get re-exported). Is this acceptable? There's a concrete case here that I don't know how should be resolved, of what the default export should be if both script tags have one.

@dandclark
Copy link
Contributor

@dandclark dandclark commented Nov 2, 2018

  • @Jamesernator I’m hesitant to complicate the model by including non-synchronous classic scripts unless we're sure we have a compelling use case. It is already a limitation of ES6 script modules that they can’t import classic scripts, so if we consider this to be a problem it’s probably one that we should try to address in a general sense for both HTML and script modules.
    Sidenote: your comment prompted me to think of another interesting case: <script type=”module” async> in an HTML Module. Per spec I guess we’re free to execute async scripts pretty much whenever we want, but I need to think about whether this has any tricky implications that we need to watch out for.

  • @caridy Yeah, I like option A best too ("throw an error for the HTML module if it is found during parse-time to contain a non-module-type script element").

  • @tomalec I hadn’t seen the display locking proposal, this does seem like an interesting potential alternative to the dynamic import() idea for FOUC prevention.

  • @littledan My previous comment elided our proposed default export behavior. Our thinking for default exports is this:

    • If no inline scripts specify a default export, set the HTML import’s document as its default export.
    • If one inline script specifies a default export, pass that through as the HTML module’s default export.
    • If multiple inline scripts specify a default export, throw an error during module instantiation – similar to what happens when a single module script tries to use multiple default exports.
@schlm3
Copy link

@schlm3 schlm3 commented Jan 16, 2019

I know, I am very late in this discussion, but wanted to throw in my opinion on the lost Html Imports:
We have been developing a Web-Application suite for the last three years based on Polymer 1.x. The WebApplication suite's core library contains 230 Custom Elements. When used in an Application of our suite, this makes use of >3000 Html Imports.
When we decided to start with Polymer 1.x, one key point of the decision was the ability to define a WebComponent in one file, having markup, style and script in one place with the ability to debug all that without a compilation step in between. Of course, it was crucial, that we could import WebComponents inside WebComponents etc. such that we could divide the Application into parts.
As the applications grew, one other important point were dynamic imports, which we need to use for late-loading parts of our applications.

We now have released the first public release of our new application suite and have the time now to plan upgrading our code base from polymer 1.x to some more recent release, like for example Polymer 3.0.
The question is: Shall we really migrate to something which does not meet our initial requirement of having the markup together with the style and script? What are the alternatives?
This thread lets me hope, that there will be some replacement to the beloved html import sometimes. But how long might this take and how good are the chances that it will even make it into a standard implemented by all browser vendors?

@justinfagnani
Copy link
Contributor Author

@justinfagnani justinfagnani commented Jan 16, 2019

@schlm3 There are basically two options for single-file components right now:

  1. Use .js as the file and write HTML templates in JS. Polymer 3 does this by simple including out HTML-based template syntax as a string. LitElement does this by using tagged template literals to put only the static parts of templates into strings and move the binding expressions into native JavaScript. This has a lot of benefits to some users when you consider that the data you're trying to interpolate into template instances exists in JS already and is naturally accessible there.
  2. Use a tool that compiles HTML to JavaScript modules. The is essentially the Vue approach and there are other tools to do this for lit-html, internal tools at Google, etc. This approach still lets you leverage the JS module loader system so dependencies are correctly loaded, ordered, etc. It does force you to decide on answers to all the questions the HTML Modules proposal brings up though, and is essentially a compile-time polyfill for the idea.

Until HTML Modules proceeds, that's about what you can do.

@AshleyScirra
Copy link

@AshleyScirra AshleyScirra commented Jan 17, 2019

Or you can use a HTML imports polyfill to keep using them, e.g. https://github.com/AshleyScirra/html-imports-polyfill

@schlm3
Copy link

@schlm3 schlm3 commented Jan 17, 2019

@AshleyScirra The Polymer polyfill (in webcomponents.js) which has been developed initially for the non-chrome browser should also work for Chrome 73 (see https://groups.google.com/a/chromium.org/d/msg/blink-dev/h-JwMiPUnuU/sl79aLoLBQAJ )

The problem I have is more, that we rely actually on toolchain (Polymer-CLI) and WebComponents which are outdated and not maintained anymore and that the actually maintained Polymer-Version requires us to migrate our whole codebase to be .js based. All this with the knowledge, that people are working on "HTML Modules" which might bring back more ore less what we have today in .html. Shifting from Polymer 1.x to 3.0 will be roundabout a 100'000$ investment. So it should really pay out...

@Jamesernator
Copy link

@Jamesernator Jamesernator commented Jan 24, 2019

The Chrome team has released an intent to implement on a form of HTML modules: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ewfRSdqcOd8/w_Fr6rJ3DQAJ

This proposal does allow including styles, templates and exports inside a single file. So this should meet your criteria @schlm3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.