Htmx strikes me as what we would've gotten earlier if we didn't throw XHTML and namespaces out with the bath water. Namespaced attributes, perhaps even tags, that already package and compose behavior seems like the natural outcome of browser spec writers reifying community conventions over time, and that kind of superimposing is precisely what XML facilitates.
Htmx is part of the GitHub Accelerator
171–180 of 520 posts
Re: Htmx is part of the GitHub Accelerator
#172In recent years, I have not seen another tool that is so inflated. The attention it can garner for a tool where all it does is do simple things by adding attributes to html elements is really weird. Anyway, we need to act as if adding an attribute to the button and changing the value written in it is a very big need. Great job congratulations.
Re: Htmx is part of the GitHub Accelerator
#173hi there, as many of you know, i am the creator of htmx and I'm happy to answer any questions about it htmx has seen a surge in popularity, triggered by a video by fireship dev ( https://www.youtube.com/watch?v=r-GSGH2RxJs ) and a series of videos by ThePrimeagen, a popular twitch streamer on it hacker news readers might be interested in the essays I have written on htmx & hypermedia in general here: https://htmx.org…
> my favorite after htmx
That's interesting. I discovered Unpoly after HTMX (which I like) and decided to stay with Unpoly for a few reasons. Do you think hypermedia libraries will converge or do you think there is space for different interpretations ?
Re: Htmx is part of the GitHub Accelerator
#174Have loved HTMX for small projects so far, quite delightful. Does anyone know what they have on the roadmap for 2.0? I'm curious what they are working towards.
Very active, helpful community on Discord [1] and a #htmx-2-dev channel for discussion on this very topic
Re: Htmx is part of the GitHub Accelerator
#175Earlier quoted context omitted.
I'm kind of guessing / reading into their comment here but. Using htmx doesn't give me the feeling of "this is the only way I ever want to do this" but more "if html worked like this I wouldn't use js most of the time." The sense that an opportunity was missed and now we're paying for it in complexity.
The complexity is just shifted around from JS to HTMX (or hypothetically, html). Not a noticeable improvement.
That's not my experience based on two scenarios:
1. Server-side rendered sites in Python using either Django or FastAPI/Jinja2 and htmx;
2. Dotnet back end with Angular front end.
In practice - for the apps I've been involved with - option (1) provides a more than acceptable user experience. There's no doubt Angular can go beyond the capabilities of SSR+htmx. But, in practice, it's in the long tail. Throw in the odd js lib, e.g. for charting, and option (1) is good enough for the vast majority of things.
The complexity is not comparable: (1) is much simpler. For a start, all logic is in one language. There's no separate build for the front end and back end; no need to reconcile state in a front end cache with the back end. There's no need to export every view as a REST API; it's a native function that gets called from the view handling function.
Others will have different experience: I'm not saying this is universal. But in my experience, objectively, it's not true that the complexity moves from js to htmx. At least, not if that implies the complexity is equivalent. It's just not the case.
Re: Htmx is part of the GitHub Accelerator
#176I've a hard time taking htmx serious for building a modern web app/site. It makes is impossible to build features that users have come to expect: * Faceted search with configurable filters, like filter date on before, between or after, but only show the filter if the user wants it. * Configure result view with different columns or even different views like maps or drawing something on a canvas like charts. You can ma…
You can check this talk out https://youtu.be/3GObi93tjZI I was thinking the same but in the video they specifically talk about faceted search and how they did it with htmx.
For the second part you probably go with your own javascript or get away with hyperscript
Re: Htmx is part of the GitHub Accelerator
#177This page made me realise I'm better off with just vanilla JS or jQuery: https://htmx.org/examples/update-other-content/ Solution 3 gave me a good laugh though.
This page illustrates why I just don't get HTMX. It seems like a ton of effort to save not a lot of server cycles and html over the wire. I've done tabbed UIs that worked like HTMX. But instead of trying to do div surgery it replaced the entire tab. It was like 20 lines of JS and a few lines in Rails to render without a layout based on a URL query param. When we're talking dozens of KBs of HTML for a tab it's not the…
Htmx advantage is not that it sends less bytes, but that it effectively removes frontend. Getting rid of the frontend dependencies, builds systems, and languages can bring a lot of speed to a project.
Of course the downside is everything must go to the server. While not perfect, many spa also do not work nicely without a connection, although they could.
Another thing is that the templates can get a bit crazy quick.
I found a good solution is to use swap-oop (https://htmx.org/attributes/hx-swap-oob/) for everything and have a "component" wrapper server-side to abstract the ids and which template to choose.
Then, some kind of typed data structure tracking all the element ids, since you need to refer to them from the templates to know which element to update. This way you can easily find all the templates that update a specific id or all the ids that are updated by a template.
Re: Htmx is part of the GitHub Accelerator
#178Earlier quoted context omitted.
I'm kind of guessing / reading into their comment here but. Using htmx doesn't give me the feeling of "this is the only way I ever want to do this" but more "if html worked like this I wouldn't use js most of the time." The sense that an opportunity was missed and now we're paying for it in complexity.
The complexity is just shifted around from JS to HTMX (or hypothetically, html). Not a noticeable improvement.
I mean, that literally the core concept entire field of programming: making abstractions to shift complexity around (else where)
Re: Htmx is part of the GitHub Accelerator
#179Earlier quoted context omitted.
Arguably you’ve got to learn HTML, so why then add learning React/etc on top of that? HTMX is more limited, but also _radically_ simpler to modern frontend development.
People want and expect pretty and interactive experiences. I don't think they care how they get there. I've written some Unity "web" apps by using the port to webgl feature, so I have no deep fondness of html or js. I just need results.
Sure, I'm just suggesting that "best bang for the buck" may well not be React/etc, because it's a lot more "bucks" for often not much more "bang".
Re: Htmx is part of the GitHub Accelerator
#180Earlier quoted context omitted.
— We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness. — That to secure these rights, Governments are instituted among Men, deriving their just powers from the consent of the governed, — That whenever any Form of Government becomes destructive of these ends, it i…
I don't think that secular society posits some kind of natural inalienable objective moral law. I'm sure you know this but many, many people do not believe in objective morality
almost all secular people do in fact believe in objective morality to some degree, though you can occasionally find a pure moral relativist or legalist
remember that the holocaust, the great leap forward, gulag, the imprisonment of galileo, daily human sacrifice to the aztec sun god, and witch-burnings in the spanish inquisition were not just legal but legally required
therefore, anyone who condemns one of them is appealing to a moral standard they consider superior to, at least, the legal systems of the countries in question at the time