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.
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?
There is an htmx demo on drag-and-drop (in the reorder sense) using Sortable.js here:
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.
Thanks! That actually seems very smooth. Trying out htmx has been high on my list for a while when I finally get time to do a little personal side project. Real life keeps getting in the way, but this is a good nudge. The appealing thing about htmx to me is that it seems like it should be very easy to keep everything in your head.
I've never seen a project highlight a negative use case in detail. This is a first.
Me neither. In the 2000s, Tor did something similar (a "what Tor can't do" page) and prominent linked to it on the front page, which definitely improved the project's reputation with a coterie of infosec professionals.
It might not have helped with wider adoption though. People would send me the link saying "Look at all of these bad things about Tor", and it would be links to Tor explanatory pages.
It was around that time that I realised that when trying to give people an intuition for what software many Internet professionals trust, the list of "green flags" I identified was, in fact, the exact opposite of what the majority might guess as being good signs. "Large list of attractive sounding features" vs "Lists problems with the tool as prominently as benefits" ; "Sold and marketed by a large well-known company" vs "Developed by a small, volunteer team" ; "Free to download" vs "Costs money"; "Modern, professionally-designed website" vs "Looks like it was built in 1997", etc, etc.
It's not quite the same but SQLite has a page where they clearly present its limitations and how to identify the situations where you should choose something else.
We have a similar essay up on when to use htmx/hypermedia:
https://htmx.org/essays/when-to-use-hypermedia/
I think it's a good idea for any software project to have something like this so that people know when it's a good fit and when it isn't.
I've used hotwire a bunch, and with minor differences, I think the list of things that htmx is not good for is spot on.
I don't think I'm explaining this well, but maybe this will help someone: Hotwire / htmx are about server-side rendering and making that work more smoothly with the client. eg fewer page navigations, more rapid update of the client, etc. But it's still, through and through, server render with server state.
It works well as long as the server is always the source of truth. The things that it isn't good at, such as drag and drop or complex, multi-state forms on the client side, are basically because you temporarily have a split source of truth: the client is the source of truth with complex state.
That said, my strong suggestion would be to use Hotwire or htmx for 95% of your project even if the main interaction loop is done in react. Your app will still likely have tons of crud around user management, settings / config, onboarding, etc. You can make all that work more nicely.
edit: in case it wasn't clear: for the things that are in the hotwire/htmx wheelhouse, the tech works really well. It's a fantastic improvement.
> 95% of your project even if the main interaction loop is done in react
The trick is to be very honest with yourself (and team) about how much complex front-end UI the application actually _requires_. Using React where it isn't necessary is very expensive in the long run. The older I get, the more the grug brained developer makes sense.
Agreed. Too often you'll see HN's claim that PHP / Java / MySQL are the best choices for everything, where often times they are blind to specific problems and use-cases that other developers are trying to solve.
>Too often you'll see HN's claim that PHP / Java / MySQL are the best choices for everything.
Either this is missing /s or this is trolling, right?
Indeed. Even if hn were a monolith and all had the same opinion, it certainly would not be a pro PHP, Java and MySQL position.
>The CEO of gumroad mentioned on twitter...
He also mentioned Rails in itself is a technical debt. And when asked about it all he said was React is so much better. As if you cant use React with Rails.
As for the article, I dont see it as a negative experience for HTMX. As soon as he mentions drag and drop, real time collaboration, I will go on to say may be even toying with HTMX was wrong in the first place?
I am also not sure what the screenshot was trying to show.
But all of that, I think it is a great pieces to be on HTMX website.
I would say React is (so much) better because it's functional, immutable, one-way, almost declarative. In comparison, stuff like ActiveRecord is very imperative, shared-mutable-state thing. For React-based code you usually take a language with a rich static type system (TS); Rails with its design-by-contract struggled to provide type signatures, last time I checked.
One of them is much easier to reason about than the other, even though the other is enviably compact.
React is a client-side library. Rails is a server-side framework. I don't see how you can even really compare these apples and oranges.
Personally, I think rails and react go together very well. For apps that need rich client-side functionality, I will do a react spa with a back end in elixir/ Phoenix (which is very similar to rails).
For apps that don't, just doing server-side rendering is plenty sufficient and is my preference.
I'm only comparing development experience and, so to say, the conceptual environment.
Verily, Rails can be a pretty good and compact way to serve backend APIs for a React-based frontend. But the API boundary is the "narrow waist", its relative neutrality allows to switch backend and frontend implementations easily, or even to mix them. I've seen a React frontend seamlessly consuming APIs served by Python and Rust services, and it's hardly possible to spot which endpoint is served by what in the frontend code.
Unlike on the frontend, FP approaches on the backend are not (as) widespread. Established imperative frameworks (Django, Rails, Spring Boot, etc) are still the huge majority.
> other thread
Very useful explanation, because at first it seemed unusual to see it on htmx.org, but well, different projects have different needs.
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!
Much respect for showing where htmx might not be as suitable as other tools. In my mind htmx is more a replacement for jQuery than React. htmx and jQuery both augment documents with interaction. React tries to be the entire document. Different tools for different jobs.
This is a great initiative. Too much people with little experience with non trivial web are vocal about htmx, and it's not a good thing for the projet.
thank you so much, I am a user since intercooler.
based, thank you
Is it just me or the article smells like AI-generated?
Your AI smell sensors need more training data to reduce hallucinations.
You can see the evolution of the article in the PR on GitHub. Seems genuine.
> 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
The AI and Tooling support point is really just an extension of the Community and Ecosystem point. Even before LLMs React had an advantage in that every question you had was probably already on StackOverflow and there are mature React libraries for almost everything. Now some people might use an LLM to answer the question they previously would have gone to StackOverflow for but the outcome is the same: there are advantages to using what other people are using.
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.
The problem is that for most domains our hammers are still pretty bad.
Agree. A lot of the most popular libraries/frameworks are not necessarily the best. Removing more fitness checks will only worsen this problem.
> LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools
This will be true for people who rely on LLMs to code, which I strongly suggest is not a great long-term bet for a software engineering career.
Yes. And no matter how good LLMs get at coding there will always be a crowd intentionally doing it themselves, especially in the open source arena, if only just to keep the joy alive.
I still think it's a perfectly fine productivity multiplier to use as long as you still understand what you're doing.
There's a very clear skill ceiling on the kind of code for which LLMs can serve as a productivity multiplier.
respectfully disagree. i think that the value of llm suggestions are driving us toward a kind of standardization that is really good. we'll all be java programmers soon!
If your devs can't work without something writing their code for them, why are you hiring them?
It's not about "being able" it is about being efficient. There are many cases where current AI can provide boilerplate and good examples for doing something specific, which eases things a lot.
There is a lot, of course, one can't take 1:1 into the final product, but it helps to find the right libraries, helps to find patterns, the right parts/functions to use where verification in the applicable documentation or source is a lot simpler than finding it in the docs to begin with.
Using it as a tool, while not a source of truth can be good.
And don't get me started about writing all the boilerplate which sometimes is needed, which is too complex for a simple editor shortcut, but too tedious for me as a human. That I review and fix a lot faster than create by hand.
I don't think it's so split between they can and can't. It's probably more about how it impacts velocity.
> If your devs can't work without something writing their code for them, why are you hiring them?
I am currently in the process of hiring a backend engineer. Anybody who does not use AI to aid development work gets an automatic disqualification. In my experience, a good engineer using AI tools will run circles around a good engineer not using AI tools.
Maybe they are just faster with AI.
I'm not too worried about this, and I think Gumroad's concern is likely overblown. I can't tell from their comment whether they actually experienced AI being bad at HTMX, or if they transitioned to talking about other resources.
LLMs are often wildly good at being universal translators. So if they pick up general patterns and concepts in popular frameworks, and enough syntax of more niche frameworks, IME, they do a pretty great job of generating good niche framework code.
Similar to how they can talk like a pirate about things things pirates never said in their training data.
In my experience, ChatGPT and Github Copilot are significantly worse at htmx compared to mainstream tech. They hallucinate A LOT more.
> they do a pretty great job of generating good niche framework code.
If you mean plausible looking code, yes - totally!
If you mean actually usable code: nope. Its always riddled with imaginary library calls that don't exist.
I had written a comment addressing this as well but you beat me to it. In a way it is similar to the effect StackOverflow had on popular libraries, but amplified. Even without StackOverflow, a library can do well if it has good documentation. I'm not sure if the same holds true with LLMs.
My prediction is that it'll be like this for a while, but as soon as tooling becomes better and the context of current APIs + local files gets better taken into consideration, this "advantage" will disappear.
This will not be true for future frameworks, though it is likely true for current ones.
Future frameworks will be designed for AI and enablement. There will be a reversal in convention-over-configuration. Explicit referencing and configuration allow models to make fewer assumptions with less training.
All current models are trained on good and bad examples of existing frameworks. This is why asking an LLM to “code like John Carmack” produces better code.. Future frameworks can quickly build out example documentation and provide it within the framework for AI tools to reference directly.
I don't think convention over configuration causes LLMs any problems, GitHub copilot generates code matching rails conventions quite easily for example.
Because there’s enough rails code in the training data to determine the proper conventions :) if you’re making something new without this glut of data, it’s going to be much more difficult for a coding assistant to match a convention it’s never seem before.
The thing is, with some elbow grease, you can write a great plugin for your preferred editor. No need for dubious LLMs results, especially when the difficult part, code intellisense, is already solved with LSP. If you're a shop that has invested in a framework, it would be cheaper and more productive.
But the new frameworks will never have anywhere near the amount of training data as established frameworks.
And:
- developers will be incapable of writing or debugging code for development stacks or project types without LLMs trained on lots of matching examples
"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?"
If your web form is more complex than a paper form, maybe rethink the former? I can not think of a form that can be implemented easily in react, but is difficult in Htmx other than wishing to plug in a React-like global application state and having the job 90% done as libraries.
I just looked at this iPhone alarm clock on Gum Road, which I also read about on HN. The page describing the clock is janky. Slowly scroll down the page (with a track pad) and it will jump up and down erratically as you get past the "Add to Cart" button. Hover your mouse in one vertical position on the page and it will turn the header on and off over and over again.
https://fatiharslan.gumroad.com/l/dieter-rams-inspired-vinta...
Maybe I'm a Luddite but I just get the feeling that we've gone very wrong in our over-engineering.
Yes. But you do it once at submission, not once per page.
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?
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.
Validating in multiple places doesn't mean 2x the code. You can validate on both the client and the server using the same code. One of the charms of server-side JS.
> 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.
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
It sounds to me like they shared a learning experience.
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.
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.
htmx vs. javascript reminds me behave (BDD) vs pytest tests: Gherkin language looks nice in simple cases, and it can be in principle extended for more complex cases, but pure python (pytest) becomes the more convenient the more complicated tests become (when it is necessary to manage several levels of abstractions.
> 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
Yeah, I've been using HTMX with UIKit components. Having a modern, stateful, and dynamic website is definitely not incompatible with HTMX.
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.
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/ would fit their needs better than HTMX, while still being similar to the concept?
"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);
}, []);Kudos to htmx.org for hosting this essay.
I really do value services/tools that explain why you shouldn't use it, as well as why you should.
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
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/
and then this tongue in cheek essay (many of the criticisms are legitimate):
https://htmx.org/essays/htmx-sucks/
We also have a mug for people who don't like htmx:
Yeah it's linked from https://htmx.org/essays/ under "On The Other Hand…"
Gumroad dude seems to have some shaky reasoning for migrating at all, sounds to me a migration just for the sake of it.
I mean, he clarified his reasoning and it made sense. Why do you think that moving away from RoR involves shaky reasoning here?
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)
?temp:gt=95&temp:lt=100
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!
:) 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!)
Why is this tongue-and-cheek? Doing this sincerely is a huge confidence builder.
What makes you think it was tongue-in-cheek? It sounds quite genuine to me?
Perhaps because of pages like this one: https://htmx.org/essays/htmx-sucks/ (note the URL)
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.
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.
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...
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.
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.
Funny, almost everything he said about htmx made me think, "this htmx sounds interesting, I should check it out".
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)
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.
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.
Thoughtful critique about a project posted to the project page? Beautiful, loved it, well done everyone involved.
> 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.)
does anybody else think that parts of this was written by ai? especially the end.
I don’t understand why the screenshot of the view on the right could not be created with htmx (or any UI framework/library).
> "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
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.
Which AI are you using for Elixir/Phoenix? I find that ChatGPT is as you describe for Elixir, but Claude writes Elixir very well.
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!
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.
https://data-star.dev combines ideas of htmx & solid (signals) and might be of interest to you
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.
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.
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.
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?
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
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"
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.
it's kind of the elm for javascript. vocal enthusiastic fans but no real usage beyond that miniscule enclave.
It's for python programmers who think front-end is an unavoidable evil but wish to avoid it anyway.
Why just Python? I feel excluded as a Go dev
To front-end devs you all look the same
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.
I will start using htmx as soon as there is a 20K MRR startup built only with it.
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.
Kinda wild that there is an entire generation of web devs for whom server side rendering is actually the new, strange thing.
convenient. I would have liked taking a look at your apps built only using htmx
The difference between a 20k MRR startup and lower will almost certainly not be because of HMTX.
this is true in theory but not in practice. just read the article, they came up to the same conclusion. if you want to offer a slick UX (a key element to convince users to pay these days) htmx won't cut it.
>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!