Complexity bad: An interview with Htmx creator Carson Gross
1–10 of 17 posts
Re: Complexity bad: An interview with Htmx creator Carson Gross
#2I have been meaning to try Htmx out. Realising its author wrote 'grug brained developer' suddenly makes it a lot more attractive.
Re: Complexity bad: An interview with Htmx creator Carson Gross
#3[dead]
Re: Complexity bad: An interview with Htmx creator Carson Gross
#4I often meet dev shops trying to sell me on a whole dev team for their next,nuxt whatever stack, so I always tell people that it makes no sense to start with that stack. But for all the stimulus, livewire, htmx micro frameworks, htmx seems to be the one that has the least amount of documentation which can make it quite painful to work with at times.
It just seems like Django has a lot less documentation than all the other frameworks. I wonder why that is.
Re: Complexity bad: An interview with Htmx creator Carson Gross
#5I just don’t buy how this is a productive way to build websites. Having the functionality of HTMX natively supported would be nice but you’d still need much of what React does. HTMX’s docs seem to hand wave away front-end state management as something that no longer applies. Simultaneously, they also assume that every API you interact with will return HTML partials.
What could convince anyone to abandon the rich and bountiful lands of JSX and TypeScript? Who would prefer to move into a write-only and stringly typed HTML that competes with PHP for the slot of least performant debugging experience?
Maybe the answer is in the question…
Re: Complexity bad: An interview with Htmx creator Carson Gross
#6I just don’t buy how this is a productive way to build websites. Having the functionality of HTMX natively supported would be nice but you’d still need much of what React does. HTMX’s docs seem to hand wave away front-end state management as something that no longer applies. Simultaneously, they also assume that every API you interact with will return HTML partials. What could convince anyone to abandon the rich and…
people who want 66% less code, 50% faster load times
& 50% less memory use?
https://htmx.org/essays/a-real-world-react-to-htmx-port/
(Of course, it depends: https://htmx.org/essays/when-to-use-hypermedia/ but, if we are going to speak in generalizations…)
Re: Complexity bad: An interview with Htmx creator Carson Gross
#7I just don’t buy how this is a productive way to build websites. Having the functionality of HTMX natively supported would be nice but you’d still need much of what React does. HTMX’s docs seem to hand wave away front-end state management as something that no longer applies. Simultaneously, they also assume that every API you interact with will return HTML partials. What could convince anyone to abandon the rich and…
You aren't more productive when building websites but when maintaining them. Suddenly you don't need a way to scale the insanely complex bundling & caching anymore with each feature you add or deal with the js upgrade churn.
The more developers you have, the less React SPAs are scaling in my own experience. In my current company it's even visible on the bundling graph itself over time.
Re: Complexity bad: An interview with Htmx creator Carson Gross
#8I have been meaning to try Htmx out. Realising its author wrote 'grug brained developer' suddenly makes it a lot more attractive.
He should rename it to GrugScript
Re: Complexity bad: An interview with Htmx creator Carson Gross
#9I just don’t buy how this is a productive way to build websites. Having the functionality of HTMX natively supported would be nice but you’d still need much of what React does. HTMX’s docs seem to hand wave away front-end state management as something that no longer applies. Simultaneously, they also assume that every API you interact with will return HTML partials. What could convince anyone to abandon the rich and…
people who want 66% less code, 50% faster load times & 50% less memory use? https://htmx.org/essays/a-real-world-react-to-htmx-port/ (Of course, it depends: https://htmx.org/essays/when-to-use-hypermedia/ but, if we are going to speak in generalizations…)
Respectfully, those metrics are not proxies for productivity. They don’t seem to be grounded in a statical model either:
>They reduced the code base size by 67% (21,500 LOC to 7200 LOC)
> They increased python code by 140% (500 LOC to 1200 LOC), a good thing if you prefer python to JS
Literally what? So they rewrote their app, which was most definitely in a state of affairs that warranted a refactor, and then concluded it must’ve been the limits of React. Oh, and rewrite the back-end too while we sing the virtues of this library claiming a lower technical investment.
Believe me, I’ve got plenty of gripes with React. It’s very easy to build the wrong things with it. And the ecosystem is an overgrown mess. But I’d still prefer a problem of technical curation over debugging a library which marries HTML and server-side templates with an untyped DOM runtime.
Re: Complexity bad: An interview with Htmx creator Carson Gross
#10I often meet dev shops trying to sell me on a whole dev team for their next,nuxt whatever stack, so I always tell people that it makes no sense to start with that stack. But for all the stimulus, livewire, htmx micro frameworks, htmx seems to be the one that has the least amount of documentation which can make it quite painful to work with at times. It just seems like Django has a lot less documentation than all the…
Which other frameworks are you referring to when comparing documentation?
For shared reference, here are the latest Django docs:
https://docs.djangoproject.com/en/5.0/
And Django 5.x docs on DevDocs, which mirrors documentation for many projects with a unified interface: