5 ms·

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 thi

by jmull 4y ago

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

recursivedoubts 4y ago
htmx focuses on extending HTML as a hypermedia and, like HTML, can work with whatever backend can produce HTML, which is pretty much all of them. We call this the HOWL (Hypermedia On Whatever you'd Like) stack.
- kitsunesoba 4y ago
  I have yet to use it in anything, but conceptually I'm a fan of this kind of freedom of choice. It's always a bummer to see something that looks cool for frontend use and find that it's tied explicitly to a particular back end.
decross 4y ago
htmx is pretty agnostic with regard to the backend side of things. You can use anything you want, really. There are htmx extensions to Django and I am working on a similar one for Express. Basically, a very simple middleware to deal with custom request and response headers.
jonomacd 4y ago
I've been building a golang app that serves html via the go standard library template system. It works really well. You can define and execute templates inline so you can define entire pages in html and then wrap a "block" around any reusable bit that you want to serve up dynamically. Really easy to use.
andy800 4y ago
Because HTMX is totally unopinionated regarding the backend, and also expects pure HTML responses, you have a ton of freedom. In most cases, this means your choice of backend framework in virtually any language, anything from Django to RoR to Spring to http4k to Laravel, plus some templating framework/language such as Handlebars, Jinja, Thymeleaf, Moustache, JTE, etc.

by jmull 4y ago

recursivedoubts 4y ago

htmx focuses on extending HTML as a hypermedia and, like HTML, can work with whatever backend can produce HTML, which is pretty much all of them. We call this the HOWL (Hypermedia On Whatever you'd Like) stack.

kitsunesoba 4y ago
I have yet to use it in anything, but conceptually I'm a fan of this kind of freedom of choice. It's always a bummer to see something that looks cool for frontend use and find that it's tied explicitly to a particular back end.

decross 4y ago

htmx is pretty agnostic with regard to the backend side of things. You can use anything you want, really. There are htmx extensions to Django and I am working on a similar one for Express. Basically, a very simple middleware to deal with custom request and response headers.

jonomacd 4y ago

I've been building a golang app that serves html via the go standard library template system. It works really well. You can define and execute templates inline so you can define entire pages in html and then wrap a "block" around any reusable bit that you want to serve up dynamically. Really easy to use.

andy800 4y ago

Because HTMX is totally unopinionated regarding the backend, and also expects pure HTML responses, you have a ton of freedom. In most cases, this means your choice of backend framework in virtually any language, anything from Django to RoR to Spring to http4k to Laravel, plus some templating framework/language such as Handlebars, Jinja, Thymeleaf, Moustache, JTE, etc.