Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

htmx.org

Post reply on HN
Print view View original

71–80 of 136 posts

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

#71

Post by noduerme »

davidmurdoch wrote: post #11
ravenstine wrote: post #5

> And, contra what Mr. Harris says, today the trend is not obviously in javascripts favor. Five years ago, we, as founding members of the javascript resistance, were despairing of any hope of stopping the Javascript juggernaut. But then something unexpected happened: Python took off and, at the same time, javascript flat lined: Why yes... if you use Stack Overflow usage as your measurement. The problem is that doesn'…

My gripe with Stack Overflow is that TypeScript and JavaScript is now what is conflated by question askers.

That seems like it would only be a problem if you're looking for Typescript answers, right? Like, ignore the typings in Typescript and in most cases you have vanilla JS (or ES6, anyway)...

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

#72

Post by projektfu »

jcelerier wrote: post #70
unclebucknasty wrote: post #63

Earlier quoted context omitted.

Agree. The other thing I'd add is that we're long overdue for a more fundamental paradigm shift in webdev. That is, we've changed our goal from the original page request/response model to one of delivering native-like SPA experiences. But, the frameworks that win don't fundamentally reconsider the old technology. Instead, they stop at the DOM layer, speak heavy HTML/CSS, make us manage browser mechanics like URLs, hi…

Check out Canonic https://www.canonic.com/ for an experimental take on an alternative web

Was that supposed to do something other than show half a page and not respond to clicks and scrolls? iOS 15 on iPhone SE 2.

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

#73

Post by Dauros »

bryik wrote: post #28
recursivedoubts wrote: post #15

Earlier quoted context omitted.

You can host an htmx-based site on Github Pages for free as well.

Does that fit with the philosophy of htmx? It looks to me like htmlx expects a server?

You can combine HTMX with a SSG like Hugo and generate a bunch of partial HTML files that HTMX can load later on request. No server is required.

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

#74

Post by noduerme »

divbzero wrote: post #35
clownworldclown wrote: post #18

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.

Although a multipage text editor would be rather charmingly annoying.

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

#75

Post by qbasic_forever »

seumars wrote: 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.

Read the third sentence of the link, they say they were explicitly asked to write about their/HTMX's response to Richard's talk.

"We have been asked for our opinion on the talk, so this essay is our response."

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

#76

Post by qbasic_forever »

Kiro wrote: post #41

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?

That's the point, it is basically a SPA but without all of the complexity and (over)engineering of using a modern JS frontend stack.

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

#77

Post by qbasic_forever »

hstaab wrote: post #50

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

Alpine is a lot closer to jquery than htmx IMHO--I think of it in a very similar way as what people used to use jquery for all the time (adding event handlers and logic to DOM elements).

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

#78

Post by qbasic_forever »

bryik wrote: post #28
recursivedoubts wrote: post #15

Earlier quoted context omitted.

You can host an htmx-based site on Github Pages for free as well.

Does that fit with the philosophy of htmx? It looks to me like htmlx expects a server?

Github pages hosting your static content is a server...

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

#79

Post by qbasic_forever »

inwardsword wrote: post #4

Not withstanding that HTML and the DOM are garbage to work with in any language

I'll take manipulating and working with the web DOM _any_ day over going back to old Win32, MFC, and other native abominations.

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

#80

Post by mitchtbaum »

I like the potential for sending minimal document elements/objects, though it seems like HTMX/Intercooler/Unpoly features should be built into the browser. Unpoly, for example, has its own entire reimplementation of fetch():

https://github.com/unpoly/unpoly/blob/4854c7ccb268890a9522c6...

and it uses several X-HTTP-Headers, which could be standardized.

Do any browsers have the early workings of a "native web application sdk"?

Post reply on HN