13 ms·

Why Gumroad Didn't Choose Htmx

440 points by rmason 2y ago

binkethy 2y ago
Another false dichotomy is server rendered vs single page app, when the happy place is both. One builds a bundle to embed in a server rendered page, as distinct from other bundles served up with other distinct pages. Ones rollup file would have an array of build objects, input output params. The user doesn't have to wait an eternity to download a monolithic single page app bundle. One doesn't get brain damaged by trying to maintain a monolithic state in a giant monolithic blob of javascript, urls work again, routing is returned to the server, and you could use a different framework on each page if you want to, thats how little it matters at that point. Why is no one mentioning embedding a js bundle in an htmx rendered page?
ttfkam 2y ago
A shame the only two choices were Htmx and React.
CraigJPerry 2y ago
One quality of htmx that a nextjs solution won’t benefit from is stability. I have come back to an htmx project months later and been able to very quickly change a behaviour. My experience with nextjs was a few deps now had vulns (fair enough, I’m grateful for the npm tooling that informed me) which necessitated updates which were a bit distracting and felt like yak shaving when all I wanted to do was a simple change. Even when there aren’t vulns I find it a bit lazy not to take the opportunity to evergreen the dependencies for a bit longer but that does frequently cost unwanted time. One place where htmx feels underpowered is when you have multiple related states on a page - a table view with some summary metric fields across the top as a dashboard and some action items in a sidebar with labels exposing counts of actions. In htmx you can always resort to hxswap basically the entire view out rather than trying to surgically update each dependent target but at that point why am I using htmx, I can just round trip for a page refresh and skip the whole hassle of having a server side component strategy.
gwking 2y ago
As many others have mentioned, the comment about AI failing to cough up good answers is intriguing. But what has not been said is that this may also be evidence that the HTMX documentation needs improvement. In particular it needs (many) more examples. I have always been a reader of documentation for libraries that I use, and I have nearly always felt that docs could be better. Having tried to write docs myself, I know how hard (impossible?) it is to imagine not knowing how the thing you are documenting works. Recursivedoubts, please take this criticism as encouragement more than anything! I think HTMX is important both as a library and as a reality check against complexity. There is something unnerving about the HTMX docs to me: over and over again, I read them, and I think, "ok got it, sounds straightforward" but then it turns out there is something slightly tricky that is hard to diagnose. I don't quite know why. One thing that has gotten me a couple times is not being clear on whether an attribute is for the request or response. I feel kind of dumb admitting this but it has been harder than I'd have thought. My best suggestion would be to add a request/response column in the attributes reference listings. Debug mode validation of "hx-*" attributes would be very welcome. Early on I definitely mixed up hx-select-oob/hx-swap-oob and hx-include/hx-vals. I've also made mistakes with hx-indicator/htmx-indicator although that's a little different because one is a css class name. Another that got me recently was trying to set an hx-on: after-settle handler in the target element (client side) and having nothing happen, but then discovering that if I put it in the response it would work. This made no sense at the time. Now I'm wondering if it was because the hx-swap was set to something other than innerHTML. Anyway, I think the main point is that some of these things are sort of related in various subtle ways, and also sound similar, and are easy to mix up. As a new user, when I try to follow the directions and then apparently nothing happens, it is very hard to know how to proceed. Really the only way forward is to find a working example and try not to break it, or selectively break it to figure out how it works. I know docs are a lot of work, but in an ideal future there would be example links to click on for each one of the attributes. Perhaps I could help with that at some point. I've always thought that HTMX has amazing potential on the documentation front because one can build working examples that are served completely statically. In fact I can't think of a UI system that is more amenable to training an LLM. You would just need to write out the expected end-state of the HTML target. For context, I've been using HTMX as crucial component of a back office web app for two years now. It is mostly a custom scheduling calendar. Most of it is simple HTMX, but I've used OOB-swap and hx-on in places. I use it to do fast state changes without full page refreshes, and to implement a few multi-step forms that require back-and forth of valid form choices. Recently I built a modal control with different edit actions, etc. I don't think I would have taken on this client at all if it weren't for HTMX. So, thank you!
ram_rar 2y ago
Kudos to htmx for their refreshingly honest blog post! I hope many other open-source tools especially Databases can do similar things. >> while it’s important to consider lightweight alternatives, it’s equally crucial to choose technologies that can grow with your project and support your long-term vision A key takeaway that resonates with me is the importance of choosing technologies with growth potential and a thriving ecosystem – essentially making a long-term bet on their success. Too many devs get entangled with adopting shiny new things, while losing focus on delivering real value to customers.
emrah 2y ago
Htmx does not seem like a good fit to replace a thick-client type front-end framework and that's ok. It meant for that. It is more in line with 37Signal's "HotWired" approach (hotwired.dev)
smallerfish 2y ago
> For instance, implementing a drag-and-drop interface for our workflow builder proved to be a significant challenge with htmx, requiring workarounds that felt clunky compared to the smooth experience we could achieve with React libraries. HTMX is better if you have a frontend bundle that does just enough but no more. Hook into the htmx.onLoad event and then look for markup with attributes in the content being loaded (for example, columns, cards, tasks, etc) to attach to. You can then, for example, bind sortable.js onto the rendered markup, and then wire sortable events to state updates via HTMX. Really pretty straightforward. They even have an example of exactly this in the docs: https://htmx.org/docs/#3rd-party https://htmx.org/docs/#3rd-party
- gen220 2y ago
  Yeah, I've been using HTMX with UIKit components. Having a modern, stateful, and dynamic website is definitely not incompatible with HTMX.
zackerydev 2y ago
This is a wonderful advertisement for the things that HTMX is good for and the thing it isn't. It's obviously tongue-and-cheek but I think it makes the case well!
- tptacek 2y ago
  Why is this tongue-and-cheek? Doing this sincerely is a huge confidence builder.
- ensignavenger 2y ago
  What makes you think it was tongue-in-cheek? It sounds quite genuine to me?
  - nasretdinov 2y ago
    Perhaps because of pages like this one: https://htmx.org/essays/htmx-sucks/ https://htmx.org/essays/htmx-sucks/ (note the URL)
    - ensignavenger 2y ago
      Different authors and very different tones, but yeah, that essay was tongue-in-cheek, so I guess I could see why you might think that at first. I thought it might be, when I saw the title, but then I read it and realized quickly it was sincere.
- recursivedoubts 2y ago
  :) this isn't tongue-in-cheek it was a real experience the htmx sucks essay was definitely tongue-in-cheek though (although many of the criticisms were legitimate, and even agree with this one, such as the lack of a component ecosystem!)
bumbledraven 2y ago
Kudos to htmx.org for hosting this essay.
- dannyobrien 2y ago
  I really do value services/tools that explain why you shouldn't use it, as well as why you should.
- jamal-kumar 2y ago
  It's really humble and honest of them to put something like this up but in the end at least they have something to point to now if people pick it up and get mad that it doesn't meet their needs
  - recursivedoubts 2y ago
    we also have this essay to help people decide when htmx (or hypermedia more broadly) might be a good fit: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ and then this tongue in cheek essay (many of the criticisms are legitimate): https://htmx.org/essays/htmx-sucks/ https://htmx.org/essays/htmx-sucks/ We also have a mug for people who don't like htmx: https://swag.htmx.org/products/htmx-sucks-mug https://swag.htmx.org/products/htmx-sucks-mug
- svat 2y ago
  Yeah it's linked from https://htmx.org/essays/ https://htmx.org/essays/ under "On The Other Hand…"
- Ayesh 2y ago
  Yeah, I expected a bit of a rant or sarcastic post, but I'm genuinely happy it's a good post with good points. I use htmx in a couple of my projects and it's been great! Posts like these give me more confident about using htmx because they seldom show where they excel and where they fall short.
nasretdinov 2y ago
I like how they compare server-side validation with React's client-side (only?) one. Wasn't able to relate to other puns all that much unfortunately.
- rozap 2y ago
  Yea this piece is often left out and is kinda the most important. A single set of validation, on the server is required. There are tons of reasonable solutions with different tradeoffs for how you run that validation on the client. But two duplicate sets of validation or client only validation are two very, very dark paths.
nsonha 2y ago
Comparing it with React is a low bar, since a lot of people are unhappy with React. Arguments like "React is popular, AI knows it", or "React is popular, lots of component have been written in it" seem weak. A proper antithesis for htmlx should compares it with SPA.
- simonw 2y ago
  HTMX can be used as a tool for building SPAs, so I don't think it makes sense to compare it with SPA. What's an SPA if not a single web page where clicking on things causes that UI to update in-place in different ways?
  - nsonha 2y ago
    htmlx is what you would have on the front end when you do server rendering. Server has to do quite a bit, routing among other things. In SPA server just serves a single page and routing is all done in the client.
- mardifoufs 2y ago
  And a lot of people are happy with react. Not sure what your point is. I mean of course people using a more niche framework will usually be more happy about it, because early adopters usually choose to use the technology. Like, it's rare to come across htmx (or svelte, or solid) in a corporate job for now, which means that almost all of their users like said frameworks enough to use and talk about them in their free time For react that's just not the case, because it's everywhere. If I was forced to use Vue, I wouldn't like it. But I'm not so I don't use it enough to criticize it a lot. If anything I've seen more people dislike angular or vue when they had to work in a project that used those frameworks, and didn't have a say in that choice. But that's also just an anecdote obviously
  - nsonha 2y ago
    Hey I like React to, I'm actually complaining that often React is used as a scapegoat and and it would be a weak/not really on point criticism for htmlx. I mean people should understand that htmlx is bad because it's clunky, not because it's unpopular and there is no job.
croes 2y ago
[dupe] https://news.ycombinator.com/item?id=41727315 https://news.ycombinator.com/item?id=41727315
draw_down 2y ago
[dead]
nop_slide 2y ago
Gumroad dude seems to have some shaky reasoning for migrating at all, sounds to me a migration just for the sake of it. https://news.ycombinator.com/item?id=41669615 https://news.ycombinator.com/item?id=41669615
- mardifoufs 2y ago
  I mean, he clarified his reasoning and it made sense. Why do you think that moving away from RoR involves shaky reasoning here?
recursivedoubts 2y ago
My comment from the other thread: The CEO of gumroad mentioned on twitter that he had tried out htmx for a project but decided to go with NextJS instead. I asked him if he was willing to write up his experience and he graciously agreed to do so. I have been looking for a thoughtful negative experience with htmx to host on the htmx website and I am very thankful he was willing to put in the work to produce one.
- kunley 2y ago
  Very useful explanation, because at first it seemed unusual to see it on htmx.org, but well, different projects have different needs.
  - ensignavenger 2y ago
    HTMX has posted links to negative articles before, but I am not aware of any as thoughtful as this one. So it wasn't all that surprising for me that they would share this. That they went out of their way to solicit it is extraordinary, though!
- hencq 2y ago
  Your attitude to call out where htmx might not be the best solution, makes me respect the project even more. It's refreshing to see this compared to lots of other projects that always seem to claim to be the best solution for everything. I'm curious in particular about the call out around drag-and-drop. Is that something you agree with? Is drag and drop difficult with htmx and if so, is that something you plan on tackling?
  - recursivedoubts 2y ago
    There is an htmx demo on drag-and-drop (in the reorder sense) using Sortable.js here: https://htmx.org/examples/sortable/ https://htmx.org/examples/sortable/ Like most of the examples on the htmx site it is pretty bare bones (we keep it that way to focus on the concepts) but it's a reasonable demonstration of the integration. Whether that is good enough of course depends on your use case If you want an integrated and polished ecosystem that's something htmx isn't going to provide: it's a library focused (mainly) on one thing: generalizing hypermedia controls. So, when you want client side functionality like this, you are going to have to glue things together a bit. I completely understand the desire of having an integrated ecosystem to avoid doing that.
simonw 2y ago
"For example, when building complex forms with dynamic validation and conditional fields, we found ourselves writing convoluted server-side logic to handle what would be straightforward client-side operations in React." Anakin Padme meme: "You still implement validation on the server-side as well, right.... right?"
- mplewis 2y ago
  Yes. But you do it once at submission, not once per page.
  - pier25 2y ago
    What's the difference? You can split the validation in multiple functions/modules which you can then use both at submission or per step/page. Also, it seems you're implying having two validation systems (on the client and server) is actually good?
    - yarg 2y ago
      Yes? You want to validate on the client side because it reduces latency and improves responsiveness. You want to validate on the server side because you cannot trust the fucking client.
      - pier25 2y ago
        The point I'm contesting is that it's more difficult to validate on the server using HTMX. And I'm not saying you should be only validating on submit when using HTMX. Client exclusive validation is quite limited. Very often you need a trip to the server anyway so I don't buy the latency argument. Plus in most cases showing error messages too fast is terrible UX. The only exception I can think of is when checking the validity of a password.
        threatofrain 2y ago
        Showing error messages on the client side is not too fast or bad UX. Let's say someone entered an invalid credit card. Or an invalid email. Why even let that touch the backend? Note that frontend forms libraries allow a lot of choice over when to show error messages.
fsndz 2y ago
I will start using htmx as soon as there is a 20K MRR startup built only with it.
- jonathan-adly 2y ago
  My startup using htmx was there - and it was acquired successfully. They migrated pretty quick to react after the acquisition due to team dynamics (offshore big teams - seeped into JS heavy client, thin server culture). htmx was a struggle there as well. It worked amazing for us as a small team where everyone was full stack and I always build using htmx-first now. But, it is a struggle for folks who have been working in React-like patterns for 5+ years and never experienced the bless of MVC apps.
  - WD-42 2y ago
    Kinda wild that there is an entire generation of web devs for whom server side rendering is actually the new, strange thing.
    - insidstwr 2y ago
      Ssr is really about React. Rendering referring to HTML generation using react. Probably the old school thing is "serving a page"
  - fsndz 2y ago
    convenient. I would have liked taking a look at your apps built only using htmx
  - createaccount99 2y ago
    > the bless of MVC apps. haha, good one
  - emseetech 2y ago
    | They migrated pretty quick to react One advantage of htmx (along with web components and standard html+css) is that migrating to anything else is much easier than the other way around. A rewrite from an htmx app to a React app can be trivial. A rewrite from React to anything else will not be.
shortrounddev2 2y ago
I literally only ever hear about htmx from YC. I still don't know what the point of it is, it seems like one of those opinionated programmer things like "I don't use a framework" or "you don't need javascript to make my site work"
- ensignavenger 2y ago
  HTMX is getting a lot of attention from other communities to, another one I am part of is the Django community, which talks about it a lot.
- thruway516 2y ago
  It's for python programmers who think front-end is an unavoidable evil but wish to avoid it anyway.
  - nasretdinov 2y ago
    Why just Python? I feel excluded as a Go dev
    - thruway516 2y ago
      To front-end devs you all look the same
- sergiotapia 2y ago
  it's kind of the elm for javascript. vocal enthusiastic fans but no real usage beyond that miniscule enclave.
- gumbul 2y ago
  The uncle who wrote the tool is probably a friend of the moderators here. He thinks that changing the texts in the element with a few xhr functions is a great success. I've seen very few guys as weird as this guy.
  - recursivedoubts 2y ago
WD-42 2y ago
Here is what I don’t understand about this post: if they knew they needed complex ux with realtime collaboration, why did they even reach for HTMX to start with? The author could have spent an hour going through the HTMX docs and would realize it’s not a good fit instead of wasting who knows how much time actually implementing it. This reeks of ad-hoc vibe-driven development.
ketzo 2y ago
> AI and Tooling Support: It’s worth noting that AI tools are intimately familiar with Next.js and not so much with htmx This is stated as a very matter-of-fact downside, but this is a pretty crazy portent for the future of dev tools / libraries / frameworks / languages. Predictions: - LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools - LLMs will encourage usage of open-source tools because they will be so much more useful with more/better training data
- wodenokoto 2y ago
  I saw a tool that had a page dedicated to AI to read. Basically you would point your llm to that page as the initial prompt and from there could start asking questions. I thought it was an interesting idea, but apparently not interesting enough to remember who did it or even check how that page looked.
  - q0uaur 2y ago
    its actually a big thing i am waiting for - both websites and ai tools to agree on a way to facilitate this. i'm doing some game development in godot as a hobby, and the current llm's are really bad at it - very often i get code suggestions that use ancient versions of gdscript or the engine. I'd love to have a big enough context window and the tooling needed to go like "look at these godot docs for the current version: (insert link)" and then ask my questions, i think it would fix 99% of these issues. same with other less well-known tools and languages.
- ryanchants 2y ago
  I was considering this other day. AI tools are stuck at a particular point in time. And even training them on newer stuff, there's only so much information to train on. I've been exploring this being a _good_ thing. In software we spend so much time chasing the latest tooling, language features, frameworks, etc. Maybe it'll be a positive that it all stagnates a bit and we just use the tools we have to get work done instead of creating new hammers every 6 months.
  - 2y ago
deleted 2y ago
[deleted]
jokethrowaway 2y ago
I use Htmx to add little functionality to static pages and it works great. I used it recently to build a small crud admin page and I soon reached the limits of the technology; in the ends I rewrote it in solid.js - because next.js / react are pretty slow and employ the wrong abstractions. I think htmx for static + solid.js for interactive is a great combination - albeit I dream of a framework which will excel at both.
- recursivedoubts 2y ago
  https://data-star.dev https://data-star.dev combines ideas of htmx & solid (signals) and might be of interest to you
hermanradtke 2y ago
I don’t understand why the screenshot of the view on the right could not be created with htmx (or any UI framework/library).
mattrighetti 2y ago
> I thought htmx could be a good solution to keep our front-end super light. It seems htmx stopped working as soon as you gave up on the super light frontend part :) You started using third party libraries to render complex UI/UX and state management. Also, I’d like to point out that saying “it was easier to do X in React” is not really fair if you did that using third-party libraries. It’s just that somebody did it for you so that you didn’t have to. I sympathise a lot with what’s written in the post actually but in this case I think that htmx was not a good solution from the start if you knew you needed to manage complex states and rendering.
- mikeocool 2y ago
  It’s kind of a nice compliment to all of the “we converted our react app to htmx and everything is so much better” articles written by people who probably shouldn’t have used react to begin with.
- WD-42 2y ago
  Exactly. I’m a big htmx fan, but I think this post displays some serious lack of technical awareness from the author. More like they wanted to try out HTMX based on vibes as opposed to its actual strengths and weaknesses which would be apparent to anyone with even a cursory knowledge of the web platform and the docs on htmx.org
  - chuckadams 2y ago
    It sounds to me like they shared a learning experience.
    - appendix-rock 2y ago
      Yeah, without having the foresight to know that Hacker News would come after them with very disingenuous interpretations of what they’ve shared, because HN commenters are so used to spending all their days having internet arguments that they take everyone as a personal attack. Nothing in this post indicates that the author doesn’t know any of what all these people in the peanut gallery are snarkily lecturing about, FFS. Working in the open must be so difficult.
ensignavenger 2y ago
I love that HTMX is posting this (and other similar things) on their site. It seems like there were a lot of legitimate reasons why HTMX alone was not a great fit. I am not a frontend specialist, but I do find it interesting, but here are some of my thoughts on the points made: 1) Don't they have to validate forms on the backend anyway? What made it so difficult to get their backend system to communicate back up to the frontend? There are absolutly great reasons in many cases to do form validation on both the frontend and backend, so in those cases you would want more than just HTMX, but I am a little confused at the phrasing of this issue? 2) HTMX alone may sort of push apps in this direction. In some cases that is a good thing, but apparantly they decided they need to do somthing different for their customers. I hope it was a good decision for them. I do think HTMX could be used effectively to make a site much less CRUDy, but I can't really argue with their results in this specific case. 3) This is an interesting argument. I would love to know more about how this team using AI tooling and has become so dependent on it that this was a major issue for them. It also brings up an interesting question for the future- if AI dev tools become a major thing, will it raise the bar too high for new frameworks/programming languages to get enough tooling an integration for adoption? Not particularly relevant to Gumroads decision making process, but an interesting line of thought. 4) A common complaint with HTMX. I think some projects just require more than just HTMX provides. Maybe future HTMX plugins will fill in this gap though? 5) Certainly a legit issue. One reason I like Django (and even Python) is because of its deep community of integrations and add-ons. Perhaps they would have better luck with something more full featured like https://unpoly.com/ https://unpoly.com/ would fit their needs better than HTMX, while still being similar to the concept?
sergiotapia 2y ago
I completely agree with the author that AI has problems with more niche language/frameworks. when I prompt for rails stuff, things work right out of the box, and it makes great suggestions. (although this may no longer be the case for rails 8 - solidqueue/cache/etc are out that are totally new!) when I prompt for elixir/phoenix stuff, I usually have to paste in documentation or it hallucinates features or worse, suggests very dated ways of doing things that no longer apply or even work! react/next has so much volume of data that the AI must be cracked on it fr.
- arrowsmith 2y ago
  Which AI are you using for Elixir/Phoenix? I find that ChatGPT is as you describe for Elixir, but Claude writes Elixir very well.
  - sergiotapia 2y ago
    I only use claude sonnet 3.5 for code, it was the last leap before ai llms become useful for coding for me. it's all butter moving forward!
joshstrange 2y ago
There is never a "one size fits all" and I get frustrated with people that say "SPA for every project" as much as those who say "SPA is always wrong". Picking the right tool for the right job is incredibly important and, as this post mentions, finding something that will scale with your project is important.
andyjohnson0 2y ago
> "HTMX is a different syntax for inline JS." I'm not a web developer [1], and I get that htmx uses JavaScript behind the scenes, but this quote seems like someone was missing the point. htmx encourages a different approach to architecting and building an app. Or am I the one who's not understanding? The comment about hiring and AI-support being better with React is imo just another depressing reminder of how much of a monoculture we have at the front-end - and imo a bloated and over-complex one at that. [1] I have read the htmx book though
dartos 2y ago
His 3rd point scares me. Imagine a world where companies pay to have their framework’s be over represented in a models training set and selling contracts off the back of that. Like SEO but baked into developer tooling.
onehair 2y ago
I don't know man, I personally wouldn't use htmx nor tailwind, but the arguments against them as mentioned in the article felt too superficial. A note to the author, please don't post screenshots that have 78.9% whitespace on them. (especially when you have a the word UX in a close-by paragraph)
meerab 2y ago
"The development process felt natural with Next.js" - the author What part of this ReactJS syntax you find natural? Familiar Yes, Natural NO. useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);
- WickyNilliams 2y ago
  You're being very generous with this code sample. It can get far more complex if you want a custom hook with variable timeout. Dan even had to write a lengthy article on the topic. https://overreacted.io/making-setinterval-declarative-with-react-hooks/ https://overreacted.io/making-setinterval-declarative-with-r...
- crubier 2y ago
  What would look natural for this use case? Can you write the code?
- chrisco255 2y ago
  HTMX doesn't have an elegant solution for timers and intervals, as far as I know. You would still need to awkwardly wire that up in JS with HTMX.
  - recursivedoubts 2y ago
    What do you mean by timers and intervals?
  - syndicatedjelly 2y ago
    It does, `hx-trigger` supports repeated polling on an interval and delays. The terminology is different, the ergonomics are different but the underlying concept is the same.
    - chrisco255 2y ago
      hx-trigger is used for server side requests. `setInterval` can be used to fire http requests on an interval but it can also be used for a lot more things and you have full control over it. `hx-trigger` involves using proprietary language as strings to program the request. I have no idea by looking at that how it tears down, cancels, or responds to other events or triggers on the page. The reason for JSX is a custom template language ALWAYS ends up reinventing JavaScript in a worse, more limited form as template strings.
maicro 2y ago
Off-topic except that it's about gumroad - does anyone know of a proper abuse submission address or form for gumroad? I've received two spam emails from them in the past week, where a seller "sold" me something for $0, with a cryptocurrency scam in the item description - so I received an email from a legit gumroad address, but with attacker-provided content (text only in the email at least). I submitted one through their form, but it's a Google Forms page configured to only allow a single response, so I could only submit once. I also forwarded one to "abuse@gumroad.com", but no clue if that's a real destination or the best place for it... Gmail flagged both of these as Spam, so while I'm not really concerned about my own security here, I figure gumroad themselves would at least like to know about this so they can limit the (spam list) reputation hit...
righthand 2y ago
NextJS while solves a lot of problems is one of the most irritating frameworks I’ve worked with from their odd required directory structure to their weird router shift, to the shoehorning of server side api controllers and rendering. Not to mention the specific requirements to host on Vercel.com and it’s intentionally misleading design to get you to host there. HTMX is a breath of fresh air where 10 other framework aspects aren’t in my way. Gumroad from reading this didn’t even try to design using the htmx methodology.
- chrisco255 2y ago
  You can self-host Next.js. There's no dependency on Vercel.
  - righthand 2y ago
    > and it’s intentionally misleading design to get you to host there.
  - syndicatedjelly 2y ago
    It is a righteous pain in the ass to do so. There is no "dependency" on Vercel, but the choice is to either build your castle in someone else kingdom, or build all the infrastructure and plumbing on your own land and "self-host". The point is, it could be a whole lot easier to self-host Next.js. There's a reason it's not.
    - chrisco255 2y ago
      It's not at all difficult to self host Next.js. First of all, you can use Next to compile a static site that can be deployed anywhere. You can also run it in Docker or outright by simply: `npm run build` && `npm run start`
exabrial 2y ago
>Scalability Concerns: As our project grew in complexity, we found htmx struggling to keep up with our needs A Haiku on the above, oft-repeated, sexy-problem-to-have: Everyone says this, but nobody has benchmarks, because its not real You are not Google, but make believe problems, Are the most fun ones!
jmull 2y ago
OK, hats off to htmx for posting/hosting this. Now, it's a bit of a safe bet to write off anyone willingly or willfully using react, but still, actually hosting this took some real flair. IDK, I'm a svelte(kit) man myself, but I don't know that dev-dom really deserves something that makes as much sense as that. htmx is so far from the worst idea out there.
SrslyJosh 2y ago
> UX Limitations: htmx ended up pushing our app towards a Rails/CRUD approach, which led to a really poor (or at least, boring and generic) user experience by default. Good websites behave in predictable ways. If I can tell your website is using fucktons of javascript, I'm probably not enjoying using it. (And calling it an "app" is a bit of a red flag for bad UX to me.)
burnished 2y ago
Thoughtful critique about a project posted to the project page? Beautiful, loved it, well done everyone involved.
PaulHoule 2y ago
I have a system I’m working on that is all HTMX but I am thinking about options. The system is a document management tool which can be configured to be a lot of different things like an image sorter or an RSS reader or an information extraction tool. The key design point is that it has to be easily configurable. I worked on a similar system at a startup that used an SPA and boy was it a bear because changing anything involved making both front end and back end changes. We had to change directions all the time to keep up with our customers and the monolithic SPA sure slowed us down. My current back end has a query builder that can generate queries with a complex structure as is supported by OWL DL, like (Temp > 95 AND Temp < 100) or (IS warm) but with HTMX I can best use URL query parameters like ?temp:gt=95&temp:lt=100 that are all ANDed. I am thinking about making little applets with svelte that could do what HTMX can’t.
- WickyNilliams 2y ago
  Could you not have ?query={entire query goes here} Rather than splitting it up into multiple query params? Feels like it's one indivisible param rather than multiple facets. You could always base64 encode if it starts getting complex
  - PaulHoule 2y ago
    If it just comes to having buttons to add and remove tags I guess the server could generate those packed query strings (that HTMX will GET or POST to) Full text fields would be harder as the front end is going to want to put them in their own query parameter although one attack on the problem is to have the query as a parameter and have parameters that define a command that changes the query and have the back end mash that into the query. The user interface for nested queries would be more complex than for the flat queries (which can usually be updated incrementally, adding or removing just one tag) but could probably be redrawn from the back end whenever it changes.
    - Izkata 2y ago
      Does it really need to be generated on the backend and passed around like that? It seems like you're doing a ton of extra work to fit it into htmx, where coming from jquery and react, it's much more natural to generate it entirely on the frontend using plain arrays and objects, then send it as a whole to the backend in one serialized json string. Of course with one final validation on the backend, possibly with a transformation into whatever query language the backend is using. But no need for round-trips to construct it like that.
greenie_beans 2y ago
does anybody else think that parts of this was written by ai? especially the end.
rossdavidh 2y ago
Funny, almost everything he said about htmx made me think, "this htmx sounds interesting, I should check it out".
hakunin 2y ago
Having read the article, the team just seems more experienced with frontend than backend dev. As somewhat an old school dev, I've been noticing these small fears and misunderstandings in the way FE devs think. Honestly, I believe it only takes a minor adjustment in thinking to understand how this stuff works, but I get it — many people at this point have never seen regular client/server approach in their entire careers. That said, I get the value of off-the-shelf React components, and ease of finding docs/help, so wouldn't discount that anyway.
- emseetech 2y ago
  Not just the devs, but this is a great example of UX designers "thinking in React" which I believe is the biggest barrier to adoption for htmx. We've had a generation of designers who design mobile and web very similarly, and offload the complexity of implementing that onto the developers. But the web is (and should be) different than mobile, whenever possible. The post says that their designs were too "generic" as a CRUD app, but is that such a bad thing? We have a universally adopted document model (a momentous task) so we could have a predictable user experience across all sites but we can't help but see that as "boring". As if there's something inherently wrong with boring. I understand the market pressures to have a unique and branded experience that feels like a mobile application, but imagine if designers could think in WWW as well as they've learned to think in React.
valcron1000 2y ago
> complex forms with dynamic validation and conditional fields So 99% of the production sites out there. Good thing I didn't invest into htmx when it was the flavor of the month.
- listenallyall 2y ago
  Seems to me all validation, simple or dynamic, should be handled server side. And once you implement that, server rendering of conditional fields is free. Feel free to pass on htmx but don't convince yourself that it can't handle "complex forms" because this particular group of knuckleheads preferred React.
lifeisstillgood 2y ago
The interesting one is “lack of AI support” - in other words chatGPT not being able to churn out example code is a strategic disadvantage these days! I do wonder how you can feed your docs to the maw of the AI machine? Can you tell if they scraped your docs?
jgalt212 2y ago
> For example, when building complex forms with dynamic validation and conditional fields, we found ourselves writing convoluted server-side logic to handle what would be straightforward client-side operations in React. I find this bit to be disingenuous. I doubt "straightforward client-side operations" can handle "complex forms with dynamic validation and conditional fields", but it's probably true that such things are much easier (but not straightforward) in React than HTMX.
bitbasher 2y ago
It's nice to see experiences using htmx (both positive and negative). However, it's hard to ignore how much misunderstanding there seems to have been when using it. There's no rule that says everything needs to go to the server and back when using htmx. You don't have to _not do_ client side scripting. There's a whole section in the hypermedia book based on client side scripting. This is why most people using htmx are also pairing it with a light library for client interactions (alpine, hyperscript, web components, etc). Heck-- you can even pair it with react or any of the other heavier libraries.
chrisco255 2y ago
I'm happy with React, so I have no idea whether HTMX is good or not, but the vibes are off the charts.

440 points by rmason 2y ago

Another false dichotomy is server rendered vs single page app, when the happy place is both. One builds a bundle to embed in a server rendered page, as distinct from other bundles served up with other distinct pages. Ones rollup file would have an array of build objects, input output params. The user doesn't have to wait an eternity to download a monolithic single page app bundle. One doesn't get brain damaged by trying to maintain a monolithic state in a giant monolithic blob of javascript, urls work again, routing is returned to the server, and you could use a different framework on each page if you want to, thats how little it matters at that point. Why is no one mentioning embedding a js bundle in an htmx rendered page?

ttfkam 2y ago

A shame the only two choices were Htmx and React.

CraigJPerry 2y ago

One quality of htmx that a nextjs solution won’t benefit from is stability. I have come back to an htmx project months later and been able to very quickly change a behaviour. My experience with nextjs was a few deps now had vulns (fair enough, I’m grateful for the npm tooling that informed me) which necessitated updates which were a bit distracting and felt like yak shaving when all I wanted to do was a simple change. Even when there aren’t vulns I find it a bit lazy not to take the opportunity to evergreen the dependencies for a bit longer but that does frequently cost unwanted time. One place where htmx feels underpowered is when you have multiple related states on a page - a table view with some summary metric fields across the top as a dashboard and some action items in a sidebar with labels exposing counts of actions. In htmx you can always resort to hxswap basically the entire view out rather than trying to surgically update each dependent target but at that point why am I using htmx, I can just round trip for a page refresh and skip the whole hassle of having a server side component strategy.

gwking 2y ago

As many others have mentioned, the comment about AI failing to cough up good answers is intriguing. But what has not been said is that this may also be evidence that the HTMX documentation needs improvement. In particular it needs (many) more examples. I have always been a reader of documentation for libraries that I use, and I have nearly always felt that docs could be better. Having tried to write docs myself, I know how hard (impossible?) it is to imagine not knowing how the thing you are documenting works. Recursivedoubts, please take this criticism as encouragement more than anything! I think HTMX is important both as a library and as a reality check against complexity. There is something unnerving about the HTMX docs to me: over and over again, I read them, and I think, "ok got it, sounds straightforward" but then it turns out there is something slightly tricky that is hard to diagnose. I don't quite know why. One thing that has gotten me a couple times is not being clear on whether an attribute is for the request or response. I feel kind of dumb admitting this but it has been harder than I'd have thought. My best suggestion would be to add a request/response column in the attributes reference listings. Debug mode validation of "hx-*" attributes would be very welcome. Early on I definitely mixed up hx-select-oob/hx-swap-oob and hx-include/hx-vals. I've also made mistakes with hx-indicator/htmx-indicator although that's a little different because one is a css class name. Another that got me recently was trying to set an hx-on: after-settle handler in the target element (client side) and having nothing happen, but then discovering that if I put it in the response it would work. This made no sense at the time. Now I'm wondering if it was because the hx-swap was set to something other than innerHTML. Anyway, I think the main point is that some of these things are sort of related in various subtle ways, and also sound similar, and are easy to mix up. As a new user, when I try to follow the directions and then apparently nothing happens, it is very hard to know how to proceed. Really the only way forward is to find a working example and try not to break it, or selectively break it to figure out how it works. I know docs are a lot of work, but in an ideal future there would be example links to click on for each one of the attributes. Perhaps I could help with that at some point. I've always thought that HTMX has amazing potential on the documentation front because one can build working examples that are served completely statically. In fact I can't think of a UI system that is more amenable to training an LLM. You would just need to write out the expected end-state of the HTML target. For context, I've been using HTMX as crucial component of a back office web app for two years now. It is mostly a custom scheduling calendar. Most of it is simple HTMX, but I've used OOB-swap and hx-on in places. I use it to do fast state changes without full page refreshes, and to implement a few multi-step forms that require back-and forth of valid form choices. Recently I built a modal control with different edit actions, etc. I don't think I would have taken on this client at all if it weren't for HTMX. So, thank you!

ram_rar 2y ago

Kudos to htmx for their refreshingly honest blog post! I hope many other open-source tools especially Databases can do similar things. >> while it’s important to consider lightweight alternatives, it’s equally crucial to choose technologies that can grow with your project and support your long-term vision A key takeaway that resonates with me is the importance of choosing technologies with growth potential and a thriving ecosystem – essentially making a long-term bet on their success. Too many devs get entangled with adopting shiny new things, while losing focus on delivering real value to customers.

emrah 2y ago

Htmx does not seem like a good fit to replace a thick-client type front-end framework and that's ok. It meant for that. It is more in line with 37Signal's "HotWired" approach (hotwired.dev)

smallerfish 2y ago

> For instance, implementing a drag-and-drop interface for our workflow builder proved to be a significant challenge with htmx, requiring workarounds that felt clunky compared to the smooth experience we could achieve with React libraries. HTMX is better if you have a frontend bundle that does just enough but no more. Hook into the htmx.onLoad event and then look for markup with attributes in the content being loaded (for example, columns, cards, tasks, etc) to attach to. You can then, for example, bind sortable.js onto the rendered markup, and then wire sortable events to state updates via HTMX. Really pretty straightforward. They even have an example of exactly this in the docs: https://htmx.org/docs/#3rd-party https://htmx.org/docs/#3rd-party

gen220 2y ago
Yeah, I've been using HTMX with UIKit components. Having a modern, stateful, and dynamic website is definitely not incompatible with HTMX.

zackerydev 2y ago

This is a wonderful advertisement for the things that HTMX is good for and the thing it isn't. It's obviously tongue-and-cheek but I think it makes the case well!

tptacek 2y ago
Why is this tongue-and-cheek? Doing this sincerely is a huge confidence builder.
ensignavenger 2y ago
What makes you think it was tongue-in-cheek? It sounds quite genuine to me?
- nasretdinov 2y ago
  Perhaps because of pages like this one: https://htmx.org/essays/htmx-sucks/ https://htmx.org/essays/htmx-sucks/ (note the URL)
  - ensignavenger 2y ago
    Different authors and very different tones, but yeah, that essay was tongue-in-cheek, so I guess I could see why you might think that at first. I thought it might be, when I saw the title, but then I read it and realized quickly it was sincere.
recursivedoubts 2y ago
:) this isn't tongue-in-cheek it was a real experience the htmx sucks essay was definitely tongue-in-cheek though (although many of the criticisms were legitimate, and even agree with this one, such as the lack of a component ecosystem!)

bumbledraven 2y ago

Kudos to htmx.org for hosting this essay.

dannyobrien 2y ago
I really do value services/tools that explain why you shouldn't use it, as well as why you should.
jamal-kumar 2y ago
It's really humble and honest of them to put something like this up but in the end at least they have something to point to now if people pick it up and get mad that it doesn't meet their needs
- recursivedoubts 2y ago
  we also have this essay to help people decide when htmx (or hypermedia more broadly) might be a good fit: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ and then this tongue in cheek essay (many of the criticisms are legitimate): https://htmx.org/essays/htmx-sucks/ https://htmx.org/essays/htmx-sucks/ We also have a mug for people who don't like htmx: https://swag.htmx.org/products/htmx-sucks-mug https://swag.htmx.org/products/htmx-sucks-mug
svat 2y ago
Yeah it's linked from https://htmx.org/essays/ https://htmx.org/essays/ under "On The Other Hand…"
Ayesh 2y ago
Yeah, I expected a bit of a rant or sarcastic post, but I'm genuinely happy it's a good post with good points. I use htmx in a couple of my projects and it's been great! Posts like these give me more confident about using htmx because they seldom show where they excel and where they fall short.

nasretdinov 2y ago

I like how they compare server-side validation with React's client-side (only?) one. Wasn't able to relate to other puns all that much unfortunately.

rozap 2y ago
Yea this piece is often left out and is kinda the most important. A single set of validation, on the server is required. There are tons of reasonable solutions with different tradeoffs for how you run that validation on the client. But two duplicate sets of validation or client only validation are two very, very dark paths.

nsonha 2y ago

Comparing it with React is a low bar, since a lot of people are unhappy with React. Arguments like "React is popular, AI knows it", or "React is popular, lots of component have been written in it" seem weak. A proper antithesis for htmlx should compares it with SPA.

simonw 2y ago
HTMX can be used as a tool for building SPAs, so I don't think it makes sense to compare it with SPA. What's an SPA if not a single web page where clicking on things causes that UI to update in-place in different ways?
- nsonha 2y ago
  htmlx is what you would have on the front end when you do server rendering. Server has to do quite a bit, routing among other things. In SPA server just serves a single page and routing is all done in the client.
mardifoufs 2y ago
And a lot of people are happy with react. Not sure what your point is. I mean of course people using a more niche framework will usually be more happy about it, because early adopters usually choose to use the technology. Like, it's rare to come across htmx (or svelte, or solid) in a corporate job for now, which means that almost all of their users like said frameworks enough to use and talk about them in their free time For react that's just not the case, because it's everywhere. If I was forced to use Vue, I wouldn't like it. But I'm not so I don't use it enough to criticize it a lot. If anything I've seen more people dislike angular or vue when they had to work in a project that used those frameworks, and didn't have a say in that choice. But that's also just an anecdote obviously
- nsonha 2y ago
  Hey I like React to, I'm actually complaining that often React is used as a scapegoat and and it would be a weak/not really on point criticism for htmlx. I mean people should understand that htmlx is bad because it's clunky, not because it's unpopular and there is no job.

croes 2y ago

[dupe] https://news.ycombinator.com/item?id=41727315 https://news.ycombinator.com/item?id=41727315

draw_down 2y ago

[dead]

nop_slide 2y ago

Gumroad dude seems to have some shaky reasoning for migrating at all, sounds to me a migration just for the sake of it. https://news.ycombinator.com/item?id=41669615 https://news.ycombinator.com/item?id=41669615

mardifoufs 2y ago
I mean, he clarified his reasoning and it made sense. Why do you think that moving away from RoR involves shaky reasoning here?

recursivedoubts 2y ago

My comment from the other thread: The CEO of gumroad mentioned on twitter that he had tried out htmx for a project but decided to go with NextJS instead. I asked him if he was willing to write up his experience and he graciously agreed to do so. I have been looking for a thoughtful negative experience with htmx to host on the htmx website and I am very thankful he was willing to put in the work to produce one.

kunley 2y ago
Very useful explanation, because at first it seemed unusual to see it on htmx.org, but well, different projects have different needs.
- ensignavenger 2y ago
  HTMX has posted links to negative articles before, but I am not aware of any as thoughtful as this one. So it wasn't all that surprising for me that they would share this. That they went out of their way to solicit it is extraordinary, though!
hencq 2y ago
Your attitude to call out where htmx might not be the best solution, makes me respect the project even more. It's refreshing to see this compared to lots of other projects that always seem to claim to be the best solution for everything. I'm curious in particular about the call out around drag-and-drop. Is that something you agree with? Is drag and drop difficult with htmx and if so, is that something you plan on tackling?
- recursivedoubts 2y ago
  There is an htmx demo on drag-and-drop (in the reorder sense) using Sortable.js here: https://htmx.org/examples/sortable/ https://htmx.org/examples/sortable/ Like most of the examples on the htmx site it is pretty bare bones (we keep it that way to focus on the concepts) but it's a reasonable demonstration of the integration. Whether that is good enough of course depends on your use case If you want an integrated and polished ecosystem that's something htmx isn't going to provide: it's a library focused (mainly) on one thing: generalizing hypermedia controls. So, when you want client side functionality like this, you are going to have to glue things together a bit. I completely understand the desire of having an integrated ecosystem to avoid doing that.

simonw 2y ago

"For example, when building complex forms with dynamic validation and conditional fields, we found ourselves writing convoluted server-side logic to handle what would be straightforward client-side operations in React." Anakin Padme meme: "You still implement validation on the server-side as well, right.... right?"

mplewis 2y ago
Yes. But you do it once at submission, not once per page.
- pier25 2y ago
  What's the difference? You can split the validation in multiple functions/modules which you can then use both at submission or per step/page. Also, it seems you're implying having two validation systems (on the client and server) is actually good?
  - yarg 2y ago
    Yes? You want to validate on the client side because it reduces latency and improves responsiveness. You want to validate on the server side because you cannot trust the fucking client.
    - pier25 2y ago
      The point I'm contesting is that it's more difficult to validate on the server using HTMX. And I'm not saying you should be only validating on submit when using HTMX. Client exclusive validation is quite limited. Very often you need a trip to the server anyway so I don't buy the latency argument. Plus in most cases showing error messages too fast is terrible UX. The only exception I can think of is when checking the validity of a password.
      - threatofrain 2y ago
        Showing error messages on the client side is not too fast or bad UX. Let's say someone entered an invalid credit card. Or an invalid email. Why even let that touch the backend? Note that frontend forms libraries allow a lot of choice over when to show error messages.

fsndz 2y ago

I will start using htmx as soon as there is a 20K MRR startup built only with it.

jonathan-adly 2y ago
My startup using htmx was there - and it was acquired successfully. They migrated pretty quick to react after the acquisition due to team dynamics (offshore big teams - seeped into JS heavy client, thin server culture). htmx was a struggle there as well. It worked amazing for us as a small team where everyone was full stack and I always build using htmx-first now. But, it is a struggle for folks who have been working in React-like patterns for 5+ years and never experienced the bless of MVC apps.
- WD-42 2y ago
  Kinda wild that there is an entire generation of web devs for whom server side rendering is actually the new, strange thing.
  - insidstwr 2y ago
    Ssr is really about React. Rendering referring to HTML generation using react. Probably the old school thing is "serving a page"
- fsndz 2y ago
  convenient. I would have liked taking a look at your apps built only using htmx
- createaccount99 2y ago
  > the bless of MVC apps. haha, good one
- emseetech 2y ago
  | They migrated pretty quick to react One advantage of htmx (along with web components and standard html+css) is that migrating to anything else is much easier than the other way around. A rewrite from an htmx app to a React app can be trivial. A rewrite from React to anything else will not be.

shortrounddev2 2y ago

I literally only ever hear about htmx from YC. I still don't know what the point of it is, it seems like one of those opinionated programmer things like "I don't use a framework" or "you don't need javascript to make my site work"

ensignavenger 2y ago
HTMX is getting a lot of attention from other communities to, another one I am part of is the Django community, which talks about it a lot.
thruway516 2y ago
It's for python programmers who think front-end is an unavoidable evil but wish to avoid it anyway.
- nasretdinov 2y ago
  Why just Python? I feel excluded as a Go dev
  - thruway516 2y ago
    To front-end devs you all look the same
sergiotapia 2y ago
it's kind of the elm for javascript. vocal enthusiastic fans but no real usage beyond that miniscule enclave.
gumbul 2y ago
The uncle who wrote the tool is probably a friend of the moderators here. He thinks that changing the texts in the element with a few xhr functions is a great success. I've seen very few guys as weird as this guy.
- recursivedoubts 2y ago

WD-42 2y ago

Here is what I don’t understand about this post: if they knew they needed complex ux with realtime collaboration, why did they even reach for HTMX to start with? The author could have spent an hour going through the HTMX docs and would realize it’s not a good fit instead of wasting who knows how much time actually implementing it. This reeks of ad-hoc vibe-driven development.

ketzo 2y ago

> AI and Tooling Support: It’s worth noting that AI tools are intimately familiar with Next.js and not so much with htmx This is stated as a very matter-of-fact downside, but this is a pretty crazy portent for the future of dev tools / libraries / frameworks / languages. Predictions: - LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools - LLMs will encourage usage of open-source tools because they will be so much more useful with more/better training data

wodenokoto 2y ago
I saw a tool that had a page dedicated to AI to read. Basically you would point your llm to that page as the initial prompt and from there could start asking questions. I thought it was an interesting idea, but apparently not interesting enough to remember who did it or even check how that page looked.
- q0uaur 2y ago
  its actually a big thing i am waiting for - both websites and ai tools to agree on a way to facilitate this. i'm doing some game development in godot as a hobby, and the current llm's are really bad at it - very often i get code suggestions that use ancient versions of gdscript or the engine. I'd love to have a big enough context window and the tooling needed to go like "look at these godot docs for the current version: (insert link)" and then ask my questions, i think it would fix 99% of these issues. same with other less well-known tools and languages.
ryanchants 2y ago
I was considering this other day. AI tools are stuck at a particular point in time. And even training them on newer stuff, there's only so much information to train on. I've been exploring this being a _good_ thing. In software we spend so much time chasing the latest tooling, language features, frameworks, etc. Maybe it'll be a positive that it all stagnates a bit and we just use the tools we have to get work done instead of creating new hammers every 6 months.
- 2y ago

deleted 2y ago

[deleted]

jokethrowaway 2y ago

I use Htmx to add little functionality to static pages and it works great. I used it recently to build a small crud admin page and I soon reached the limits of the technology; in the ends I rewrote it in solid.js - because next.js / react are pretty slow and employ the wrong abstractions. I think htmx for static + solid.js for interactive is a great combination - albeit I dream of a framework which will excel at both.

recursivedoubts 2y ago
https://data-star.dev https://data-star.dev combines ideas of htmx & solid (signals) and might be of interest to you

hermanradtke 2y ago

I don’t understand why the screenshot of the view on the right could not be created with htmx (or any UI framework/library).

mattrighetti 2y ago

> I thought htmx could be a good solution to keep our front-end super light. It seems htmx stopped working as soon as you gave up on the super light frontend part :) You started using third party libraries to render complex UI/UX and state management. Also, I’d like to point out that saying “it was easier to do X in React” is not really fair if you did that using third-party libraries. It’s just that somebody did it for you so that you didn’t have to. I sympathise a lot with what’s written in the post actually but in this case I think that htmx was not a good solution from the start if you knew you needed to manage complex states and rendering.

mikeocool 2y ago
It’s kind of a nice compliment to all of the “we converted our react app to htmx and everything is so much better” articles written by people who probably shouldn’t have used react to begin with.
WD-42 2y ago
Exactly. I’m a big htmx fan, but I think this post displays some serious lack of technical awareness from the author. More like they wanted to try out HTMX based on vibes as opposed to its actual strengths and weaknesses which would be apparent to anyone with even a cursory knowledge of the web platform and the docs on htmx.org
- chuckadams 2y ago
  It sounds to me like they shared a learning experience.
  - appendix-rock 2y ago
    Yeah, without having the foresight to know that Hacker News would come after them with very disingenuous interpretations of what they’ve shared, because HN commenters are so used to spending all their days having internet arguments that they take everyone as a personal attack. Nothing in this post indicates that the author doesn’t know any of what all these people in the peanut gallery are snarkily lecturing about, FFS. Working in the open must be so difficult.

ensignavenger 2y ago

I love that HTMX is posting this (and other similar things) on their site. It seems like there were a lot of legitimate reasons why HTMX alone was not a great fit. I am not a frontend specialist, but I do find it interesting, but here are some of my thoughts on the points made: 1) Don't they have to validate forms on the backend anyway? What made it so difficult to get their backend system to communicate back up to the frontend? There are absolutly great reasons in many cases to do form validation on both the frontend and backend, so in those cases you would want more than just HTMX, but I am a little confused at the phrasing of this issue? 2) HTMX alone may sort of push apps in this direction. In some cases that is a good thing, but apparantly they decided they need to do somthing different for their customers. I hope it was a good decision for them. I do think HTMX could be used effectively to make a site much less CRUDy, but I can't really argue with their results in this specific case. 3) This is an interesting argument. I would love to know more about how this team using AI tooling and has become so dependent on it that this was a major issue for them. It also brings up an interesting question for the future- if AI dev tools become a major thing, will it raise the bar too high for new frameworks/programming languages to get enough tooling an integration for adoption? Not particularly relevant to Gumroads decision making process, but an interesting line of thought. 4) A common complaint with HTMX. I think some projects just require more than just HTMX provides. Maybe future HTMX plugins will fill in this gap though? 5) Certainly a legit issue. One reason I like Django (and even Python) is because of its deep community of integrations and add-ons. Perhaps they would have better luck with something more full featured like https://unpoly.com/ https://unpoly.com/ would fit their needs better than HTMX, while still being similar to the concept?

sergiotapia 2y ago

I completely agree with the author that AI has problems with more niche language/frameworks. when I prompt for rails stuff, things work right out of the box, and it makes great suggestions. (although this may no longer be the case for rails 8 - solidqueue/cache/etc are out that are totally new!) when I prompt for elixir/phoenix stuff, I usually have to paste in documentation or it hallucinates features or worse, suggests very dated ways of doing things that no longer apply or even work! react/next has so much volume of data that the AI must be cracked on it fr.

arrowsmith 2y ago
Which AI are you using for Elixir/Phoenix? I find that ChatGPT is as you describe for Elixir, but Claude writes Elixir very well.
- sergiotapia 2y ago
  I only use claude sonnet 3.5 for code, it was the last leap before ai llms become useful for coding for me. it's all butter moving forward!

joshstrange 2y ago

There is never a "one size fits all" and I get frustrated with people that say "SPA for every project" as much as those who say "SPA is always wrong". Picking the right tool for the right job is incredibly important and, as this post mentions, finding something that will scale with your project is important.

andyjohnson0 2y ago

> "HTMX is a different syntax for inline JS." I'm not a web developer [1], and I get that htmx uses JavaScript behind the scenes, but this quote seems like someone was missing the point. htmx encourages a different approach to architecting and building an app. Or am I the one who's not understanding? The comment about hiring and AI-support being better with React is imo just another depressing reminder of how much of a monoculture we have at the front-end - and imo a bloated and over-complex one at that. [1] I have read the htmx book though

dartos 2y ago

His 3rd point scares me. Imagine a world where companies pay to have their framework’s be over represented in a models training set and selling contracts off the back of that. Like SEO but baked into developer tooling.

onehair 2y ago

I don't know man, I personally wouldn't use htmx nor tailwind, but the arguments against them as mentioned in the article felt too superficial. A note to the author, please don't post screenshots that have 78.9% whitespace on them. (especially when you have a the word UX in a close-by paragraph)

meerab 2y ago

"The development process felt natural with Next.js" - the author What part of this ReactJS syntax you find natural? Familiar Yes, Natural NO. useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);

WickyNilliams 2y ago
You're being very generous with this code sample. It can get far more complex if you want a custom hook with variable timeout. Dan even had to write a lengthy article on the topic. https://overreacted.io/making-setinterval-declarative-with-react-hooks/ https://overreacted.io/making-setinterval-declarative-with-r...
crubier 2y ago
What would look natural for this use case? Can you write the code?
chrisco255 2y ago
HTMX doesn't have an elegant solution for timers and intervals, as far as I know. You would still need to awkwardly wire that up in JS with HTMX.
- recursivedoubts 2y ago
  What do you mean by timers and intervals?
- syndicatedjelly 2y ago
  It does, `hx-trigger` supports repeated polling on an interval and delays. The terminology is different, the ergonomics are different but the underlying concept is the same.
  - chrisco255 2y ago
    hx-trigger is used for server side requests. `setInterval` can be used to fire http requests on an interval but it can also be used for a lot more things and you have full control over it. `hx-trigger` involves using proprietary language as strings to program the request. I have no idea by looking at that how it tears down, cancels, or responds to other events or triggers on the page. The reason for JSX is a custom template language ALWAYS ends up reinventing JavaScript in a worse, more limited form as template strings.

maicro 2y ago

Off-topic except that it's about gumroad - does anyone know of a proper abuse submission address or form for gumroad? I've received two spam emails from them in the past week, where a seller "sold" me something for $0, with a cryptocurrency scam in the item description - so I received an email from a legit gumroad address, but with attacker-provided content (text only in the email at least). I submitted one through their form, but it's a Google Forms page configured to only allow a single response, so I could only submit once. I also forwarded one to "abuse@gumroad.com", but no clue if that's a real destination or the best place for it... Gmail flagged both of these as Spam, so while I'm not really concerned about my own security here, I figure gumroad themselves would at least like to know about this so they can limit the (spam list) reputation hit...

righthand 2y ago

NextJS while solves a lot of problems is one of the most irritating frameworks I’ve worked with from their odd required directory structure to their weird router shift, to the shoehorning of server side api controllers and rendering. Not to mention the specific requirements to host on Vercel.com and it’s intentionally misleading design to get you to host there. HTMX is a breath of fresh air where 10 other framework aspects aren’t in my way. Gumroad from reading this didn’t even try to design using the htmx methodology.

chrisco255 2y ago
You can self-host Next.js. There's no dependency on Vercel.
- righthand 2y ago
  > and it’s intentionally misleading design to get you to host there.
- syndicatedjelly 2y ago
  It is a righteous pain in the ass to do so. There is no "dependency" on Vercel, but the choice is to either build your castle in someone else kingdom, or build all the infrastructure and plumbing on your own land and "self-host". The point is, it could be a whole lot easier to self-host Next.js. There's a reason it's not.
  - chrisco255 2y ago
    It's not at all difficult to self host Next.js. First of all, you can use Next to compile a static site that can be deployed anywhere. You can also run it in Docker or outright by simply: `npm run build` && `npm run start`

exabrial 2y ago

>Scalability Concerns: As our project grew in complexity, we found htmx struggling to keep up with our needs A Haiku on the above, oft-repeated, sexy-problem-to-have: Everyone says this, but nobody has benchmarks, because its not real You are not Google, but make believe problems, Are the most fun ones!

jmull 2y ago

OK, hats off to htmx for posting/hosting this. Now, it's a bit of a safe bet to write off anyone willingly or willfully using react, but still, actually hosting this took some real flair. IDK, I'm a svelte(kit) man myself, but I don't know that dev-dom really deserves something that makes as much sense as that. htmx is so far from the worst idea out there.

SrslyJosh 2y ago

> UX Limitations: htmx ended up pushing our app towards a Rails/CRUD approach, which led to a really poor (or at least, boring and generic) user experience by default. Good websites behave in predictable ways. If I can tell your website is using fucktons of javascript, I'm probably not enjoying using it. (And calling it an "app" is a bit of a red flag for bad UX to me.)

burnished 2y ago

Thoughtful critique about a project posted to the project page? Beautiful, loved it, well done everyone involved.

PaulHoule 2y ago

I have a system I’m working on that is all HTMX but I am thinking about options. The system is a document management tool which can be configured to be a lot of different things like an image sorter or an RSS reader or an information extraction tool. The key design point is that it has to be easily configurable. I worked on a similar system at a startup that used an SPA and boy was it a bear because changing anything involved making both front end and back end changes. We had to change directions all the time to keep up with our customers and the monolithic SPA sure slowed us down. My current back end has a query builder that can generate queries with a complex structure as is supported by OWL DL, like (Temp > 95 AND Temp < 100) or (IS warm) but with HTMX I can best use URL query parameters like ?temp:gt=95&temp:lt=100 that are all ANDed. I am thinking about making little applets with svelte that could do what HTMX can’t.

WickyNilliams 2y ago
Could you not have ?query={entire query goes here} Rather than splitting it up into multiple query params? Feels like it's one indivisible param rather than multiple facets. You could always base64 encode if it starts getting complex
- PaulHoule 2y ago
  If it just comes to having buttons to add and remove tags I guess the server could generate those packed query strings (that HTMX will GET or POST to) Full text fields would be harder as the front end is going to want to put them in their own query parameter although one attack on the problem is to have the query as a parameter and have parameters that define a command that changes the query and have the back end mash that into the query. The user interface for nested queries would be more complex than for the flat queries (which can usually be updated incrementally, adding or removing just one tag) but could probably be redrawn from the back end whenever it changes.
  - Izkata 2y ago
    Does it really need to be generated on the backend and passed around like that? It seems like you're doing a ton of extra work to fit it into htmx, where coming from jquery and react, it's much more natural to generate it entirely on the frontend using plain arrays and objects, then send it as a whole to the backend in one serialized json string. Of course with one final validation on the backend, possibly with a transformation into whatever query language the backend is using. But no need for round-trips to construct it like that.

greenie_beans 2y ago

does anybody else think that parts of this was written by ai? especially the end.

rossdavidh 2y ago

Funny, almost everything he said about htmx made me think, "this htmx sounds interesting, I should check it out".

hakunin 2y ago

Having read the article, the team just seems more experienced with frontend than backend dev. As somewhat an old school dev, I've been noticing these small fears and misunderstandings in the way FE devs think. Honestly, I believe it only takes a minor adjustment in thinking to understand how this stuff works, but I get it — many people at this point have never seen regular client/server approach in their entire careers. That said, I get the value of off-the-shelf React components, and ease of finding docs/help, so wouldn't discount that anyway.

emseetech 2y ago
Not just the devs, but this is a great example of UX designers "thinking in React" which I believe is the biggest barrier to adoption for htmx. We've had a generation of designers who design mobile and web very similarly, and offload the complexity of implementing that onto the developers. But the web is (and should be) different than mobile, whenever possible. The post says that their designs were too "generic" as a CRUD app, but is that such a bad thing? We have a universally adopted document model (a momentous task) so we could have a predictable user experience across all sites but we can't help but see that as "boring". As if there's something inherently wrong with boring. I understand the market pressures to have a unique and branded experience that feels like a mobile application, but imagine if designers could think in WWW as well as they've learned to think in React.

valcron1000 2y ago

> complex forms with dynamic validation and conditional fields So 99% of the production sites out there. Good thing I didn't invest into htmx when it was the flavor of the month.

listenallyall 2y ago
Seems to me all validation, simple or dynamic, should be handled server side. And once you implement that, server rendering of conditional fields is free. Feel free to pass on htmx but don't convince yourself that it can't handle "complex forms" because this particular group of knuckleheads preferred React.

lifeisstillgood 2y ago

The interesting one is “lack of AI support” - in other words chatGPT not being able to churn out example code is a strategic disadvantage these days! I do wonder how you can feed your docs to the maw of the AI machine? Can you tell if they scraped your docs?

jgalt212 2y ago

> For example, when building complex forms with dynamic validation and conditional fields, we found ourselves writing convoluted server-side logic to handle what would be straightforward client-side operations in React. I find this bit to be disingenuous. I doubt "straightforward client-side operations" can handle "complex forms with dynamic validation and conditional fields", but it's probably true that such things are much easier (but not straightforward) in React than HTMX.

bitbasher 2y ago

It's nice to see experiences using htmx (both positive and negative). However, it's hard to ignore how much misunderstanding there seems to have been when using it. There's no rule that says everything needs to go to the server and back when using htmx. You don't have to _not do_ client side scripting. There's a whole section in the hypermedia book based on client side scripting. This is why most people using htmx are also pairing it with a light library for client interactions (alpine, hyperscript, web components, etc). Heck-- you can even pair it with react or any of the other heavier libraries.

chrisco255 2y ago

I'm happy with React, so I have no idea whether HTMX is good or not, but the vibes are off the charts.