Complexity bad: An interview with Htmx creator Carson Gross

https://www.infoworld.com/article/3713164/complexity-bad-an-interview-with-carson-gross.html

by floobertoober • 2 years ago

58 15 2 years ago

imjonse• 2 years ago

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

jt2190• 2 years ago

He should rename it to GrugScript

rjzzleep• 2 years 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• 2 years 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/

And Django 5.x docs on DevDocs, which mirrors documentation for many projects with a unified interface:

https://devdocs.io/django~5.0/

throwaway2845342• 2 years 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…

recursivedoubts2• 2 years 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/

(Of course, it depends: https://htmx.org/essays/when-to-use-hypermedia/ but, if we are going to speak in generalizations…)

throwaway2845342• 2 years 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.

realusername• 2 years ago

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.

avisser• 2 years ago

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)

ralmidani2• 2 years ago

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.

jiggawatts• 2 years ago

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.

nsonha• 2 years ago

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

chuckadams• 2 years 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.

Complexity bad: An interview with Htmx creator Carson Gross

Related Stories