How to make websites that will require lots of your time and energy

Dependencies, Reuse, and “Rolling Your Own”

• Many agree the problem isn’t dependencies themselves but using them indiscriminately for trivial tasks (“is-odd”-style packages).
• Some prefer vendoring tiny libs or reimplementing simple logic rather than pulling in full npm trees.
• Others point out that correctness in JavaScript edge cases and bad inputs can justify even small utilities, depending on how much you care about trash input.

Components, Templating, and PHP

• Simple copy‑paste HTML is defended for tiny sites, but others describe how it quickly becomes unmanageable when shared headers/nav bars change across many files.
• Lightweight templating (custom scripts, includes, nginx/Lua, bash/Python generators) is presented as a middle road between “just HTML” and full frameworks.
• PHP is praised as an underrated HTML preprocessor, but critiqued as becoming unmaintainable once inline logic grows beyond triviality.

Frameworks, Overengineering, and Motivation

• A recurring theme: frameworks and complex stacks often stem from overengineering, boredom, or resume/skill maintenance rather than need.
• Some deliberately avoid frameworks to keep things simple, then end up with small ad‑hoc “frameworks” anyway.
• Others argue frameworks (Astro, Svelte, Django, etc.) can be a huge productivity boost for non‑trivial sites, and that refusing them can be its own kind of dogma.

Build/Compilation Steps and TypeScript

• The article’s jab at “always requiring a compilation step” resonated as a joke about needless complexity.
• Several commenters defend compilation and TypeScript as essentially mandatory for large projects; using TS is framed as a practical, not fashionable, choice.
• Others prefer JSDoc or minimal build steps to avoid long‑term tooling churn and bitrot.

ORMs, SQL, and Performance vs Safety

• ORMs trigger a large, mixed debate: some complain about N+1 queries, bloated joins, and performance mysteries; others report years of success with mature ORMs (Django, EF, Ecto, etc.).
• Pro‑ORM arguments: safer defaults (avoiding SQL injection), easier migrations, schema evolution, type safety, and clearer data‑layer boundaries.
• Anti‑ORM arguments: hidden complexity, custom DSLs to learn, leaky abstractions for complex queries, and teams eventually fighting both ORM and database.
• Multiple people note that teams avoiding ORMs often reinvent worse, homegrown versions—or scatter raw SQL insecurely across the codebase.

Maintenance, Dependency Churn, and Security

• Frontend stacks (React/Next, CRA) are cited as particularly brittle: old projects become hard to update, with time spent fighting the toolchain instead of adding features.
• Some advocate pinning versions and updating cautiously; others highlight that pinned dependencies still become security liabilities and must eventually be replaced or patched.

Organizational and DevOps Complexity

• Commenters joke (and complain) about spinning up CI, platform teams, Terraform, Kubernetes, multi‑AZ clusters, etc. before a single page ships.
• Backend “anti‑patterns” listed include hand‑configured servers, no config management, no backups, unmanaged TLS certs, and noisy monitoring/alerts.
• Several threads suggest that much of modern complexity exists to justify roles or follow cargo‑culted “big company” practices, not actual project needs.