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

101–110 of 136 posts

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

#101

Post by recursivedoubts »

hu3 wrote: post #94
jonathan-adly wrote: post #47

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

what's "HOWl"?

Hypermedia On Whatever you'd Like: use a more powerful version of HTML/hypermedia (e.g. htmx, unpoly or hotwire.dev), minimize your front end javascript, and with it the pressure to adopt javascript on the back end. This frees you to choose "Whatever you'd Like" for your back end language, without the "two codebases/two languages" problem inherent if you go with an SPA framework and a non-js backend language.

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

#103

Post by nine_k »

recursivedoubts wrote: post #9
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'…

The good news is that there wasn't much left in the article save a silly meme. Although perhaps this is worth pondering: > We are fond of talking about the HOWL stack: Hypermedia On Whatever you'd Like. The idea is that, by returning to a (more powerful) Hypermedia Architecture, you can use whatever backend language you'd like: python, lisp, haskell, go, java, c#, whatever. Even javascript, if you like. There's no ac…

Diversity is also costly.

With JS or TS, it's really easy to have all the same IDEs, CI, testing frameworks — and of course libraries, programming idioms, and the general way of thinking both on backend and frontend.

This makes hiring easier, and hiring engineers is one of the tougher problems in tech companies.

There is a reason why folks writing Haskell on the backend try to compile it to JS for frontend, or go for PureScript. The same reason lies beneath other attempts to write non-JS and compile it to JS for client-side execution. Switching between languages for major components, and between different approaches these languages offer, has a real cost.

With JS being the only game in town for client side, the playing field is heavily tilted towards JS for everything.

(Yes, I know about WASM and about Dart. It's still not it, because they can't directly operate on DOM. It's like using a game engine to write a native Windows or MacOS app: most OS-wide affordances don't work.)

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

#104

Post by nine_k »

polyrand wrote: post #88

One misconception about Hypermedia-driven applications is the belief that you can't / shouldn't use JS or other new technologies. You can create a Cloudflare Worker returning HTML[0], which you can call using HTMX in the frontend. Using HTML to drive an app's interface has nothing to do with the tech stack, in fact, I think it opens the door to a more diverse tech stack. Optimistic UI updates, state management, and o…

From another POV, browsers are pretty bad at displaying HTML and CSS.

The layout mechanics are complicated. DOM is slow and non-transactional which means jumpy redraws and jank during partial updates, and you just can't render it at 60 fps, or even 30 fps, like you would with a direct-mode game-style UI; at best you can peg several CPU cores to 100%.

And this can never be fixed because backwards compatibility. It can only be replaced in some indefinite future.

This is why the virtual DOM was invented. And yes, if you know how to cook it, it's faster than jQuery.

OTOH great many web pages are not apps, and should not be treated as SPAs. But this happens, and it will until server-side rendering is made ridiculously easy to set up, and also becomes the fashion.

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

#105

Post by divbzero »

noduerme wrote: post #74
divbzero wrote: post #35

Earlier quoted context omitted.

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.

That sounds like a charming mess.

Each keypress would direct you to a new URL derived from a hash of the new text, an approach that takes advantage of browser history to provide a built-in undo function. Fans of this “content-addressable text editor” say it reminds them that writing is ultimately a grand exploration of Borges’ Library of Babel.

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

#106

Post by est »

SPAs are fundamentally flawed. I am making a webapp with lots of images and media resources to download, when the user click to another page, the media on the previous page are being still downloading in the background and choked the 6 connection limit. To avoid this I have to encapsulate the download queue to each "page" manually.

Another issue is how browser cache 404, for SPA app, the "known" routes are stored in main.js rendered in browser, the nginx doesn't know which page is not defined, so every page is 200 and then rendered 404 in browser only, the browser would still cache the "wrong" 404 page because nginx has to serve index.html with main.js as 200 first.

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

#107

Post by nine_k »

unclebucknasty wrote: post #63
cdata wrote: post #48

Anyone 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 t…

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…

Ah, yes: Flash, Dart, game engines.

Great graphics, often great performance. Also, trouble with spell-checking, copy-paste, even selecting text. Often hard to make the layout responsive. Reading mode, screen readers need not remind of their existence. Hypertext links into that are also problematic.

It would be nice to be able to create a new, different platform for hypermedia documents right inside the legacy browser platform from 1996. Sadly, it's not yet there.

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

#108

Post by ng12 »

peanut_worm wrote: post #98
ng12 wrote: post #62

God, I am so tired of these arguments. We need to stop bike-shedding web technology. You will never, ever convince me to go back to server-side rendering for the type of work I do. Are there other domains where that would be the wrong choice? Absolutely. The web is a platform and we should not treat these tools as one-size-fits-all. Use the tools that fit your use case; there's no use in talking about the how without…

What kind of work do you do where client-side rendering is better?

Interactive display of data sets. Mostly in finance, but I've worked in a few other industries where the same patterns apply. The focus of my development time is building out interactivity and optimizing data loading. Generating pages is the easy part.

As an example, I don't care about bundle size at all. A given app might have a hundred users all on desktop loading from an internal network. I will happily add a few MBs to the bundle if it increases the development velocity of my team.

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

#109

Post by mwattsun »

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 SO experience lately has been the accepted answer is 12 years old and the correct, modern solution is down at the bottom with 1 point and I can't upvote it because they want me to jump through some hoops to get "reputation" before I can vote

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

#110

Post by unclebucknasty »

nine_k wrote: post #107
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…

Ah, yes: Flash, Dart, game engines. Great graphics, often great performance. Also, trouble with spell-checking, copy-paste, even selecting text. Often hard to make the layout responsive. Reading mode, screen readers need not remind of their existence. Hypertext links into that are also problematic. It would be nice to be able to create a new, different platform for hypermedia documents right inside the legacy browser…

>Flash, Dart, game engines.

Hopefully, those aren't the only possibilities.

>new, different platform for hypermedia documents right inside the legacy browser

I believe there are use cases for which we need to chose between documents and applications.

Post reply on HN