Lit-html: 1.0 Release

[justinfagnani]

See progress in the 1.0 milestone: https://github.com/Polymer/lit-html/milestone/2

[ExE-Boss]

Investigate returning a Promise from render() that resolves when all async work is done

Possibly make it so that the promise resolves with the Node containing the rendered DOM if the container argument is not passed.

[ghost]

no RX functionality ?

[motss]

Don't see better support for Edge, IE11 and browsers with no support for native Web Components in the list. How come?

[logicalphase]

Recommend revisiting some the latest news. Edge bightly build activates
Shadow Dom which reduces the polyfills dependency. lit-html is working on
fixes for known IE11 conflicts. And there are still talks on adding html
import support albeit in a modified solution. Check on polymer channels in
Slack for related discussions.

[PaulHMason]

@hyperpress Wait, what? Edge has Shadow DOM in the nightly builds now?

[PaulHMason]

@motss lit-html is just about rendering dom and is meant to be used with different component models (or on its own). If you want to use native Web Components then you just use lit-html to render the dom inside your Web Component, or use something like lit-element, which wraps lit-html in a Web Component and adds the Polymer property effects to make life a bit easier,

[logicalphase]

Doh! Sorry Paul. I meant to say FF activated Shadow DOM. Edge is listed as
under consideration still.

[CaptainCodeman]

Consider making lit-extended the default: rename lit-html.js to lit-core.js and lit-extended.js to lit-html.js`

I think this would be a big improvement but I question whether there is much value in having any split at all - everyone imports lit-extended and having another variant that doesn't support the same template syntax only appears to save a few (notional) bytes in the package at the expense of creating a "gotcha" for people unfamiliar and unaware that the syntax differs.

[justinfagnani]

@CaptainCodeman the point of the split wasn't to save bytes, but to have an un-opinionated core that didn't add any additional semantics to HTML syntax, and extension points to add opinionated and more ergonomic flavors. Polymer-style syntax is only one way to allow for property binding and event handlers. @bgotink has created one with Angular-like syntax: https://github.com/bgotink/lit-html-brackets

[justinfagnani]

@gedw99

no RX functionality ?

What would that look like to you? lit-html so far only knows how to deal with built-in types. I don't think it the core should have opinions about userland types, other than to make it possible to nicely consume them via directives and part callbacks.

[justinfagnani]

@motss

Don't see better support for Edge, IE11 and browsers with no support for native Web Components in the list. How come?

Edge and IE11 are pretty well supported, outside of an attribute name issue that's filed.

lit-html has nothing much to do with Web Components, implementation wise.

[CaptainCodeman]

the point of the split wasn't to save bytes, but to have an un-opinionated core that didn't add any additional semantics to HTML syntax, and extension points to add opinionated and more ergonomic flavors. Polymer-style syntax is only one way to allow for property binding and event handlers ... one with Angular-like syntax: https://github.com/bgotink/lit-html-brackets

Thanks, I understand this provides some flexibility but if all it does is provide for a proliferation of different (incompatible) frankentemplate syntaxes I don't really see that as a good thing ... but if people can still do that by referring to a lower-level core class that isn't normally exposed as the default to people wanting to use lit-html it will tick both boxes and avoid confusion for lit-html users.

[justinfagnani]

Different template syntaxes are compatible - you can mix and match them. I'm not sure what would make a syntax a "frankentemplate" - the author of the particular template gets to choose what syntax they want, any consumer doesn't have to know.

[simonbuchan]

Sorry if this seems a bit self-serving to be pushing my own issue, but #283 is needed for proper interop with other libraries, not just observables: react, vue etc. all want to know when to clean up. Is this something you would want to support in a 1.0?

(really I should rename that issue to support "unmount" semantics in directives)

[tvvignesh]

I love the work all of you guys do. But, it would be great if you could give us some idea regarding the approx. release date for 1.0 milestone. Was planning to use Polymer 3 but I am lucky that I saw the link here: https://www.polymer-project.org/blog/2018-05-02-roadmap-faq which advises to use LitElement. While I will be happy to, I am just not sure of what would break if I start building with Lit now. Also, MWC for web components is also in active development. Some light would be great. Thanks.

[daKmoR]

so this will not be part of 1.0?
"Static parts - parts that interpolated before template creation" e.g. support for dynamic tags

also not as an extension like proposed in https://github.com/Polymer/lit-html/pull/568?

[justinfagnani]

@daKmoR probably not in 1.0, mainly because it's not a breaking change and not a release blocker. It could quick follow in 1.1.

[justinfagnani]

@tvvignesh check out the 1.0 milestone: https://github.com/Polymer/lit-html/milestone/2

It's updated as the issues close. Since it's redundant with this issue, but subscribers to this issue are probably wanting the notification when it's closed, I'm going to empty out the task list from the description here and just rename this to the "1.0 Release" issue.