51–60 of 216 posts
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!
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!)
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…
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…
Earlier quoted context omitted.
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)
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.
> 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…
> 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…
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
Earlier quoted context omitted.
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 li…
I don't think convention over configuration causes LLMs any problems, GitHub copilot generates code matching rails conventions quite easily for example.