[HN Gopher] The Future of Htmx
___________________________________________________________________
The Future of Htmx
Author : polyrand
Score : 438 points
Date : 2025-01-06 18:05 UTC (4 hours ago)
(HTM) web link (htmx.org)
(TXT) w3m dump (htmx.org)
| xvinci wrote:
| I am still trying to get HTMX adopted in a ~ 800 employee
| software development company. And while we do not yet have a
| project using HTMX in production, I like to use it a lot in
| thought experiments with mentees: Could you do it with HTMX /
| Fragments? If yes, how would you design it? Do we REALLY need an
| SPA?
|
| Kudos to the developers.
| graypegg wrote:
| I do think "use HTMX" is a tough sell for a 800 employee
| company, just because it doesn't really solve issues on it's
| own. (Imagining the pitch is "add HTMX to an existing project")
| Going all-in on hypermedia definitely means the service that
| serves your application needs to be more than just a JSON
| parrot. Templating HTML and sending the right chunks back is
| hard to do if those services aren't built around being
| hypermedia services.
|
| I really like turbo-rails [0] (the ruby gem that Rails 7+
| bundles in for turbo support, meaning helpers that make turbo
| frames/responses a native "thing" rails understands) because
| it's a complete solution. There's at least some obvious
| structure to build off of, and I'm not stuck trying to build up
| my own framework on the BE for my newly simpler FE.
|
| django-htmx [1] also fits in this case too. I feel like any
| honest pitch of HTMX should involve some BE solution as well.
|
| [0] https://github.com/hotwired/turbo-rails
|
| [1] https://github.com/adamchainz/django-htmx
| kgeist wrote:
| I tried to get HTMX adopted for a new project but the unanimous
| response was "what is this? why not React? everyone knows
| React. period" and most of my arguments for HTMX were ignored,
| because to most people, HTMX looked like some obscure, yet
| another JS framework created last week, with questionable
| future.
| frde_me wrote:
| To be fair, it's not an unfair response. Being able to hire
| for a technology, and having a large community around the
| tech stack you use has tangible value.
|
| HTMX might not be something that will vanish in a week, but
| it's also nowhere close to a mainstream framework.
| wg0 wrote:
| Very anti React person went for Svelte but the kind of
| modularity React offers, HTMX can't hope to match especially
| on larger projects.
|
| Modern React is too simple. A component is just a pure
| function taking arguments and returning UI as JSX. The only
| other thing you need to know is few hooks.
| The_Colonel wrote:
| > Modern React is too simple. A component is just a pure
| function
|
| React is simple only in some mathematical theoretical
| sense, but not for understanding by human minds which
| fundamentally operate imperatively ("if I click on this,
| load data X from the server and show them to the user...").
|
| You can get some hello world example relatively easily, but
| you hit the complexity wall quite quickly (need to know
| "some hooks" - some, like useEffect() are very complex, yet
| often needed for basic things). The worst of all is
| debugging with stacktraces making no sense with it all
| being from the React itself, not your code, not tracking
| some logical pathway.
|
| (I'm saying that as someone who generally likes React and
| would choose it for a new project)
| wg0 wrote:
| useEffect is simple. If I recall correctly, with no
| arguments it is like onMount and with the dependent
| variables listed in array, it would be executed every
| time any of the listed variables change.
| brtkdotse wrote:
| > The only other thing you need to know is few hooks.
|
| ...and then draw the rest of the owl.
| bvrmn wrote:
| > The only other thing you need to know is few hooks.
|
| And where you can't use them. Hopefully there are zillions
| of YT videos from experts teaching you all react gotchas.
| cpill wrote:
| try passing state around the component hierarchy and see
| how simple it is. HTMX makes it easy but centralising the
| state in one place ie the server. try coming back to your
| code base in a year or two and see how simple it seems then
| :D
| wg0 wrote:
| You pull the state up. Props down.
| robertoandred wrote:
| Except when your state appears in many parts of the page,
| HTMX makes it hard to keep everything updated.
| sethammons wrote:
| agreed: htmx is good for "swap out this one element and
| its children". It is not good for "and these other
| related elements need to update"
| sethammons wrote:
| maybe you can send me to the right tutorial. I'm a backend,
| distributed systems engineer. I have worked on eye-watering
| scale. React is anything but simple to me.
|
| I tried create-react-app, the thing built and downloaded
| for several minutes, and then there was a nest of file
| relationships that I didn't grok. It seemed like any change
| required three files to be updated. Lots of ancillary
| things like bundlers, packers, tree shakers, lions, tigers,
| and bears, oh my. After an hour, I didn't get what I was
| doing. Somehow, altering this function over here made this
| other thing over there go "moo."
|
| I used to do web development back in like 2001. I
| understand the web, http, css, html, and basic js. I'm not
| up on all the latest, but I have a very firm base.
|
| I got htmx working and pretty much fully digested in the
| same amount of time I wasted on React and have produced a
| working prototype. I find htmx to be like how the web used
| to be. It makes sense.
| greenavocado wrote:
| The reason is because all new technology is a staffing and
| training problem management needs to solve. Someone has to
| maintain your thing after its built and be ready when you
| leave the organization. If React can solve the issue in a
| similar timeframe and level of effort and it is easy to
| source React developers then obviously your proposal will be
| rejected because React is simply far easier to deal with from
| a training and staffing perspective for what you are trying
| to do. You need more merits to warrant the introduction of
| new languages and frameworks.
| recursivedoubts wrote:
| That's a fair response:
|
| https://htmx.org/essays/when-to-use-hypermedia/#if-your-
| team...
|
| the reality is that the only way to prove htmx is around for
| the long term is to stick around for the long term, and I
| hope this essay contributes towards that.
|
| We'll see how this years JS rising stars shakes out.
| on_the_train wrote:
| Same story here, although the poison of choice is angular.
| jjk7 wrote:
| I built an HTMX fragment framework for Django. It allows you to
| render a fragment, and automatically serves the fragment
| separately for live-updates. I'll open source it tonight and
| post back.
|
| In my opinion, HTMX + custom elements does everything React
| does but better, and is a billion times cleaner.
| WD-42 wrote:
| Sounds great!
| whinvik wrote:
| Is jquery something people start projects with today? If so, what
| is the motivation?
| michaelcampbell wrote:
| Start? Not generally I don't think.
|
| That said, back in the day it provided functionality that JS
| just didn't, or was quite cumbersome.
|
| With recent JS versions, JS can do a lot of what JQ did for it,
| but JQ's API or "surface area" is still syntactically smaller
| and (IMO) more sane than those JS improvements.
| 42lux wrote:
| Wordpress Themes/Plugins are still all over it.
| recursivedoubts wrote:
| ~43% of the internet runs on WordPress[1] while ~75% of the
| internet uses jQuery[2], so even if you took out every
| website that used jQuery due to being built on WordPress, the
| number of websites using jQuery would be over six times
| higher than the number of sites built using react.
|
| [1] - https://colorlib.com/wp/wordpress-statistics/
|
| [2] -
| https://w3techs.com/technologies/overview/javascript_library
| Gys wrote:
| You saw 'jquery' in the second sentence of the text,
| immediately closed the link and started a comment with this
| question?
| pelagicAustral wrote:
| I have, many times in the last 2 or 3 years... I still do...
| It's cheap and easy to implement, it's easy to use and it ads
| just as much cruft as I'm willing to tolerate. I build boring
| software, average CRUD applications for government departments,
| people in this line of work don't give a shit about millisecond
| delays or reactivity, hell, they don't even care about
| responsiveness... jQuery facilitates high speed development,
| provides neat functionality that doesn't get in the way, it's
| easy to maintain, and keeps people happy.
| amadeoeoeo wrote:
| Even if you did give a shit about those things, all that can
| be achieved with jQuery. IMO the real downside of jQuery is
| not being as opinionated as other mentioned "technologies",
| which leaves too much room for thinking
| dpc_01234 wrote:
| If you haven't started your dev journey with React or some
| other framework like it, you actually know for a fact that they
| are not necessary an probably an overkill for a lot of web
| apps. Websites were built with interactivity, were lighter and
| worked better, before the dawn of slop-assisted SPAs and
| developers who don't even know how the browser and hypermedia
| actually works.
| cloudking wrote:
| Yep, works great for simple projects.
| bdcravens wrote:
| Start? Not really. However that doesn't mean there isn't active
| development and new features happening on projects that are
| already using jQuery, and so the expectations from that library
| matter.
| marcosdumay wrote:
| I dunno, but it is included in many commercial libraries (free
| ones tend to be less reliant on large dependencies); a lot of
| people know it and a lot of people don't even know how to start
| bundling a node (or dino? what are people using now?) project;
| and it has a lot of extensions that really impress some people.
|
| Besides it having a way more convenient API than bare JS. (That
| honestly, I only don't use because bare JS is conveniently
| documented by MDN, otherwise I think I'd be fully on it too.)
| syndicatedjelly wrote:
| I use jQuery when I want to finish a web project, not leave it
| in perpetual development.
| andrewstuart wrote:
| Off topic but the other day I tried again to build a vanilla JS
| application.
|
| By the end of the day having built quite a lot I then converted
| the entire thing to react within half an hour stopped wasting my
| time and got in with the job of building the thing.
|
| I like to try library free JS every now and then and yet again it
| was not competition for react.
|
| I know react, it makes sense to me, I find it easy and powerful,
| I know how to fix most issues and probably most importantly
| Claude is able to write react for me almost without me
| intervening at all.
|
| I'm not saying react is for everyone but for me it's a power tool
| that I know and the AI knows very well and it gets big stuff
| built quick.
| wordofx wrote:
| That's great for you. But every single react project I've seen
| or inherited has been a steaming pile of shit.
|
| All these new front end developers who jumped in on react with
| no other experience have no idea how web works are struggle to
| build without react.
|
| Anyone competent in web development prior to react could build
| with htmx or even vanilla js just as fast without react as they
| could with react. Won't stop the brainwashed react devs coming
| out defending their only source of income tho.
| robertoandred wrote:
| That's the fault of bad developers, not React. There are bad
| developers for each and every language, library, framework,
| and stack.
| phist_mcgee wrote:
| Isn't that like saying that a "competent" woodworker has to
| know how to use handtools first before trying to build
| anything with power tools?
|
| What's the problem with starting from an elevated starting
| point?
| WA wrote:
| Question is, can you have a super thin layer that gives you the
| reactivity we all crave and don't want to reimplement in
| vanilla ourselves without using legacy tech React.
|
| In a way, it's depressing that the thing that holds developer
| minds hostage gets even more hold over devs, because the
| frickin AI knows it best.
|
| Just a reminder: React was created as a not-a-framework-but-a-
| view-library but everybody writes _React_ apps, not JS apps.
| eawgewag wrote:
| > React was created as a not-a-framework-but-a-view-library
|
| Honestly, I think this was the biggest mistake the React team
| made. It was never intended to be this way. It was just
| _marketed_ this way in order to convince people to try it.
|
| Once you started to use it you could very easily tell how it
| never fit in the traditional MVC model.
| viraptor wrote:
| You didn't really set the scene. What kind of application was
| it? If it's a fully interactive rich application with real time
| multi user handling, then sure. If it was a static page blog,
| then that's a problem (yet I see people do that anyway).
| There's a whole spectrum of interactivity and expectations
| here.
| clwg wrote:
| I did something similar but I took it entirely the other way, I
| built a full CRUD application with no javascript.
|
| The app is fully SSR and integrates with a fairly complex
| inline data enrichment and analysis system. I used Tailwind
| alongside regular CSS for the layouts and some visual
| enhancements. Eventually, I gave in and added a bit of
| JavaScript to submit a form when a dropdown is selected--
| usability is important to me. Other than that, everything works
| as needed.
| tbatchelli wrote:
| I value the hard stance on stability and backwards compatibility
| over the constant churn that some JS libraries/frameworks have. I
| understand the need both approaches, but this is a breath of
| fresh air.
|
| I also happen to think that most web apps have no business being
| so complex, and that too much work goes into dealing with the
| added complexity of running SPAs where an SPA is not needed.
| robertoandred wrote:
| Why is the added complexity of running HTMX better than the
| complexity of an SPA?
| rednafi wrote:
| Because then I can keep the bulk of the logic in a language
| that's better designed than JS. Not having to write JS is a
| huge feature. The added complexity of HTMX is abstracted
| behind a single library, and the bulk of the logic stays in a
| better-designed language--Go, Python, Java, Kotlin, Rust,
| Zig, C#, anything.
| recursivedoubts wrote:
| it is sometimes much lower, if it fits your use case:
|
| https://htmx.org/essays/a-real-world-react-to-htmx-port/
| evolve2k wrote:
| I'm very grateful for how htmx by focussing on a very specific
| part of "interactive JavaScript on the page" was able to shift a
| whole bunch of similar JavaScript actions into an elegant
| abstraction that rested so neatly on all the existing work that
| had/has gone into developing html. And even for having the
| clarity to name it as such.
|
| In a way it's a bit of a lesson in managing complexity, rather
| than seek to be "the next JavaScript framework to replace all the
| others with its theory of the universe", it instead carved off a
| smaller slice and said these Thich are related, we're just for
| dealing with these thing, nothing more.
|
| In one swoop a whole raft of manual developer programming
| workload was packed up with a new easier to understand
| abstraction.
|
| Kudos to the team, I'm grateful for the considered way you've
| developed this tool for the rest of us.
| swyx wrote:
| how do you feel about its adoption in things like
| https://fastht.ml/ ? i was open to the idea at first esp with
| jeremy howard's endorsement, but once you start updating
| multiple things on a page at once i felt like i was fighting
| htmx rather than it helping me. components are a really neat
| paradigm and just bc react is currently in a complexity upswing
| doesnt mean we want to throw the baby out with bathwater
| mejutoco wrote:
| You can build your own python component implementation on top
| of htmx, like in the example you show. That is not a failing
| of htmx IMO.
| swyx wrote:
| thats not what the js world traditionallyunderstands as a
| component - eg - it doesnt take an argument that, when the
| argument value changes, the component rerenders. you still
| have to wire all that up with htmx (again, as far as i
| undersatnd it, having spent a week with htmx)
| WickyNilliams wrote:
| I think web components would be an excellent pairing with
| htmx. You get some kind of component abstraction
| (admittedly janky in some ways, though libraries like lit
| or atomico make this much better). But crucially you get
| automatic upgrade/initialize behaviour whenever the
| browser encounters a custom element. So the backend can
| just send down the custom elements as plain html, you
| don't need to wire anything up, the browser will bring
| them to life.
| _tom_ wrote:
| I feel this article makes the same mistake many technical
| articles make.
|
| What does it do? After reading a large chunk of the article, I
| have no idea. No, wait it "enables behavior".
|
| Maybe it's only relevant to people that are already familiar with
| it. But it would seem that a hacker news front page would be a
| great opportunity to let more people know about your product.
| recursivedoubts wrote:
| i would recommend the homepage & docs:
|
| https://htmx.org
|
| https://htmx.org/docs
|
| and if you want a more in depth treatment, our book (free
| online):
|
| https://hypermedia.systems
| ggregoire wrote:
| > But it would seem that a hacker news front page would be a
| great opportunity to let more people know about your product.
|
| It's on the front page every other week...
|
| https://hn.algolia.com/?query=htmx
| bdcravens wrote:
| Why should every article on a site restate the premise of the
| project? After all, this article doesn't tell me what React is:
|
| https://react.dev/blog/2024/10/21/react-compiler-beta-releas...
| ecshafer wrote:
| This isn't an announcement of a project. This is more a
| statement of their philosophy and what they are doing. This is
| targeted towards people familiar with the project.
| eawgewag wrote:
| As a React developer, I love that HTMX is trying to aim for
| stewardship and "No new features as a feature". IMO, page router
| NextJS is perfect (and in line with the original API it pitched),
| and the bifurcation to app/page router has been complicated. Yes,
| I am fully aware that NextJS works with both app/page. I just
| find it mentally confusing to wrap my head around both worlds.
|
| I feel this way about base React too, including --
| functional/class components, hooks/non-hooks, and more recently,
| RSCs/Client components. Although I'm more willing to see React as
| an evolving research project, as contradictory as this may sound.
| WD-42 wrote:
| I've been bitten so many times with the app/page router
| thinking I was looking at docs for one but I was actually
| looking at them for the other. So annoying.
| logankeenan wrote:
| I really wish htmx would use fetch rather than xhr, and now it
| looks like that won't happen. Fetch is easier to proxy, so it
| would open up a lot more possibilities for backends, like ones
| running in browser or a native process. I had to hack together a
| xhr fetch proxy to make this happen.
|
| https://github.com/logankeenan/xhr-fetch-proxy
| recursivedoubts wrote:
| we've looked at doing it but unfortunately fetch() doesn't fire
| upload events which would make implementing some events
| triggered by htmx possible
|
| it's too bad the two APIs have overlapping but not contained
| functionality.
| logankeenan wrote:
| Are the upload events specifically used for files or for most
| server interactions. I haven't noticed any issues with my
| proxy yet...
| kmos17 wrote:
| Greatly appreciate this philosophy and what htmx brings to the
| table. It is very simple and quick to pick up, and the longterm
| stability and simplicity are major advantages for web
| development.
| jilles wrote:
| I've created a Django application using HTMX. Usually I'd jump to
| React or Vue. It was a great exercise and I can see where HTMX
| would be a great fit.
|
| 1. If you consider yourself a "backend developer" only and want
| to write the minimum amount of JS/TS.
|
| 2. If your application is simple. Yes you can do more complicated
| interactivity with oob swaps, but you end up with more complexity
| than you chose HTMX for.
|
| For my next projects, I will still use Django but with React/Vue
| for pieces that need interactivity. As an example in my HTMX app,
| I wanted to add a profile image uploader. Lots of great frontend
| libraries exist to resize / modify your image before even
| uploading it to your server.
|
| Finally, HTMX is just not testable the same way modern frontend
| libraries are. I've managed to write some decent tests using
| beautifulsoup, but it's night and day compared to vitest or jest.
| igortg wrote:
| IMHO one of the biggest advantages of using HTMX is not having
| to maintain three layers of test suites (backend, frontend,
| end-to-end). You just need to test that your endpoints return
| the right HTML piece. You don't need unit testing the frontend
| since you don't have that much logic there. Just rely on end-
| to-end tests as a complementary tool to check small pieces of
| logic on the HTMX code.
| The_Colonel wrote:
| That honestly sounds like a downside. Having to verify HTML
| as an output (in comparison to e.g. JSON) is brittle since it
| will often change just for presentation reasons. Having a
| clear and somewhat stable API (which is a boon for testing)
| is IMHO a strong reason for the SPA model.
| recursivedoubts wrote:
| htmx moves the data -> html transformation to the server
| side and thus should be more testable
| eddd-ddde wrote:
| Not really unstable since you generate it and there's no
| browser modifying it. However you'd still lack client
| functionality testing.
| seanwilson wrote:
| > Having to verify HTML as an output (in comparison to e.g.
| JSON) is brittle since it will often change just for
| presentation reasons.
|
| For HTML tests, if you target elements by their ARIA role,
| semantic tag, or by matching against the text/label/title
| the user would see, it should be robust to a lot of
| presentation changes. See Playwright locators for example:
|
| https://playwright.dev/docs/locators
|
| Not sure if this what was meant, but you can't just rely on
| only the JSON because you can't assume it's been properly
| transformed into the expected HTML.
| danpalmer wrote:
| I'm not sure I'd agree. The HX attributes encode a lot of
| functionality and you want to check that they do the right
| thing together. You can test you get the right attributes in
| a response, but that's only a proxy for the application doing
| the right thing, so you most likely still need the end to end
| tests.
|
| The problem is that end to end tests are the hardest kind to
| write. At least if you have a frontend code base you can have
| some tests there and get some confidence about things working
| at a lower level.
| seanwilson wrote:
| > You just need to test that your endpoints return the right
| HTML piece. You don't need unit testing the frontend since
| you don't have that much logic there.
|
| Only using the standard Django test client? I don't find this
| myself when I've had to work with HTMX code e.g. if you're
| using HTMX for your sign up form, it can be completely broken
| on the happy path and on form errors if the HTMX attributes
| are wrong, and the standard Django test client won't let you
| know, so you lose a lot of confidence when making
| refactors/changes.
| viraptor wrote:
| You don't have to write your own using beautifulsoup. There are
| test frameworks like https://www.cypress.io/ and
| https://playwright.dev/ that work great there.
| jilles wrote:
| With the BeautifulSoup tests I can run 1000s of tests in
| seconds. Cypress/Playwright are wonderful for e2e tests, but
| not comparable to simple unit tests you'd have in React/Vue.
| I find that the BeautifulSoup tests are a decent middle
| ground.
| luontola wrote:
| I've successfully used (for 3+ years in multiple projects)
| an approach similar to BeautifulSoup's get_text() function
| to assert the whole visible text of a component. You can
| implement it in other languages with a few regexes.
|
| One addition makes it an order of magnitude more versatile:
| a way to visualize non-textual information as text in the
| tests. For example add a data-test-icon attribute which
| contains the replacement text that should be shown in
| tests. Another method is to parse the HTML and write custom
| visualization for some elements, so that you get useful
| default visualization for at least form elements and such,
| without having to repeat the data-test-icon attribute every
| time.
|
| See https://martinfowler.com/articles/tdd-html-
| templates.html#Bo...
| azemetre wrote:
| Why is that a good thing when testing a web app? You want
| to see if the browser is executing your code with the
| correct intent.
|
| Seems very brittle and may not catch actual regressions
| browsers introduce.
| viraptor wrote:
| But with beautifulsoup you don't test the interactions at
| all. You only test the rendered template which is nice, but
| doesn't tell you if any button actually works the way you
| expect.
| x0x0 wrote:
| I'm all in on Hotwire, which is pretty similar.
|
| They're both fantastic expansions of what server-side rendering
| can do. They can't really do work as nice as what React can,
| but you can get perhaps 85% of React for 5-10% of the
| development time. And a big increase in usability of your app.
| eawgewag wrote:
| > 1. If you consider yourself a "backend developer" only and
| want to write the minimum amount of JS/TS.
|
| This is a great point and should be underscored more. I think
| generally the HTMX vs React/Vue/Svelte argument gets undercut
| when people don't express their innate bias on which part of
| the stack they want to give more control to. HTMX is great if
| you're pro-expanding the server; JS Frameworks if you're trying
| to expand it from the application layer.
| queenmab wrote:
| This was my exact experience - loved it as a backend developer
| wanting to build simple frontends with minimal JavaScript (and
| I still recommend it for many use cases) but when I then tried
| HTMX to build a more complex application I found that the
| complexity that would normally be handled by a JavaScript
| framework ultimately grew and shifted to the HTML and,
| surprisingly, the backend as well.
|
| For example, error handling in complex forms. When you have
| React handling errors you simply return a 400 JSON response
| with fields and reasons, or some other error message, and React
| decides what to do depending on the context, which it knows.
| When this responsibility is moved to the backend you now need
| to track the request location, state etc. and find the right
| fragment, which very quickly turned the code into a mess.
|
| I think the choice of backend is also important. I suspect that
| Java (Spring Boot) made using HTMX much less pleasant than it
| would have been with something else, especially when it comes
| to templates and routing. Using Java for HTML templates
| (Thymeleaf or any of the other popular libraries) is something
| I will never do again.
|
| Edit:
|
| The analogy with jQuery is interesting. I feel the same way
| about HTMX now as I did about jQuery ten years ago. I used to
| plug jQuery into every project even if it was just to select
| elements or whatever, but whenever I used jQuery entirely over
| the frameworks that were popular at the time (Ember, Angular) I
| ended up with way messier code.
| pier25 wrote:
| > _For my next projects, I will still use Django but with React
| /Vue for pieces that need interactivity_
|
| What's your plan for "plugging" these into your HTML? Web
| components?
|
| Does Django have some kind of integration with Vite for hot
| reload during dev?
| stevoski wrote:
| Love this.
|
| The attitude of the htmx developers is highly commendable.
| bravura wrote:
| "Today many web developers consider jQuery to be "legacy
| software." With all due respect to this perspective, jQuery is
| currently used on 75% of all public websites, a number that
| dwarfs all other JavaScript tools."
|
| This argument is that jQuery is still very popular compared to JS
| _frameworks_ like React, etc.
|
| What about vanilla JS?
|
| As someone who isn't that experienced with JS, my understanding
| is that modern vanilla JS is "about as good as" jQuery. i.e. if
| you don't need much JS these days, just choose vanilla JS.
| recursivedoubts wrote:
| That may or may not be the case (see
| https://youmightnotneedjquery.com/) but the fact remains that
| jQuery is used on 75% of all public websites.
| gjsman-1000 wrote:
| Notice how the "modern" is almost always more verbose than
| JQuery.
|
| JQuery might as well be a shorthand JS library.
| recursivedoubts wrote:
| it's a good API! and consistent!
| matharmin wrote:
| I view JQuery as similar to C in some ways: It's been
| around forever, it's mature, and it works. It gives a good
| experience to get something up and running quickly: it's
| lightweight and simple.
|
| But if you're working on bigger projects: It is possible,
| but have have to be very principled in how you use it,
| otherwise you're going to end up with either a massive
| spaghetti codebase and lots of edge cases in your app that
| breaks.
|
| Alternatives like React and Rust may add more complexity
| upfront, but the improved structure and safety it gives has
| big benefits in all but the smallest projects.
| peebeebee wrote:
| Not so sure about that. You can easily write horrible
| code in React: Too complex, inefficient, and/or resource-
| intensive. If you don't know the tools and have good
| theoretical programming knowledge, all code will be
| spaghetti code in the long run.
| klabb3 wrote:
| I'm no fan of React, but these aren't equivalent. If you
| follow the rules, react (or any of its alternatives) will
| manage stateful changes like adding and removing
| components and event listeners. JQuery is more similar to
| doing manual memory management in C. It's extremely easy
| to get it wrong and introduce leaks and other non-local
| errors.
| bdougherty wrote:
| React is also extremely easy to get it wrong.
| The_Colonel wrote:
| I don't disagree, but this is not relevant for the
| vanilla JS vs. jQuery discussion, since vanilla JS has
| exactly the same problems you mention as jQuery.
| Bengalilol wrote:
| Have a look at jQuery 'load' :
|
| <https://github.com/jquery/jquery/blob/main/src/ajax/load.j
| s>
|
| Then at the vanilla JS 'load' : const
| response = await fetch('/path/to/template.html');
| const body = await response.text();
| document.querySelector('#some.selector').innerHTML = body;
|
| IDK, all in all it is a proxy functions lib.
| ofrzeta wrote:
| That might be related to Wordpress including jQuery.
| The_Colonel wrote:
| That website is (inadverently) one of the most effective
| marketing campaigns for jQuery. Some of the vanilla JS
| examples are atrocious.
|
| What it doesn't show is that vanilla JS is not chainable
| (jQuery is).
| Bengalilol wrote:
| What do you mean ? let result = " hello
| jQuery " .trim() .replace("jQuery",
| "javascript") .toUpperCase();
| console.log(result);
|
| map, filter, ... let numbers = [1, 2, 3, 4,
| 5]; let result = numbers .filter(num => num % 2
| === 0) .map(num => num * 2) .reduce((sum, num)
| => sum + num, 0); console.log(result); // 12
|
| Simple string let myStr = "This is a
| wonderful day."; let reversed = myStr
| .split("") .reverse() .join("");
| console.log(reversed); // ".yad lufrednow a si sihT"
|
| DOM elements
| document.querySelector('#element')
| .classList.add('active') .classList.remove('hidden');
|
| Using a class class Chainable {
| constructor(value) { this.value = value;
| } add(num) { this.value += num;
| return this; // make it chainable }
| multiply(num) { this.value *= num;
| return this; } getValue() {
| return this.value; } } let result = new
| Chainable(5) .add(3) .multiply(2)
| .getValue(); console.log(result); // 16
| Klonoar wrote:
| It's functionally as good as jQuery.
|
| However to this day I still find jQuery to be one of the nicest
| APIs to ever be used on the frontend stack. It is legitimately
| just more pleasant to write.
|
| (Yes yes I am more than aware of how to shim a lot of it for
| vanilla JS)
| Bengalilol wrote:
| "What about vanilla JS?"
|
| Vanilla JS, as an experienced dev, is the best thing for now.
| You can write your proxy functions, and globally you get the
| control over every little thing.
| kweingar wrote:
| I'd love to use HTMX at work. Sadly the security folks would
| probably balk at checking in JS code that uses eval(), even
| though you can disable eval at runtime in the HTMX config.
|
| I thought about writing a script to remove all references to eval
| (and all tests relying on eval), but at that point it would
| probably be easier to just rewrite the library.
| recursivedoubts wrote:
| eval can be disabled at the CSP level, which is much better
| than at the source level (which can always be obfuscated,
| missed in a version update, etc)
| viraptor wrote:
| It can be, but then you discover how marketing added lots of
| gtag and other content which is already full of eval ;)
| recursivedoubts wrote:
| oof
| jmull wrote:
| > ...you can use as much or as little of it as you like...
| Stability as a Feature... No New Features as a Feature...
|
| This is the way.
|
| Having lived the alternative, I won't consider building anything
| significant on top of an abstraction that doesn't credibly
| promise these.
|
| When the abstraction you've built on changes or fails, the thing
| you built breaks. When you choose an unstable abstraction, you're
| creating future bugs you'll have to spend future time on to
| resolve (and if it wraps the lower layer rather than sitting
| beside it, you have fewer options to fix them).
|
| These aren't concerns for things that will be short-lived, or are
| small enough to replace if needed. But I've seen plenty of small
| and temporary things turn into large and permanent things when
| they end up being useful.
| game_the0ry wrote:
| > ...you can use as much or as little of it as you like...
| Stability as a Feature... No New Features as a Feature...
|
| Given my experience with node ecosystem, react, and nextjs, I
| am inclined to agree.
| jmull wrote:
| I agree about react and nextjs.
|
| But the node ecosystem includes essentially everything that
| touches on javascript, both the bad and the good.
|
| I don't think there are very many ecosystems that are
| guaranteed to have only good stuff. Regardless of ecosystem,
| the developer has to examine what is available and make wise
| choices.
| klabb3 wrote:
| I think the culture is so prevalent that I have to defend
| parent's statement. Node itself, and npm which is a node
| project, are some of the worst offenders. It's had abysmal
| stewardship imo, and one could argue this sets the tone for
| the ecosystem at large. Hack upon hack, config files of
| doom.
|
| There are exceptions, but at this point the verdict is
| clear. It's like the meme about Java being enterprisey and
| over-abstracted with factories. As far as stereotypes go,
| it's true. (Or was, haven't used it in forever)
|
| I'm not even against JS, and much less the web. I think
| it's the 7th wonder of the world. But the developer
| practices makes me want to tear my hair off.
| diggan wrote:
| There is a great way to combat this, use libraries you've
| reviewed to have proper design and implementation, then
| ignore the rest. People rely on libraries for the
| stupidiest shit, and also are really afraid to go against
| the current flow. If you're not doing
| TypeScript/VueJS/$POPULAR_THING you don't know anything
| about JS and you're a dumb developers, which of course is
| very wrong. And stop listening to recommendations from
| lifestyle developer streamers who most likely got paid to
| recommend whatever they're babbling about.
| jmull wrote:
| > the verdict is clear
|
| Not to me.
|
| I know there's plenty of junk, but if you opt out of the
| node ecosystem in its entirety, you're essentially opting
| out of most of javascript development as well, which is a
| substantial part of web development.
|
| That's your choice, but you're missing out on a lot of
| good and useful things... just in terms of software
| development but also in terms of meeting whatever your
| business needs are (if you're trying to make money).
|
| Javascript static analysis tools can be very useful (like
| TS and eslint). app frameworks can provide routing, UI
| frameworks, UI controls, validation libraries, etc. that
| you would otherwise have to implement on your own.
|
| These are all part of the node ecosystem. htmx is part of
| the node ecosystem. IDK, lumping it all together doesn't
| make sense to me because there's a lot lost and little
| gained.
| lakomen wrote:
| Nextjs is a nightmare. React is pretty good nowadays imo.
| citizenpaul wrote:
| >But I've seen plenty of small and temporary things turn into
| large and permanent things when they end up being useful.
|
| My experience is that probably more than 9/10 temp projects end
| up forever projects. My goal is never to work anywhere again
| that insists on just get it done quick and dirty "its
| temporary" ever again.
| ryanmcbride wrote:
| I don't remember where I stole it from but at work any time
| we're discussing something temporary I like to drop in a
| "remember there's nothing more permanent than a temporary
| fix" and it usually gives us at least a few more minutes of
| considering things carefully before pulling the trigger.
| Makes me feel better anyway.
| sethammons wrote:
| I have a wood block wedged between my car's battery and
| battery mount because the new battery was smaller and I
| couldn't get the mount to adjust down. I cringe whenever I
| get the oil done but I don't fix it because it is good
| enough. I do feel dirty about it and every other weekend I
| think, "I should install a proper sized mount." But the
| battery doesn't wiggle. It works. It is a temp fix that has
| been there half a year. Code is even less visible to most,
| so even more out of sight and out of mind.
| fermigier wrote:
| Good. For a couple of seconds, I feared something like "The next
| step of our wonderful journey...".
| baobabKoodaa wrote:
| The creator of HTMX likes to periodically troll people on
| Twitter like this.
| uludag wrote:
| > No New Features as a Feature
|
| No new features is such an underrated feature. It's funny
| sometimes when people see some Common Lisp or Clojure library
| with no commits in the last X period of time, and people
| immediately come to the conclusion that something must be wrong.
|
| In the world of AI tooling, "completed" should have a huge
| advantage over libraries with lots of churn. Maybe a positive
| side-effect of new AI tooling is that there will be competitive
| pressure for libraries to reach a completed, no-new-features
| state.
| buryat wrote:
| This is just people's subconsciousness fighting against the
| rolling progress. It's trying to avoid learning new things and
| trying to preserve the status quo where you can keep rolling
| using the already acquired knowledge. It's anti-thetical to being
| a hacker.
|
| The modern way is to use LLMs to auto generate all this code and
| do some small corrections in the process. So you wouldn't have to
| worry about the underlying tech and would only be concerned about
| the core functionality and actual mechanics of the product rather
| than being interested and spending efforts on memorization of the
| specific instructions for the machine. The whole evolution of the
| programming languages is a process in that direction and new
| technologies that were embraced by the newer generation like
| React and Vue.js is the way to go. You can't run geosites
| forever.
| lemonwaterlime wrote:
| The philosophy of a tool like htmx encourages the opposite of
| "avoiding learning new things". The reality is that there is
| not often anything that is truly novel. We waste time by
| failing to recognize patterns and abstractions that persist
| over long periods of time and in many cases that are even
| foundational knowledge.
|
| A foundational fact by definition does not need to be
| constantly scrutinized as if it were not. Rather it is
| something that can be relied upon stably until such a time that
| a change in a core assumption forces us to reevaluate the
| foundation if and when that scenario occurs.
| peebeebee wrote:
| It's about using the right tools for the job. FAANG and
| developer advocates made the web needlessly complex for most
| people. The over-engineered tools and frameworks became the
| "default" way of programming for the web, loosing some strong
| key features that were good about it: simplicity, transparency,
| and speed.
| brushfoot wrote:
| > It's trying to avoid learning new things and trying to
| preserve the status quo
|
| Well, yeah. Sometimes the status quo is good. Sometimes you
| don't want to learn how to do simple async page updates for the
| thousandth time.
|
| Because many of us here have been there, done that. Over dozens
| of years. With dozens of libraries.
|
| It's a hamster wheel. It's boring. It's pointless.
|
| In the end, if your website/app does what HTMX is good at, just
| use it.
|
| I learn dozens of new things every day as a solopreneur SaaS
| guy. I don't want to relearn how to make async page updates
| ever again, unless there is a very, very compelling reason to
| do so.
| JodieBenitez wrote:
| > The modern way is to use LLMs to auto generate all this code
| and do some small corrections in the process.
|
| it sounds a lot like correcting the work of a junior developer
| and it's definitely _not_ what I want to do for a living.
|
| > new technologies that were embraced by the newer generation
| like React and Vue.js is the way to go.
|
| IMO, anything that requires a build step to the browser runtime
| is at best a temporary solution waiting for a web standard and
| at worst a regression.
| lemonwaterlime wrote:
| I am a fan of this approach. About to launch a SaaS now and htmx
| powers much of the interaction so far.
|
| Tools like htmx make it easier for solo founders and small teams
| who don't have the bandwidth or the desire to manage all the
| churn. Keep the dependencies tight and ship!
| ksec wrote:
| >In particular, we are trying to push the ideas of htmx into the
| HTML standard itself, via the Triptych project. In an ideal
| world, htmx functionality disappears into the web platform
| itself.
|
| I have been calling for this for a very long time even during
| pjax era. I hope that is not only an ideal but a realistic
| pathway forward. Chrome / Blink or Safari / Webkit. If we could
| just get one of them to implement it as experimental feature. How
| could we push this forward?
|
| JPEG XL and HTMX in HTML, along with some sort of basic rich text
| editor for everyday writing is what I want browser to be included
| by default.
| recursivedoubts wrote:
| you can support and publicize the triptych project:
|
| https://alexanderpetros.com/triptych/
|
| https://github.com/alexpetros/triptych?tab=readme-ov-file
| AbraKdabra wrote:
| I've been a Vue user for years, I do automations and glue code
| mostly, and most of the times using Vue is a bit too much, for my
| last project I used https://github.com/guyroyse/htmx-tailwind-
| vite and been delighted about it, it's exactly what I need.
| BrenBarn wrote:
| People are commenting about "no new features as a feature", and I
| agree, but even better is this:
|
| > People shouldn't feel pressure to upgrade htmx over time unless
| there are specific bugs that they want fixed
|
| Frickin A! Nice to see somebody pushing back against the trend of
| "if you haven't updated your software in the last five minutes
| you're on an unsupported configuration".
| ofrzeta wrote:
| So if you have a project that uses a (even small) number of
| libraries, how to you keep track of being affected of some
| specific bug of some library?
| itishappy wrote:
| You submit a bug report and (assumedly) get a fast response
| because they explicitly prioritize fixing bugs over adding
| new features.
| ofrzeta wrote:
| I guess in most cases you will be affected by bugs that you
| did not notice let alone report.
| itishappy wrote:
| More reason to prefer a more deliberate release cycle!
| Focusing on security and stability restricts the area
| available to bugs significantly more than chasing hot new
| features all the time.
| ploxiln wrote:
| A) New library versions are roughly as likely to introduce
| new bugs, as they are likely to fix old bugs. (If not, why
| are there still so many updates, you should be running out of
| bugs ...)
|
| B) If you run into a bug, update that library, then look into
| fixing it and offering a PR with the fix. Easy-peasy.
|
| Compared to: oh this is a bug in a library that's fixed in an
| update ... but then we need to update another library it
| depends on, but that requires an update to nodejs, but that
| requires us to update some other libraries, which introduce a
| new more serious regression, so we can't unless we re-write
| to remove that dependency ...
| abirch wrote:
| The classical joke:
|
| Why programmers like cooking: You peel the carrot, you chop the
| carrot, you put the carrot in the stew. You don't suddenly find
| out that your peeler is several versions behind and they
| dropped support for carrots in 4.3
| simonw wrote:
| Anyone got a good feel for the htmx accessibility story at the
| moment?
|
| I'm interested in using it more, but I want to be 100% confident
| that I understand how to get htmx sites to work well with screen
| readers. I worry about things like fetching new data into a page
| not altering the screen reader user in the same way as refreshing
| a page completely would.
|
| I'm not interested in whether or not htmx uses the correct ARIA
| attributes - I want to be confident that those ARIA attributes
| (or similar) do the right thing.
|
| My ideal is still to use JavaScript libraries where the
| documentation not only describes how they work with screen
| readers, but is accompanied by video evidence showing the
| experience a screen reader user gets for different problems
| solved by that library.
| 1propionyl wrote:
| Handling ARIA attributes is out of scope for HTMX. It is your
| responsibility to include ARIA attributes on the HTML you
| return and swap/transclude.
|
| As for handling dynamic content for screen readers, focus
| management is already a thing, and is in the scope of browser
| standards and the HTML your backend returns. As before, it's
| your responsibility to manage this. HTMX will neither help you
| nor get in your way.
|
| HTMX merely extends hypertext functionality to its (mostly)
| natural conclusion. It is not a component library, or a
| framework for building components, or a site building
| framework, or...
|
| You can use other tools to enhance and audit accessibility, but
| their use is orthogonal to HTMX. I think web developers in
| general are very used to frameworks abstracting a ton of
| complexity, but HTMX is not a framework so much as a
| standardized set of tools for specific low level problems, it
| is not a one stop shop.
| simonw wrote:
| In that case it would be great if the HTMX documentation
| included worked examples and guidance for how to do this.
|
| Leaving accessibility up to the end developer feels like a
| genuine missed opportunity for me here. One of the great
| things about NOT using a JavaScript library is that you can
| rely on the browser's default accessibility features for
| forms and links. Those benefits are the thing I care most
| about when considering HTMX or jQuery or React or Vue or
| similar.
| 1propionyl wrote:
| > In that case it would be great if the HTMX documentation
| included worked examples and guidance for how to do this.
|
| You can refer to the WAI-ARIA standards.
|
| > Leaving accessibility up the end developer feels like a
| genuine missed opportunity.
|
| This doesn't compute for me. What would HTMX even provide?
| It's a set of attributes that extend the behavior of form
| submission to other elements and all request methods.
|
| > HTMX or jQuery or React/Vue
|
| These aren't the same kinds of tools. They address
| fundamentally different things. Handling ARIA automatically
| for you isn't in scope for any of them.
| simonw wrote:
| Referring to the ARIA standards doesn't help me answer
| the more important question: will what I'm doing work in
| screen readers or not?
|
| I feel completely starved of information here. I care
| about accessibility. I want to build a web page where
| clicking on a tab refreshes a subset of that page... and
| I still can't find a really good guide on how to do that
| in a way that works in screen readers, that's accompanied
| by a video (ideally multiple videos, one for each common
| screen reader) showing the experience I can expect my
| users to have from that pattern.
|
| HTMX actively encourages that pattern, so I'd love to see
| the project also embrace helping developers do The Right
| Thing with regards to the accessibility of that pattern.
| ossobuco wrote:
| > will what I'm doing work in screen readers or not?
|
| Why not try it? But also, why wouldn't it?
| robin_reala wrote:
| Pointing at the ARIA spec as a way of writing code
| that'll work with all assistive tech is like pointing at
| the HTML and CSS specs circa 2005 and saying that
| following them will make your site work in all browsers.
| xg15 wrote:
| Try in which screen reader?
| 1propionyl wrote:
| > I feel completely starved of information here. I care
| about accessibility. I want to build a web page where
| clicking on a tab refreshes a subset of that page... and
| I still can't find a really good guide on how to do that
| in a way that works in screen readers, that's accompanied
| by a video (ideally multiple videos, one for each common
| screen reader) showing the experience I can expect my
| users to have from that pattern.
|
| I completely agree that this is a pain point. In general,
| high quality documentation is lacking. I am not however
| convinced that this is a problem that can be automated
| and abstracted away. Neither am I convinced that it's one
| we should necessarily try to hide. It won't win me any
| favors but I think the issue here is simply an endemic
| skill and knowledge gap. Shifts in culture via higher
| educational curricula and stated quality attribute
| priorities within companies will do more good here than
| anything else.
|
| Accessibility is a quality that needs to be built in from
| the start. The good news is that provided your HTML is
| sane and not a mess of class tagged DIVs, or you're
| building a pretty straightforward document-like
| navigation/content/etc site, you really only need to
| declare attributes to handle the places you do something
| unusual. The defaults are generally correct.
|
| Much of this "unusual" behavior that needs special
| treatment is within custom components (e.g. a custom date
| selector widget with plenty of invisible divs used for
| layout of the calendar days can be inscrutable to a
| screen reader without hinting) and is the responsibility
| of component library or framework producers. Some issues
| here run deeper, like properly correlating ARIA
| attributes in shadow and light DOM. But that being the
| case, such component libraries aren't even necessarily
| suitable for many sites (either too complex, or make too
| many mismatching assumptions).
|
| The bulk of the remaining accessibility attribute
| slinging that needs to happen has to do with the overall
| site layout (especially reactive layouts). I don't know
| of any framework that will handle this for you in a
| satisfying way for anything sufficiently sui generis. I
| think the tough but true answer here is "the people
| building the site should have at least skimmed the WAI-
| ARIA standard, and be using an auditing tool, and know
| what to be thinking about as they design the site from
| the start".
| nindalf wrote:
| Everyone needs to read this spec and then live and
| breathe its tenets ... sure. This reminds me of the time
| when we fixed the footguns with C by making everyone into
| better developers.
|
| That guy is asking you if replacing a part of the html
| with some other html alerts screen readers to the change.
|
| It's a reasonable question and you could share what you
| know about how screen readers react when this replacement
| happens. You could write some documentation on how to
| alert them, some best practices to follow.
|
| Instead you say read the fucking manual, as if that
| helps. You put on a veneer of caring for accessibility
| but it seems you care about the "purity" of htmx more.
| throwitaway1123 wrote:
| Agreed.
|
| Frontend frameworks often do spend a lot of time thinking
| about the accessibility concerns associated with client
| side routing, so it's not absurd to consider this
| question in scope for a frontend library that handles DOM
| updates.
|
| See for instance this 2019 study by Gatsby:
| https://www.gatsbyjs.com/blog/2019-07-11-user-testing-
| access...
|
| Or even the modern Next docs on route announcements:
| https://nextjs.org/docs/architecture/accessibility#route-
| ann...
|
| Some of this will have to be bespoke work done on a per-
| site basis, but I'm not sure I'm comfortable with the
| idea of completely punting this responsibility to
| developers using htmx, even if it does make philosophical
| sense to say "this is scope creep", because ultimately
| users with disabilities will end up being the ones
| sacrificed on this altar of ideological purity.
| simonw wrote:
| "It won't win me any favors but I think the issue here is
| simply an endemic skill and knowledge gap."
|
| My problem with that is that, as you can hopefully see, I
| am _very_ motivated to learn how to do this... and yet I
| have not managed to learn it.
|
| "Learn how to do it" only works if there are clear and
| obvious resources we can point people to that will help
| them learn what the need to learn. The ARIA spec is not
| that.
|
| This also feels like an inherently solvable problem,
| which is why I always take any opportunity to put it in
| front of people that might feel incentivized to help
| solve it.
| omnimus wrote:
| I think what they are trying to say is that it has very
| little to do with htmx or react of whatever framework.
| None of it can handle accessibility automagically. Its
| like asking if it can write html for you - its different
| problem and a skill. But skills in accessibility apply to
| all frameworks.
| skrebbel wrote:
| > > In that case it would be great if the HTMX
| documentation included worked examples and guidance for
| how to do this.
|
| > You can refer to the WAI-ARIA standards.
|
| Every time someone asks for concrete a11y advice for
| concrete situations, some joker refers them to WAI-ARIA.
| This is ridiculous! That document is extremely hard to
| parse, and it offers absolutely no guidance wrt which
| parts matter the most, or, say, how the various _real_
| screen readers used in the wild behave. Please stop doing
| this. Accessibility is hard to get right! Making people
| feel like they 're idiots for trying is very unhelpful.
| agumonkey wrote:
| This makes me think that we all need this tutorial to get
| rapidly on par and ready to read the whole spec
| gadflyinyoureye wrote:
| I'm not in a good place to check but what the various AI
| tools recommend?
| lelandfe wrote:
| And then you get to WAI-ARIA's practical examples and
| they have a yellow warning intoning "not intended for
| production environments" and there "may be support gaps"
| in assistive technology: https://www.w3.org/WAI/ARIA/apg/
| patterns/combobox/examples/c...
|
| I think everyone's afraid of getting sued.
| yawaramin wrote:
| > it would be great if the HTMX documentation included
| worked examples and guidance for how to do this.
|
| The htmx documentation does include examples with
| accessibility guidance. Eg https://htmx.org/examples/bulk-
| update/
|
| > The server will bulk-update the statuses based on the
| values of the checkboxes. We respond with a small toast
| message about the update to inform the user, and use ARIA
| to politely announce the update for accessibility.
|
| If you check the Server Requests panel it also shows the
| responses and the ARIA attribute they include.
|
| EDIT: I've submitted a PR to fix the notification toast
| announcement, with this the screen reader announces the
| notification correctly:
| https://github.com/bigskysoftware/htmx/pull/3112
|
| The key is to mark all live regions statically _before_
| doing any htmx requests, then injecting the response HTML
| _inside_ those regions. Then they are announced by the
| screen reader. This is nothing special to htmx of course;
| every app needs to work the same way.
| nodamage wrote:
| > I worry about things like fetching new data into a page not
| altering the screen reader user in the same way as refreshing a
| page completely would.
|
| Isn't this more of a general browser question that would apply
| to any website that uses Javascript to load page elements?
|
| How would using HTMX (as opposed to any other library, or plain
| old Javascript) affect the answer to the question?
| simonw wrote:
| Yeah, any website that uses JavaScript to load page elements
| needs to solve this. My hope is that a library like HTMX can
| help reduce the friction in implementing the best possible
| patterns for doing so.
| ThibWeb wrote:
| See the proposed moveBefore API [1] which is meant to solve
| those issues at the platform level. In the meantime, htmx
| has their morphdom extension, which I'd say is a must when
| replacing any page content with interactive elements
| within. Aside from that one major gotcha, the main issues
| with htmx are the poor accessibility of the examples in the
| docs [2]. In particular seeing so much ARIA without the
| corresponding keyboard support.
|
| [1] https://htmx.org/examples/move-before/ [2]
| https://github.com/bigskysoftware/htmx/issues/1431
| alexpetros wrote:
| Hey Simon, maintainer + article co-author here.
|
| tl;dr htmx is better than a lot of alternatives, but Simon is
| right, it can improve this story and it has a responsibility to
| do so.
|
| As a framing device: any interactivity that is not described
| with HTML is interactivity that someone is responsible for
| making accessible (which you correctly pointed out). Unlike JS
| frameworks, htmx encourages the developer to solve problems
| with HTML first, so the inaccessible surface area that the
| developer has to worry about is going to be much smaller on
| htmx-based applications than it is with JS-based applications.
| That's a pretty strict win from where a lot of the industry is
| right now.
|
| That having been said, I agree with you (and disagree with a
| lot of our defenders in the comments) that thinking about this
| is in-scope for htmx. In fact, I'm a firm believer that
| libraries are exactly where responsibility for implementing
| ARIA attributes live. The average web developer should not have
| to think about this at all--they should be able to use
| declarative abstractions and trust that they are annotated
| correctly for screen readers. This is the only system that
| scales, and htmx should adhere to it as much as possible.
|
| Ideally, htmx would just add the polite notification attribute
| to the elements it processes, and give an easy way to customize
| that. I think it's basically possible to do this in a
| backwards-compatible way (first as an extension) that aligns
| with the maintenance strategy outlined in this essay. And I do
| think we can improve the documentation as well.
| liendolucas wrote:
| I'm huge a supporter of the HTMX philosophy. I highly recommend
| reading Hypermedia Systems especially for people that are just
| beginning doing web development. I've purchased the book and it
| was a wonderful read especially for its explanations and
| pragmatism.
| rglover wrote:
| If you like this approach but want a full-stack JS solution,
| check out Joystick [1] (the philosophy [2] page echoes a lot of
| the same sentiments here).
|
| [1] https://cheatcode.co/joystick
|
| [2] https://docs.cheatcode.co/joystick/philosophy
| chimen wrote:
| i love frontends like shadcn/ui too much to go away from react -
| AS MUCH as I'd love to do it since I hate npm cancer to death
| drdaeman wrote:
| Htmx always sounded nice and I always wanted to give it a try -
| yet, paradoxically, I always had my reservations about it on the
| conceptual level.
|
| With something like Elm, I'm basically thinking of the frontend
| as a state machine (composed of smaller state machines). I always
| know what's [supposed to be] going on exactly, and assuming that
| all the underlying machinery is working as expected and that I
| haven't messed up anywhere, I can be sure that everything is
| consistent. Basically, things are data-driven.
|
| Htmx feels like a step back in this regard. Let's say
| https://htmx.org/examples/delete-row/ - something back in my mind
| yells at me that I don't really know what I'm presenting in that
| table. The state is in DOM, all "inverted" as the frontend is not
| really aware what it's displaying (it can figure it out by
| introspecting the DOM, but that's exactly what feels off). I'm
| just concerned that it'll end up like my ancient Delphi or Visual
| Basic projects, where it was impossible to understand what's
| going on, because everything got tangled up in a ball. This is
| opposite of data-driven approach that I don't really know a name
| for... "shape-driven"?
|
| I look at examples like https://htmx.org/examples/sortable/ and I
| just can't shrug off the feeling that with such design the
| frontend has no idea about what's going on, and while it's fine
| if all I ever need is a small sorted list (that I can pull back
| from DOM - which acts like a weird pseudo-database), if it grows
| it becomes error-prone, difficult to comprehend and maintain.
|
| I suspect this is because HTML was always about documents, and
| never about interactive applications, so there's this fundamental
| impedance mismatch when one tries to build an application in a
| browser. I thought the solution was to build a new abstraction
| replacing HTML - with things like React being intermediate steps,
| still using HTML/CSS for rendering, and canvas-based GUIs being
| the way to go, unburdened by the document-based foundations
| anymore. In other words, I'm not really convinced that Hypermedia
| is a suitable foundation for a lot of the things people actually
| build online.
|
| Htmx surely has appeal in simplicity, but doesn't this simplicity
| brings back all the complexity people tried to get rid of all
| this time? Is there something I'm missing? Should I possibly
| think of the frontend as a terminal-like system that can run
| small programs but is not an application so it's never aware of
| what's going on? Or is it something else?
|
| My apologies for the confusion, or if I wrote something weird (I
| sure babbled a lot). I'm just trying to keep up with the world
| and understand it.
|
| (And, of course, no doubt, one can write crappy incomprehensible
| mess of a codebase using any technology. Maybe all my issues is
| that I have no idea how to write good Htmx code that wouldn't
| bloat and rot over time?)
| pragma_x wrote:
| > Should I possibly think of the frontend as a terminal-like
| system that can run small programs but is not an application so
| it's never aware of what's going on?
|
| Kinda? Where HTMX sits in my head is on a different
| evolutionary path starting from server rendered pages back in
| the 1990's. Instead of doing full page renders, HTMX lets us
| update discrete portions of the DOM from server rendered
| content... and that's all. It's like heavy client JS apps never
| existed. IMO, the key here is that the browser is assumed to be
| mostly just for display, and the backend is still expected to
| be inside the user interaction loop.
|
| The last time I tried to do anything with HTMX, the technology
| practically resisted any attempt to add any substantial state
| management on the client-side (which is kinda/sorta by design).
| As you mention, complex controls that do this like fully-
| featured tables, are a poor fit. It's possible, but not elegant
| or easy. Meanwhile, fetching an updated fragment from the
| server to do those kinds of jobs on user input, is trivial.
| It's super inefficient for bandwith, but way easier to code and
| maintain (IMO). To me, that's the core tradeoff here.
| mtrovo wrote:
| It is clear that htmx has a growing community, but it still feels
| a bit too backend-minded to convince frontend developers to adopt
| it. I tried it in a prototype, and it was quite pleasant until I
| realised I needed to account for additional state management and
| backend wrangling to be able to provide some dynamic features.
| That was the moment I realised htmx is not a fully fledged
| product but rather a core feature that sits neatly atop a
| traditional server-driven setup.
|
| That's why I think their roadmap looks right. I believe the way
| to broader adoption is to improve tooling, encourage
| standardisation, and integrate htmx more closely with well-known
| frameworks. That's the only way I can see dev teams buying into
| the paradigm change and htmx jumping into mainstream usage.
| rednafi wrote:
| The idea is to have fat backends and dumb clients. It's
| definitely a different way of building things and not
| everyone's cup of tea. For me, the biggest selling point is
| getting to write less JS.
|
| Writing the bulk of the logic in Go, Python, Kotlin, Rust, or
| Zig is a huge plus, as I consider them better-designed
| languages with easier maintainability.
| danpalmer wrote:
| I've just completed a port from HTMX to Hotwire (Stimulus,
| Turbo). HTMX is a great idea, but in my experience it's a poor
| execution.
|
| It's really quite buggy, in my experience it plays poorly with
| fundamental web and browser features (relative links are broken
| in at least 2 ways, I fixed a third way). One of the events just
| stopped working at all in the most recent release. The docs are
| lacking. And where it promises to let you write less JS, if you
| ever do need to write some JS you're on your own in structuring
| that, and you'll be fighting against HTMX (who gets to update the
| DOM, maintaining event handlers, etc).
|
| As a (brief) contributor to HTMX, I also feel like these issues
| were all inevitable. It's a single 5k line file with 190 top
| level functions in it meaning it's pretty impenetrable to get up
| to speed on. When proposing a bug fix the maintainers weren't
| sure if it would have other consequences. Tests didn't cover the
| functionality. I've been mostly a backend engineer in my career,
| and I empathise with not wanting the complexity of a modern
| frontend, but that doesn't mean we can't have some basic
| organisation of the code to make it approachable and more obvious
| whether changes will work or not.
|
| After porting to Turbo and Stimulus I have a more reliable code
| base, I have significantly less JavaScript, and I have a JS code
| base that much easier to reason about. I really wanted to like
| HTMX but the execution is not there. A focus on stability is a
| great fit for the project, but it's most certainly not there yet
| and has quite a way to go in my experience.
| mring33621 wrote:
| Last time i tried it, i couldn't get hotwire to work with a
| non-ruby backend.
|
| HTMX had no issue, tho
| danpalmer wrote:
| It's definitely documented as Rails first, but so far I've
| had no compatibility issues using it with my Swift backend.
| mring33621 wrote:
| no doubt there was something small that i was missing, but
| i was doing a rapid, time-boxed experiment and didn't have
| time to get deeper into it, at the time
| srameshc wrote:
| I have had a great experience with Astro and HTMX. When the
| first time I tried, I didn't think much about HTMX and thought
| it was an Astro thing, about a year or over. But this time, I
| had a great experience and I understand the power of htmx and
| native web only JS, no framework when building simple sites is
| much refreshing.
| alexpetros wrote:
| Hey Dan, htmx maintainer here.
|
| I would love to know in what other two ways relative links are
| broken, and which event stopped working, so we can get those
| fixed. With respect to the fix you PRed (thank you, by the
| way), we did get that merged very quickly, and would love to do
| the same for whatever is broken here, even (especially) if you
| are no longer interested in doing the fix yourself. [0]
|
| As for the DX of making changes to htmx: absolutely true! The
| single file is a DX we've chosen, and it has both costs and
| benefits, which we've written about in "Why htmx doesn't have a
| build step". [1]
|
| [0] https://github.com/bigskysoftware/htmx/pull/1960
|
| [1] https://htmx.org/essays/no-build-step/
| everybodyknows wrote:
| Maybe I'm missing something here, but JS modules do not
| require a build step.
|
| * Note to non-JS hackers: JS module symbol scope is per-
| source file.
| recursivedoubts wrote:
| JS modules can't be imported with a plain script tag.
| seanwilson wrote:
| Anybody have any thoughts on if the View Transition API is going
| to replace a lot of HTMX usage?
|
| This multi-page demo is decent, where each click is actually
| loading a new page: https://view-transitions.chrome.dev/stack-
| navigator/mpa-prer...
|
| https://developer.chrome.com/docs/web-platform/view-transiti...
|
| > The View Transition API gives you the power to create seamless
| visual transitions between different views on your website. This
| creates a more visually engaging user experience for users as
| they navigate your site, regardless of whether it's built as a
| multi-page application (MPA) or a single-page application (SPA).
| Typical situations where you would use view transitions include:
|
| > A thumbnail image on a product listing page that transitions
| into a full-size product image on the product detail page.
|
| > A fixed navigation bar that stays in place as you navigate from
| one page to another.
|
| > A grid with items moving positions as you filter through.
|
| So this would cover a few uses of HTMX?
|
| Recent Safari and Chrome now have decent support. Sounds like
| Firefox are working on it but I couldn't find an expected release
| date.
| recursivedoubts wrote:
| i think the transition API, when it is broadly available for
| MPAs, could replace a fair number of simple UI use cases of
| htmx. The main feature it would likely obsolete is the `hx-
| boost` feature:
|
| https://htmx.org/attributes/hx-boost/
|
| There are already people, including people on the core htmx
| team, who think that hx-boost isn't a great feature:
|
| https://htmx.org/quirks/#some-people-don-t-like-hx-boost
|
| If that goes away, htmx will be useful for smaller
| transclusional features at a lower level of complexity, so the
| two should complement one another in my opinion.
| robertoandred wrote:
| I've found Htmx to be smug and misleading. "Look how simple it
| is! No JavaScript! Ignore the fact that you need a complex
| backend in a separate language and environment to generate your
| html."
| rednafi wrote:
| Separate language is fine for those of us willing to write
| anything but JS. As long as it means writing less JS, a
| separate backend isn't that big of a deal.
| WD-42 wrote:
| Why does it have to be a separate language? You can serve
| templates with javascript, thus it works just fine with HTMX. I
| think you have some fundamental misunderstanding.
| lakomen wrote:
| Overhyped, back to 20 years ago. No proper framework in any
| language. And no it's not the new jquery.
|
| You can't do real time time tickers. You can't call client side
| functions.
|
| It's hyped by entry level web devs, because they don't know any
| better. You get all the baggage with it, that you hoped to be rid
| of with the separation of data provider and client consumer.
| Session management, path parsing and matching, flash messages,
| complicated nested if else blocks. Argh. Search engines can crawl
| js nowadays.
|
| It's like going back to sysinit when you have systemd only worse.
| But HN never fails to hype bs tech
| rednafi wrote:
| I've heard this kind of pushback from k8s wranglers whenever a
| small-scale alternative is proposed. The big win here is
| writing less JS and more of a language that's better designed
| (aka not JS).
| recursivedoubts wrote:
| Really, back 30 years if you think about it.
| ijidak wrote:
| > No New Features as a Feature
|
| > We are going to be increasingly inclined to not accept new
| proposed features in the library core
|
| I deeply wish the C# team recognized the value of this.
| jakubmazanec wrote:
| > This means accepting and documenting the quirks of the current
| implementation.
|
| If you're planning no new features as a feature, why not first
| remove those quirks? Why keep them around?
|
| > People shouldn't feel pressure to upgrade htmx over time unless
| there are specific bugs that they want fixed
|
| Truly, there exists a middle path: you can make breaking changes
| and user still can upgrade at their own pace (using future flags,
| codemods, etc.), you don't have to refuse progress - it's just a
| "more" work for the creator.
| rsyring wrote:
| I have used and like HTMX. But I think Unpoly is more batteries
| included, in a good way:
|
| https://unpoly.com/
|
| It has more built-in functionality that most web applications are
| going to need.
| recursivedoubts wrote:
| Unpoly is a great library that I try to signal boost
| frequently:
|
| https://x.com/search?q=from%3Ahtmx_org%20unpoly&src=typed_qu...
|
| I interviewed the creator here:
|
| https://htmx.org/essays/interviews/henning-koch/
___________________________________________________________________
(page generated 2025-01-06 23:00 UTC)