Doesn't using something like hx-preserve effectively make it an SPA? It makes an AJAX request and replaces part of the DOM. What's the difference?
How a hypermedia approach can address usability concerns with multi-page apps
41–50 of 136 posts
Re: How a hypermedia approach can address usability concerns with multi-page apps
#42hello, I am the author of this article it is a response to a talk that Mr. Harris gave at JamStack entitled "Have Single-Page Applications Ruined the Web?": https://www.youtube.com/watch?v=860d8usGC0o in the article I show how a hypermedia-oriented (rather than javascript-oriented) library like htmx can address many of the usability concerns that Mr. Harris raises with MPAs, without abandoning the fundamental REST-fu…
I've changed the title above to try to say what the article is about, using your wording here (but edited to fit HN's 80-char limit). In cases like this we try to avoid references to personalities. (We also try to avoid acronyms where possible, which is why I said 'multi-page apps' instead of 'MPAs'.) If there's a better title, i.e. a more accurate and neutral one, we can change it again.
Re: How a hypermedia approach can address usability concerns with multi-page apps
#43I don't mean to belittle anyone, but libraries like htmx are rather primitive compared to tools like svelte. What makes them see themselves so important?
That often it's enough ?
You don't need jumbo jet to deliver pizzas locally.
Re: How a hypermedia approach can address usability concerns with multi-page apps
#44No post body was provided.
Re: How a hypermedia approach can address usability concerns with multi-page apps
#45Regular server/client beats SPA because each request starts with an empty state, whereas SPAs build up bugs as they try and fail for mutate state over time. What about an SPA that made internal requests to a server backend, running in the browser?
> each request starts with an empty state
Strange place to post such a … misguided stance. HTMX regularly brags about how it’s meant to be used to mutate the DOM the user already has loaded, thru custom HTML attributes handled by their JS framework.
You’re just arguing in favor of HTML, but HTMX is trying to have their cake and eat it too. JS-level state is clearly easier to manage than DOM-level.
Re: How a hypermedia approach can address usability concerns with multi-page apps
#46I don't mean to belittle anyone, but libraries like htmx are rather primitive compared to tools like svelte. What makes them see themselves so important?
From the article: > This is, unfortunately, part of the culture of front end development right now: sky-high levels of complexity are tolerated in application frameworks, in build tool chains, in deployment models and so on, and, when problems arise due to all this complexity, more complexity is often offered as the answer. > "Simple" is disparaging and "sophisticated" is high praise. So, rather.
No post body was provided.
Re: How a hypermedia approach can address usability concerns with multi-page apps
#47HOWl is a good idea.. either it will catch on and make web development fun again, or it will at least force the JS ecosystem to wake up and fix its terrible tooling and bloat.
Re: How a hypermedia approach can address usability concerns with multi-page apps
#48Anyone who claims one language or tech stack is going to become the be-all, end-all of how we build things on the web is either naive or selling something.
I've gotten a lot of mileage out of ignoring grandstanders and focusing my time and energy on learning how browsers work. If you understand the DOM, CSS and core JavaScript fundamentals, you can apply your skills to virtually any front-end stack.
In the end, the thing that hurts the web the most is complexity in the name of DX. We are tricked into thinking that the simple thing is too hard to learn on the one hand, while being asked to juggle multiple layers of "sophisticated" abstraction on the other. These days there are entire businesses rising on the need to reduce the cognitive load created by our layers of sophisticated abstraction. But, I bring you the good word: you can still build incredible experiences without pulling in most of the complexity (and without sacrificing as much DX as you think).
Re: How a hypermedia approach can address usability concerns with multi-page apps
#49Earlier quoted context omitted.
From the article: > This is, unfortunately, part of the culture of front end development right now: sky-high levels of complexity are tolerated in application frameworks, in build tool chains, in deployment models and so on, and, when problems arise due to all this complexity, more complexity is often offered as the answer. > "Simple" is disparaging and "sophisticated" is high praise. So, rather.
Seconded. There was a series of similar Twitter discussions when a popular JavaScript "influencer" published an article[0] on how they built their website. The amount of complexity that is self-inflicted in the said article was obviously enormous for proponents of MPAs. However the JS community mostly echoed that the complexity was absolutely within norm. The cultural chasm between JS developers and people who push f…
Thirded (if that's a thing).
I've been working recently on two code bases: one using angular and the other htmx (with python/jinja2/FastAPI). Both aiming to deliver broadly comparable interaction - so approximately comparable in essential complexity.
In a month, or a year, I'm confident I'll be able to check out the htmx app and work with it pretty much right away. The dependencies won't have changed much; the build will still work; and I'll be able to understand the code. I will lay bets now that the same will not be true of the angular app. On any one of those three counts.
If simple, understandable, stable and effective are what GPP meant by "primitive", then I want more "primitive" tools like htmx.
Light sabres, not death stars.
Re: How a hypermedia approach can address usability concerns with multi-page apps
#50Can anyone recommend a good resource for comparing htmx with alpinejs? I’ve seen them both mentioned here but their differences are not clear to me.