dream-html

That's why you need something that lets you componentize your templates. React did this really well with JSX. But classic-style templating languages are not great at this. Django just recently introduced a 'partial templates' feature. I built my own: https://github.com/yawaramin/dream-html/blob/todoapp/app/REA...

This really depends on your server-side HTML rendering approach. I have a library in which I can do this: node +@ Hx.swap_oob "true" And this adds the `hx-swap-oob=true` attribute to the given node. It makes it trivial to add on any defined markup in an oob swap. I get that many people prefer template-based rendering, but imho to extract the maximum power from htmx an HTML library that's embedded directly in your programming language is much more powerful. https://github.com/yawaramin/dream-html/blob/f7928616b9ca1d6...

Htmx doesn't preclude a component model for the UI. See: - https://www.fastht.ml/ - https://github.com/yawaramin/dream-html/tree/todoapp/app In fact if you look at how htmx is recommended to be used, you realize they specifically are recommending a component-based architecture: https://htmx.org/essays/when-to-use-hypermedia/#if-your-ui-i...

I would argue that frontend libraries like htmx and React are not the place to build in ARIA attributes patterns/behaviours. In fact, none of the Big Ones do anything specifically w.r.t. announcing changes. See https://news.ycombinator.com/item?id=42625070 What would be the appropriate place, imho, would be component frameworks that are built on top of htmx. FastHTML is an example; they already have htmx integration and they talk about server-side components. If we look at a popular one in React, this is what they do: https://blog.logrocket.com/aria-live-regions-for-javascript-... Thinking about it in terms of dream-html[1], it might look like: let announce msg = p [ class_ "announcement"; Hx.swap_oob "innerHTML:.announcement"; Aria.live `polite; ] [txt "%s" msg] (* POST /purchase *) let pu

> When this responsibility is moved to the backend you now need to track the request location, state etc. and find the right fragment, Maybe not? I'm just returning a 422 JSON response with fields and reasons and I have a tiny bit of JavaScript in the frontend that just plugs them in to the form with the built-in Constraint Validation API. https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg > I suspect that Java (Spring Boot) made using HTMX much less pleasant than it would have been with something else, especially when it comes to templates and routing. I strongly agree with that and created a library to help with those aspects: https://github.com/yawaramin/dream-html?tab=readme-ov-file#f...

htmx is a JavaScript library which interprets a set of HTML attributes and JavaScript events. It doesn't have anything to do with static typing. However, it's fairly easy to add a statically-typed layer on top of it eg https://github.com/yawaramin/dream-html

This is exactly why I always recommend that htmx is best used not with a traditional templating engine, but with an HTML generation library embedded directly in your favourite programming language. Eg if you use Python there is https://htpy.dev/ - and many others in other languages. What these all do is they allow using the full power of your programming language to create component-like abstractions much like you would in React. I show an example of this with my own library: https://github.com/yawaramin/dream-html/tree/todoapp/app

There is some truth to this. Imho the next level of htmx is unlocked when you componentize everything like a React app...but with nested routes corresponding to nested components like a Remix app...and using an HTML generation DSL embedded directly in your language, so HTML becomes a first-class citizen of your language's constructs, rather than a templated afterthought. I have a demo of this: https://github.com/yawaramin/dream-html/tree/todoapp/app

Nowadays I highly recommend HTML embedding libraries directly in the programming language. E.g. ScalaTags https://com-lihaoyi.github.io/scalatags/ or (my own) https://github.com/yawaramin/dream-html Yes, you give up the ability of designers and frontend-only people to easily work with the HTML templates. But in exchange you get quite a lot.

> templating languages are horrible and stuck in 2005. An underrated pro of react [1] + typescript is that you get to write your UI logic in regular typescript, Yeah exactly, which is why I always recommend DSLs that embed HTML directly in the language. E.g. https://com-lihaoyi.github.io/scalatags/ or (my own) https://github.com/yawaramin/dream-html They make writing HTML a breeze with the full power of the programming language available. > We were doing this the same year that React came out, and clearly had some of the same thoughts as Dan Abramov did Dan Abramov is not the original creator of React. That was Jordan Walke: https://www.youtube.com/watch?v=GW0rj4sNH2w

(2020) Folks, this is exactly what htmx (and Phoenix LiveView and Laravel Livewire and Rails Hotwire) solves. OP was almost there but couldn't quite articulate this niche. Which is OK, we have the benefit of hindsight now. Try htmx. It will blow you away with its simplicity compared to (today's) React. My personal recommendation: try it with dream-html, a library I wrote for expressing HTML directly in the language: https://github.com/yawaramin/dream-html (or some similar library).

I found your article very informative and it matches up quite a bit with my own thinking about HTML generation. In fact it looks like we independently arrived at pretty much the same conclusions. A lot of the issues you raise are the impetus behind the way I designed my HTML-generation DSL: https://github.com/yawaramin/dream-html

Look at this code which prints out an HTML tag: https://github.com/yawaramin/dream-html/blob/main/lib/dream_... Initially you might think generating HTML tags from data structures in code should be a simple matter. But there are complexities--some tags are defined as having no child tags, others do. Some tags are purely character data (unstructured text), not structured data. Some are just comments. We need a way to compose multiple tags together into a single 'virtual' tag for flexible HTML generation. All these conditions can be pretty hard to keep track of--unless your compiler does exhaustiveness checking. Then the compiler will tell you if you missed any cases. In the example above I didn't make any manual effort to cover all the cases, I simple listed out the cases I wanted to handle in order. The compiler made sure that I didn't mi