521–530 of 530 posts
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.
Ofc if you really want to lose bloat, there's always Htmz https://leanrada.com/htmz/
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.
Earlier quoted context omitted.
How do you handle routing with plain React?
React is an implementation of View component of MVC, View is responsible for displaying Model contents, not for handling routes. You are trying to use the wrong tool.
Earlier quoted context omitted.
I was able to find architectural patters that work smooth as glass. Here is what my htmx apps have: - Single-purpose endpoints: Each endpoint returns ONE thing (a card list, a tag cloud, a form fragment) - Optimistic UI: Preferences like font/theme update the DOM immediately; the save is fire-and-forget with no response needed - Simple error handling: Most endpoints either succeed (return HTML) or fail (HTTP error co…
Please do a write up of the best practices you've found. I tried htmx a few years ago for a side project and while I appreciated the simplicity of a lot of it, I had trouble understanding how/when to use it and in what ways. I think I was trying to contort it too much into my understanding of api/spa. That or my interactivity needs were too complex for it, I can't tell. These days, I admit, though, the ship has saile…
Earlier quoted context omitted.
I was able to find architectural patters that work smooth as glass. Here is what my htmx apps have: - Single-purpose endpoints: Each endpoint returns ONE thing (a card list, a tag cloud, a form fragment) - Optimistic UI: Preferences like font/theme update the DOM immediately; the save is fire-and-forget with no response needed - Simple error handling: Most endpoints either succeed (return HTML) or fail (HTTP error co…
I have never loved the idea of the server rendering HTML which is probably why I have such a hard time with HTMX. In every other paradigm you clearly separate your server API and UI rendering/logic. Web apps are the only place where it seems common to have the server render UI components. Imagine if you had a Java or Swift application and had the server sending your phone UI screens. I don’t even know how you would p…
https://www.reddit.com/r/iOSProgramming/comments/1khv43o/com...
'This technique is known as Server Driven UI and it is used by Uber, AirBnb and several other big players. The idea is to change the UI instantly without submitting a new version. Developer can just add a new entry in JSON, which can map to an existing component (already available in the binary) and then that component gets displayed on the screen.'
If you pitch to your business that you can update the app automatically without an app store submission, they will start salivating, if not foaming at the mouth.
Earlier quoted context omitted.
Clearly you haven't used something like HTMX. Do you understand what "returning HTML by the server" mean? You are basically sending back a view, like you would in any other framework actually. This would be the exact same pattern as displaying or dynamically adding a new component from either React or Vue. It doesn't create any styling issue at all, nor any unintended consequences.
I’ve used jquery which is very heavy into html fragments. It can get unwieldy compared to keeping all your rending logic in one place and applying data to it like in React. Other comments here validate the suspicion that HTMX can fall apart in large systems. Unless you’re saying the components returned by HTMX are using the shadow dom for isolation, you can very easily run into styling problems by changing a style an…
document.addEventListener('htmx:configRequest', evt => {
evt.detail.headers['Accept-Version'] = APP_VERSION;
});
Earlier quoted context omitted.
> you can just use the heavier one for everything Because people don't like using heavyweight solutions needlessly. That's the logic that begat C++ and Ada and Multics and ASN.1 and CORBA. All of which were good solutions useful for "everything" in their domain. But people hate them, mostly. Historically big "everything" solutuions end up losing in the market to lighter weight paradigms with more agility and flexibil…
The thing is most of us have jobs where we can't unilaterally switch to the 'cooler' solution, and I value my own context-switching overhead much more than I value a slightly smaller bundle or dep tree. I'll much sooner optimize the former than the latter and so the general purpose solution that will solve both my own projects and the work ones typically wins.
And this is how your company ultimately loses in the market. For every bloated incumbent you will get a snappy new competitor. Keep saying 'it's not worth it to try new stuff', right until you finally realize you never learned anything new and now your company made you redundant.
Earlier quoted context omitted.
> it polluted my codebase HTMX is less noisy if you integrate it into your backend framework. A contact of mine build a python/flask app. To simplify coding, he wrote a file to extend the flask framework to support the HTMX patterns he needed with just a single line of boilerplate. Took him about a day, his team is happy with the results.
It's not less noisy, you just move the noise to the backend
This evangelism around HTMX is bit misplaced. First - simple use cases sure great. But imagine you have to update some element out of the from tree. Now you need to have OOB swaps and your HTML must contain that fragment. Not just that your server template code now has to determine if it is HTMX request and only render OOB fragments if so. Even at decent size app, soon it turns super brittle. Yet to talk about compli…
This is super simple to do if you are using a library to generate HTML in your backend programming language.
> Not just that your server template code now has to determine if it is HTMX request and only render OOB fragments if so.
This is literally just a function that checks for a couple of headers, chooses between two rendering options, and adds a `Vary` response header to take care of the caching. Hardly anything complicated.
> htmx can do it but it's going to be very very difficult and brittle.
The problem with this summary is that it misses the point–htmx is not doing backend stuff, your backend app server is. Htmx is just swapping in what the backend sends.
> it is NOT the only tool for all use cases.
The OP said exactly this, the htmx people have always said this, and no one ever claimed otherwise. There are people out there who don't think in absolute all-or-nothing terms.
Earlier quoted context omitted.
lol. oh boy! everything from scratch! must reimplement the whole library even though I don't package server responses for injection. glad you're enjoying your framework, friend!
Thanks. I love it when people make incorrect claims, I reply with corrections, and get condescending comments in return.