Live data from Hacker News

How a hypermedia approach can address usability concerns with multi-page apps

htmx.org

31–40 of 136 posts

Re: How a hypermedia approach can address usability concerns with multi-page apps

#31
post #7

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.

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 instructive or interesting way of discussing this topic.

Re: How a hypermedia approach can address usability concerns with multi-page apps

#32

I'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…

Ah, and this is precisely where you make your bloomer: we are not making a programming language.

Rather, we are making two programming languages:

https://hyperscript.org/

Re: How a hypermedia approach can address usability concerns with multi-page apps

#33

I'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…

React is not only 5.3kb because that’s not the only piece you will need to actually use it. Check out the bundle of CRA for a real-world example.

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

#34
post #31

Earlier 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…

you can find many such articles on the talk page at htmx:

https://htmx.org/talk

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

#35

contrary 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…

I agree as well.

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

#36
Regular 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?

Re: How a hypermedia approach can address usability concerns with multi-page apps

#37

I 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.

Agreed. Judging from this example: https://github.com/rajasegar/htmx-trello which uses htmx in pug templates combined with hyperscript the results are... dubious and hardly scalable.

Re: How a hypermedia approach can address usability concerns with multi-page apps

#38
post #12

I 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.

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 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:

https://news.ycombinator.com/item?id=28818829

Re: How a hypermedia approach can address usability concerns with multi-page apps

#39
post #22

Earlier 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.

we were asked multiple times for a response to Mr. Harris' talk, and so we gave one

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

#40
This is absolutely the right approach for building web sites IMO. It's the best mix of whatever-server-you-want-to-use and minimal JS on the client.

I 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.

Post reply on HN