4 ms·

Complexity bad: An interview with Htmx creator Carson Gross

58 points by floobertoober 3y ago

imjonse 3y ago
I have been meaning to try Htmx out. Realising its author wrote 'grug brained developer' suddenly makes it a lot more attractive.
- jt2190 3y ago
  He should rename it to GrugScript
wetpaws 3y ago
[dead]
rjzzleep 3y ago
I 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.
- brylie 3y ago
  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/ https://docs.djangoproject.com/en/5.0/ And Django 5.x docs on DevDocs, which mirrors documentation for many projects with a unified interface: https://devdocs.io/django~5.0/ https://devdocs.io/django~5.0/
throwaway284534 3y ago
I 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…
- recursivedoubts 3y ago
  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/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ (Of course, it depends: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ but, if we are going to speak in generalizations…)
  - throwaway284534 3y ago
    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.
    - ralmidani 3y ago
      Comparing percentages can be misleading. 8,400 total LOC vs. 22,000 total LOC is an incredible win.
    - recursivedoubts 3y ago
      ¯\_(ツ)_/¯ there's always going to be an excuse if you want there to be this is a real world situation (warts and all) where someone rewrote their whole app that had taken them two+ years to build and that was stalled with htmx in two months from a cold start w/no falloff in UX, they simplified the codebase tremendously, they improved performance in both dev & prod and it flipped their entire team to full stack, eliminating a flow bottleneck in their development process i try to be balanced about things, outlining when hypermedia is a good choice (it was in this case) and when it isn't, but c'mon... if a more conventional reactive library showed this sort of improvement you'd be interested in learning more. So, maybe it's worth a more serious look, despite your priors? The ideas are interesting, at least: https://hypermedia.systems https://hypermedia.systems
nsonha 3y ago
"Complexity bad so let's do complexity in a different way"
chuckadams 3y ago
There's nothing about htmx that would make me choose it over my preferred framework of VueJS, but I am very supportive of its central premise: that anchors and form actions should be able to target their output at the granularity of individual elements, not just entire documents. I think it would be a common-sense evolution to the HTML standard, along with scoped ids.

58 points by floobertoober 3y ago

I have been meaning to try Htmx out. Realising its author wrote 'grug brained developer' suddenly makes it a lot more attractive.

jt2190 3y ago
He should rename it to GrugScript

wetpaws 3y ago

[dead]

rjzzleep 3y ago

I 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.

brylie 3y ago
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/ https://docs.djangoproject.com/en/5.0/ And Django 5.x docs on DevDocs, which mirrors documentation for many projects with a unified interface: https://devdocs.io/django~5.0/ https://devdocs.io/django~5.0/

throwaway284534 3y ago

I 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…

recursivedoubts 3y ago
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/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ (Of course, it depends: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ but, if we are going to speak in generalizations…)
- throwaway284534 3y ago
  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.
  - ralmidani 3y ago
    Comparing percentages can be misleading. 8,400 total LOC vs. 22,000 total LOC is an incredible win.
  - recursivedoubts 3y ago
    ¯\_(ツ)_/¯ there's always going to be an excuse if you want there to be this is a real world situation (warts and all) where someone rewrote their whole app that had taken them two+ years to build and that was stalled with htmx in two months from a cold start w/no falloff in UX, they simplified the codebase tremendously, they improved performance in both dev & prod and it flipped their entire team to full stack, eliminating a flow bottleneck in their development process i try to be balanced about things, outlining when hypermedia is a good choice (it was in this case) and when it isn't, but c'mon... if a more conventional reactive library showed this sort of improvement you'd be interested in learning more. So, maybe it's worth a more serious look, despite your priors? The ideas are interesting, at least: https://hypermedia.systems https://hypermedia.systems

nsonha 3y ago

"Complexity bad so let's do complexity in a different way"

chuckadams 3y ago

There's nothing about htmx that would make me choose it over my preferred framework of VueJS, but I am very supportive of its central premise: that anchors and form actions should be able to target their output at the granularity of individual elements, not just entire documents. I think it would be a common-sense evolution to the HTML standard, along with scoped ids.