4 ms·

Both these look great, But I dont understand Googles stand on Polymer now. Does Polymer use this or Polymer and lit-* are going different direction

lstamour 8y ago
https://www.polymer-project.org/blog/2019-02-05-lit-element-and-lit-html-release https://www.polymer-project.org/blog/2019-02-05-lit-element-... is probably a better link for context. These two lightweight libraries are building on top of browser advances. And now I’ll start speculating, I’ve no inside baseball — but the way I see it, Polymer is having a bit of a re-think (3 times in a row now, if I recall correctly) because some early ideas on HTML includes and zip packaging are taking longer to become web standards. And having little market traction, with official Material components published for multiple JS frameworks, Polymer has to evolve and simplify to gain traction. These projects appear to be part of that evolution. I suspect the next thing that might encourage more use of these sort of components and modularization would be the “never-slow” modes recently debated on HN, but there’s a push and pull. Sometimes browser-makers get web devs to adopt their new APIs or heed their warnings, other times it’s the browser-makers wondering if they can make virtual dom diffing more efficient, or effectively embed the core of React or Vue frameworks into first-class browser APIs. If so, these might be considered a first step towards newer API iterations. I’d really like the inside scoop on how web components are working out for Google/YouTube in practice, but for now these frameworks are just “yet another way of doing web components”, but with potential if Vue or other front-end JS frameworks adopt them down the road now that the API for these have hit a stable 1.0.
spankalee 8y ago
lit-html and LitElement are products of the Polymer project. They're different enough from the classic Polymer library, yet can be used interoperably with Polymer because it's all just web components, that they deserved new names. The classic Polymer library is in maintenance mode now. It's getting critical bug, security, and performance fixes only. We're moving customers from Polymer 1 & 2 to Polymer 3, then from there we're encouraging them to incrementally adopt LitElement, which again, they can do because they work together. Our situation is quite different from frameworks because of web components. First, we care more about web components adoption than any specific library. Then, because apps can mix web components made with different libraries, we don't have to bank everything on one flavor or specific set of ideas. That said, we think lit-html is an even better solution than what we've had before, and we're focusing on that.
- nwmcsween 8y ago
  How does LitElement compare with something like hyperapp[1] or meiosis[2]? The issue I have with $new_tool is trying to figure out what it offers vs the competing tools and it's a non-trivial time sink. [1] https://github.com/jorgebucaran/hyperapp https://github.com/jorgebucaran/hyperapp [2] https://meiosis.js.org/ https://meiosis.js.org/
  - spankalee 8y ago
    Hyperapp isn't Web Components. We're able to freely mix Polymer and LitElement components because the browser does it for us. LitElement really is just Web Components with reactive properties and lit-html rendering. Everything else is plain HTMLElement. Hopefully there's very little to learn that's not standard and transferrable to any other web-based code. I'm not exactly sure what Meiosis is, to be honest.

lstamour 8y ago

https://www.polymer-project.org/blog/2019-02-05-lit-element-and-lit-html-release https://www.polymer-project.org/blog/2019-02-05-lit-element-... is probably a better link for context. These two lightweight libraries are building on top of browser advances. And now I’ll start speculating, I’ve no inside baseball — but the way I see it, Polymer is having a bit of a re-think (3 times in a row now, if I recall correctly) because some early ideas on HTML includes and zip packaging are taking longer to become web standards. And having little market traction, with official Material components published for multiple JS frameworks, Polymer has to evolve and simplify to gain traction. These projects appear to be part of that evolution. I suspect the next thing that might encourage more use of these sort of components and modularization would be the “never-slow” modes recently debated on HN, but there’s a push and pull. Sometimes browser-makers get web devs to adopt their new APIs or heed their warnings, other times it’s the browser-makers wondering if they can make virtual dom diffing more efficient, or effectively embed the core of React or Vue frameworks into first-class browser APIs. If so, these might be considered a first step towards newer API iterations. I’d really like the inside scoop on how web components are working out for Google/YouTube in practice, but for now these frameworks are just “yet another way of doing web components”, but with potential if Vue or other front-end JS frameworks adopt them down the road now that the API for these have hit a stable 1.0.

spankalee 8y ago

lit-html and LitElement are products of the Polymer project. They're different enough from the classic Polymer library, yet can be used interoperably with Polymer because it's all just web components, that they deserved new names. The classic Polymer library is in maintenance mode now. It's getting critical bug, security, and performance fixes only. We're moving customers from Polymer 1 & 2 to Polymer 3, then from there we're encouraging them to incrementally adopt LitElement, which again, they can do because they work together. Our situation is quite different from frameworks because of web components. First, we care more about web components adoption than any specific library. Then, because apps can mix web components made with different libraries, we don't have to bank everything on one flavor or specific set of ideas. That said, we think lit-html is an even better solution than what we've had before, and we're focusing on that.

nwmcsween 8y ago
How does LitElement compare with something like hyperapp[1] or meiosis[2]? The issue I have with $new_tool is trying to figure out what it offers vs the competing tools and it's a non-trivial time sink. [1] https://github.com/jorgebucaran/hyperapp https://github.com/jorgebucaran/hyperapp [2] https://meiosis.js.org/ https://meiosis.js.org/
- spankalee 8y ago
  Hyperapp isn't Web Components. We're able to freely mix Polymer and LitElement components because the browser does it for us. LitElement really is just Web Components with reactive properties and lit-html rendering. Everything else is plain HTMLElement. Hopefully there's very little to learn that's not standard and transferrable to any other web-based code. I'm not exactly sure what Meiosis is, to be honest.