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

211–220 of 530 posts

Re: Please just try HTMX

#211

Post by lunar_mycroft »

adamzwasserman wrote: post #175
lunar_mycroft wrote: post #137

Earlier quoted context omitted.

(Disclaimer: I haven't actually run into a case where I had to move from HTMX to a SPA framework, even partially, so this is largely an educated guess) I think this scenario would either be very apparent early on in the project, or wouldn't actually be that challenging. There are a couple ways you could run into the limits of HTMX: 1. You require purely client side interactivity. The right (IMO) way to use HTMX is as…

multicards is almost purely client side interactivity. I STILL use htmx for a number of reasons: - No JSON serialization: HTMX sends form data natively no JSON.stringify() needed - Less JavaScript: Declarative hx-* attributes replace imperative fetch code. in my world declarative always wins. - Automatic headers: HTMX handles X-User-Id and other headers configured globally - Built-in error handling: hx-on::error inst…

You won't keep those performance numbers if the network conditions are bad, unfortunately. For things that require a network round trip, that's fine, because doing it via JSON (or some other serialization format) won't save you anyway. On the other hand, if it can be done entirely on the client, adding network round trips will slow the interaction down. It sounds like you're mostly doing the former (otherwise loading indicators and serialization wouldn't matter), but it's a point that should still be emphasized.

Re: Please just try HTMX

#213

Post by adzm »

alfonsodev wrote: post #128
chrisweekly wrote: post #97

Earlier quoted context omitted.

This is where I think Astro shines, with its "islands of interactivity" approach. Keep things as simple as reasonably possible, and provide an idiomatic, first-class mechanism for supporting more complexity where appropriate.

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…

Astro is great. If you are familiar with React, you can pick it up pretty much instantly. The design is simple enough to extend when needed as well for custom things.

Re: Please just try HTMX

#215

Post by bottlepalm »

stefan_ wrote: post #80
perardi wrote: post #60

I did. My startup did. And now we’re going to rip it all out and move to a React front-end. HTMX makes response handling much more complex. Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads. And HTMX is still a fairly obscure library. The documentation and examples are lacking, there isn’t a…

It's terrible, why would I want my endpoints to return random HTML fragments? I realize thats how you did it in the JQuery times, but I was never in those - at that time we simply had template engines in the backend so this HTML slop wouldn't contaminate everywhere.. Most of the frontend stuff I do is for internal pages on embedded devices, and I'm very happy with a structure where I have the frontend being a full Re…

Returning HTML sounds like a styling nightmare, if anyone changes the structure, unintended consequences. Plus it’s difficult to reason possible states of the UI with fragments sitting on the server, possibly dynamically built on the server. Very jquery/PHP ish. I had my fun and don’t want to go back.

Re: Please just try HTMX

#216

Post by recursivedoubts »

moralestapia wrote: post #209
lagniappe wrote: post #47

Earlier quoted context omitted.

I'm curious if the author of the article is an HN reader, and if yes, how this comment is received.

I will never ever ever ever touch htmx after this interaction I just witnessed.

what do you mean?

Re: Please just try HTMX

#217

Post by dpifke »

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…

https://unpoly.com touts "progressive enhancement."

Third link on the page ("read the long story") points to https://triskweline.de/unpoly-rugb/, which renders as a blank page with NoScript enabled.

Sigh.

Re: Please just try HTMX

#218

Post by wrs »

stefan_ wrote: post #109
ErroneousBosh wrote: post #88

Earlier quoted context omitted.

> It's terrible, why would I want my endpoints to return random HTML fragments? What would you return instead? It's easy to generate HTML, because that's what your server is already generating (and that's about all it should generate).

HTML is the last thing I would ever want to generate on my embedded device, it's a terribly verbose string-based mess invariably coupled with stylistic choices. Which is why my servers don't generate any of that, they serve static files - and any interactive information in something that looks a lot more like an interface definition.

I don’t get what you’re saying (maybe there’s a typo). With React, generating HTML on the embedded device is exactly what you’re doing — twice (virtual and real DOM).

Re: Please just try HTMX

#219

Post by furyofantares »

rpdillon wrote: post #201
furyofantares wrote: post #61

> "I'm not a fucking saint" You're not a fucking person, this is LLM output. It starts with the overdone sweary thing then mentions it's overdone and says it's not gonna do it, and it's almost enough to make me think the article is going to offer someone's point of view. But once again the LLM has erased any point of view the author may have had going in (or prevented them from developing it) and replaced it with a m…

Do you have evidence, or is it mostly vibes? EDIT: Decided to dig up the source: https://github.com/algal/pleasejusttryhtmx/commits?author=al... Looks like the initial commit might well have been generated, and then the document touched up in several following commits. But there's clearly a person behind it: algal.

There's a person behind all of these bad posts that are making it here. What I've said is that their perspective has been erased by the garbage the LLM put together from whatever inputs they gave it. OK - OK - I did say "you're not a real person" which is maybe what you're responding to here; I did not mean algal is not a real person, I meant algal didn't write the line I was quoting.

But yes, it's "vibes" - although extremely obvious IMO. Extreme usage of headings for paragraphs, which are often just a bullet list or a string of short marketing-speak fluff statements.

That's all aesthetic though and not the offensive part, it's just what makes it obvious. The offensive part is you can read the whole thing and come away with little more than the title. The author's perspective and voice is lost, beyond "they want you to try htmx" I can't tell what they care about or why, I can't tell what it is they were excited to try to convey.

Btw they did just add this to the footer.

> Does this all sound a bit like shallow slop? Yup, please help make it better.

Re: Please just try HTMX

#220

Post by wrs »

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?

That seems like an odd take. I don’t know that anyone ever intended React to completely insulate you from the actual UI framework (HTML/CSS in this case). You’d have to reinvent a whole new set of layout and styling features. Why would you bother? React is for orchestrating your use of the UI framework, not for replacing it.
Post reply on HN