I'd like to make a small plug for a really awesome Golang web development starter kit I found recently called pagoda (https://github.com/mikestefanello/pagoda). It wires up HTMX, together with Alpine.js and Bulma CSS, onto a really fantastic collection of Go libraries on the back end.
Htmx in a Nutshell
281–290 of 414 posts
Re: Htmx in a Nutshell
#282Earlier quoted context omitted.
The great thing about HTMX is it fits really nicely with templated server-rendered frameworks like Django. You can have a page with a list of items. The page is one template, and it includes a sub-template which is just the items. Then you have a separate view for "get list fragment" which just returns the updated/sorted/filtered , rendered with that same sub-template. If you toggle the ordering, or filter the list,…
But you can already do that. I was doing it in the 90s, Ruby on Rails supports it, etc. Just send the HTML if you want to and call `el.innerHTML = response.body`. The false dichotomy here is that it's either htmx or React. Why not... neither?
I ask similar questions about React ecosystem for years and the most frequent answer is “you’ll know when you need it”. Made few dashboards, smartphone-servers control panel with live streams, svg-heavy fully interactive cashflow graph builder for inhouse accounting, a bunch of typical “react” sites (literally because “frontend dev is slow and we need something right now, they’ll catch up later”, how does that sound) and still waiting for that enlightenment to come.
People throw bs under their feet and then learn how to avoid stepping into it too much. It’s insane. I think that htmx, despite clearly being a breath of fresh air for them, is in the same category: it does all you that could just_do already, but looks nice.
Re: Htmx in a Nutshell
#283Have been using htmx for a little over a year now, and I am so thankful for this library. It has simplified our development tremendously from ClojureScript / React to vanilla Clojure on the backend doing SSR of HTML with htmx HTML element attributes. All with 1 script tag that includes this wonderful library. Kudos to the creator of htmx! This is what hypermedia architecture with true HATEOAS is all about. It feels l…
Do you know off hand how much JavaScript your pages are including now versus when you were using ClojureScript/React? I ask because I know ClojureScript is built on Google Closure which has pretty advanced dead code elimination (and typically for React functionality people use libraries like reagant that take advantage of this - I think?). Presumably with htmx users are having to download the whole htmx lib.
The JavaScript we use is now much, much less. Actually, most times we just sprinkle in a bit of hyperscript for the times we need something a bit more dynamic than plain htmx. _hyperscript is a separate library by the same author that provides an HTML type of scripting in the attribute tags.
Still, in general, because we are generating fragments of hypermedia (HTML) on the server and returning that to target elements in the browser directly, the need for JavaScript directly in our code lessens dramatically. As you mentioned, though, you do need to include the hmtx JavaScript libary with a script tag. That library is very small though when min - something like 12k.
Amazingly, you can build some pretty dynamic web apps using htmx and sprinkling in a little vanilla JavaScript or _hyperscript if you are daring! The main key for us though is thinking from a hypermedia point of view with SSR; that coupled with the elimination of the complicated development configurations, is a huge win in simplicity and productivity. No more versioning our endpoints too!
Re: Htmx in a Nutshell
#284Earlier quoted context omitted.
Yeah, that I understand. I am not a huge fan of sending JSON that's not backwards compatible. Sending HTML is probably a good choice for some applications, but that was already well supported 20 years ago. Why is htmx better than one line of javascript saying `onload = function() { e.innerHTML = response.body` } ?
Look at each of the distinct things that htmx lets you do, and tell me what would be required to do it in vanilla JavaScript. Notwithstanding that even in your example `onload = function() { e.innerHTML = response.body` } [sic{ doesn’t even tell the whole story, HTMX does more than just this and this is blindingly obvious from its documentation. If you need those things more than, say, a couple of times in your proje…
The reality is that there are a whole load of projects where this isn’t the case
The reality also is you don’t know that until the project is archived. Their questions and doubts are valid, why not just say “yeah, it’s just a nice looking sugar for that with manageable caveats”.
I can see how reiterating on what can be done with it as if that couldn’t be done with AJAX in the same amount of code could make discussion a little confusing.
Re: Htmx in a Nutshell
#285Earlier quoted context omitted.
Can you speak of your experience with liveviewjs? I've been looking at it, and htmx, and everything else, over the past few months for a heavily-interactive frontend project I need to start. I'm an experienced ios dev, but in at the deepens with all this js frontend stuff. There are so many options! The one thing I'm sure of is I don't want to use react.
Have you considered https://inertiajs.com ? It's still SPA-ish, but keeps server-side routing and controllers. To me it sort of looks like templates rendered in the browser with almost no need to keep state and juggle xhr calls, the app component just re-renders with new props whenever something is submitted to the server.
This comment chain:
"HTMX is great."
"I'm burnt out on frontend frameworks. HTMX has been a good change to JS heavy alternatives."
"Can you give more thoughts on it for heavy interactions?"
"You might try LiveViewJS."
"Can you tell me about your experience with LiveViewJS?"
"Have you considered InertiaJS?"
I have no intent here other than I found this circular chain amusing. Let it go on long enough and someone will without a doubt recommend HTMX as if it's something they don't expect the parent has heard of.
Is it any wonder the OP was burnt out on web dev?
Re: Htmx in a Nutshell
#286Earlier quoted context omitted.
After going through a fever swamp project involving React, I am definitely in the camp of getting back to basics.
SvelteKit just hit 1.0. Out of all the 'modern' meta frameworks, it's the one that feels most like just writing HTML.
I'm not sure why you're posting this on a thread about HTMX. HTMX is almost certainly more like "just writing HTML"
Svelte lets you keep HTML, JS, and CSS all together, so that's nice, but it's typical use case involves writing a fair bit of Javascript/Typescript
Re: Htmx in a Nutshell
#287Fake logic attributes are my least favorite part of a js framework.
Re: Htmx in a Nutshell
#288My colleague and I created a library 11 years ago which does this without any markup changes:
Re: Htmx in a Nutshell
#289Earlier quoted context omitted.
Not sure what you mean by "heavy" frontend, but you might want to look into LiveViewJS (and/or similar) if there's a lot of frontend iteractivity, but you still want to do most of the logic/interaction on the backend. I don't have much experience with HTMX, but it seems to be aimed at sites with a little bit of interactivity, especially if you want to be "forced" to maintain compatibility with no-js. (I mean "forced"…
Can you speak of your experience with liveviewjs? I've been looking at it, and htmx, and everything else, over the past few months for a heavily-interactive frontend project I need to start. I'm an experienced ios dev, but in at the deepens with all this js frontend stuff. There are so many options! The one thing I'm sure of is I don't want to use react.
Positive experience with Phoenix LiveView here. I don't know what you mean when you say heavily interactive but I've got: via JS hooks: drag and drop and charts; and hand built with live view: data tables with filter+sort, query builder and a simple report builder. It's pretty easy to hand off to JS when the need arises.
Re: Htmx in a Nutshell
#290Earlier quoted context omitted.
I am so tired of everyone complaining about complexity in front end frameworks, as if this sort of thing doesn't exist in other languages and stacks, and as if frontend dev isn't as complex as other domains. Just ignore them or do something else.
I’m tired of everyone talking about the frontend as if it’s a monolith. In a world where web uses span all the way from a blog with a contact form to an entire app like Gmail it’s silly to pretend there’s only one answer. I think we’re still suffering from “everything with React” syndrome, I’ve never used htmx but if it can help as an antidote I’m all in.
This is so true. I have two real hobbies - web dev and wood working. One thing that makes me chuckle is the different takes the communities have on tools. In the web dev people constantly argue about how there is one best tool!!! The wood workers make an art form out of collecting the most tools possible, because each tool has a job and the person who dies with the most tools wins.
(Edited for typos)