Complexity bad: An interview with Htmx creator Carson Gross(infoworld.com)
infoworld.com
Complexity bad: An interview with Htmx creator Carson Gross
https://www.infoworld.com/article/3713164/complexity-bad-an-interview-with-carson-gross.html
16 comments
> 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.
I feel like you're begging the question that you need front-end client & state. I have ASP.NET apps still running from 10 years ago. They're fine. I'm adding HTMX to remove the page reloads. Why do I _need_ anything else?
(edited HTML => HTMX)
> HTMX’s docs seem to hand wave away front-end state management as something that no longer applies.
I feel like you're begging the question that you need front-end client & state. I have ASP.NET apps still running from 10 years ago. They're fine. I'm adding HTMX to remove the page reloads. Why do I _need_ anything else?
(edited HTML => HTMX)
Define "need".
I've been consulting for a large org where someone decided that every web app needs to use a consistent pattern, and they mandated Angular. This could have been React, Vue, whatever, the point is that they picked a client-side JavaScript framework for all of their web apps.
Turns out that they weren't actually making web "apps". They were making web sites with mostly read-only content and a handful of web forms.
Traditional server-side templating, like Razor pages, is a well-established method for handling this. Something like HTMX adds the tiny bit of client-side interactivity that is actually required. Nothing else is needed.
The article talks about about reducing code size to 2/3rds and you just handwave that away!?
That's the exact same thing I've been telling my customer! They're literally bloating out their codebase three times over (3x!) by using JavaScript client-side rendering instead of plain, ordinary, boring, and simple server-side rendering like they should have.
For every single thing that they do, they need a C# bit of code and a TypeScript bit of code, and a whole API thing to wire the two up. They are forced to use distributed monitoring spread across the browser (untrusted!) and the server! Deployments have to factor in client-side cache expiry! And on, and on, and on.
I did a demo for them recently where I rewrote several thousand lines of code with 50. Not fifty thousand. Fifty.
"Thousands of lines? This is fine" -- says the developer on the hourly contractor rate.
I've been consulting for a large org where someone decided that every web app needs to use a consistent pattern, and they mandated Angular. This could have been React, Vue, whatever, the point is that they picked a client-side JavaScript framework for all of their web apps.
Turns out that they weren't actually making web "apps". They were making web sites with mostly read-only content and a handful of web forms.
Traditional server-side templating, like Razor pages, is a well-established method for handling this. Something like HTMX adds the tiny bit of client-side interactivity that is actually required. Nothing else is needed.
The article talks about about reducing code size to 2/3rds and you just handwave that away!?
That's the exact same thing I've been telling my customer! They're literally bloating out their codebase three times over (3x!) by using JavaScript client-side rendering instead of plain, ordinary, boring, and simple server-side rendering like they should have.
For every single thing that they do, they need a C# bit of code and a TypeScript bit of code, and a whole API thing to wire the two up. They are forced to use distributed monitoring spread across the browser (untrusted!) and the server! Deployments have to factor in client-side cache expiry! And on, and on, and on.
I did a demo for them recently where I rewrote several thousand lines of code with 50. Not fifty thousand. Fifty.
"Thousands of lines? This is fine" -- says the developer on the hourly contractor rate.
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.
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.
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…)
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.
>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.
¯\_(ツ)_/¯
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
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
Comparing percentages can be misleading. 8,400 total LOC vs. 22,000 total LOC is an incredible win.
> hand wave away front-end state management as something that no longer applies
Does client-side state often need to exist independently of server-side state? I’m having trouble imagining a shopping cart or email draft being optimal UX-wise without the ability to resume on a different device.
For things like dropdowns and modals, you can bring in _hyperscript, Bootstrap, Alpine, or even CSS hacks (my preferred approach).
> the rich and bountiful lands of JSX and TypeScript
One person’s richness is another person’s needless complexity.
JSX is cool when you first try it, but the novelty wears off (at least for me it did). There are superior templating languages (Django, Jinja, EEx, erb) that don’t require bizarre syntax such as nested ternaries, and they make it feel like you’re just using a slightly-enhanced superset of HTML (not to mention being able to use them to render things other than HTML).
As for TypeScript, with the checks stripped out at runtime, you’ll still need to validate and test the assumptions your typed code is making. Frankly, TS seems like busywork to me.
Finally, Progressive Enhancement is a thing with htmx. You might be able to have it with React, but then you introduce even more complexity into the build system.
Does client-side state often need to exist independently of server-side state? I’m having trouble imagining a shopping cart or email draft being optimal UX-wise without the ability to resume on a different device.
For things like dropdowns and modals, you can bring in _hyperscript, Bootstrap, Alpine, or even CSS hacks (my preferred approach).
> the rich and bountiful lands of JSX and TypeScript
One person’s richness is another person’s needless complexity.
JSX is cool when you first try it, but the novelty wears off (at least for me it did). There are superior templating languages (Django, Jinja, EEx, erb) that don’t require bizarre syntax such as nested ternaries, and they make it feel like you’re just using a slightly-enhanced superset of HTML (not to mention being able to use them to render things other than HTML).
As for TypeScript, with the checks stripped out at runtime, you’ll still need to validate and test the assumptions your typed code is making. Frankly, TS seems like busywork to me.
Finally, Progressive Enhancement is a thing with htmx. You might be able to have it with React, but then you introduce even more complexity into the build system.
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.
"Complexity bad so let's do complexity in a different way"
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.
It just seems like Django has a lot less documentation than all the other frameworks. I wonder why that is.
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:
https://devdocs.io/django~5.0/
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:
https://devdocs.io/django~5.0/
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…