I'm sorry but what's the point here? Rich's talk was not even remotely aimed at HTMX yet this article is nothing but a shameless list of HTMX features.
The point is that the hypermedia approach, which is what htmx (among other technologies, such as hotwire and unpoly) takes, can address many of the usability criticisms that Mr. Harris levels at MPAs, without abandoning the fundamental REST-ful web architecture.
How a hypermedia approach can address usability concerns with multi-page apps
31–40 of 136 posts
Re: How a hypermedia approach can address usability concerns with multi-page apps
#32I'm not sure these are actual problems (other than JS tooling, which I find opaque.) Instagram works just fine for the vast majority of people. It's taken as gospel that Javascript frameworks are "bloated" but 1) is this really true; and 2) if true does this really matter if the page loads fast enough? React is only 5.3kB and gives a very simple model for reasoning about code. Making code smaller or faster has a cost…
Rather, we are making two programming languages:
Re: How a hypermedia approach can address usability concerns with multi-page apps
#33I'm not sure these are actual problems (other than JS tooling, which I find opaque.) Instagram works just fine for the vast majority of people. It's taken as gospel that Javascript frameworks are "bloated" but 1) is this really true; and 2) if true does this really matter if the page loads fast enough? React is only 5.3kB and gives a very simple model for reasoning about code. Making code smaller or faster has a cost…
I agree with the general sentiment though. I think the issue is that it’s easy to just import the whole npm registry in a bundle and ship it — and it’s too hard to trim it down.
For you a 2MB bundle is ok, but for me it’s taking 30 seconds to open this site and I’m standing here. That’s not ok.
Frameworks like Next.js provide a sane base for this; Most others don’t.
Re: How a hypermedia approach can address usability concerns with multi-page apps
#34Earlier quoted context omitted.
The point is that the hypermedia approach, which is what htmx (among other technologies, such as hotwire and unpoly) takes, can address many of the usability criticisms that Mr. Harris levels at MPAs, without abandoning the fundamental REST-ful web architecture.
In that case it would be much more interesting to read about the "hypermedia approach" including its own downsides. For instance, the differences between SPA/MPA implementations are also directly linked to developer experience – most people simply prefer business logic to live inside components. Is that possible using a hypermedia approach? Who knows, but "we think our library is great" isn't particularly an instruct…
in this article we respond to specific criticisms of MPAs in terms of htmx, as it is a response to Mr Harris's talk
Re: How a hypermedia approach can address usability concerns with multi-page apps
#35contrary to most of the comments I'm in full agreement with the hypermedia approach. This is an exciting development, especially with hyperscript! I actually attempted to make a "simplified" "js" framework (where you just had some html tags and it did things for you) for tasks congruent to alpine (since I found alpine rather complex, or that it comes with so much but you still have to do a good amount of work to get…
SPAs might be the right approach for specific applications that are actually applications (e.g. text editors, Jupyter notebooks, chat and other web apps) but more generally the web is designed from the ground up to work well with separate pages representing separate resources.
Re: How a hypermedia approach can address usability concerns with multi-page apps
#36What about an SPA that made internal requests to a server backend, running in the browser?
Re: How a hypermedia approach can address usability concerns with multi-page apps
#37I think they're overlooking a very big issue which is trying to do any sort of business logic in a markup language is terrible. HTML is good for presentation, trying to embed logic like retrying requests in it can lead to weird code. The reason people like Javascript is having a fully C-style language for things makes logic easier to read and maintain.
Re: How a hypermedia approach can address usability concerns with multi-page apps
#38I 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.
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 for simplicity was huge. And the refusal to admit the unnecessary complexity was nothing short of Stockholm Syndrome, imho.
[0] https://kentcdodds.com/blog/how-i-built-a-modern-website-in-...
This was the HN reaction to the article:
Re: How a hypermedia approach can address usability concerns with multi-page apps
#39Earlier quoted context omitted.
The point is that Rich suggested that SPAs are the only way to solve these problems, and that MPAs can’t. This is a rebuttal from HTMX suggesting that MPAs can in fact solve these problems.
No, the entire point of borrowing the term transitional is "having the best of both worlds". The SPA/MPA comparison is about highlighting the best aspects of each method and envision ways of implementing both. Any decent framework nowadays can be used to implement "transitional" features, so HTMX using this as a way to plug their own is lazy and annoyingly counterproductive in this particular discussion.
i think you are missing the hypermedia vs. RPC aspect of the discussion, and the javascript-everywhere vs. Hypermedia-On-Whatever-you'd-Like aspect of it, which i believe are relatively unique in the discussions i have seen
but, it is fair, both laziness and self-promotion are forever a danger for me
Re: How a hypermedia approach can address usability concerns with multi-page apps
#40I built my own (proprietary for my employer) general-purpose AJAX etc framework that uses minimal javascript to produce flexible, interactive web sites with 1/100 the bulk of React. It even degrades gracefully for clients that don't run JS. But I'm tired of maintaining it. HTMLX looks like an even better approach because it doesn't seem to require me to add explicit event handlers all over the place and it's open source so I won't be the sole maintainer.
Looking forward to evaluating HTMLX as a replacement for my stuff.