nymanjon

With HTMX 4.0 it might be a bit nicer. I use my own home-grown HTMZ-BE lib/snippet that has the back end decide where to place the elements. Deciding from the back end makes it so you go from a lot of eventing on the front end to middleware on the back end, which significantly reduces the complexity of the application. And then when you do have a lot of interactivity you just send down the whole interactive area and have morphdom (HTMX uses idiomorph, I believe) which will do a comparison of the DOM compared to what your new HTML is and update just what needs to be updated.

I've found that to really reduce the complexity of my applications. If I really do need something more powerful with state machine interaction, then I use VanJS. But, really, I've only used that for my static sites where I need a little interaction on the front end and no back end connection.

Here's an example of using HTMZ-BE (which can easily be extended to HTMX 4.0 and Data-Star - if you need even more features).

https://github.com/jon49/Soccer

It also uses an _<action> attribute pattern on the HTML for simple, declarative front end state interaction. Makes the user's life a little nicer.

It's amazing how simple things can be if you work with it and think about, "I want simplicity." A lot of the front end frameworks add a lot of complexity, even nice frameworks like Svelte, I think because the paradigm is just wrong.

I created this app to help me track cash transactions that I can then export as a CSV file and then import into my PTA. It works well. It can work offline. I built it to be progressively enhanced. So, no JS needed but, if you don't mind JS being used, then it will have better features and even work offline, saving any transactions for when you are online again.

https://github.com/jon49/cash

I created a little app that tracks the cash spending that I can export with a CSV file. You can host it yourself. I had no idea that my wife was using so much cash!

https://github.com/jon49/cash

I took that idea and made it actually usable.

https://github.com/jon49/htmz-be

It's amazing how much further you can go when you flip the server as the one deciding where what should be updated on the page.

This was originally conceived by datastar and nomini also implements it this way. And HTMX 4.0 will have this as a first class citizen.

HTMX and related libs work just fine as offline apps. I've been doing it with my personal apps I make for myself for a long time.

Also, morphdom/idiomorph get you a long way even when you have highly interactive pages, especially if you have to hit the back end anyways. If you don't need to hit the back end then a front end lib is fine. But even then, the simpler pattern of hypermedia-driven applications can be better.

See https://github.com/jon49/Soccer as an example of this.

There's also htmz-be, nomini.js. Depending on your complexity needs.

This exactly. React is spaghetti code with the reducers. Using API end points to fetch HTML makes it super simple to see what is going on.

fixi.js, nomini.js, data-star, htmz-be. All have smaller footprints. All work just fine, depending on your needs.

Here's an example offline-first hypermedia-driven soccer application. The match page is the most complex part of the application and I use Morphdom to just do a diff on the main section of the page. I find hypermedia-driven development to be super simple.

I find React to be really complex. What normally takes me just some HTML rendered from the back end and some interactivity on the front end can be done in just a few lines of code, but React takes 10s of lines of code for what I can write in a single line of code using vanilla js. The virtual dom causes it to make everything state. I always find it odd that people reach for that as their front end. I could understand something like Svelte, but even that is too complex for my needs. But I'm always writing CRUD apps, so there is some complexity but not that much, React just makes something that was simple, super complex.

https://github.com/jon49/Soccer

Interesting read. I haven't quite finished it all. I haven't ever needed anything like that when writing web pages with HTMX, html-form (my own), nor htmz-be (another one I wrote based off of htmz but the back end decided where the HTML will go, similar to data-star and nomini). When I write code from the back end and target the front end I can use middleware to common updates.

Here's the most complex app I've made with it. The most complex part of the app is the match page. I just use morphdom for that part of the app and it makes it super easy, I just send the whole main part of the page back and let a dom diff happen.

https://github.com/jon49/Soccer

This is a offline-first PWA app where I serve the back end from a service worker using JS template literals to stream HTML. This uses a variant of HTMZ to increase the interactivity of the app along with Morphdom for DOM diffing.

Mastro looks like what I do for my offline-first, rendered from Service Workers. I just compose html template string literals and stream them back to the front end. The lib I use for HTML is a bit more powerful though. It is a very elegant way to program.

https://github.com/jon49/Soccer

I added one site that is mostly a static recipe site that my family uses. It includes VanJS to pick random recipes and you can save them as you go along to pick what you are planning for dinner that night. It also has a filter to find the recipes by name and a filter to filter by type. Mainly for personal use but shows what you can do with not a whole lot of code.[1]

I also added a question for my soccer app. Cloudflare doesn't know how to work with service worker-driven applications :-) This one puts the back end in the service worker and uses HTMZ-BE to make it feel like you are using an app. So, basically, a front end MPA with nice interactivity. Super light weight for what it does and easy to use.[2]

[1] https://github.com/jon49/recipes

[2] https://github.com/jon49/Soccer

With highly dynamic page where you would normally start using a front end lib, Idiomorph makes it so you can stick with the hypermedia approach instead.

HTMZ-BE:

<a id="contact1" href="/contact/1/edit" role="button">Edit</a>

Hhhmmm..., that's more verbose than both :-(

If you are looking for a very tiny foot print, you might like htmz-be.

I build most of my personal websites with service workers. No need for the framework, I just build it for the specific use case I have at the moment.

Here's an offline-first soccer app: https://github.com/jon49/Soccer

And here's an MPA that caches the pages and save the updates for later when you are back online. So, you can navigate around and see the old data even if you are offline: https://github.com/jon49/cash

No need for HTMX, HTMZ can get you most of the way there if it is going from simple MPA to slightly more complicated. I used a variation of HTMZ to make a offline-first soccer app I use for myself. I thought I would need to use a front end for the match play page, but, nope, I used Morphdom with HTMZ and I was able to keep the simplicity of templating and a back end.

[1] https://github.com/jon49/htmz-be

[2] https://github.com/jon49/Soccer

My intent wasn't to say it is a Datastar replacement. Just to say that I used their idea of deciding where to place the returned HTML is based on the back end driving the decision, rather than the front end.

Datastar's model of doing it this way really simplifies the front end even more compared to HTMX's model of having the elements on the front end decide where to put the returned HTML.

When HTMZ was announced I thought it was a neat little script. But I didn't understand how this would be practical in the real world. This little "extension" makes it have the full power of hypermedia development but targeted from the back end (similar to data-star). The repository has a link to see the full interactive examples of how this works.

https://jon49.github.io/htmz-be/

I replaced my `html-form` library with this as it has a smaller foot print and, therefore, easier to maintain.

The article stated that he no longer needs eventing to update other parts of the page, he can send down everything at once. So, I guess that is much less complex. Granted, eventing and pulling something down later could be a better approach depending on the circumstance.

I advocated for intercooler.js/HTMX at work and to better understand HTMX I built this library.

This library takes an HTML-standards-first take to hypertext programming. Because of this it makes it easy to build progressively enhanced MPAs.

I've successfully built offline-first applications with it using service workers.

I recently did a rewrite (inspired by fixi) cleaning the code up and making it tinier and moving parts to extensions.

Another solution besides data-action pattern is html-traits or web components.

I've found for state machine on the front end which uses mostly data that is already on the front end that using a lib like VanJS can be very nice and useful. Using the correct paradigm for the problem is nice. This would be over kill for the problem mentioned in this post though.

Yes, going from SPA-like libs to hyper text libs is definitely a change in how you use your mind and approach problems. It's like going from OO to Functional-style programming. It really messes with the brain. But eventually you learn to love both paradigms and see the good and both and then you start using both patterns in your code, which really messes with other devs as they see both patterns being used.

I've been programming on personal projects with html-form (my own lib that is a radically paired down version of HTMX with a focus on using native form controls, which makes it so you don't need hydration like you do in HTMX).

So, some thoughts on your problem.

One note. Many people mention OOB. But there is also hx-select, which can be quite handy.

I think there are multiple different approaches that are possible, that I can think of, depending on your needs.

Use eventing. On the server create an event that will be called on the front end by HTMX. When this is called have some vanilla JS that updates the class on your location in the form.

Send all the forms down and have them only visible based on CSS or using an input element is checked or not or using JS. That would be pretty straight forward.

If the form passes then replace all the body contents or main element. If it doesn't just update the form and add any user information. Or send an event back which causes a popup to tell the user what their issue is. Or send an even that causes some text to show.

Also, you can also use CSS and native HTML form validation that will show text underneath an input (or above the input) that tells the user what the the input requires. Modern CSS has a pseudo selector which only turns on when the input is invalid[1].

This is simple enough that a straight up MPA could be used with page animations between pages using view transitions[2].

Similar to one of the solutions above, but using data-action style of programming.[3]

But, I usually try to not over complicate things.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/:user-inval...

[2] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_view_tr...

[3] https://www.lorenstew.art/blog/frontend-event-system

It took me an hour to add a link to the page because I had to learn about how the React Router works and learn how to set it up for the page I was on. With HTML it takes a couple of minutes, no need to set up props, pull in a library. I just create the link and the anchor tag and bam! Just like that I'm done!

I'm working on a React code base that literally uses over 100 lines of code to navigate to the next page. It also takes about 20 lines of code to have a link. It seems like React devs have never programmed outside of React.

I do like front end libs. I use them sometimes for the right context. But all the business apps I've worked on have never needed a front end lib. With web components even less so than before as the state based interactions that are local to that input element or some other element doesn't need a full blown framework.

My favorite front end lib right now is VanJS. It feels like writing straight vanilla JS without the cruft of writing actual vanilla JS. HTMX is good too, if you are working with back end state but need a little more smooth interaction. Of course, Datastar, html-form, etc all work too.

I could see it used for something like that. But it is more general as it can act upon any HTML element. So, you could use it for masking an input element or any other local state based element. Granted, it doesn't need to be limited to local, but at that point HTMX, Datastar, html-form, etc might make more sense.

html-form is the one I made out of those and it is more single focus using the native platform.

So, what use case would you see with ShadowDOM?

I see this more as a way to progressively enhance an element. But in my own use of web components I haven't seen a need for ShadowDOM, but I'm usually just progressively enhancing my page and adding behaviors to my elements. I can see a use case for ShadowDOM when completely creating a new element, but at that point it makes sense to just use a regular web component. Maybe I'm wrong. But that is the reasoning I'm using.

I built a simple lib for JS/HTML called html-traits[1]. It's similar to built-in web components but instead of using the `is` attribute you use the `traits` attribute. So, it is specifically meant for progressive enhancement. Let's say I have a `textarea` element and I want it to have the behavior where the text box expands automatically, I would add a trait called "expando" that would do that for me. But let's say I also want it to turn red when there's more than 200 characters entered, so I could add another trait called "character-limit" with an added attribute `data-character-limit="200"`.

So, the element works like normal if no JS is enabled or if the JS broke for some reason, but it has those extra behaviors when JS is working. And it is very clean as it is just attributes on the element rather than having nested element hell like when you are using normal web components, or worse, like when you have web components which don't even show the `textarea` element at all and they put it in the shadow DOM and the developer has to reimplement all the behavior of the original element.

So, composition over inheritance.

[1] https://github.com/jon49/html-traits