deniz-a

2 yıl öncediscuss

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.

deniz-a

2 yıl öncediscuss

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

deniz-a

2 yıl öncediscuss

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.

deniz-a

2 yıl öncediscuss

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.

deniz-a

2 yıl öncediscuss

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.

deniz-a

3 yıl öncediscuss

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.

deniz-a

3 yıl öncediscuss

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.

deniz-a

3 yıl öncediscuss

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 :]

deniz-a

3 yıl öncediscuss

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.

deniz-a

3 yıl öncediscuss

> there are no clients which can use it

... HyperCard?

Submissions

Missing.css 1.2.0

comments