Developing a Modern Full-Stack Application: Choosing the Right Tech Stack

Original Article ↗ Hacker News Discussion ↗

Choosing a “modern” full‑stack setup—TypeScript/Node backends, Prisma, Next.js, and managed platforms like Vercel—raises sharp trade‑offs between developer experience, performance, and operational reliability. Commenters argue over whether Node and ORMs can scale or inevitably cause bottlenecks, contrast hype‑driven stacks with “boring” frameworks like Rails, Django, or Go, and question the wisdom of deep vendor lock‑in and fragile serverless tooling. Many conclude that for typical CRUD SaaS apps, database design, architecture, and mature infrastructure matter more than chasing the latest stack.

Backend language and performance

  • Strong disagreement over Node.js/TypeScript backends:
    • Critics say Node/TS is inherently slow for CPU-heavy work (large arrays, math), fine for v1 but painful at scale; prefer Go/Rust/Java from the start.
    • Others argue Node’s performance is comparable to Java/Go for typical web workloads; most apps are I/O-bound and hit DB limits before CPU.
    • Some cite TechEmpower benchmarks to claim Node is slow; others counter with high-performing JS runtimes/frameworks and note all stacks rely on native code underneath.
    • Consensus that heavy computation should often be offloaded to separate services, regardless of main backend language.

ORMs, querying, and Prisma

  • Prisma draws substantial criticism: slow, inflexible for complex queries, known open issues; some would avoid it entirely.
  • Defenders say Prisma is fine for most cases and that you can drop to raw SQL when needed; others prefer Drizzle, Zapatos, or direct SQL with type-safe wrappers.
  • Several note that ORM misuse and huge query results cause performance problems in any language; better to chunk/stream data and optimize DB/indexes.

TypeScript’s type system

  • Debate over “only sort of static”:
    • One side emphasizes progressive typing, any/unknown, and lack of runtime types; also notes runtime mismatches (e.g., schema changes vs long-lived clients).
    • Others insist TS is statically typed but not fully sound, and that you should pair it with runtime validation (e.g., zod/yup) at boundaries.

Infra, hosting, and “boring tech”

  • Many pain points reported with modern managed/serverless stacks (e.g., Vercel): flaky migrations and cron jobs, odd env var and caching behavior, auth library quirks, background-job limits due to function timeouts.
  • This fuels support for “choose boring technology” (traditional AWS, Rails/Laravel/Django, self-hosted Postgres/MySQL, simple VPS) to avoid hype-driven paper cuts.
  • Concerns about Next.js vendor lock-in and weak self-hosting story; some prefer Remix or container-based platforms like Cloud Run.

HTMX, PocketBase, and alternative stacks

  • HTMX: praised for simple apps and avoiding heavy JS toolchains; critics say hype is strong, complex UX becomes hard to maintain and staff for, not a full SPA replacement.
  • PocketBase + SQLite: lauded for speed and rapid setup; skeptics worry about single-instance availability and “not production-ready” status, but others note most apps never hit those limits.
  • Multiple commenters advocate classic monolithic stacks (Rails/Laravel/Django + Postgres/MySQL) or Go-based stacks for balance of simplicity, performance, and maturity.

Security and frameworks

  • Custom auth shown as hash-based (bcrypt) but flagged as likely vulnerable to timing and other subtle issues.
  • Several argue that established frameworks (Laravel/Django/Rails) reduce such risks and let teams focus on product rather than re-inventing backend fundamentals.