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 b

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.