React is also not 6.4kb, it's 316kb for base React + 4.5mb for React DOM + who knows how much for any other library you decide to use.

Parent was referring to bundle sizes:

- https://bundlephobia.com/package/react@18.2.0

- https://bundlephobia.com/package/react-dom@18.2.0

I presumed, but either way you still have to consider that React's "6.4kb" is without any of the actual building blocks a web app will need, just the absolute bare minimum of what React itself needs.

HTMX does not promise to "do away with" client-side code. In many cases, you don't need or need significantly less JavaScript in an HTMX codebase than in other alternatives, but the point is not to use no JavaScript, but rather to extend HTML to do what JavaScript shouldn't be needed for. Its error handling story could be better in a number of ways, but it isn't a promise break.

Slight correction - <output> is not inert for users who use screen readers, though in this case it shouldn't cause issues. If you need an actual inert element, use a div.

I'm a big fan of HTMX and it heavily inspired Ajaxial from top to bottom. In fact, until it started diverging more significantly, it originally began as "HTMX but fixing the things I don't like".

From a functional standpoint:

- HTMX is already tiny at 47.8kb minified, but Ajaxial is even tinier at just 5.0kb minified

- HTMX has more "batteries included" for things like history support and inline event handlers, where Ajaxial takes a more minimal approach with a heavy focus on extensibility, so that it's as easy as possible to add those batteries if you need them

- HTMX supports IE11 (until the currently-alpha v2.0) and has a lot of browser support-induced quirks as a result, where Ajaxial uses current modern web technology like fetch

The single biggest thing that sets Ajaxial apart is that it's designed to be as deeply extensible as possible. Where HTMX has more magic that makes things "just work" out of the box, Ajaxial leaves as much of the process as possible open to changes or additions, so that it can be trivially extended to support almost any use case. For example, here's a tiny extension that enables Mustache template support =)

  <script src="https://cdn.jsdelivr.net/npm/mustache@4.2.0"></script>
  <script>
    Ajaxial.responseConverters.mustache = (body, template) => {
      const template = document.querySelector(`template[name="${template}"]`).innerHTML
      const rendered = Mustache.render(template, JSON.parse(body))
      return Ajaxial.responseConverters.html(rendered)
    }
  </script>

While you certainly could do this, a major benefit of web components is that you get all of this for free out of the box. It's less error/mistake prone, keeps your code cleaner and more obvious exactly what it does, etc.

Thanks for filling my "only read the headline and made a snarky comment anyway" bingo square!

I actually recently contributed Shadow DOM support to the HTMX cobebase for 2.0! Once that drops, linking Facet and HTMX will only take a simple mixin.

    <template mixin="htmx" global>
      <script on="connect">htmx.process(root)</script>
    </template>

Wow, just wow! 100x simplicity accomplished! THANKS a TON!!! <3

Not exactly. While they can be used in tandem, I'm not necessarily suggesting that they should be; rather, the two serve different purposes and solve different problems.

A framework component is effectively a reusable block of code. It's an organizational principle more than anything; modular and reusable, but not meaningful to the browser in its own right once rendered. A web component, on the other hand, is very literally a new HTML element, and is treated by the browser as such. Once defined, the browser itself sees that component as a meaningful entity in its own right.

While the difference between those two ideas is fairly subtle on the surface, there's a whole nest of smaller differences that result from it. For just one example, web components are perfectly AJAX-compatible with no extra strings attached - you simply add the HTML tag representing a component to the DOM, and it works out of the box, no matter when or from where you got it. Achieving that with a framework component requires some additional work at best, which may or may not have been done for you by the framework authors.

That's not to say one is necessarily better than the other either, to be clear - they're just different, and treating them as if they were the same does both a disservice.

> A framework component is effectively a reusable block of code.

I think that, for me as a newcomer to front-end development, this is the biggest takeaway: a framework component is a reusable block of javascript while a webcomponent is a reusable HTML element.

As a newcomer[1] it does not make sense to even learn the front-end frameworks. As an example, the time spent in learning the entire framework simply so I can 'watch' an element's value for changes, or propagate an element's changed value to other elements is going to be order of magnitudes greater than simply writing 3 custom elements that monitor and propagate values for any child element.

(PS. I like your post. I think a followup blog post with two concrete examples may make sense in refining your thesis:

Example 1. This is a popular React mechanism to do $FOO, here's how it is easier in a webcomponent.

Example 2. This is a complex webcomponent, here's how it is easier in React.)

[1] One who is not looking to put "react", "vue", etc on their CV.

> than simply writing 3 custom elements that monitor and propagate values for any child element.

I feel like you're underestimating how easy this is to skrew up.

You're probably correct in your assessment of my estimation.

However, it's far far easier for a newcomer to screw up when approaching react or cue than when approaching a custom html element.

Time will tell as I use my experiment in more domains, more often and in larger apps.

I rather like https://lit.dev/ for web components so far.

For the reactivity stuff, you might want to read https://frontendmasters.com/blog/vanilla-javascript-reactivi... - it shows a bunch of no-library-required patterns that, while in a number of cases I'd much rather use a library myself, all seems at least -basically- reasonable to me and will probably be far more comprehensible to you than whatever I'd reach for, and frameworks are always much more pleasant to approach after you've already done a bunch of stuff by banging rocks together first.

> a framework component is a reusable block of javascript while a webcomponent is a reusable HTML element.

Web components/custom elements are reusable behaviours/functions - which can contain custom js, all bundled as a reusable HTML element.

Think of it a bit like an object in an object orientated programming language - the object has both data/state (DOM) and code/functions to manipulate that state.

> A framework component is effectively a reusable block of code.

So is a web component…

Do you think that there is a distinction between "reusable block of JavaScript" and "reusable HTML element"?

To me there is a larg distinction but I do concede that to others there may be no difference.

Both Web Components and Framework Components utilize JS and HTML.

> Both Web Components and Framework Components utilize JS and HTML.

If you're writing them, certainly.

For web designers, using Web Components means not having to know JS, not having to know React, not having to know hooks, not having to know usememo, etc.

That's, to my mind, a large enough distinction: the requisite knowlege to reuse a framwork's components needs a full time developer. The knowledge required to reuse a web component is ... HTML (and maybe CSS?)

How so? I'm more than happy to take constructive criticism, but without specifics there's not much I can do.

1. Element styles cause specificity issues. Probably not an issue in most cases you'd use this, but still a relevant consideration. 2. Element styles don't allow you to style child elements, pseudo-selectors, pseudo-elements, etc. They can only style a single element, directly, with no regard for anything else.