[telman17]

Too often I read something frontend related on HN and am disappointed to find it’s full of hyperbole and/or just a lack of experience or knowledge at what having an actual job writing code on the frontend of a real software customers pay for is like. And half the time their “solution” is swapping out some predetermined mashup stack (usually nonsensical or worse, thrown together by a first year grad) for some other trendy tech.

It feels like the jquery years all over again when the landscape was filled with frontend influencers peddling their speaking services to talk about their naming semantics for css or whatever.

Not saying complexity doesn’t exist and maybe some of it isn’t needed but a surface level blog post that conveniently smooths over all the nuances and problems developers encounter in the real world doesnt do much for me. At worse it just adds to the pile of misinformation about front end in non toy applications.

[PaulHoule]

The HTMX route that this article is advocating has some value.

My YOShInOn RSS reader works that way and I think it is great -- but it is my own thing and I don't have customers and managers coming to me with requirements and I can build everything with that architecture in mind.

As I see it the basic front end problem is that you click on something and then the page is updated and this updating could be really simple (like you are typing into an autocomplete box and search results appear under it) or it might impact a large number of elements spread all over the page and some applications might be very dynamic and updating dependent on the UI state and can't be figured out ahead of times (imagine a developer tool which has lots of property sheets and tool windows)

HTMX is very simple for the simplest cases, requires some back end framework for harder cases (like a page might have 20 partials in it when it draws for the first time, 3 partials need to be redrawn when you click on something, you need to format a response packet that draws those 3 partials in the right place) and breaks down for the hardest cases. Part of the React puzzle is that we often use React for apps that don't need its full power but hey, even for something CMS-adjacent why fight with unintuitive Markdown (face it!) when you could write

   <MyElement attributeThatMattersToMe="yes">Here's the content</MyElement>

which conforms to your needs.

As much as I love HTMX, I got into it when my dissatisfaction with React was at its peak, more recently React is my go-to for anything from whimsical personalized landing pages to biosignals application that use Web Bluetooth, USB and Serial. Why? I use it at work all day and know how to get things done. I can draw anything at all, even 3-d worlds with A-Frame. That frustrating build system is clearing up.

[sublinear]

> Here is an idea: UI mostly server-driven, server-side rendered with the use of HTMX

Yeah it's more HTMX evangelism.

I agree with you, but I can sort of see their point. I have successfully advocated for and implemented very barebones static HTML/CSS pages for some clients in the past, but that's rarely the right choice. They wanted deep control of the exact markup and style because they cared the most about SEO, WCAG compliance, responsive mobile design, and legacy browser support. They did not have much interactivity apart from a couple of form tags. They even worked flawlessly without javascript enabled.

I know that sounds appealing to the naive and stubborn types who hate all other web dev, but there's a catch. The "simpler" a web page is, the more testing there will need to be. You're not reducing the complexity, but just moving it somewhere else. These pages were micromanaged into oblivion with frequent audits by large teams each with their own specific concerns. The majority of my time was coordinating a circus, not writing code. In that kind of situation, there is no other choice. It was an absurd amount of testing to make that work. All that for pages that barely did anything, and questionable business value. If you want your "bullshit job", look no further than that type of web dev.

The misunderstanding I see over and over is not realizing how broad web development is. I wouldn't be doing my job if I didn't optimize for maximum flexibility of the most actively developed implementation details the client cares about. The higher value web dev is interactive functionality, not bullshit marketing pages.

All I can really say is HTMX is not a tool I see myself ever reaching for any serious production use case. It will never beat plain static pages on flexibility, speed, or scalability. It will never beat serious web app frameworks like React or Vue on developer ergonomics and tools. More generally, server-side rendering is shooting yourself in the foot the moment you need to host off a CDN or migrate. The list of downsides is endless.