181–190 of 224 posts
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…
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…
Places.js supports component based rendering, and state management integrated with backend data fetching. It also has faster rendering performance than React due to the use of vanilla JS web components.
Places.js is also designed to dynamically render parts of a page while making sure the rest of it is statically rendered. HTMX can be used on those parts, and be used to enhance HTML generated by components through the htmx.process() method. https://htmx.org/api/#process
Great, now you can't offload your FE to a CDN. But on serious note, htmx is basically a solution in the search of a problem. It is the new hype. Or rather, a solution that overlooks 2 decades of learnings. Yes, for a small set of projects htmx is okay, but even then, where htmx is ideal, static is king, and once static is not good enough, htmx sooner or later starts to feel like the XAML and BPEL soap. The fundamenta…
Using a tool such as htmx is an effective way for them to solve current challenges while minimizing complexity.
Earlier quoted context omitted.
Yes but then you're doing HTMX not HTML and at that point why not use something that's more flexible. I'm saying this as a person who still maintains a small application done with Intercooler.js and is perfectly happy with it. If you want basic interactivity, HTMX is fine. If you want something more (like sortable) I'd reach for lit instead of adding the Sortable.js dependency, something the HTMX docs suggest ( https…
> There is no golden rule to all of this but finding out what makes sense is a fun exercise. "Fun" as in you're years into a project before you fully accept that you made the bad call.
Earlier quoted context omitted.
Infinite scroll with htmx: https://htmx.org/examples/infinite-scroll/
It’s funny how hilariously simple that is and the parent commenter making it sound like you need a full JS framework for that instead.
Earlier quoted context omitted.
Angular being basically the same HTMX is nonsense and you should know better. Say you have a huge Google Ads budget burning up on those landing pages. Make one version with React and one with HTMX. Open Lighthouse and see performance difference. First page renders are much slower with React. Page load is slower and this makes a huge difference in mainland USA where people are still on 3G speeds on their budget phones…
The only nonsense here is ignoring that React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015. The gist of it continuously seems to be that people who think HTMX Great, know very little about good frontend engineering.
I don't currently use use HTMX. However, that doesn't invalidate the use of htmx by others when it is a better fit for their experience and use cases.
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.
Earlier quoted context omitted.
Yes but then you're doing HTMX not HTML and at that point why not use something that's more flexible. I'm saying this as a person who still maintains a small application done with Intercooler.js and is perfectly happy with it. If you want basic interactivity, HTMX is fine. If you want something more (like sortable) I'd reach for lit instead of adding the Sortable.js dependency, something the HTMX docs suggest ( https…
> There is no golden rule to all of this but finding out what makes sense is a fun exercise. "Fun" as in you're years into a project before you fully accept that you made the bad call.
Everything served under one domain doesn’t have to use one technology.
Use backend rendering when you can, use HTMX where you need a little bit more, use React on the actual bits where it matters.
As a side-benefit, the React bits might end up less complicated as React doesn’t need to handle every single use case.
Earlier quoted context omitted.
Yes but why bother with React, Hydrating pages at all if you can do something simpler? What advantages does React provide here? HTMX tools are simpler while providing straightforward thinking around html fragment caching, whole page caching. React just gives a runaround way of doing everything. I'll remind you React was built so that people could continue watching a streamed video while they navigated on a page. Most…
What advantages does HTMX have? You end up with splintered spaghetti code, multiple languages/idioms, and unpredictable state.