4 ms·

Author here. I must begin by saying that lit-HTML is really interesting, and I hope it does well. It will be particularly exciting if Polymer 3 or Polymer 4 or

Author here. I must begin by saying that lit-HTML is really interesting, and I hope it does well. It will be particularly exciting if Polymer 3 or Polymer 4 or whatever primarily uses lit-HTML out of the box. > lit-html is not a new framework, but simply a template library. Nobody wants to be called a framework, do they? For years, React developers insisted that it was nothing but a "view" layer, because everybody knows that "frameworks" suck. > lit-html has no component model, so by using it to implement WCs, you get a component model. I think you mis/underestimate the extent to which you have a component model already. What you already have is the equivalent of React's "functional components," where the component is nothing but its render method. > A template library is not in direct competition with Web Component base classes/frameworks, but can be used by them It's great that WCs let you interop with all WC-based frameworks, but some folks will avoid lit-HTML in favor of Stencil's JSX approach, or in favor of Svelte's Vue-alike HTML components, or more generally to decide whether to observe changes and respond to them or whether to regenerate the UI as a function of state. Interop doesn't mean you're not in competition.

floatboth 9y ago
> decide whether to observe changes and respond to them or whether to regenerate the UI as a function of state These things don't conflict with each other though. In Polymer, you usually observe changes to fire off requests and stuff, but the UI is pretty much described as a function of state.
rictic 9y ago
> I think you mis/underestimate the extent to which you have a component model already. What you already have is the equivalent of React's "functional components," where the component is nothing but its render method. When we (Polymer folks) think of a component model, we think of a lifecycle. Being notified when you boot up, when you're activated, when you're deactivated, and when the state you care about changes. React has that, Web Components have that, lit doesn't. Agreed that there's a lot of baggage on the term `framework`, it's probably a good idea to taboo the word and break it apart into the pieces that we care about. IMO that's: - how big is the cost of adding the dependency – mostly this is the size of the library - how big is the ecosystem of code that it can play nicely with - are there well documented best practices - is there a complicated black box of internals that do a bunch of magic, or is it composed of small modular pieces that can be understood in isolation

floatboth 9y ago

> decide whether to observe changes and respond to them or whether to regenerate the UI as a function of state These things don't conflict with each other though. In Polymer, you usually observe changes to fire off requests and stuff, but the UI is pretty much described as a function of state.

rictic 9y ago

> I think you mis/underestimate the extent to which you have a component model already. What you already have is the equivalent of React's "functional components," where the component is nothing but its render method. When we (Polymer folks) think of a component model, we think of a lifecycle. Being notified when you boot up, when you're activated, when you're deactivated, and when the state you care about changes. React has that, Web Components have that, lit doesn't. Agreed that there's a lot of baggage on the term `framework`, it's probably a good idea to taboo the word and break it apart into the pieces that we care about. IMO that's: - how big is the cost of adding the dependency – mostly this is the size of the library - how big is the ecosystem of code that it can play nicely with - are there well documented best practices - is there a complicated black box of internals that do a bunch of magic, or is it composed of small modular pieces that can be understood in isolation