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

391–400 of 530 posts

Re: Please just try HTMX

#391

Post by dweldon »

superjose wrote: post #127

Datastar has been garnering my attention https://data-star.dev/

My company makes a few products - one of them is just forms, lists, and links. When the codebase was really small we tried using htmx, then alpine ajax, then datastar. We stuck with datastar and I really enjoy it for projects that don't have a highly complex client state. Overall it's a really simple build and deploy process. I find it easier to secure and to reason about. Additional bonus: I'm able to lint the whole thing with biome since it's just typescript and jsx templates.

Re: Please just try HTMX

#392

Post by array_key_first »

ChocolateGod wrote: post #178
mrinterweb wrote: post #166

HTML over the wire frameworks like HTMX, Hotwire (rails), LiveView (phoenix), Livewire (laravel), LiveView (django), etc. They all have the same basic idea with differences in how they achieve it. I feel this approach is overlooked, and it drives me crazy. There is a huge complexity cost attached with JS frontend app + backend that everyone seems to have accepted as reality. HTML over the wire (really need a catchy a…

Using JSON over the wire means you can re-use your backend between multiple frontends (like with mobile apps).

You can certainly try, but a lot of times the applications are different applications with different semantics so this doesn't work and you create a bunch more endpoints.

Re: Please just try HTMX

#393

Post by elif »

I always thought the GWT->react branch of the webdev family tree was an inbred, unecessarily cumbersome compromise bred from JavaScript and performance metrics rather than descending from the beautiful code family we used to have with Rails and Django.

The only reason react seems to look beautiful is because it's compared to custom JavaScript state management rather than the server-state paradigm that probably makes most sense for over 90% of apps.

The only real place it makes sense is when you're Google or Facebook and those 15 milliseconds actually translate to quantifiable lost user attention.

If your app is actually useful and not just an attention farm, those 15ms are almost never worth your engineering team's sanity.

Re: Please just try HTMX

#395

Post by adamzwasserman »

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…

I use nested templates the same way React uses nested components. The key is cascading the context (like props) down the hierarchy. Column order change? One edit in the table template; everything that includes it gets the update.

The "header frontend / body backend" split is a choice, not a requirement. I wouldn't make that choice.

Re: Please just try HTMX

#396

Post by naasking »

nchmy wrote: post #354
naasking wrote: post #114

Earlier quoted context omitted.

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

There is, Datastar has client-side rendering based on signals [1]. Datastar is also very explicitly designed to be modular and extensible, so you can extend the client-side with more features, as they've done with Web Components.

[1] https://data-star.dev/guide/reactive_signals

Re: Please just try HTMX

#397

Post by lbreakjai »

array_key_first wrote: post #384
lbreakjai wrote: post #376

Earlier quoted context omitted.

This isn't about state, is it? In a classic react app, if I need to display the name of a user, then I fetch it (from the server) once, and display it as many times as I need, in as many forms as I need. There's only server state. I don't see how it's any simpler to shift partial presentation duties to the backend. Consider this example: https://htmx.org/examples/active-search/ The backend is supposed to respond with…

> This isn't about state, is it? In a classic react app, if I need to display the name of a user, then I fetch it (from the server) once, and display it as many times as I need, in as many forms as I need. There's only server state. No, there's two states here: the frontend state, and the backend state. The name example is trivial, but in real applications, your state is complex and diverges. You need to constantly s…

> These are hard problems.

I fail to see how HTMX helps. I fail to see how SSR necessarily helps too. You could be serving a page for an order that's been cancelled by the time the user sees it.

> I put in some search criteria, maybe a check a few boxes. Refresh? All gone

You could see that 20 years ago too, unless you manually stored the state of the form somewhere. Again, what does it have to do with HTMX, or Rect, or SSR?

Re: Please just try HTMX

#398

Post by adamzwasserman »

yellow_lead wrote: post #337
MrPowerGamerBR wrote: post #334

Earlier quoted context omitted.

I have something similar on my website, and my solution was to make server driven modal/toast responses. Allow the server to return a modal/toast in the response and, in your frontend, create a "global" listener that listens to `htmx:afterRequest` and check if the response contains a modal/toast. If it does, show the modal/toast. (or, if you want to keep it simple, show the content in an alert just like you already d…

Good idea, thanks for sharing! Nice design also

hx-trigger in the response header would handle that cleanly. Fires an event client-side; one global handler shows the error.

Similar to wvbdmp's approach but without needing the extension

Re: Please just try HTMX

#399

Post by adamzwasserman »

IgorPartola wrote: post #367
adamzwasserman wrote: post #181

Earlier quoted context omitted.

I was able to find architectural patters that work smooth as glass. Here is what my htmx apps have: - Single-purpose endpoints: Each endpoint returns ONE thing (a card list, a tag cloud, a form fragment) - Optimistic UI: Preferences like font/theme update the DOM immediately; the save is fire-and-forget with no response needed - Simple error handling: Most endpoints either succeed (return HTML) or fail (HTTP error co…

I have never loved the idea of the server rendering HTML which is probably why I have such a hard time with HTMX. In every other paradigm you clearly separate your server API and UI rendering/logic. Web apps are the only place where it seems common to have the server render UI components. Imagine if you had a Java or Swift application and had the server sending your phone UI screens. I don’t even know how you would p…

At the end of the day, personal preferences play a huge role. All programming is a compromise between tradeoffs.

React has a lot going for it. It's simply that I prefer htmx; it feels cleaner to me.

Re: Please just try HTMX

#400

Post by lbreakjai »

array_key_first wrote: post #388
lbreakjai wrote: post #327

Earlier quoted context omitted.

Splitting application API and generic data API is orthogonal to HTMX. You still have issues compared to plain JSON, don't you? Imagine you need firstName/email in once place, firstName/email in another, and firstName/D.O.B in another. In a plain JSON world, I'd craft a single "user" endpoint, returning those three datapoints, and I would let the frontend handle it. My understanding is with HTMX, I'd have to craft (an…

> n a plain JSON world, I'd craft a single "user" endpoint, returning those three datapoints, and I would let the frontend handle it. The main problem is that this is extremely, extremely expensive in practice. You end up in Big Webapp hell where you're returning 4mb of data to display a 10 byte string on the top right of the screen with the user's name. And then you need to do this for ALL objects. What happens if a…

> What happens if a very simple page needs tiny bits of data from numerous objects? It's slow as all hell, and now your page takes 10 seconds to load on mobile. If you just rendered it server-side, all the data is in reach and you just... use what you need.

You went on a long tirade against REST, which nobody mentioned. Just ... write an endpoint returning the data you need, as JSON? But write it once, instead of once per view variant?

> Just throw that in HTML, boom, 100 lines of code.

Now you need the exact same data but displayed differently. Boom, another 100 lines of code? Multiply by the number of times you need that same data? Boom indeed, it just blew up.

Post reply on HN