Hacker News Reader

It's too bad Htmx isn't just the native behavior of HTML, implemented in a cross-platform standard, that does not need to rely on Javascript in user space code. It could just be part of the browser. It should have been part of the browser.

It's awesome, I'm not criticizing Htmx at all to be clear, I am criticizing our seemingly inability to advance the core web technology of HTML in browsers to include this kind of tech natively.

If somebody from the WhatWG, e.g. Apple, Google, Microsoft, Opera, and Mozilla, etc. wants to embrace and support the creators of Htmx and wrap this into the browser natively, I will proudly retract my comment.

I recall that was the intent of HTMX? His dream being to steer HTML towards these kinds of primitives and HTMX becoming deprecated.

Yep, you're right [1] - and the author is posting in here I believe, if he sees this - I just have to say, thank you for all you've done... maybe someday the browsers, WhatWG etc. will catch up with you...

[1] https://htmx.org/essays/future/#writing-research-and-standar...

we are working on this minimum viable set of changes currently:

https://triptychproject.org/

Best wishes for getting those through and thank you!

This seems like a strange combination of proposals:

1) PUT, PATCH, and DELETE methods: Logical and obvious extension, no extra syntax, but easy to get around today by just using POST for everything.

2) Buttons actions without forms: Just syntax nicety to avoid a single form tag, unconsequential and just adds implementation complexity.

3) Partial page replacement: Would completely revolutionize js-free html capabilities, but the draft is unfinished..

It would seem to me that the author should have just made the thrid proposal, and not wrapped it in a project of two much less consequential proposals?

> So now I am building my own forum completely without JS, and with Python Django doing a lot of heavy lifting.

Later this year I will be releasing Misago 0.40, which is a near complete rewrite from React.js to HTMX, with rest of features to follow in 2027. And yes, noscripy support is part of it.

https://misago-project.org/t/removing-reactjs-from-the-codeb...

Indeed. And the amusing/disappointing/frustrating thing is: my next.js site works if you turn off JS. Links are server-rendered as links, HTML is server-rendered as HTML. If you visit one of the tools that run on the client then they won't work, but the pages that could be static content? They're static content.

Or at least they were, until I started using cache components the other week, and I'd not noticed they'd regressed. That's frustrating. Give me a few minutes...

OK, while the fix was pretty easy (stopping wrapping static content in Suspense), actually getting it deployed was delayed :P. But it's fixed now.

I get the point but I do feel like Htmx's whole design is a big automatic fallback... If some browsers will never be able to understand the hx-get/post/etc attribs, you can just design the initial html you send over around that.

while what you're saying is true in theory, you still have to make sure that e.g. your form responses do the right thing. You might think "just return the full page!" but it's extra work that for many people is busywork, and makes it harder to reuse things ("my comment post endpoint returns the rendered comment" becomes "my comment post endpoint needs to know what page the comment is in to return the fully rendered page")

In practice I think it's very easy to make your htmx application JS-requiring.

Your comment post endpoint already knows what page the comment is in, it’s in whatever page the ‘post a comment’ form is in. When we design apps in a way that respects the conventions of REST (hypermedia and resource-oriented design), htmx slots in perfectly.

PunkwebBB maintainer here. This is good feedback. The only thing that really does need HTMX/JS on PunkwebBB is the shoutbox polling, which you can opt out of anyway. But you're right that there should be non JS fallbacks in place of modals and other small htmx interactions. I'll get on this.

I haven't published a release yet, I removed HTMX from thread/post actions and deleting categories/subcategories. The shoutbox is now the only functionality that won't work when JS is disabled. I've improved the fallback of the thread/post editor when JS is disabled as well. Those changes are in the main branch now.

Release will come soon, still some things baking.

Htmx is actually quite good at graceful degradation IF you stick to hx-boost for most interactions. See https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-i...

I have learned that whenever anything is "X if Y" it means it is really weak at X and "if Y" is just a workaround. This has saved me a lot of grief in life by identifying my personal emotional attachment to things.

That’s great, but unless you know some secret perfect technology that the rest of us don’t, every tech you use is also full of these workarounds, you just ignore them because you like the tech.

Also, hx-boost isn’t really a workaround, it’s a fully supported and documented feature.

But I really want hx-hyper, when is that going to be released?

This is exactly why I prefer Turbo ( https://turbo.hotwired.dev/ ).

Turbo comes from a progressive-enhancement philosophy: start with proper HTML and add richer behaviour on top. HTMX is a JavaScript library in much the same sense that React is. There is nothing inherently wrong with that, but it makes this anti-pattern easier to fall into.

Honestly, “the site should work without JavaScript” is no longer the strongest argument. Server-rendered, semantic HTML matters more for accessibility, SEO, and increasingly for LLMs and other automated tools.

Of course, you can write excellent HTML with HTMX. It just requires more discipline—or enough experience to recognize when you are quietly building a JavaScript application in HTML attributes.