The Rise of Worse Is Better (1991)

JavaScript and the archetype of “worse is better”

• Many see JavaScript’s rise as textbook worse‑is‑better: hacked together quickly, poorly designed, yet ubiquitous on client and later server (via Node).
• Some argue it keeps getting “polished” (engines, TypeScript, ARM chips tuned for JS), others say the underlying language remains fundamentally flawed.
• WASM is viewed as a possible escape hatch (letting “better” languages run in the browser), but commenters note it lacks the incremental, tooling, and app‑model advantages needed to displace JS.
• Server‑side JS is divisive: some cite isomorphic code and familiarity; others say it’s chosen only by non‑polyglots and is a poor fit compared to alternatives.

Lisp, “The Right Thing”, and language taste

• Thread revisits Lisp vs C in the original essay’s historical context: Lisp once concentrated “right thing” features (GC, first‑class functions, macros, OO) now common elsewhere.
• Strong disagreement over Lisp’s real‑world value: some see it as beautiful, malleable, and “chill” to work in (REPL, macros, MOP); others find its culture off‑putting and its power overhyped.
• Homoiconicity and macros are praised but also blamed for unreadable “bespoke” Lisps, especially in teams.
• Several emphasize personal cognitive style and environment (solo vs large org) as key to whether Lisp helps or hurts.

Rust, C/C++, and modern language design

• Rust is debated as a potential MIT‑style “right thing” in systems programming: strong safety guarantees vs C’s “YOLO” model.
• Critics call Rust too complex and slow to compile; predict it will stay niche vs “simpler” Go/Zig or entrenched C++.
• Others argue Rust’s memory/concurrency safety is exactly what large institutions and kernels now want, even if not “worse‑is‑better”.
• Discussion touches on prior safe systems languages (Ada, Cyclone) and whether Rust’s ownership model is truly novel or just successfully productized.

Networking stacks and OSI vs TCP/IP

• OSI vs TCP/IP is discussed as a classic worse‑is‑better victory: messy but working TCP/IP beats elegant but heavy OSI.
• Some say the OSI model is pedagogically useful; others call it misleading, arguing real stacks don’t fit its fixed seven layers.
• Long linked critiques claim OSI was overdesigned for mainframe/terminal use and failed despite technical sophistication.

Expedience, satisficing, and product dominance

• A parallel concept of “expedience” is introduced: what wins is often not best, but easiest to adopt and hardest to regret (Amazon, mainstream social networks, certain cars).
• Related ideas: satisficing (“good enough” above a threshold), search costs, risk of unknown vendors, and liberal return policies explaining dominance despite non‑optimal quality or price.

Reframing “worse is better” and its limits

• Some see worse‑is‑better as a useful lens on time‑to‑market, evolving requirements, and the impossibility of perfect upfront design.
• Others argue it’s often post‑hoc rationalization for why one’s preferred “better” tech lost, or becomes toxic when turned into “move fast and break things”.
• Alternative formulation: prioritize minimal scope, timeliness, relevance, and integration with existing infrastructure over abstract simplicity/correctness.
• Counter‑essays (“Worse is Worse”, “Is Worse Really Better?”) are cited, and several note that “perfect is the enemy of good” captures part, but not all, of the dynamic.

Analogies and broader cultural reflections

• Non‑software examples (central vacuum systems, climate change geoengineering, clothing, cars) are used to generalize how cheaper, simpler, or more “expedient” options beat technically superior ones.
• Several comments lament path dependence and “mono‑memetics”: once an inferior standard goes viral (Unix/C, JS, TCP/IP), it’s nearly impossible to dislodge, even if superior designs exist.