Poor web components. Everybody rags on them.
LitElement + lit-html give you very efficient updates, and don't require non-standard JS like JSX.
VS Code is as able to analyze lit-html templates as well as JSX via the lit-plugin extensions. It gives you type-checking, code completion, hover-over docs, and linting.
Yes, JSX needs transpilation but that happens at compile-time. Which is better, pre-processing at compile-time, or "transpilation" (i.e., string processing) at run-time?
https://github.com/Polymer/lit-html/wiki/How-it-Works#4-upda...
Excerpt:
update() simply iterates through each part and value (the parts array and values array are always the same length) and calls part.setvalue(v) for each part.
https://lit-html.polymer-project.org/guide
Excerpt:
Behind the scenes lit-html creates HTML <template> elements from your JavaScript templates and processes them so that it knows exactly where to insert and update the values from expressions.
This is very limited. You need to manually update DOM unless your updates are simple changes in values of expressions.
lit-html updates only the parts of DOM that are dynamic and change. It handles nested templates as values, only updating the whole nested template if the template itself changes, otherwise recursing and only updating that template's values if needed. Repeated DOM is handled either by simply updating state for each item in sequence (non-keyed), or by using the repeat() directive which will move DOM (keyed).
You absolutely don't need to manually update DOM. The whole point is to describe your DOM structure as a function of data, and to be to describe all the conditional / repeated parts in the template expression itself.
Where is the plug-in that does compile-time checks of HTML tags and attributes?
This is the tsc plugin: https://www.npmjs.com/package/ts-lit-plugin
If you look at https://lit-element.polymer-project.org — it's just a base class that integrates declarative DOM templates.
The platform APIs are not opinionated about templating, they just provide proper mechanisms for declaring elements and having isolated DOM subtrees. It makes sense to leave templating to libraries, because… well, good luck on getting even just two people to agree about how templating should be done :)
On one hand it looks neat. This is something i expected browsers to be able to do since i noticed that Mozilla (pre-Firefox) implemented <blink> (or <marquee>?) in JavaScript.
On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like <news-article id="23848923"> and the JavaScript side will do the rest.
But being able to do something like <my-fancy-button caption="Go To Google" target="http://google.com/"> that in the background creates all the canvases and such needed will be neat.
This is already the case on a lot of sites, just not standardized. With the standard you could sandbox the javascript or maybe implement specific parsing for the most common web components.