Claude Code transcript - page 1/1

# Hacker News Discussion: "Please Just Try HTMX"

## Key Discussion Themes

**Creator's Response**
recursivedoubts (HTMX creator) expressed discomfort with hyperbolic advocacy, stating: "I'm not a huge fan of these types of hyperbolic articles" while acknowledging the actual article proved "not nearly as unreasonable as I thought."

**Resume-Driven Development Debate**
azangru criticized the article's job market argument as fundamentally flawed, arguing developers should prioritize building quality products over market demand. However, multiple commenters countered that hiring difficulty and career portability are legitimate practical concerns when selecting technologies.

**Technical Criticisms**
perardi reported ripping out HTMX in favor of React, citing complexity in endpoint response handling, documentation gaps, and poor LLM support. Conversely, adamzwasserman detailed architectural patterns that work "smooth as glass," advocating single-purpose endpoints and optimistic UI patterns.

**Framework Comparison**
Discussions explored HTMX versus React, Unpoly, Astro, and Alpine.js. Key tension: HTMX requires server-side HTML generation and tight backend-frontend coordination, while React provides clearer separation of concerns but adds complexity and bundle size.

**Scaling Questions**
mikepurvis asked about extensibility when hitting HTMX's limits. Responses suggested the "islands of interactivity" pattern allows mixing HTMX with JavaScript frameworks for complex features.

**Organizational Impact**
wrs noted HTMX's requirement for backend developers to understand frontend concerns, potentially eliminating unhelpful silos but demanding different team structures than typical SPA architectures.

# Comments on Article Quality and AI-Generation

I searched the provided Hacker News discussion but found **no comments explicitly mentioning "slop," "AI generated," "ChatGPT," "LLM," "vibecoding," "low quality," or "shallow"** in relation to criticizing the article as AI-written or low-effort.

However, there are relevant discussions about documentation quality and LLM capabilities:

**On LLM limitations with HTMX:**
- One commenter noted that "LLMs aren't great at it" regarding HTMX documentation and best practices
- Another discussed how Claude struggles with Unpoly: "LLMs don't _get_ it, no matter how many pointers to the (excellent!) docs one includes"

**Author response to criticism:**
The article's author (algallagla) appeared late in the thread, stating: "I'm the author of the original article. fwiw, I haven't seen anything that bothers me" and emphasized they're "pretty light-hearted about this topic! It's more fun that way."

The creator of HTMX (recursivedoubts) initially expressed preference for a "chill vibe" but later acknowledged the article was "not nearly as unreasonable as I thought based on the just-f***ing-use template."

# Comprehensive Summary of HN Discussion on "Please Just Try HTMX"

## Author's Perspective & Tone

**recursivedoubts** (HTMX creator) expressed initial concern about the article's hyperbolic nature, preferring a "chill vibe" for HTMX promotion. However, he later acknowledged the piece wasn't "nearly as unreasonable" as expected and that "a lot of the criticisms are legitimate." He advocated for balanced assessment of tradeoffs rather than zealous advocacy.

The article's actual author appeared relaxed, stating they hadn't seen anything bothersome in responses and appreciated the lighthearted approach.

## Core Technical Debates

### HTMX vs. React Paradigm
**Major tension:** Resume-driven development vs. pragmatic architecture

**azangru** argued passionately that choosing technologies based on job market availability is problematic, citing Hacker News running on Lisp successfully. **Octoth0rpe** countered that language/framework popularity affects hiring ability and team maintainability—valid concerns beyond individual developers.

**perardi** (startup CTO) reported migrating away from HTMX, citing "response handling complexity" where "every endpoint returns 3-5 different HTML fragments" requiring frontend-backend coordination. However, **adamzwasserman** countered with architectural patterns minimizing this: single-purpose endpoints, optimistic UI updates, and fire-and-forget saves.

### Server-side HTML Rendering
**stefan_** expressed distaste for "HTML fragments contaminating everywhere," preferring clean API/SPA separation with static file serving for embedded devices (64MB ARM processors).

**ErroneousBosh** questioned this logic: "What would you return instead?" suggesting HTML generation isn't inherently problematic.

**leoedin** explained the embedded device argument—keeping server logic minimal for resource-constrained hardware—but **bccdee** countered that HTML templating is often cheaper than JSON serialization anyway.

### Extensibility & Complexity Wall
**mikepurvis** raised concerns about hitting HTMX's limits: "Where do I add JavaScript for things it doesn't natively do?" He wanted extensibility stories and real apps that pushed boundaries.

**lunar_mycroft** provided nuanced response: pure client-side needs should use vanilla JavaScript or Alpine.js; complex state could adopt "islands architecture" with JavaScript frameworks; if everything needs client interactivity, HTMX isn't suitable.

**gregmac** emphasized framework longevity depends on whether you can extend without rewriting everything—a "hard thing to get right."

## Documentation & LLM Training Issues

**ZeroConcerns** (Unpoly user) highlighted that LLMs struggle with Unpoly's specific patterns (like "shatter" for dismissing layered elements), regressing to "fragile cascading Javascript listeners." **recursivedoubts** deferred to this experience while hoping LLM support improves.

**perardi** noted "LLMs aren't great at" HTMX, making React more practical for "agentic AI coding"—a pragmatic if uncomfortable dependency on AI tooling.

## Hello World vs. Real-World Complexity

**g947o** criticized using tiny examples to sell frameworks, noting "Of course it will work...what does it prove?" He questioned whether backend dependencies and realistic scenarios were represented.

**foldr** pointed to htmx.org's real-world React-to-HTMX port essay as substantive evidence, though **g947o** countered that different teams have different needs—one success story doesn't prove universal applicability.

**yoyohello13** reported intranet apps built successfully with Python + HTMX without hitting limitations.

**adamzwasserman** showcased production apps (DecisionMe, multicardz) achieving excellent performance metrics (100/100 Lighthouse scores, 0.4s FCP).

## Organizational & Hiring Concerns

**moregrist** identified practical factors: ease of hiring experienced developers and long-term maintainability. Small job market (2 HTMX positions vs. 13,758 React) affects recruitment difficulty.

**marcus_holmes** elaborated that HN (Lisp-based) avoids this problem through prestige and internal hiring, but most projects lack that advantage. Training new developers in unpopular languages adds "six months of slow learning" and requires premium salaries.

**lbreakjai** bluntly stated: "I appreciate the idealism but I appreciate being able to pay my mortgage more."

## Alternative Frameworks & Solutions

**recursivedoubts** recommended **Unpoly** as "excellent" and "more complete" with "best in class progressive enhancement," while HTMX is "lower level" focusing on "generalizing hypermedia controls."

**lgvld** mentioned Alpine AJAX for simpler usecases, finding Unpoly "too complex."

**chuckadams** noted Unpoly uses Arc (Lisp dialect)—maximally niche.

**alfonsodev** described journey from React burnout → HTMX → **Astro**, appreciating its "islands of interactivity" providing JSX components while avoiding pure template engines.

## Error Handling & Production Patterns

**yellow_lead** struggled with HTMX error handling for file uploads, settling on `htmx:afterRequest` listeners.

**wvbdmp** proposed returning errors as text/plain with global dialog handlers, using CSS :empty selectors for animations.

**MrPowerGamerBR** described server-driven modal/toast responses parsed globally, avoiding custom per-endpoint listeners.

## Framework Maturity Concerns

**perardi** cited lack of "established best practices at scale" and "lacking documentation/examples" as reasons for abandoning HTMX despite initial enthusiasm.

**adamzwasserman** promoted **DATAOS.software** as emerging "best practices cookbook" beyond Hypermedia Systems book.

**komali2** noted Vue's "progressive" marketing confused adoption—if using Vue, commit fully rather than fragment adoption.

## Agreement on Trade-offs

Consensus emerged that:
- HTMX suits CRUD/admin tools, content sites, and intranet apps
- React remains superior for highly interactive SPAs, embedded devices with weak servers, and when LLM assistance is valued
- Both approaches have legitimate use cases; neither universally optimal
- Job market realities affect technology selection regardless of technical purity
- Server-rendered HTML fragments require careful architecture to avoid chaos

## Tone & Community Dynamics

**internet2000** warned against HTMX becoming known for "overbearing advocates," citing Rust's community reputation damage. **bccdee** countered that annoying blog posts don't actually harm adoption and noted Rust thriving despite controversies.

**moralestapia** stated they'd "never touch htmx" after witnessing the interaction—suggesting some found the discourse itself off-putting.

**puppy_lips** appreciated the creator's "unhinged energy" and transparency.

# Hacker News Thread Summary

**Original Comment by furyofantares:**
The user critiques a post about HTMX, arguing the article appears LLM-generated. They note: "You're not a fucking person, this is LLM output" and claim the AI writing erased the author's authentic perspective, leaving only "mediocre infodump" without genuine insight.

**Response by rpdillon:**
This commenter requests evidence and investigates the GitHub repository, discovering the initial commit appears AI-generated with human edits following. They acknowledge "algal" is a real person behind the work.

**Clarification by furyofantares:**
The original critic clarifies they didn't deny the author's humanity, only that the quoted line wasn't human-written. They point to stylistic red flags—excessive heading usage and marketing-speak fluff—as indicators. The core complaint: readers cannot discern what genuinely excited the author beyond the title.

**Additional Comments:**
- **chamomeal** laments the missed creative opportunity and questions why the community hasn't called out the obvious AI style
- **furyofantares** theorizes readers skim content, making low-effort AI posts viable for generating comment discussion
- **nicolaslem** suggests it may be intentional homage to certain shock-value websites
- **algallagla** (the author) responds: "I get it. Sorry if I wasted your time."