Building the same app using various web frameworks

Original Article ↗ Hacker News Discussion ↗

Building the same simple CRUD app in multiple web frameworks highlights trade-offs between productivity, long-term maintainability, and architectural choices. Commenters contrast batteries-included monoliths like Rails, Laravel, Django, or Phoenix with serverless stacks and “vanilla” approaches, arguing over costs, complexity, security exposure through dependencies, and how easily code can be updated years later. Many also note that AI coding assistants and newer tools like HTMX, FastHTML, SvelteKit, and Bun are reshaping how developers choose languages and frameworks, while sometimes reinforcing bad patterns or outdated APIs.

AI and Coding Assistants

  • Assistants can speed up scaffolding across frameworks but often suggest deprecated patterns, nonexistent functions, or outdated React idioms.
  • Their usefulness depends heavily on up-to-date docs: people recommend feeding framework documentation (often single-page markdown) into tools like Cursor.
  • Some worry that improving assistants plus code-gen will erode demand for certain roles, especially frontend.

Framework Ergonomics and Patterns

  • For Next.js and SvelteKit, several argue that using built-in “actions”/form-actions is cleaner than rolling separate API routes, with better progressive enhancement and built-in validation/loading/error handling.
  • Full-stack monoliths (Phoenix, Rails, Laravel, Django, Laravel) are praised for productivity: one-command CRUD, batteries-included auth/queues/emails, ideal for small teams.
  • Others complain that some “HN-favorite” frameworks (e.g., Phoenix) can be painful to upgrade and suggest sticking to “boring” stacks.
  • There’s interest in Python HTML-in-Python approaches (FastHTML, htpy) and JSX-like ideas for Python, but concerns about maturity (e.g., demo apps with plaintext passwords).

Serverless vs Always-On Servers

  • Some claim serverless/Lambda-based systems are a maintenance nightmare: hard local testing, complex configs, debugging across many AWS services, secret-management costs, and architectural sprawl.
  • Others report well-tested FaaS systems are feasible, but complain about stability and very high production cloud costs.
  • A counterargument: a small always-on server is cheap and simpler; “scale-to-zero” benefits can be outweighed by cold starts and operational pain.

Vanilla Stacks, Dependencies, and Security

  • One camp favors minimal or “vanilla” stacks (Go, plain Node/Deno, web components, HTMX) to avoid dependency hell, upgrade churn, heavy tooling, and framework lock-in.
  • Another camp argues frameworks reduce cognitive load, standardize conventions, and are easier for teams; rewrites away from frameworks often cost more than server bills.
  • Security debate:
    • Fewer dependencies ⇒ smaller attack surface and fewer supply-chain risks.
    • More popular libraries ⇒ more eyes, tooling, and vulnerability scanning; self-written code gets no such scrutiny.
    • “Security by popularity” vs “security by obscurity” are both criticized; context and scale matter.

Languages, Platforms, and Other Notes

  • Some prefer non-JS languages (Gleam, Go, C# with Blazor, Django/Python) for core logic, using JS only for necessary UX “sprinkles.”
  • Go+templates+HTMX is praised for internal apps; Blazor gets mixed reviews vs traditional ASP.NET Razor or React.
  • There’s side debate on Go vs C# for concurrency and cloud cost, with conflicting performance claims.
  • One commenter highlights that real framework comparisons should include correctness (e.g., proper CSV escaping, streaming large data) rather than only folder structure and “toy” CRUD.