A Rant about Front-end Development

Original Article ↗ Hacker News Discussion ↗

Semantic HTML, Accessibility, and Content

  • Many agree with the rant that “div soup” and misused tags (e.g., <ul> + manual numbers vs <ol>) are symptomatic of poor front-end practice.
  • Pro‑semantics camp: correct elements convey meaning (ordered vs unordered lists, tables for tabular data, regions, ARIA roles), help assistive tech, and enable machine legibility and future re‑presentation of content.
  • Skeptical camp: for many apps, users just need legible UI; caring about <section>, <header>, etc. is “life’s too short” minutiae if ARIA roles and visual behavior are fine.
  • Disagreement over how much search engines actually use semantic HTML; some argue crawlers largely ignore it because the web is invalid in practice.

CSS, Styling Approaches, and Tooling

  • Some strongly defend plain CSS: it’s powerful, specs are thoughtful, problems come from misuse (global soup, single huge stylesheet, only using <div>).
  • Others argue CSS is fundamentally ill‑suited for app‑like UIs and is the true pain point in modern FE.
  • Tailwind gets both praise (great shared design vocabulary, zero custom CSS, good for non‑devs) and criticism (utility soup, dependency bloat).
  • Classless CSS, BEM/CUBE, and simple component‑scoped styles are proposed as saner alternatives; CSS nesting and scoping in new specs are noted.

SPAs, React, and Framework Debate

  • Strong split:
    • Pro‑React/Next/etc.: unified language across client/server, components, type safety, routing, code‑splitting; easier onboarding because devs already know it; avoids reinventing a bespoke “organic” framework.
    • Anti‑React: over‑engineered, brittle, churn-heavy ecosystem, encourages junior‑friendly but long‑term‑fragile patterns, huge dependency trees, unnecessary for many sites.
  • Some see React’s rise as driven by bootcamps, hiring, and ability to coordinate large teams of average devs, not purely technical merit.
  • Others insist most problems blamed on React are organizational or misuse, not inherent to the library.

Server-Side Rendering vs Client-Side

  • Many advocate SSR or “95% SSR + 5% JS” using templates, htmx, Alpine, Turbo, etc., claiming better performance, maintainability, and simpler deployments.
  • Others prefer heavy client‑side rendering for interactive, stateful apps, arguing it simplifies state management and separates “backend = data” from “frontend = rendering”.
  • Static site generators and pre‑rendering are popular middle grounds.

Developer Skills, Culture, and Complexity

  • Recurrent theme: front-end is flooded with juniors and “framework cargo‑culting,” leading to bloated, inaccessible apps.
  • Counterpoint: back‑end developers also lean heavily on frameworks; it’s unfair to single out JS devs.
  • Several note front‑end now spans everything from simple blogs to “Photoshop in the browser,” so one “right” stack doesn’t exist.
  • Some see the rant as cathartic but solutions‑light; others say it accurately captures a real decline in craft and overuse of SPAs for simple content.