Hacker News new | past | comments | ask | show | jobs | submit login

I've never considered #9 (global namespace) until yesterday, but it seems like a show stopper for dynamic web components, whereas a system like React has components simply being JavaScript objects that can be imported and whose name is largely irrelevant except at JSX (or HTM[1]) parsing time.

[1] https://www.pika.dev/packages/htm




It's being worked on: https://github.com/w3c/webcomponents/issues/716

The fundamental difference here is that HTML needs to know what class to instantiate when it sees a tag. Supplying that unlocks a lot of power, like custom elements in the main document, Markdown support for free, easy integration with existing CMSes.

We can and will solve the single namespace problem though.


Thanks for the link.

By the way I just noticed you're the maintainer of lit-html. How does it compare to HTM[1]? They both look like they accomplish the same goal but HTM's implementation looks smaller.

[1] https://github.com/developit/htm


htm is a nice bridge, because it works with React and Preact and both allows for development in standard JavaScript as well as being a runtime perf boost because strings are a lot faster to parse than nested function calls.

But htm is just a shell over VDOM (that's why it's small, you still need the real VDOM implementation).

React + htm still suffers from its use of VDOM and the diff that necessitates. lit-html doesn't do a diff because it remembers where the dynamic expressions are located in the DOM, so it can directly update them.


Oh so lit-html has the incremental DOM update feature built-in? It's a full-fledged replacement for the VDOM? I thought it was just a syntax parser like HTM. (Hence my question.)

[Edit] Oooh, I see where I got mixed up: in your README, the only part where I can find mention of this feature is in the very last part of this line:

> "lit-html templates are plain JavaScript and combine the familiarity of writing HTML with the power of JavaScript. lit-html takes care of efficiently rendering templates to DOM, including efficiently updating the DOM with new values."

Specifically the "including efficiently updating the DOM with new values" part, that's the only mention on this page, and it's literally right after where I started to skim due to (incorrectly) assuming the rest of the sentence was just a continuation of the first part.

That feature should probably be mentioned more prominently.

Also, if it has the ability to re-render based on state updates (e.g. from onclick callbacks), an example would be really important to know how to make use of that feature.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: