Are you talking about the specs? The stuff on https://www.w3.org/WAI/ARIA/apg/ seems pretty scrutable to me.

As for "real screen readers", yeah. There needs to be a caniuse.com for assistive technology.

that classlist example won't work: https://developer.mozilla.org/en-US/docs/Web/API/DOMTokenLis...

Oops. You are right, I beg your pardon. Here's a working example.

HTML

  <span class="a b c"></span>

JS

  function getClassList(el) {
    let ele = document.querySelector(el);
    let list = ele.classList;

    return {
      add: function (c) {
        list.add(c);
        return this;
      },
      toggle: function (c) {
        list.toggle(c);
        return this;
      },
      remove: function (c) {
        list.remove(c);
        return this;
      },
    }
  }
  getClassList('span').remove('b').add('e').toggle('a');
  console.log(document.querySelector('span').classList);

Congrats you're reinventing jQuery. With a worse and more limited API.

Plus jQuery is one of the most battle tested libraries in the world.

That "ops" you made with classlist, you're bound to repeat these mistakes ad infinitum. And they can bite in subtle ways only your users might experience.

People rarely report broken websites unless they really need to.

I am truly interested in your arguments on why using chainable DOM Elements leads to less buggy websites.

You're the only one making that claim.

Plus using a homemade alpha version of jQuery written by one dev leads to more bugs, not less.

> That "ops" you made with classlist, you're bound to repeat these mistakes ad infinitum. And they can bite in subtle ways only your users might experience. People rarely report broken websites unless they really need to.

I think those two sentences are out of bounds, but I somehow get you. Yet I don't get the 'broken website' remark (took it condescending, or is it from experience?).

Mainly, I was replying to the affirmation that javascript is not chainable which is (imho) an indication of how one could get disconnected to the underlying lang by simply relying on libs such as jQuery (and I am thinking the same about htmx). Thanks for your reply!

Thanks again for a nice demonstration of having to reinvent the wheel to produce a poor-man's buggy reimplementation of jQuery.

The "structured data with programmatic access methods" sounds a lot like microformats2 (https://microformats.org/wiki/microformats2), which is being used quite successfully in the IndieWeb community to drive machine interactions with human websites.

Thanks for the link!

The server-rendered web app (without htmx, think crusty PHP router admin panel) is actually very similar to the Elm architecture.

The database is the Model.

The server is the update function.

The HTML template is the view function.

HTTP requests are the Msg.

Database/API calls are the Cmd.

The problem with this model is that recreating the whole UI every time is slow and clunky.

Elm and most JS frameworks fix this by running the `Model` and `update` function on the user device and doing tree diffing. This is reasonably performant if you do it well, but it's also hard to do well (see: every website ever these days) and introduces complexity, particularly because the client-side `Model` almost always needs to be synchronized with a database or some other "canonical" model.

As pragme_x touched on in a sibling comment, what htmx does is not an iteration on the framework model; it's an alternate solution to the original problem. What it does to avoid the clunkiness is let the server to return `Delta HTML` instead of `HTML`, and for the slowness, it leaves the vanilla-JS escape hatch open for things that can be done without altering the Model (database). This model also has its flaws, especially if you need to use that escape hatch a lot, but it's also a lot simpler conceptually and keeps the `Model` and `update` function in a trusted computer, meaning you don't need to marshal and validate stuff between two models.

> how to write good Htmx code that wouldn't bloat and rot over time?

- Don't try to perform fine-grained updates if you don't have to. It's fine to replace a little more than you absolutely need to, and htmx takes care of some of the things you might worry about like preserving focus. For example, in the "delete row" example, it might be more robust to replace the whole table.

- Use htmx for anything "side-effecty", i.e. anything where a network request is compulsory. Relegate JavaScript to "micro-interactions". I consider a code smell in an htmx application any time I need to add new elements to the DOM via JavaScript, most of it should be manipulating classes, attributes and styles.

- For those micro-interactions, the "component" model heralded by the big three JS frameworks doesn't work as well here, since components have their own state, which is another "shadow-Model". Instead, try the RSJS methodology (https://rstacruz.github.io/rsjs/) with "behaviors".

- To wire up that JS to your app, reach for custom events. The `hx-trigger` attribute is the "port" that translates JS-based interactions to Msg.

> I suspect this is because HTML was always about documents, and never about interactive applications

This is a really common refrain and it peeves me, but I don't have a good rebuttal to it yet so I won't weaken my comment by trying to make one. I don't have good explanations for a lot of things about htmx and hypermedia, actually. The code of htmx is mostly complete, but the theory is still WIP.

This is a great explanation. You should write more HTMX tips and tricks and how to do UI with it.

Co-author here. We rewrote the book in Typst. On the hypermedia.systems website, the new EPUB ebook release is built from the new codebase. I'm working on a blog post with details on why we switched and what the process was like. The content of the book has not meaningfully changed.

Thanks :)

Generally curious about new authoring/markup tools and systems, so I'll keep an eye out for the post.

(The quoted blog post is part of an effort to explain some work I've been doing to single-source documentation and output multiple formats while taking advantage of the idioms/affordances of each format. I spent quite a bit of time reviewing and trying markup systems before deciding what I wanted didn't quite exist. Typst wasn't released when I did all of that; I'm aware of it but I haven't read enough to pull it out of my blind spot.)

I'm curious about using typst for printed technical books.

What was the experience like? What features is it missing?

If users are expected to spend a long time and use many tools to compose something, then I agree a full page form is best. For something like adding to a todo list, or where users are expected to add many items one after the other, a modal is better.

You can also take a hybrid approach: many calendar apps have a small popup for adding an event that the user can expand into a whole (nonmodal) window for editing all the details.

It's not trying to compete with Next, but advertising how Deno's similarity to the browser and being able to run on CDN-like networks (which i refuse to call "the e*ge") can let you build a better version of Next's features yourself.

In the sample code, there is no "streaming" going on -- the server simply uses the client code as a template to generate HTML and sends it as a normal HTTP response. In pseudocode:

    import "client.js" as client
    on request:
      document = new ServerDOM(),
      client.render(document, data),
      respond with document.toHtmlString()

> I don't understand why it isn't "true" SSR This article seems to be using the term SSR exclusively in the frontend framework sense, where client code is run on the server. It's not how I use the term but it is a common usage.

Another possible reason that the htmx approach isn't discussed: the any-server-you-want nature of htmx is terrible for selling Deno Deploy :]

Ah, I thought there was some sort of diff-and-send going on to the client.

I do know there are folks using htmx and deno (we have a channel on our discord) so I don't want to come across as oppositional! Rather, I just want to say that "normal" SSR (just creating HTML) can also be used in a richer manner than the plain HTML example given.

If you're writing a web app that only works in a browser you control, then no, you won't benefit from hypermedia. The rest of us like search engines being able to index our sites though.

> there are no clients which can use it

... HyperCard?