http://htmx.org + whatever backend you like best
Seriously, is super productive this way!
Here's a great talk on why he asserts that: https://www.youtube.com/watch?v=J_7_mnFSLDg
Not sure I 100% agree, but I appreciate the fresh look at oil patters.
Each class is applied in pipeline.
And ONLY to that tag. This is key. This leads to know, exactly, what are the effects on each tag, making the UI design very readable.
Then, you can customize it, and have a way to generate a VERY small CSS as result (another big advantage!) because the naming is normalized.
In short: Is the "same" but with more structure, predictability and tooling applied.
The more you need to customize, and the more pain you to "reverse" a CSS made by others, the more this make sense.
Half of TailwindCSS is a _way_ of using styles, but the other half is almost a theme: a set of margins, paddings, text sizes, colours, etc. that work well together.
Everything is now all at the same global namespace and all of the issues that people run into with specificity go away in the process.
It’s not my personal choice on how to solve that problem I think shadowDOM via web components are a much nicer option personally but Tailwind has a lot of very enthusiastic fans who seem to enjoy it.
Is very pragmatic. That means your whole investment in the arcane ways of JS are dust. Not hipster at all.
---
More seriously, Is of little issues here. You setup and it works, so is not something that lead to "generate content" like other setups.
I found only a significant issue (to me) (https://github.com/bigskysoftware/htmx/issues/596) but then I do something that have never done in long time with a JS library: I poke into the source and fix it myself. Far easier than expected! (ie: The code is plain!)
I quite like HTMX myself, although I consider it a tool you use to enhance websites and not something you use to build full blown web apps.
Yes you could inspect the headers and such to determine what type to return, but the core problem remains, that the HTML in those is not reusable whereas as JSON would be.
How much overhead this is for you depends on your design of course, but it does mean some work might potentially be wasted if you go down the full SPA application later and even if not changing layouts and such might be a pain.
if it is greenfield development, it is much better to simply return SSR HTML and avoid that complexity
you can join the discord for more immediate help:
Web2py (being phased out by py4web which I haven't tried) made that very easy. If your api is accessed as api/hello.html, it can return HTML. According to the extension, hello.json, hello.csv, hello.txt, hello.pdf, etc. can return the adequate content.
Of course you can always return JSON regardless of the extension, but I found the same endpoints serving different formats very convenient.