Developing a Modern Full-Stack Application: Choosing the Right Tech 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.