Things engineers believe about Web development

Original Article ↗ Hacker News Discussion ↗

Engineers debate common myths around modern web development, from whether browsers are truly good at handling complex dynamic UIs to when single-page app frameworks are justified over simpler, server‑rendered multipage sites. Many argue that heavy JavaScript stacks, build steps, and SPA architectures are overused for basic CRUD and content sites, creating performance, accessibility, and maintenance costs that outweigh UX benefits, while others counter that reactive front-end tools are more productive once interactivity grows. Underneath is a broader tension between “simplest tool that works” versus “most flexible/modern stack,” shaped by developer familiarity, hiring incentives, and the split between desktop‑style app expectations (e.g. Figma, Photoshop) and the web’s original document-centric model.

Browser rendering performance & alternatives

  • Some disagree that browsers are “good at” complex, long‑lived DOM trees; others argue decades of optimization make them hard to beat for dynamic trees.
  • Alternatives cited: WPF (Windows) and Avalonia (cross‑platform) with built‑in data binding/templates; game engines and WebGL/canvas renderers that easily handle thousands of animated objects.
  • Examples: Figma, Google Docs/Sheets and Photoshop-on-web bypass much of the DOM using WebGL/canvas/WASM, seen by some as evidence the DOM is a poor fit for complex UIs.

JavaScript, graceful degradation & accessibility

  • A vocal minority advocates sites working without JS, especially content and simple CRUD apps, for robustness, testing, and accessibility.
  • Others see JS‑off users as negligible and argue business reality doesn’t justify designing for them.
  • Counterpoints: flaky networks can “disable” JS in practice, microbrowsers/crawlers don’t run full JS, and heavy SPAs degrade UX on low-end or mobile devices.

SPA vs MPA, interactivity spectrum & tool choice

  • Big theme: Figma/Photoshop are overused as justification for SPA stacks on mostly CRUD apps.
  • One camp: prefer minimal JS, server‑rendered MPAs for simpler apps; complexity should live on the backend; SPAs are “motte-and-bailey” (clearly right for rich editors, weak for most apps).
  • Other camp: SPAs (React/Preact/Vue etc.) feel architecturally simpler for rich interaction, accumulate benefits as features grow, and give smoother UIs (e.g., faceted filters, maps).
  • Many point out middle-ground patterns: progressive enhancement, partial HTML updates (Turbolinks/Hotwire-like), server components, islands/SSR, and embedding isolated SPA widgets into MPAs.
  • UX tradeoffs: SPAs can feel faster and more fluid, but often mishandle history, fail under intermittent connectivity, and ship large JS bundles; MPAs can flicker and feel “jarring” without optimization.

Build steps, tooling & DX

  • Some argue “web shouldn’t need a build step”; build pipelines add latency, complexity, and frequent breakage when returning to old projects.
  • Others defend build steps for tree‑shaking, bundling, HMR, and static typing via TS/Rust/WASM, while noting JS build tooling is unusually fragile and fast‑changing.
  • Alternatives mentioned: simple server‑side includes, static site generators, or embedding admin UIs directly into backend services instead of separate Node frontends.

Desktop vs web apps & sandboxing

  • One side prefers heavy apps as native desktop software, seeing the browser as a document viewer.
  • Others strongly prefer running such apps in the browser for sandboxing and easier teardown, citing invasive native clients (e.g., always‑running background processes).
  • Long subthread debates whether browsers are “more secure” than native or mobile apps, versus simply another (very complex) sandbox layer; concerns raised about Chromium monoculture vs app‑store duopolies.

Other recurring themes

  • Frequent tension between “simplest tool that works now” vs “flexible tool that might cover future needs.”
  • Complaints about resume‑driven and fashion‑driven tech choices.
  • Observations that browser specs and engine teams often lack day‑to‑day web‑dev perspective; conversely, many web devs misunderstand engine constraints.