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

Please just try HTMX

pleasejusttryhtmx.com

Post reply on HN
Print view View original

351–360 of 530 posts

Re: Please just try HTMX

#351

Post by jonathrg »

internet2000 wrote: post #229
recursivedoubts wrote: post #29

Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…

You really need to shut this down dude. If HTMX becomes famous for having overbearing advocates that's a really bad look. Look at what happened with Rust.

Rust is doing great.

Re: Please just try HTMX

#352

Post by turtlebits »

aembleton wrote: post #346

> The server just returns HTML (not JSON, actual HTML) Thats the thing I don't like. I don't want parts of the structure of my page coming from the backend server. I just want that to send data, as JSON and for the front end to handle that into whatever structure it deems suitable. That way all of the front end code is in one place.

In the simplest web server, the server returns HTML. Having the backend return JSON is where you're adding complexity. Your front end code won't even work without some base HTML.

Re: Please just try HTMX

#353

Post by jeffjeffbear »

I just don't like having to send HTML and have the backend deal with what are really frontend problems. Sending JSON is great since you can serialize most reasonable data types into it and then the backend has no responsibility for how it is rendered which helps for having mobile apps use the same backend as the website. Sending HTML just seems nuts since if you change your design you would have to change the backend too.

Re: Please just try HTMX

#354

Post by nchmy »

naasking wrote: post #114
samtheprogram wrote: post #82

Earlier quoted context omitted.

When an API returns JSON, your JS framework can decide what to do with it. If its returning HTML that's intended to go in a particular place on a page, the front-end has far less flexibility and pretty much has to put it in a specific place. Hence why they said endpoints can return 3-5 different versions of HTML.

> When an API returns JSON, your JS framework can decide what to do with it. The JS framework is the frontend, so you're still coordinating. > If its returning HTML that's intended to go in a particular place on a page, the front-end has far less flexibility and pretty much has to put it in a specific place. Well yes, because presumably that's what the app is supposed to do. If it's not supposed to put it in that pla…

To clarify, there's nothing React or SPA about datastar. Moreover, HTMX v4 is essentially Datastar-lite (but heavier, and less capable)

Re: Please just try HTMX

#355

Post by turtlebits »

lbreakjai wrote: post #270

It feels like the worst of both worlds, what am I missing? I get server-side rendering. I can boot my server, and everything is there. If my model changes, I can update the view. It's cohesive. I get client-side rendering. The backend returns data, the frontend decides what to do with it. It's a clear separation. The data is just data, my mobile app can consume the same "user" endpoint. This seems like a worst-of-bot…

You need to get out of the mentality that there have be two states.

Ultimately the frontend state cannot exist without the backend, where data is persisted. Most apps don't need the frontend state, all it really gives you is maybe a better UX? But in most cases the tradeoff in complexity isn't worth it.

Re: Please just try HTMX

#356

Post by nchmy »

asim wrote: post #50
kitd wrote: post #37

Earlier quoted context omitted.

This is the thing. Htmx is great if you only consider the frontend. But it does require fixing up the backed to match. A framework like that needs to integrate the front & back ends fairly tightly to have good UX. You may be interested in Datastar which does this better IMHO https://data-star.dev/

Thanks I'll look into it, but on first glance I feel like I just got space blasted by the website! What happened to simple websites eh

I assume youre referring to the "starfield" on the home page. That's just showcasing their "Rocket" webcomponents tool, which makes it vastly simpler to make WCs.

It is otherwise a very simple website, and the framework and its SDKs are much simpler, yet more powerful, than HTMX

Re: Please just try HTMX

#357

Post by listenallyall »

samtheprogram wrote: post #82
naasking wrote: post #70

Earlier quoted context omitted.

> Frontend and backend must agree on every scenario When is this not the case?

When an API returns JSON, your JS framework can decide what to do with it. If its returning HTML that's intended to go in a particular place on a page, the front-end has far less flexibility and pretty much has to put it in a specific place. Hence why they said endpoints can return 3-5 different versions of HTML.

"framework can decide what to do with it" sounds like a feature (more flexibility) but is actually often the source of errors and bugs.

A single, consistent, canonical response, generated by the server, taking into account all relevant state (which is stored on the server) is much cleaner. It's deterministic and therefore much more testable, predictable and easier to debug.

For pure UI-only logic (light/dark mode, etc) sure you can handle that entirely client-side, but my comment above applies to anything that reads or writes persistent data.

Re: Please just try HTMX

#359

Post by turtlebits »

lbreakjai wrote: post #333
adamzwasserman wrote: post #288

Earlier quoted context omitted.

Not a problem with Jinja (or any server-side templating). Both the table and dropdown render from the same context variable in one template pass. One endpoint, one data fetch, two presentation formats. The "two endpoints" concern assumes you're fetching fragments independently. If you're composing a full page server-side, the data is already there

So now you have presentation logic, tightly coupled, spread over two places. You need to jump between two codebases to even have a clue about what is rendering on the page. There's an example on their website where the header of a table is defined in the frontend, and the body is returned by the backend. If I wanted something as simple as switching the order of the columns, I'd actually need to create a new version o…

So what if you have presentation logic in two places, if it isn't necessary, remove the second instance?

There are so many gains by not using a frontend. You've greatly reduced your site size, removed duplicated logic, a shitload of JS dependencies, and an unnecessary build step.

Re: Please just try HTMX

#360

Post by roncesvalles »

But I don't want SSR, period. My backend is an HTTP API that speaks JSON. My frontend is whatever thingimajig can talk to an HTTP API in JSON. That's it. I love it this way and see no reason why I should blur the lines between frontend and backend.
Post reply on HN