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

121–130 of 136 posts

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

#121

Post by polyrand »

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

Yes! Thanks for the insight about the virtual DOM. I'm definitely not saying the virtual DOM is bad, or that JS is bad. But like you said, people are starting to mix pages and apps, thus also mixing the complexity requirements of each one. Luckily, it seems server-side rendering is coming back, even in React.

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

#122

Post by unclebucknasty »

nine_k wrote: post #115
unclebucknasty wrote: post #110

Earlier quoted context omitted.

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

I'd love to hear about other possibilities. This space is currently heating up, for the reasons discussed here. Currently when people choose it to be an application, it's usually a React / Angular / Svelte application. Purpose-built tools fulfilling their purpose.

>I'd love to hear about other possibilities.

Me too! I've written about this on HN more than once and bore myself with it at this point, but the short version is that I'd like to see more alternative approaches that effectively abstract away Web idioms altogether.

React, etc. code could be compiler output, not the code in which we think or write.

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

#123

Post by inwardsword »

austincheney wrote: post #6
inwardsword wrote: post #4

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

The DOM is a tree model. Navigating a tree is highly imperative. Developers allergic to imperative code tend to require unnecessary abstractions to make sense of the technology. Everything that follows is a foot gun of dependency hell.

No post body was provided.

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

#124

Post by jcelerier »

Brian_K_White wrote: post #87
jcelerier wrote: post #70

Earlier quoted context omitted.

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

Great. Someone reinvented flash, except the plugin is dowloaded and compiled in-page every time instead of installed traditionally. Even better! All those shitty restaurant web sites that were forced to become almost useful when flash went away, can rejoice and go back to being as awful as they were.

No, the end goal is to have an entirely separate browser which browses a web built with QML instead of html / js / css ; since Qt compiles to WASM it's a simple way to try it but the actual thing exists as a standalone desktop app: https://github.com/canonic/canonic

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

#125

Post by kiawe_fire »

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…

This is perhaps the oddest point the article makes.

They argue that JavaScript is still available for its “originally intended” purpose of light scripting, but that using less JS on the front end somehow frees you to use whatever you want on the back end.

But there is nothing inherent to SPAs that would force anyone to use JS on the back end.

And if “diversity is our strength” then I see no reason that wouldn’t be equally true when building JS-heavy SPAs.

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

#126

Post by Uranidiot »

beebeepka wrote: post #84
kanonieer wrote: post #38

Earlier quoted context omitted.

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…

> The cultural chasm between JS developers and people who push for simplicity was huge Yet another cheap shot. Might as well say 'fu js devs'. How come every time we have a thread on this thing its devs and supporters always come across as arrogant, bitter folks with an axe to grind. I don't like your technology. I didn't like it several years ago when I was introduced to it, and I don't like it now. It's not a bad i…

No post body was provided.

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

#127

Post by cdata »

88913527 wrote: post #69
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…

Angular and React were a response to the problem of abstraction-less frontends: spaghetti jQuery, piled ten miles high. I appreciate the concern for over-abstraction introducing unnecessary complexity, but there's got to be a point on the continuum of spaghetti-jquery to react+redux+node_modules that's the sweet spot. If you're choiceful in what tools you use, you can have that in 2021. It doesn't have to be overly c…

I hear what you are saying. I'll offer you: people have built some great experiences with jQuery, and people have built some terrible ones with React.

In the end, what makes the work product great has more to do with the team than the technology.

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

#128

Post by naasking »

rezonant wrote: post #91
beebeepka wrote: post #84

Earlier quoted context omitted.

> The cultural chasm between JS developers and people who push for simplicity was huge Yet another cheap shot. Might as well say 'fu js devs'. How come every time we have a thread on this thing its devs and supporters always come across as arrogant, bitter folks with an axe to grind. I don't like your technology. I didn't like it several years ago when I was introduced to it, and I don't like it now. It's not a bad i…

Absolutely this- Saying that the complexity of modern web dev is needless without even addressing things like state management, URL routing, component encapsulation, stylesheet encapsulation, performance, compatibility, semantic markup, offline-first, server-side rendering (for SEO and first paint) are somehow not real problems that need to be addressed. If you don't do it in the frontend, guess what? All of that is…

Half of those things you list are already handled by the browser, that's why htmx is so simple. Htmx does not preclude building an SPA, because all resources can be directed through service workers, but that's outside of the scope of htmx specifically. It just directs you to use hypermedia and exploit native browser technologies instead of inventing ad-hoc JS libraries and/or protocols.

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

#129

Post by culebron21 »

recursivedoubts wrote: post #21

hello, 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…

Good luck with your effort! I started making web pages in 1998, in high school. Then years later finally got a job and worked for 7 years as web developer full-time, but after I saw Angular and React and tried making a project with them, I quit.

But even without SPA frameworks, a boilerplate for a simple project was insane: linters, assemblers, template frameworks, etc.

With React it was one notch more boilerplate, and yet after all that you had to write pretty much all the interactive UI still on your own.

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

#130

Post by naasking »

kiawe_fire wrote: post #125
recursivedoubts wrote: post #9

Earlier quoted context omitted.

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…

This is perhaps the oddest point the article makes. They argue that JavaScript is still available for its “originally intended” purpose of light scripting, but that using less JS on the front end somehow frees you to use whatever you want on the back end. But there is nothing inherent to SPAs that would force anyone to use JS on the back end. And if “diversity is our strength” then I see no reason that wouldn’t be eq…

You're maintaining two development environments without also using JS on the backend, and require developers that are skilled with both environments and languages. This isn't really an issue with htmx, or with using JS at both ends.
Post reply on HN