Building the same app using various web frameworks

Original Article ↗ Hacker News Discussion ↗

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.