31–40 of 414 posts
I've normally extremely skeptical of anything like this, but HTMX just feels right when using it.
Earlier quoted context omitted.
if you like the retro-vibe of htmx, you might also like my homage to HyperTalk, the scripting language from HyperCard: https://hyperscript.org
Hey, I didn't know the same person made both of these! How close would you say HyperScript 0.9.7 is to production-ready?
i would stick with what it is designed for: light front end scripting, rather than writing a huge app in it, but within that domain I think it'll be pretty reliable
If so, what do people pair it with on the backend?
I can see how this approach allows for much more dynamic pages with just static content, but what about when there is a database involved?
Also, what do people use for "published" static sites (I mean where the site is static once published, but the publishing step can pull content from dynamic source. Not sure the common terminology for that, but in this case, there tends to still be app logic to be developed, but it's just executed at publishing time rather than run time.) I'd imagine a publishing framework that is htmx-aware/friendly would be powerful.
Just curious how people round out the tech stack.
At the end of the day, I want my backend API to be restful json(or grpc, graphql) any client can consume. I want the client to be written with as few dependencies as possible. Maybe I'm misunderstanding though. Put another way: suppose I have an existing backend REST API where input/output is json. Can I use htmx without any changes to the api or server-side code to translate json to markup?
I am burnt out (but recovering!) with web dev and htmx is what I am using for my project. Django, DRF, Postgres, tailwind and HTMX. I am so tired of all the front end frameworks and all the complexity that gets added. At some point I think you need it and you get returns from it but hearing more people in the industry recognize and talk about how JS everything isn't always the answer gives me hope. I like what HTMX h…
howdy, I'm the creator of htmx, happy to talk about it
I want to like - I feel like the frameworks are all too much ceremony now. You need to buy into a bunch of different build tools, a cli or two, and are left wondering "where is my app again?" I've tried htmx, though, and like the simplicity, but am not 100% sold. In the olden days, ASP.NET Web forms Ajax had "Update Panels", which were similar to this. You'd wrap a section of markup in an "Update Panel" and that made…
https://htmx.org/essays/hypermedia-apis-vs-data-apis/
https://htmx.org/essays/splitting-your-apis/
Generally, I would recommend splitting your data and hypermedia APIs up, so you can take advantage of the features of hypermedia (the uniform interface) and still provide a good data API to clients that want it.
Also, this is pedantic, but a graphql JSON API is almost certainly not REST-ful, in the original sense of that term:
https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
https://htmx.org/essays/hateoas/
More essays and other silliness here:
If I'm understanding this correctly, this is a front-end only framework... is that right? If so, what do people pair it with on the backend? I can see how this approach allows for much more dynamic pages with just static content, but what about when there is a database involved? Also, what do people use for "published" static sites (I mean where the site is static once published, but the publishing step can pull cont…
We call this the HOWL (Hypermedia On Whatever you'd Like) stack.
100% plain HTML, CSS, and JavaScript based components (zero attribute hacks or compiler tricks). No external libraries for basic functionality (state, data fetching, url handling—all included or relies on native browser functionality). All a part of one full-stack framework that works out of the box.