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

Htmx Is the Future

quii.dev

Post reply on HN
Print view View original

821–830 of 875 posts

Re: Htmx Is the Future

#821

Post by Capricorn2481 »

obpe wrote: post #3

It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code fro…

> For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input.

These are two different things and I don't see how they're related. You don't need code sharing to do client side navigation. And you should always be validating on the backend anyway. Nothing is stopping an MPA from validating on the client, whether you can do code sharing or not.

Re: Htmx Is the Future

#822

Post by dang »

lakomen wrote: post #553
doodlesdev wrote: post #317

No it's not. Honestly, the fact that this website displays like shit without JavaScript enabled is ironic considering it uses HTMX. Please just use the damn full-stack JS frameworks, they make life simpler, just wait for WebAssembly to allow us to have full-stack Rust/Go/whatever frameworks, and then you can abandon JavaScript, otherwise you get the mess of websites like this one where the developer has not written J…

[flagged]

Please don't break the site guidelines like this! We have to ban accounts that do that.

If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.

Re: Htmx Is the Future

#823

Post by dang »

doodlesdev wrote: post #581
lakomen wrote: post #553

Earlier quoted context omitted.

[flagged]

I'm sorry for saying something you disagree with. Next time I'll ask for permission to comment my opinion. Really, what's the point of your comment? At least state why you think I have no idea what I'm talking about, the way you wrote it adds literally nothing to the conversation.

Please don't respond to a bad comment by breaking the site guidelines yourself. That only makes things worse.

https://news.ycombinator.com/newsguidelines.html

Re: Htmx Is the Future

#824

Post by quii »

jdthedisciple wrote: post #546
quacker wrote: post #481

Earlier quoted context omitted.

How is it fundamentally any different than 10s of thousands of clients requesting JSON or whatever other serialized data format?

Insofar as only retrieving data and returning it as json is way less work for the server than retrieving data plus rendering it.

Converting data to a HTML string is not a performance bottleneck you'll be worrying about. I wasn't worrying about it much in 2000, and you really shouldn't need to in 2023.

Re: Htmx Is the Future

#825

Post by recursivedoubts »

lakomen wrote: post #552
recursivedoubts wrote: post #190

Earlier quoted context omitted.

https://htmx.org/essays/hateoas/

I hate HATEOAS with a passion. Yet another useless Java gimmick with no support other than 1 single framework, Spring Boot. If htmx has anything to do with HATEOAS it's going to be ignored out of principle.

That's because you are using in a JSON API context, where it doesn't make any sense.

HATEOAS (or, as Fielding prefers to call it, the hypermedia constraint) is a necessary component of a truly REST-ful networking system, but unfortunately the language around REST is all jumbled up.

I try to explain why this is here:

https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...

and I try to explain what HATEOAS really is here:

https://htmx.org/essays/hateoas/

and I try to explain why HATEOAS has been, by and large, a failure outside of true hypermedia clients presenting directly to humans here:

https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

Re: Htmx Is the Future

#826

Post by recursivedoubts »

sublinear wrote: post #599
recursivedoubts wrote: post #597

Earlier quoted context omitted.

In the article I recommend splitting your hypermedia and data APIs up into two separate concerns. The data API can address all of the concerns you have. The hypermedia API, being consumed by an htmx front end, can then take advantage of the strengths of hypermedia (e.g. the uniform interface giving you a lot of flexibility in aggressively refactoring your API.) Please, read the article.

There is no data that should be encapsulated in hypermedia. YAGNI in this sense is the opposite - You Are Gonna Need It

That's fine, you can build a reasonable general purpose JSON API very quickly, particularly if you aren't having it dragged around by your web applications nitty-gritty needs.

In the linked essay I am riffing on someone already recommending splitting your JSON APIs into a general purpose API for clients, and a specialized one for your web application, in order to separate these two concerns and remove the pressure that that latter puts on the former.

I recommend going further with that and adopting hypermedia for your application API, since no one else should be depending on it. I recommend this because I like the hypermedia paradigm, but it only makes sense as part of a complete hypermedia system. Trying to reuse a hypermedia API for other clients isn't a good idea and that's not what I'm recommending.

Does that make sense?

Re: Htmx Is the Future

#827

Post by decross »

ukuina wrote: post #465
recursivedoubts wrote: post #190

Earlier quoted context omitted.

https://htmx.org/essays/hateoas/

Doesn't this make serverless read-only apps (that only require a fileserver) effectively impossible? In a serverless read-only app, all business logic and state is maintained on the browser.

You can embed a "backend" as a service worker and use htmx to interact with it. A proof of concept here: https://github.com/richardanaya/wasm-service

Re: Htmx Is the Future

#828

Post by benatkin »

csjh wrote: post #389
benatkin wrote: post #77

Earlier quoted context omitted.

Links and forms are the bread and butter of many frameworks. Like with HTMX, SvelteKit and Remix forms won't function properly without the framework.

SvelteKit forms work fine with Javascript disabled -- Rich Harris is a big proponent of progressive enhancement.

I know they work at some level. That's why I'm comparing them to HTMX.

They don't work fine if the users/stakeholders don't find it acceptable to render the result to the full window instead of the hx-swap style area, or to spend extra time on the backend making it render the whole thing.

Actually, this is one area were SvelteKit has it beat, because the backend is done by SvelteKit, and you don't have to manually deal with hx-swap not taking effect.

Re: Htmx Is the Future

#829

Post by aabbcc1241 »

If you like the concept of putting some work back to the server instead of throwing to the client, you may also checkout the liveview approach. It drives the entire website using the server with realtime updates (similar interactivity as SPA)

This approach has been implemented in most popular programming languages used for backend development: https://github.com/liveviews/liveviews

Re: Htmx Is the Future

#830

Post by kbenson »

taeric wrote: post #488
kbenson wrote: post #487

Earlier quoted context omitted.

No, I'm talking about back end processing cost. If the main page of the app has a significant server cost in the determining what data is being sent, being able to just redisplay the data you have when you browse back to the main page instead of request it again, which could incur that large processing fee, is a large gain. As a simplisit ecanple, imagine an app which on login has to do an expensive query which takes…

I find it hard to really agree that the backend of Gmail would be more involved with a thinner frontend. The "low bandwidth html" version sorta gives the lie, there...

I'm not sure what you're getting at. I'm not talking about bandwidth usage at all. I'm talking about CPU, memory and IO (as in disk, not client server transfer) usage.
Post reply on HN