Earlier quoted context omitted.
The philosophy of HTMX is not to send JSON, but HTML fragments.
They didn't mention sending JSON though... and you can absolutely return HTML fragments in a JSON response.
But why?
Why you should choose HTMX for your next web-based side project (2024)
11–20 of 81 posts
Re: Why you should choose HTMX for your next web-based side project (2024)
#12I can't believe they still don't have a way to parse JSON responses automatically. If you combine e.g. hx-post with hx-target, then it will put the text from the response into the target selector... but there is no "hx-source" to select what part of the response to use. I'd really love to be able to set e.g. hx-source="somejsonfield" instead of having to manually handle the response with a custom function that parses…
[deleted]
Re: Why you should choose HTMX for your next web-based side project (2024)
#13Earlier quoted context omitted.
The philosophy of HTMX is not to send JSON, but HTML fragments.
They didn't mention sending JSON though... and you can absolutely return HTML fragments in a JSON response.
Then what's the point of using HTMX?
If you're not sending just exactly the necessary HTML to replace the target's HTML; if you need to parse JSON, then even jQuery would be better suited.
The whole idea of HTMX is to get rid of the extra steps.
Re: Why you should choose HTMX for your next web-based side project (2024)
#14At what point are we going to say browsers with JS is outdated and painful? Every few months there’s some new framework. I think it stems from the fact that we refuse to change the browser. HTML was nice but all these solutions to make it modern are…ugly. And don’t get me started on JS. I just want an elegant solution that’s intuitive and built for modern applications.
Re: Why you should choose HTMX for your next web-based side project (2024)
#15HTMX seems like a solution in search of a problem.
HTMX is a solution of a problem like the following: how to add small bits of server-based interactivity to an otherwise static HTML page?
One way would be to go with React, Nest.js, setting up SSR and hydration of just the right fragments, etc. Another would be to take your existing static HTML page, and add very few bits in a specific place.
An easy example: a "like" button + counter of "likes" under a blog post.
If you need a complex SPA UI, you need a different tool.
Re: Why you should choose HTMX for your next web-based side project (2024)
#16I got a wave of shudder reading the acronym "HAM stack". Yugh. MEAN, MERN, RERN–once hyped up hot air which now sounds so dated and hackneyed. It's cool to be excited about tech but if your main selling point is building "faster and cheaper", I don't know if picking up a minimalistic framework you know nothing about is faster than just re-using your trusty boilerplate.
Be it React or Svelte or whatever. With serverless backend if you want to keep costs down. Although a server from Hetzner isn't that expensive and you can host multiple APIs there.
Re: Why you should choose HTMX for your next web-based side project (2024)
#17At what point are we going to say browsers with JS is outdated and painful? Every few months there’s some new framework. I think it stems from the fact that we refuse to change the browser. HTML was nice but all these solutions to make it modern are…ugly. And don’t get me started on JS. I just want an elegant solution that’s intuitive and built for modern applications.
I think your suffering from the same thing that makes 2014 feel like 5 years ago when its over a decade ago.
The framework landscape has remained relatively entrenched in React since 2016. Sure theres a few new ones time to time but nothings ever come close to unseating it in the same way it took over from Angular.
(Yes you could argue Nextjs but thats just react with a backend bolted to it)
Re: Why you should choose HTMX for your next web-based side project (2024)
#18HTMX sets up an underlying network traffic pattern:
1. The user interacts with the page.
2. The page sends a request to the server.
3. The server returns one response to the client, containing HTML, which the client inserts into the page.
4. (Optional) If the response includes references to other resources, like images or fonts, the client makes more requests for these.
The consequence of the 'one request, one response' thing is that the whole thing is fast. All the HTML arrives in one go. None of this request-one-thing-then-run-some-JS-on-the-client-to-decide-whether-to-request-another-thing nonsense that you can watch happening in real time that happens in an alleged productivity tool I have to use at my day job.
Re: Why you should choose HTMX for your next web-based side project (2024)
#19At what point are we going to say browsers with JS is outdated and painful? Every few months there’s some new framework. I think it stems from the fact that we refuse to change the browser. HTML was nice but all these solutions to make it modern are…ugly. And don’t get me started on JS. I just want an elegant solution that’s intuitive and built for modern applications.
Many web developers make applications that are expected to work on every platform, every screen size, load instantly for new users, sync user state between every device instantly, and work offline (in some cases). All this takes place in an execution environment that perfectly sandboxes it, allowing users to download and run any application without any fear of viruses. Yes, the stack is complicated, but it's a complicated problem. The fact that people are making libraries to make web development simpler... well, no platform other than the web has even attempted to achieve everything I've listed, so we don't really have a point of comparison.
Re: Why you should choose HTMX for your next web-based side project (2024)
#20I recently found Datastar [0], another hypermedia project. It was originally inspired by htmx, but they are fully on their own (hypermedia) course. According to the devs, who had a bunch of discussions with maintainers of htmx, the htmx project considers itself finished and no new features forthcoming. It is laudible, a project considering itself complete.
Datastar considers its library v1.0 release [1] to be complete, offering a core hypermedia API, while all else consists of optional plugins. The devs have a hot take wrt htmx in their release announcement:
> While it’s going to be a very hot take, I think there is zero reason to use htmx going forward. We are smaller, faster and more future proof. In my opinion htmx is now a deprecated approach but Datastar would not exist but for the work of Carson and the surrounding team.
When you think of adopting htmx, it may be worth making a comparison to Datastar as well.