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

261–270 of 530 posts

Re: Please just try HTMX

#261

Post by adamzwasserman »

yellow_lead wrote: post #231
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…

How do you handle HTTP errors? Just curious because when I used HTMX I didn't enjoy this part.

Honestly? I never think about it. I've never had to. What did you run into? Curious what the pain point was.

Re: Please just try HTMX

#262

Post by pkorzeniewski »

hard_times wrote: post #53

Not HTMX but Alpine.js has been a complete revelation to me. What clicked for me was that you're enhancing server-rendered HTML, not replacing it. Need a dropdown menu? Add x-data="{ open: false }" and you're done. Want to show/hide elements? x-show does exactly what you expect etc. No bundler required, no compilation step.

Same here, using Alpine.js is a breeze and it made working on frontend fun again, everything is so easy and intuitive to implement and manage, even on large projects. It's definitiely my favourite frontend framework right now and a default for new projects.

Re: Please just try HTMX

#263

Post by naasking »

wrs wrote: post #186
naasking wrote: post #70

Earlier quoted context omitted.

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

I suspect the hidden assumption here is that frontend and backend are written by different people/teams with a narrow interface between them. Because they use different technologies and build tools it’s easy for them to end up being competely siloed, which IMO is one of the worst aspects of how webdev evolved in the last 20 years. Thus, it’s considered normal that the backend team spits out some JSON and doesn’t know…

It is true that htmx requires some straddling backend and frontend. I think the organizational approaches that split them is dumb to begin with personally. Good UI/UX almost always impacts the backend.

Re: Please just try HTMX

#264

Post by yellow_lead »

adamzwasserman wrote: post #261
yellow_lead wrote: post #231

Earlier quoted context omitted.

How do you handle HTTP errors? Just curious because when I used HTMX I didn't enjoy this part.

Honestly? I never think about it. I've never had to. What did you run into? Curious what the pain point was.

I had a site where the user can upload a file If it exceeds it, I returned 400. I had to add an event listener to check for the code (htmx:afterRequest) and show an alert(), but this gets difficult to manage if there's multiple requests to different endpoints on the page. Looking at it now, maybe I should have configured HTMX to swap for 4xx.

Re: Please just try HTMX

#265

Post by url00 »

65 wrote: post #172

Do not use HTMX for anything other than very simple CRUD apps. The vast majority of the time you'll be wishing you had client side two way data binding and state management. If you want "simple and not React", just use Alpine.js. It has way better ergonomics and features than HTMX and can do essentially everything HTMX can do.

This matches my experience. State management is the key thing - you end up needing to put way more on the backend then you'd otherwise like to. Quick example: something like a multi-step "wizard" is far more difficult to express in HTMX than with any SPA-ish pattern.

Re: Please just try HTMX

#266

Post by dalmo3 »

xnorswap wrote: post #93
naasking wrote: post #62

Earlier quoted context omitted.

> That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it. That's not a valid analogy, 99.99% of C# developers never see or touch CLR bytecode, where every React developer is still working with HTML+CSS.

That's possibly true, but I wonder why react as an abstraction fails to deliver that kind of independence. In theory, react developers ought to be able to code against the react API in typescript, without seeing the "raw" HTML+JS that gets delivered to the browser. So what's failing those developers? Is it the tooling, the abstraction itself, or something else?

> So what's failing

You're failing to understand the difference between react and react-dom.

> be able to code against the react API in typescript

https://github.com/chentsulin/awesome-react-renderer

Re: Please just try HTMX

#267

Post by lvl155 »

To be honest, none of these new-ish frameworks are good because there’s not enough data to train LLMs. React/NextJS is great because I can 80% get there with LLMs.

Re: Please just try HTMX

#268

Post by farmeroy »

mal-2 wrote: post #233
alfonsodev wrote: post #128

Earlier quoted context omitted.

I overlooked Astro for a long time, I didn't really get it, and my journey back to it went something like this: - 1 Getting burned out by Nextjs slowness in a complex production project that shouldn't be that complex or slow on the dev side, (this was 2022 approx) - 2 Taking a break from React - 3 Moving back to classic server side rendering with python and Go and dealing now with template engines. Hyped with HTMX an…

This is what doesn't get discussed enough around htmx, in my opinion. So much of the difficult steps are left for the templating system, and template systems aren't great in general. You need to track a lot of identifiers for htmx to work properly, and your template and view logic needs to make that make sense. For the templating systems I've seen, that's not so simple to do.

1000% this. I actually am using htmx at ${JOB} and this is essentially the only downside to htmx. I want to know which template partial is getting swapped. My IDE doesn't know. I need to track countless html ids to know what will be swapped where... how? It hasn't been a big deal because I alone write the frontend code so I have all my hacks to navigate and my intimate knowledge of the code, but if we need more devs on the frontend, or if the frontend drastically grows feature wise, i will need to tackle this issue post haste. I think template partials could help, but then we also would end up with giant template files and that would also be annoying.

Re: Please just try HTMX

#269

Post by gloosx »

This fucker didn't even bother showing us some real POST requests. And he actually wrote JavaScript to make those work.

Why would you mock it on the client-side if HTMX makes it so simple??

Re: Please just try HTMX

#270

Post by lbreakjai »

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-both-worlds paradigm, where the backend needs to be intimately aware of the frontend context. Am I not getting it or is there a massive implicit coupling?

Now if I need to display the same "user" data twice, in different formats, on my website. Say, as a table in "My account", and as a dropdown in the menu bar. Do I need to write two endpoints in the backend, returning the same data in two different formats?

Post reply on HN