Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Complexity bad: An interview with Htmx creator Carson Gross

infoworld.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Complexity bad: An interview with Htmx creator Carson Gross

#11

Post by avisser »

throwaway284534 wrote: post #5

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…

> 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)

Re: Complexity bad: An interview with Htmx creator Carson Gross

#12

Post by ralmidani »

throwaway284534 wrote: post #5

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…

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

Re: Complexity bad: An interview with Htmx creator Carson Gross

#13

Post by ralmidani »

throwaway284534 wrote: post #9
recursivedoubts wrote: post #6

Earlier quoted context omitted.

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

Comparing percentages can be misleading. 8,400 total LOC vs. 22,000 total LOC is an incredible win.

Re: Complexity bad: An interview with Htmx creator Carson Gross

#14

Post by recursivedoubts »

throwaway284534 wrote: post #9
recursivedoubts wrote: post #6

Earlier quoted context omitted.

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

¯\_(ツ)_/¯

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

Re: Complexity bad: An interview with Htmx creator Carson Gross

#16

Post by chuckadams »

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.

Re: Complexity bad: An interview with Htmx creator Carson Gross

#17

Post by jiggawatts »

throwaway284534 wrote: post #5

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…

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.

Post reply on HN