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…
It's tiring, but for those of us that have the humility to know, for example, that we aren't experts in implementing every last detail of WCAG-spec compliant accessibility --and the application I'm building requires it-- it's better to build on top of someone else's solution. There's so many pitfalls to quite easily writing un-semantic, incorrect HTML. Browsers are forgiving, but a screen reader won't be.
IME, HTML-driven web applications (to say nothing of simple pages) in the field are generally more screen reader friendly than SPAs, though you can certainly achieve good accessibility with the right team and resources.
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…
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.
There is a reason we complain about front end frameworks. The fatigue is real. The npm and node_modules hell is real. The constant quirks with JS to make it work with our backend is real. I have been programming professionally for 18+ years and even though I can do anything, JS frameworks give me the most anxiety. Just this other day, something broke with an npm package and the error messages require me to hire a cryptography expert. I am half joking.
I am all in for something that keeps us on server side templates/HTML with dynamic capabilities.
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?
yep, htmx isn't that complicated
but it does support history, collecting parameters from the DOM, an extensive event model and extension model, targeting other elements, listening for events in sophisticated ways, coordinating multiple elements that are making requests, etc.
so there's some additional stuff in there that makes building a proper hypermedia-driven application easier
Consider the case of calling your backend with a POST call and then updating your app in response. Typically, for a SPA: your backend would return some data, and your frontend would then figure out how to update your html in response to it. For a multi-page-app: your backend will redirect the user to a whole new page with new HTML. This is somewhere in between: Your backend will send just a little bit of HTML and you…
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 project, the natural thing to do is to factor them out to what essentially becomes a framework.
This is what that is.
HTML element attributes is used as the interface because there are a whole lot of people that don’t like switching to writing JavaScript. You can argue all you like that you’re not a fan of this, but plenty of people are.
You can also argue all you like that one will eventually need to write some JS which will make the whole thing confusing to follow. The reality is that there are a whole load of projects where this isn’t the case.
If you’ve spent this long going back and forth with people about the merits of this project, and still don’t see it’s value, then it legitimately isn’t addressing a problem you have, or, more likely, it isn’t to your personal style/taste, or for whatever reason you are unable to relate it to any personal circumstances you’ve ever been in.
The documentation gives tonnes of practical examples of how the framework can be useful, and there’s mountains of third party examples. Beyond that, your arguments seem to revolve around a lot of technical, performance, and DX hypotheticals that you could test yourself by experimenting with the project. Part of its selling point after all is the lack of a need for complex build tooling.
If you still legitimately can’t see the value then it doesn’t seem worth the discussion.
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…
If you are burned out because of tooling, but trying to recover, I do recommend throwing out tailwind and just use pure CSS for your styling. Modern CSS is plenty fun, there is no need for an external framework to do a complex layout. CSS grid is the simplest way to do layout even if you include CSS frameworks. Custom properties (CSS variables) are more powerful then reusable styles from frameworks. The final peace o…
Do you have any specific suggestions for resources for exercising grid & shadow dom knowledge/chops?
I'm updating my CSS understanding after having left the front end for ~6 years (but having done a lot of front-end work for the previous 10), loving custom properties and am intrigued with some of the systems built around them (e.g. Pollen), trying to figure out where else I should be directing attention.
This is refreshing, and not unlike what Stimulus is trying to do in the RoR space. This is simpler than Stimulus, IMHO.
So much about modern FE dev requires knowing stuff that was intentionally abstracted to purer forms years if not _decades_ ago and easy to pull off in a browserserver relationship with a little bit of JS for state management or swapping content. The author even uses the phrase "AJAX," which I feel like I haven't seen used in earnest in years. This library is for the OGs.
Obviously, trade offs etc etc. If you're starting a new web based project, something that's just submitting forms and showing results, why would you really use anything more complicated than this? It's sorta hilarious that JSX took off; it shows that the declarative nature of HTML was right all along.
howdy, I'm the creator of htmx, happy to talk about it
I've never used htmx, primarily because I like the concept of "components" so much. (They serve two needs - standardizing larger blocks of UI and encapsulating them with an alternative interface, and providing islands of rich interactivity)
Is there any material on successfully combining htmx with web components? It doesn't look to me like the original design takes this possibility into consideration...
(note: at a surface glance it doesn't look to me like components are in conflict with hypermedia - one could treat them as a side channel that "enhances" the standard set of elements)
> The fastest way to get going with htmx is to load it via a CDN HTMLX is great and all, but loading it from a CDN is insecure and wrought with problems. Namely, the JS file in question could be hijacked and replaced with a malicious version that can steal data. It's unlikely, but still a plausible scenario. Also: the resource could just 404 and not be available due to work-in-progress scenarios on the CDN side. I wo…
It is available for download - see "Installing" under the table of contents. I always prefer to host locally myself and I do this for htmx.
that would probably be best accomplished w/ a custom htmx:configRequest handler: https://htmx.org/events/#htmx:configRequest you could jam the outerHTML of the detail.target into the detail.parameters map, maybe based on the presence of an attribute...
I'm gonna make a note on that when I have cycles to burn to experiment with htmx. From my understanding of reading that section, parameters being a container of kv pairs, I'd have to hack on the internals of htmx for it to be able to send a pure string (not form/multipart) as the body of a post/put request. If I get around of experimenting with that, and it fits my flow, would that be something you'd accept back into…
i don't think you'd need to hack the internals, you just hook into that event to do what you need:
htmx.on("htmx:configRequest", function(evt) {
evt.detail.parameters['my-html'] = evt.target.outerHTML; // or whatever
}
you can jump on the discord and we can help you out when the time comes:
Hi, thanks for the libraries! When I started using them, one of the hardest parts was to actually have it imported and built with webpack, since the site focuses on cdn and webpack example is really brief. Same goes for hyperscript Do you see cdn as a preferred way of usage?
unfortunately I don't know webpack really well, although I'd love docs contributions on it if the existing docs aren't good
you're not missing anything :-P
there's a big distortion field around expectations vs reality with webpack.