111–120 of 224 posts
Earlier quoted context omitted.
You swapped out HTMX because you couldn’t figure out how to load a list of items gradually instead of all at once??
Wouldn't constantly loading new items into a select form be super annoying? Can HTML even keep a select input open when new items are added?
Example: Render a scrollable list and you need to change contents of the li items mid scroll - it resets the scroll position to the top because of how it replaced the entire HTML on render. There are workarounds you can do, DOM hacks, but they aren’t ideal.
React is designed around that kind of thing. They do some funny magic under the hood to support seamless DOM reconciliation and things like prop drilling of entire components on the prop of another, and so-on. This gives them a more granular way to manipulate the DOM without total page re-rendering.
Next.js SSR works because it’s designed around React. So they’re giving you all the SSR stuff you want but you still get client-side React for rich interaction design and other SPA niceties.
So if someone releases an SSR-like thing like htmx it feels like something is missing.
Maybe htmx needs an opinionated framework that gets more into high performance rendering and state management.
Or maybe they hone in on the “basic web pages” market. Who knows, maybe those make a comeback somewhere. PDF gets replaced with standalone HTML or something, and people use HTMX, or maybe it’s used in a dev environment for HTML email design in some future where email can have events (who knows). Couple of ideas.
Right now it feel incomplete or has nowhere for me to plug it in. Love the concepts though, HTML/JS should have been like that.
As others mentioned, not great for rich interactivity. Example: Render a scrollable list and you need to change contents of the li items mid scroll - it resets the scroll position to the top because of how it replaced the entire HTML on render. There are workarounds you can do, DOM hacks, but they aren’t ideal. React is designed around that kind of thing. They do some funny magic under the hood to support seamless DO…
Earlier quoted context omitted.
I’m not sure I follow. SPA’s tend to require more network round trips, sometimes significantly more based on the architecture.
It’s in the name: an MPA requires a page roundtrip for every navigation, while SPA requires a single page roundtrip. Any subsequent requests are part of the application itself and can be handled without disrupting UX.
The UX for an SPA can indeed be excellent, but the average SPA is worse than the average MPA, in my opinion. It’s just much easier to break things in many subtle ways in an SPA.
I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form w…
You can always make the server-side render partials based on a request header. https://github.com/dsego/ssr-playground/blob/main/src/server...
Earlier quoted context omitted.
> The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX. That's how interactivity has alway…
One nice thing about using React even on the web is that it forces your Backend to be REST right from the start. Although I sincerely thing that is less important now with the explosion of LLMs. I've started thinking about everything as Display + MCP Server. Where a SPA front end is really just pre-defined display.
The creator of HTMX would disagree with you (as the person who described and coined the term REST)
https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
I think HTMX is a great fit for forum software. Forum websites mostly deliver non-interactive content in the form of text and maybe some audio, video, or image content. All of this can be represented as HTML and CSS. With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions. The only prope…
I'd extend this to "web apps that revolve around forms, views, filters and pagination" when it comes to "Ajax" stuff (yes, I'm old).
The part of htmx that's relevant to these topics being discussed here, I once wrote an inferior clone of, some years ago.
It was "isomorphic", tailored to our PHP-based CMS, and could handle filters, search forms, and pagination.
Suitable for forums definitely, and current PHP-based forum software vendors that are still on the market follow the same paradigm.
Earlier quoted context omitted.
You can always make the server-side render partials based on a request header. https://github.com/dsego/ssr-playground/blob/main/src/server...
That is what I did. I was using Astro which has full support for partial HTML via the router
I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form w…
have a look at https://segor.de/ - it just downloads 2MB of product listing data (pre-dating JSON!) and then does all filtering client-side
I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form w…