[zelphirkalt]

What I don't like about Htmx is, that it is still a JS framework, without good automatic fallbacks for a noscript situation. This leads to web devs thinking it would be great to do all the things in Htmx, even if all they have is a static page with static content.

Just recently I looked at hosting an old school forum. I don't want to load all the PHP and MySQL baggage on my server or even run it in docker, so I looked for Python solutions. Found PunkwebBB. Was happy for a short time with it, until I tested it more in depth with no scripts. Unfortunately, while it has some good fallbacks in some places, it doesn't have them everywhere and some buttons just don't do anything without JS. It also uses Htmx. Completely unnecessary JS, considering the function of the buttons.

I considered forking it. But the amount of work to remove the needless JS, and repair it ...

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

[sixdimensional]

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.

[recursivedoubts]

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

https://triptychproject.org/

[mollerhoj]

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?

[sixdimensional]

Best wishes for getting those through and thank you!

[BbzzbB]

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

[sixdimensional]

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

[Ralfp]

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

[punkweb]

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.

[punkweb]

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.

[andrewaylett]

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

[andrewaylett]

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.

[beepbooptheory]

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.

[rtpg]

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.

[yawaramin]

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.

[yawaramin]

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

[asdfsa32]

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.

[yawaramin]

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.

[cientifico]

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.