KatrinaKitten

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.

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.

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/[email protected]"></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>

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.

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.