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

111–120 of 136 posts

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

#111

Post by throwaway894345 »

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

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…

This probably feels like a big advantage if you’re in the JS world where setting up IDEs and bundlers and CI is a big involved endeavor, but Go+static HTML is close to effortless. No need for CI pipelines to build and publish source code or docs packages, and the test framework and build tooling require minimal effort to set up in a CI capacity. Similarly, Dockerfiles are trivial and minimalist, and everything builds, tests, and deploys lightning fast. It’s not as glitzy as some really high end web apps, but the quality is usually higher on the medium and low ends and it’s almost always faster.

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

#112

Post by mixmastamyk »

seumars wrote: post #37
toastking wrote: post #23

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.

Looks awesome, it's darn near readable.

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

#113

Post by nine_k »

throwaway894345 wrote: post #111
nine_k wrote: post #103

Earlier quoted context omitted.

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…

This probably feels like a big advantage if you’re in the JS world where setting up IDEs and bundlers and CI is a big involved endeavor, but Go+static HTML is close to effortless. No need for CI pipelines to build and publish source code or docs packages, and the test framework and build tooling require minimal effort to set up in a CI capacity. Similarly, Dockerfiles are trivial and minimalist, and everything builds…

If you can afford static (100% server-rendered) HTML, the world is your oyster! Party like it's 1998, but with incomparably better tools.

But a large enough proportion of modern web sites need enough interactivity to make even jQuery or even HTMX slightly inadequate.

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

#114

Post by zapt02 »

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'm surprised you chose to shelve the project after looking at Svelte, as it's by far the simplest framework compared to its contemporaries (React, Vue et al.)

For example, here is a fully functional Svelte component:

``` Hello world! ```

And here's another one that adds a bit of design:

``` Hello world!

h1 { color: red; } ```

I wouldn't call it particularly hard!

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

#115

Post by nine_k »

unclebucknasty wrote: post #110
nine_k wrote: post #107

Earlier quoted context omitted.

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.

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.

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

#116

Post by naasking »

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…

The fastest DOM update libraries in the benchmarks I've seen eschew the vDOM entirely. See domdiff for instance.

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

#117

Post by throwaway894345 »

nine_k wrote: post #113
throwaway894345 wrote: post #111

Earlier quoted context omitted.

This probably feels like a big advantage if you’re in the JS world where setting up IDEs and bundlers and CI is a big involved endeavor, but Go+static HTML is close to effortless. No need for CI pipelines to build and publish source code or docs packages, and the test framework and build tooling require minimal effort to set up in a CI capacity. Similarly, Dockerfiles are trivial and minimalist, and everything builds…

If you can afford static (100% server-rendered) HTML, the world is your oyster! Party like it's 1998, but with incomparably better tools. But a large enough proportion of modern web sites need enough interactivity to make even jQuery or even HTMX slightly inadequate.

Agreed, but I contend that this is a small share of the sites that use a frontend JS framework (which is to say that these frameworks are often used unnecessarily) and even those which genuinely need some serious JS could likely scale it back considerably to significant benefit. I say this as someone who usually argues in favor of the new and shiny.

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

#118

Post by naasking »

rezonant wrote: post #89
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.

I hear this a lot and I have to wonder if people have used JS tooling lately. When targetting the web all I need is `npm install`, `ng new`, `ng serve` and `ng build`. I have no idea what Webpack version or plugins or Sass compiler is in use, and I never need to modify it. It is productive, fast, easy to use, and powerful. For REST APIs one can use Nest.js or so to get a similar experience.

HOWI is about using backends other than JS. That's not as trivial to integrate.

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

#119

Post by hu3 »

recursivedoubts wrote: post #101
hu3 wrote: post #94

Earlier quoted context omitted.

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.

Thanks!

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

#120

Post by nine_k »

naasking wrote: post #116
nine_k wrote: post #104

Earlier quoted context omitted.

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…

The fastest DOM update libraries in the benchmarks I've seen eschew the vDOM entirely. See domdiff for instance.

One may not need to build an entire tree and then compare to another tree; the generation and comparison may go hand in hand to avoid building an actual vDOM.

It's DOM diffing anyway. It's still the "track and update dirty regions" logic of 8-bit game consoles, instead of the "redraw the whole screen from scratch" logic of modern game engines. DOM is not performant enough, and likely will never be, in its current shape.

Merging the vDOM-less transactional DOM update logic into the DOM standard could be nice, though.

Post reply on HN