Everyone has JavaScript, right?

Original Article ↗ Hacker News Discussion ↗

Performance and Low-End Devices

  • Several argue devs should build and test on underpowered hardware and slow connections to feel real-world pain: cheap Android phones, school-filtered Chromebooks, 512MB RAM, spotty mobile data, trains with poor coverage.
  • Others think such scenarios are too niche for many products and not worth optimizing for unless explicitly part of the target context.

Target Audience and Business Tradeoffs

  • One view: if ~1–2% of users lack JS and aren’t core demographics, ignoring them is acceptable.
  • Counterview: many users globally have low-end hardware, unreliable connectivity, and limited data; heavy JS and assets effectively exclude them.
  • Some say big-volume, low-margin businesses (e.g., mass retail) must optimize for low-end users, not “Louis Vuitton” audiences.

JS Availability and Failure Modes

  • Discussion of corporate firewalls, SSL MITM proxies, and “security” appliances that can alter or break JS, especially on managed devices.
  • Disagreement over how common ISP/mobile manipulation is in modern HTTPS setups.
  • Cloudflare is characterized as a “man in the middle” but with site-owner consent; captchas and 3G behavior are specific pain points.

Extensions, Adblockers, and Responsibility

  • One side: if users install extensions that break JS, that’s their problem; devs shouldn’t cater to them.
  • Other side: from a business/user-experience view, broken sites are still the site’s problem; many users don’t understand the cause.
  • Ad/tracking blockers and privacy tools often break analytics-dependent JS; some see this as “unbreaking” the web.

Progressive Enhancement and Accessibility

  • Multiple comments endorse building primary content and core flows in HTML/CSS, using JS for enhancement and real interactivity.
  • Examples where critical flows (paying bills, shopping) are blocked by nonessential JS-heavy widgets and social buttons.
  • Screenreader users report JS can work well when it enhances rather than reimplements standard controls.

Attitudes Toward Supporting No-JS

  • Spectrum ranges from “JS or no service” and “latest browser only” to strongly advocating robust no-JS fallbacks.
  • Some praise sites that remain usable without JS; others argue modern, interactive apps reasonably depend on it.

JS Bloat, Data Usage, and Ecosystem

  • Complaints about enormous JS payloads on mostly-text sites, wasted mobile data, and sluggish experiences.
  • Some see JS and frameworks as enablers of good offline-like behavior and reduced roundtrips; others blame them for performance decay.
  • Side thread on TypeScript: some find it essential for large codebases; others find toolchain complexity and debugging painful.