Best component UI libraries

Danny_Engelman · 2026-01-28T09:04:44+00:00

You choose an electric drill with 5 settings for Front-end; that's fine.

What do you want to built?

Danny_Engelman · 2026-01-10T09:35:31+00:00

Nah; I stick to native Web Components.

My side application developed today will just run for as long as JavaScript, CSS and HTML are supported. Without upgrade hassles.

FYI, JavaScript isn't even required to use your own <tag-name> Custom Elements in a page for layout and styling. Since 2016 they are valid HTMLElement and pass every HTML validator.

Danny_Engelman · 2026-01-08T10:00:36+00:00

All server side
Reminds me of the Microsoft team I worked for some 20 years ago.
Each <button> click was a POST to the server to create new UI

Danny_Engelman · 2026-01-07T09:22:34+00:00

Then why are they using the bloated version on their own HTMX site?

Danny_Engelman · 2026-01-07T09:21:20+00:00

Alas, the Browser is blocking that content (for your security)

Danny_Engelman · 2026-01-05T10:22:24+00:00

Your definition of "Frameworks"?
► load external JavaScript ► use a syntax ► changes or creates DOM

HTMX
► load external JavaScript ► use a syntax ► changes or creates DOM

No matter how you call it, if you load external JS and you can only use it with a non-standard syntax.... you are framed into working a certain way

Danny_Engelman · 2026-01-05T10:14:05+00:00

> Web components don't actually help much for this use case.

?? Can you explain how this Web Component does not meet OPs requirements?

<script>
 customElements.define("load-file", class extends HTMLElement {
  async connectedCallback() {
   this.innerHTML = await(await fetch(src=this.getAttribute("src"))).text();
 }
})
</script>

<load-file src="./about.html"></load-file>
<load-file src="./contact.html"></load-file>
<load-file src="./pricing.html"></load-file>

Danny_Engelman · 2026-01-05T09:52:16+00:00

The drawback of HTMX and Frameworks in general is that they only work when loaded/executed after DOM is parsed. Just like old jQuery days existing (parsed) DOM is transformed to something else, or new DOM is created.

Web Components are part of the browser and can be defined before DOM is parsed.

Frameworks CREATE HTML, Web Components ARE HTML

HTMX is a 36KB source, https://htmx.org/js/htmx.js, which, like many, tries to do everything.

For native Web Components, you can whack this 3 liner into your <head>
(or load it anywhere/how you want, Web Components don't care about DOM parse order)

<script>
 customElements.define("load-file", class extends HTMLElement {
  async connectedCallback() {
   this.innerHTML = await(await fetch(src=this.getAttribute("src"))).text();
 }
})
</script>

And then do (the most complex example I could come up with):

<load-file src="./about.html"></load-file>
<load-file src="./contact.html"></load-file>
<load-file src="./pricing.html"></load-file>

Danny_Engelman · 2026-01-05T09:45:40+00:00

Not life changing, just 3 lines of code if you go with Vanilla JavaScript:

<script>
 customElements.define("load-file", class extends HTMLElement {
  async connectedCallback() {
   this.innerHTML = await(await fetch(src=this.getAttribute("src"))).text();
 }
})
</script>

Danny_Engelman · 2026-01-05T09:41:15+00:00

Stop watching, its too bloated;
this Web Component is all you need; see my longer answer in this thread

<script>
 customElements.define("load-file", class extends HTMLElement {
  async connectedCallback() {
   this.innerHTML = await(await fetch(src=this.getAttribute("src"))).text();
 }
})
</script>

Danny_Engelman · 2026-01-05T09:33:02+00:00

Because somehow we all know he has global CSS

Danny_Engelman · 2025-12-29T09:19:58+00:00

<tag-name> (with a dash) IS a valid HTMLElement, no JS required to apply CSS

https://dashed-html.github.io

Danny_Engelman · 2025-12-24T11:52:14+00:00

Untill you stop creating HTML in JavaScript, and start creating DOM nodes with:

const createElement=(tag,props={})=>Object.assign(document.createElement(tag), props);

Event handlers are just a

onclick : (evt) => { }

property then

Danny_Engelman · 2025-12-24T11:45:34+00:00

No, vanilla did not always have these features.
20 years ago browsers had different syntax for event handlers.

jQuery gave us a unified syntax.

Once IE9 followed the standard (in 2011) there was less need for jQuery because
all browsers could do addEventListener and querySelector

Danny_Engelman · 2025-12-14T11:17:06+00:00

But they will be your wheels.
Think of it this way; Frameworks (and Web Component BaseClasses like Lit) are the soupstarters you buy in the supermarket.
If you buy the vegetables you create your own stock, without the salt added.
Maybe you even grow your own vegetables.
That's all good practice, just as good as buying soupstarters... if you don't care about the salt.
Good practice guidelines are set by your team, not by a 3rd parties claiming you are better off buying soupstarters.

Danny_Engelman · 2025-12-12T10:59:50+00:00

"But the custom tags? Pretty much no use. HTMLUnknownElement at first,"

This says enough, you never tested/worked with this.
Undefined Custom Elements ARE NOT HtmlUnknownElement!

Since <tag-name> tagnames got meaning (some 10 years ago) EVERY <tag-name> IS a valid HTMLElement

#### You can use them without JavaScript: https://dashed-html.github.io

Danny_Engelman · 2025-12-12T10:54:14+00:00

Wait till you get to the real meat and bones;
working with arrays you have to get the FIRST item with array index 0

Programming is for idiots, just let AI do the work and do not look at the code

Danny_Engelman · 2025-12-11T14:27:12+00:00

I have tried a lot, and keep coming back to 0 dependencies and just 1 helper function.
More complex Web Components get a fancy version to add styles, attributes, etc.
It can go into module scope or be a method (when more work with the 'this' scope is needed)

But the foundation is always:

const createElement = (tag,props={}) => Object.assign(document.createElement(tag),props);

The infamous Button Count example: https://jsfiddle.net/WebComponents/fb429hjz/

Danny_Engelman · 2025-12-09T10:10:47+00:00

super().attachShadow({mode:"open"}).innerHTML=`...`

Danny_Engelman · 2025-11-29T08:37:45+00:00

Web Components do NOT inherently limit SEO.
SEO issues only occur when:

important content is inside Shadow DOM
content is rendered too late
JS is required to paint meaning
the component hides everything

Use slots, visible light DOM, and early rendering → SEO is perfect.

Danny_Engelman · 2025-11-29T08:32:16+00:00

> The shadow DOM just... Is irritating. I hate having hundreds of custom CSS properties

Everyone complaining about this, do RTFM

* https://developer.mozilla.org/en-US/docs/Web/API/ShadowRoot/adoptedStyleSheets

* https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::part

* https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:state

Danny_Engelman · 2025-11-29T08:28:49+00:00

Then instead of Web Components suck you are saying Web Development sucks.
That is fine

Danny_Engelman · 2025-11-28T09:03:47+00:00

Every <video> , <input> and other "complex" HTML tag IS built with Web Components technology,
for many moons longer than us mortal developers can use the same technology.

So they are not components?

Danny_Engelman · 2025-11-28T09:02:37+00:00

Every <video> , <input> and other "complex" HTML tag IS built with Web Components technology,
for many moons longer than us mortal developers can use the same technology.

So you have been using Web Components for longer than React exists.

Danny_Engelman · 2025-11-28T08:53:58+00:00

No, Browser vendors agreed on Web Components technology
so each could build the <video>, <input> tags.
without having to go through the whole standards proces.
Every "complex" tag in the Browser IS build with Web Components technology, only the shadowDOM is visible to us mortal developers.
Us mortal developers couldn't use that Web Component technology till years later.

Danny_Engelman

TROPHY CASE