Hacker News Reader

Comment by cmpolis | Hacker News Reader

This is one of the goals of Polymer- a cleaner API/abstraction layer on top of web components, right?

Well, forget about "Polymer the library", it served us well but it's very legacy at this point. The successor is https://lit-element.polymer-project.org and it's awesome.

Why on earth do you need something that heavy? How about this 200-line lib instead: https://github.com/wisercoder/uibuilder It lets you TSX format (same to React) to implement as well as to use web components.

> Unlike React.js UIBuilder does not do incremental screen updates

LitElement + lit-html give you very efficient updates, and don't require non-standard JS like JSX.

lit-html is no more of a standard than JSX. In fact JSX is better because tools like VSCode is able to validate both HTML and embedded JavaScript.

Huh? lit-html uses standard JavaScript. That's it. JSX is a non-standard extension. So yes it is more standard than a non-standard, and lit-html runs directly in browsers without any transpilation while JSX very much doesn't.

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.

lit-html needs a 1600 line library where as UIBuilder is a 200-line library: https://github.com/wisercoder/uibuilder/blob/master/UIBuilde...

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?

UIBuilder doesn't do incremental updates at all. You might as well use innerHTML and template literals. That's a 0-line library :)

Updates offered by lit-html appear to be very limited. If you change value of expressions it updates the DOM. What about larger changes, such as list items changing? What about child elements being replaced with new ones?

It handles all of that.

That does not appear to be correct.

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.

It is very correct: lit-html is amongst the fastest template systems in use right now. This is shown in every benchmark I've seen or made for it.

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.

OK, so plugins can enhance code editing. But what about compile-time checks? With TSX, if you have a mis-matched tag the TypeScript compiler will give you an error.

Same with lit-html and the TypeScript compiler plugin.

All I am able to find is this "intellisense" (i.e. editing time) plug-in: https://github.com/microsoft/typescript-lit-html-plugin

Where is the plug-in that does compile-time checks of HTML tags and attributes?

This is the VS Code plugin: https://marketplace.visualstudio.com/items?itemName=runem.li...

This is the tsc plugin: https://www.npmjs.com/package/ts-lit-plugin

So we finally got a goddamn proper standard and we're already cheering for the next API to throw in front of it to make it "cleaner"?

Actually, no. There's no need or possibility to make it "cleaner", but there's always the direction of making it more "high level". These are very different things.

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 :)

Reply on news.ycombinator.com