I think at least some of these issues can be avoided with a different UI/UX to avoid passing temporal/unsaved data between screens.
looking forward to the next instalment!
Then solving this by recreating the entire stepper html at each step, with the added complexity that if it contains something you want to keep "it's a nightmare"?
Then having to create a temporary server-side session to store data that somehow the browser can't keep between two clicks?
Etc.. it's write web apps like it's 1999.
The two biggest problems with HTMX is that being fully server side controlled you need to put the whole app state in the URL and that quickly becomes a nightmare.
The other is that the code of components is split in two, the part that is rendered on the first time, and the endpoint that returns the updated result. You need a lot of discipline to prevent it from turning that into a mess.
The final nail on the coffin for me was that the thing I wanted to avoid by picking HTMX; making a rest api to separate the frontend and the backend, was actually a good thing to have. After a while I was missing the clean and unbreakable separation of the back and front. Making the rest api was very quickly done, and the frontend was quicker to write as a result. So HTMX ended up slower than react / vue. Nowadays react/vue provide server side rendering as well so i'm not sure what Htmx has to bring.
> The two biggest problems with HTMX is that being fully server side controlled you need to put the whole app state in the URL and that quickly becomes a nightmare.
Or you can create a large session object (which stores all the state) on the server, and have a sessionId in the URL (although I'd prefer a cookie) to associate the user with that large session object.
> Nowadays react/vue provide server side rendering as well so i'm not sure what Htmx has to bring.
You should be doing this anyway ... it's so annoying when my wife sends me a link at work and it just goes to a generic page instead of the search results she wanted to share with me. She ends up mostly sending me screenshots these days because sharing links don't work.
All of this stuff needs to be stored on the server anyway… otherwise how will you get it back on the page when I switch computers or pull it up on my phone.
Then it is not simple (as in simple I understand it) it's just the same we already have, reinvented.
If it would be simple and lean, it would solve the most common problems by itself (like I don't need to care about the HTTP part in .Net - it's a one liner and the framework solves it for me).
Yeah, that also bothered me. To me it looks like the page (template) should fetch that partial from the same endpoint that will deliver the partial via the wire to HTMX.
I haven't gotten around to it yet, but my plan is to use in-process REST with Objective-S, so that accessing the internal endpoint will be the cost of a function call.
The HTTP wrapper for external access is generic.
To avoid the cost of updating the entire page, htmx only fetches a parent element and all of its children, but this runs into the problem that you must choose the common parent element for all the elements you want to update.
So the author reaches the conclusion that htmx is not meant to be used for SPA style apps. It's meant to add a little bit of interactivity to otherwise static HTML.
Why is every developer trying to make things complicated?
Whenever I go debug unnecessary state machines, or have to refactor them (to compress the number if steps), I scratch my head half the time, trying to follow the string of thought that my predecessor felt so smart about.
I usually solve the second problem by simply saving the state of the individual input fields, you only need a user session. Depending your use-case, you might need to be transactional, but you can still do this saving everything as "partial" and close the "transaction" (whatever it might mean in the given context) at the last step. Much-much simpler than sending form data over and over.
I did mention using OOB, but I preferred swapping the entire Stepper because the logic on the backend was just a little bit cleaner, and the Stepper didn't include anything else anyways.
> I usually solve the second problem by simply saving the state of the individual input fields, you only need a user session.
I believe this is exactly what I did in the article, no?
In datastar the "Out Of Band" updates is a first class notion.
I think it is best seen in examples on DS website.
I didn't see guidance in the docs for routing one tab's interaction events to the backend process managing that tab's SSE. What's the recommend practice? A global, cross-server event bus? Sticky sessions with no multiprocessing, and an in-process event bus?
If a user opened the same page in two tabs, how should a datastar backend know which tab's SSE to tie an interaction event to?
So when opened on a different tab, the backend would do authentication and render the page depending on the store state.
In general, the backend must always compare the incoming state/request with stored state. E.g the current step is step 2 but the client can forces it to go to step 4 by manipulating the URL.
DS v1.0 now supports non-SSE (i.e. simple request/response interaction as well) [1]. This is done by setting appropriate content-type header.
[1] https://data-star.dev/reference/actions#response-handling
This blogpost affirms it
Why not use cookies?
So, when /upload is requested, the backend in response sets a cookie with a random uploadId (+ TTL). At the backend, we tie sessionId and uploadId.
With every step which is called, we verify sessionId and uploadId along with additional state which is stored.
This means even if the form is opened on a different tab, it will work well.
However, it's difficult to get things right. I spent way too much time on some basic features that I could have shipped quicker if I used React.
The issue with React though, is that you end up with a ton of dependencies, which makes your app harder to maintain in the long-term. For example, I have to use a third-party library called react-hook-form to build forms, when I can do the same thing using plain HTML and a few AlpineJS directives if I need dynamic fields.
I'm not sure if I'll ever build an app using HTMX again but we need more people to write about it so that we can nail down patterns for quickly building server rendered reactive UIs.
This Github demo was pulled straight out of some work I was doing for the Admin of Prayershub (https://prayershub.com).
Working on this specific feature (the soundtrack uploader) though, I reguarly asked myself "what if I just used Svelte or SolidJS"?
Note, Prayershub uses a regular mix of HTMX and SolidJS, so I can pop-in SolidJS whenever I find convenient.
For other page, I'll use full-blown SolidJS (with JSX and everything) for like a popup. Example: https://pasteboard.co/hY35xM7VbATG.png
Now, how I specifically embed SolidJS, its pretty simple, I have my entrypoint files for specific pages: assets/admin-edit-book.tsx assets/admin-edit-song.tsx assets/single-worship.tsx assets/worship-edit.tsx
Then I have a 30-line build script that invokes esbuild along with esbuild-plugin-solid (to compile JSX to plain-old html, no fancy virtual dom) to compile the scripts into javascript.
I can share the build script if you'd like. It helps that SolidJS is so self-contained that it makes such a setup trivial.
For passing data into it I've used Inertia.js [0] and also my own data-in-page setup that's parsed and loaded into the Vue app. The app then writes the changes back out, usually into a hidden form input. The form on the page is then submitted as usual to the server, along with any other data that I need.
It's a great way for adding more complicated behaviour to an existing app.
Otherwise vanilla forms are great in React. If you did this by hand in Vue or vanilla it would also be hell.
Also in terms of maintenance burden the top libraries in this space are massively popular. Most here would likely be making a great maintenance burden decision in offloading to well reputed teams and processes rather than in housing your own form and validation library.
Regular form elements work just fine in React, all you need to do is interrupt the onInput and onSubmit handler and deal with the form data yourself. I've tried a handful of these form libraries and frankly they make everything way more complicated and painful than it needs to be.
I've recently, once again, gave native inputs a chance in a new project. It lasted as long as I've described in the first sentence. And I've been in the frontend world for 20 years. Trust me, you don't want complicated native forms.
And react-hook-form is just what you need (albeit it also is boilerplate-ish, so I always end up wrapping it up in a simpler and smarter hook and component).
edit: Same, in a sense, for HTMX. It's ok for simple things. But eventually you may end up trying to build a house with a fork. The fork in itself is not a bad tool, sure. But you also don't need a concrete mixer with your morning toast.
Why? I've written a lot of React and I've never used this library. In fact, I rarely use any React-focused dependencies except a router, as you say every dependency has a cost especially on the client.
React works just fine without dependencies.
But for forms I honestly would recommend to start with plain React and only abstract things you need in your project.
I want to make the intent of this blog post extremely clear (which tragically got lost when I got deep into the writing).
I love HTMX, and I've built entire sites around it. But all over the internet, I've seen HTMX praised as this pristine perfect one-stop-solution that makes all problems simple & easy (or at least... easier than any framework could ever do).
This is a sentiment I have not found to be true in my work, and even one where the author of HTMX spoke out against (although I can't find the link :(
It's not a bad solution (it's actually a very good solution), but in real production sites, you will find yourself scratching your head sometimes. For most applications, I believe it will make ALMOST everything simpler (and lighter) than traditional SPA frameworks.
But for some "parts" of it, it is a little tricker, do read "When Should You Use Hypermedia?" [1];
In the next blog post (where we'll be implementing the "REAL" killer features), I hope to demonstrate that "yes, HTMX can do this, but it's not all sunshine & rainbows."
---
On a completely separate note, one may ask, then, "why use HTMX?" Personally, for me, it's not even about the features of HTMX. It's actually all about rendering HTML in the backend with something like Templ [2] (or any type-safe html templating language).
With Templ (or any type-safe templating language), I get to render UI from the server in a type-safe language (Golang) accessing properties that I KNOW exist in my data model. As in, the application literally won't compile & run if I reference a property in the UI that doesn't exist or is of the incorrect type.
You don't get that with a middle-man API communication layer maintained between frontend and backend.
All I need now is reactivity, and htmx was the answer. Hope you understand!
[1] https://htmx.org/essays/when-to-use-hypermedia/#if-your-ui-h...
From reading this, I’ve decided I will never attempt to use it again. All I could think was, just use Go’s HTML templating. What is HTMX adding, really?
HTMX here is making it so the page works without doing a full HTTP form submission + page load for each stage of the "wizard". instead, you write some HTMX stuff in the page that submits the form asynchronously, then the server sends back the HTML to replace part of the page to move to you to the next step in the "wizard", and then HTMX replaces the relevant DOM nodes to make that so.
Go's templating is completely unrelated to any of this happening on the front end - it's just generating some HTML, both the "whole page loaded by the browser normally" and the "here's the new widget state code", and so obviously:
> just use Go’s HTML templating.
is incorrect.
I remember, working with a co-worker, we planned out the process (a step-by-step on the application like this post) and it made sense to me - but this journey was much harder for my co-worker.
Why is this? Simply because he is familiar with MVC pattern of sending json data back and forth, and getting the frontend to update and render it, etc. The idea of html flying with htmx as the behaviour (inside html tags) was just too much.
For me, I always preferred the old school way of just letting the server-side generate the html. All htmx does is adds extra functionality.
I tried hard to explain that we are sending html back, and to break things down one at a time but each new task was left scratching his head.
In the end, our website had somewhere around 20-50 lines of javascript! Much smaller footprint than over 400 lines in our previous project (that being generous). Sure, our server side code was larger, but it was all organised into View/PartalView files. To me, it made really good sense.
In the end, I dont think I won htmx over with my co-worker. As for another co-worker, who had a chance to build a new project with htmx, decided on some client javascript tool instead. I dont think I got a legit answer why he did that.
With all this above, I learned that some (perhaps most... perhaps all) struggle to adapt to htmx based on their many years building websites a particular way, with popular tools and javascript libraries. Overall htmx does not really change anything - you are still building a website. If anything htmx just add an additional layer to have website really work.
Yoda's words now have new meaning :- "No! No different. Only different in your mind. You must unlearn what you have learned."
For some its just not happening. I guess Luke Skywalker really shows his willpower, being able to adapt to htmx easier than others. :-)
I think a lot of the arguments over HTMX come down to this difference. The people that love it see how much better it is for their use case than something like React, while the critics are finding it can't replace bigger frameworks for more demanding projects.
(Here's an example interface made with HTMX. IMO React would have been overkill for this compared to how simple it was with HTMX. https://www.bulletyn.co )
alex-moon•4h ago
rapnie•2h ago
[0] https://data-star.dev
jgalt212•1h ago