Javascript, the good, bad and ugly.

22-12-2022

Contents

Brendan Eich wrote the first version of JavaScript in ten days in May 1995, under pressure to ship something for the Netscape Navigator 2.0 beta. He had wanted to put Scheme in the browser; management wanted something that looked like Java, because Java was the hot thing that year. So he took the functional core of Scheme, the prototype-based objects of Self, and bolted on a curly-brace syntax that resembled Java without behaving anything like it. The result was called Mocha, then LiveScript, and finally — in a marketing deal with Sun — JavaScript. Three names and a deadline measured in days. Three decades later that ten-day prototype runs in every browser on earth, on servers, on embedded boards, and increasingly inside my home automation. I have shipped a lot of JavaScript and I have sworn at a lot of JavaScript, often in the same afternoon. This is the honest tour: where it earns its place, where it irritates, and where it genuinely gets ugly. <h2 id="why-the-language-is-the-way-it-is">Why the language is the way it is</h2><div class="ad-unit ad-in-article" aria-label="Advertisement"> Advertisement <ins class="adsbygoogle" style="display:block;text-align:center" data-ad-client="ca-pub-3726833845844946" data-ad-slot="3291553914" data-ad-format="auto" data-full-width-responsive="true"></ins> <script>(adsbygoogle = window.adsbygoogle || []).push({});</script> </div> Almost every complaint people have about JavaScript traces back to that origin story. The ten-day deadline meant rough edges shipped. The “must look like Java” mandate gave it a syntax that promises class-based, statically-typed behaviour and then delivers prototype-based, dynamically-typed behaviour underneath — a mismatch that confuses people for years. And the fact that it landed in the browser, where breaking old pages is unforgivable, means the language can almost never remove a mistake. Bad decisions become permanent. Understanding that history is the single most useful thing you can do before judging the language, because it explains why the good and the ugly live so close together. The other thing worth knowing up front: there is the language (ECMAScript, governed by TC39, with a yearly spec since ES2015) and there is the ecosystem (npm, bundlers, frameworks, the whole churning mess). Most of the day-to-day pain is the ecosystem, not the language. I’ll keep them separate where I can, because conflating them is how people end up shouting at the wrong thing. <h2 id="the-good">The good</h2> It is genuinely everywhere, and that is a real superpower. One language runs the browser, the server (Node, Deno, Bun), build tooling, serverless functions, desktop apps via Electron, and a surprising amount of IoT. I can write a validation function once and run the identical code on the client for instant feedback and on the server where it actually matters for security. No other language has that reach without a compile-to-target hop. For a small team or a solo tinkerer, the cognitive saving is enormous. The asynchronous model is excellent. This is the part people underrate. JavaScript’s single-threaded event loop with non-blocking I/O is a fantastic fit for the thing most software actually does: wait on the network and the disk. <code>async</code>/<code>await</code> (standardised in ES2017) turned callback hell into code that reads top-to-bottom: <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-javascript" data-lang="javascript">// Fetch in parallel, fail loudly, and don't block the event loop async function loadDashboard(userId) { try { const [profile, orders] = await Promise.all([ fetch(`/api/users/${userId}`).then((r) => r.json()), fetch(`/api/users/${userId}/orders`).then((r) => r.json()), ]); return { profile, orders }; } catch (err) { console.error("dashboard load failed:", err); throw err; // let the caller decide what to render } } </code></pre></td></tr></table> </div> </div><code>Promise.all</code> fires both requests at once instead of one-after-the-other, and the whole thing reads like synchronous code while never blocking. When I want a service to handle thousands of mostly-idle connections, this model is hard to beat and harder to get wrong than threads-and-locks. Modern JavaScript is a different language from the one people remember. Since ES2015 the additions have been steady and genuinely good: <code>let</code>/<code>const</code> instead of <code>var</code>, arrow functions, destructuring, modules (<code>import</code>/<code>export</code>), optional chaining (<code>obj?.a?.b</code>), nullish coalescing (<code>x ?? fallback</code>), template literals. Most of the “wat” demos that get passed around mock idioms no sensible person writes any more. The ecosystem, for all its sins, is vast and fast-moving. Whatever you need, someone has built it, and tooling like Vite or esbuild has made builds quick rather than glacial. When I want automated dependency hygiene to keep that ecosystem from rotting, I lean on the same pattern I describe in <a href="/story/renovate-bot-automated-dependency-updates-that-dont-break-everything/">Renovate Bot: automated dependency updates that don’t break everything</a> — npm makes the dependencies easy; keeping them current is the discipline you add yourself. You can read it incrementally. Because the language is dynamic and the browser console is always one keypress away, JavaScript has the shortest possible feedback loop of any mainstream language. Open dev tools, paste an expression, see the result. For learning, prototyping, and the kind of “what does this API actually return” spelunking I do constantly, that immediacy is worth a great deal. No compile step, no boilerplate <code>main()</code>, no project scaffolding — just type and run. The flip side, of course, is that the same property lets you ship broken code just as fast, which is the recurring theme of this whole article. <h2 id="the-runtime-landscape-briefly">The runtime landscape, briefly</h2><div class="ad-unit ad-in-article" aria-label="Advertisement"> Advertisement <ins class="adsbygoogle" style="display:block;text-align:center" data-ad-client="ca-pub-3726833845844946" data-ad-slot="3291553914" data-ad-format="auto" data-full-width-responsive="true"></ins> <script>(adsbygoogle = window.adsbygoogle || []).push({});</script> </div> It used to be that “JavaScript on the server” meant Node.js, full stop. That’s no longer true, and it matters because the runtime you pick shapes the pain you get. Node is the boring, ubiquitous default — enormous ecosystem, runs everywhere, and the one I still reach for when I want zero surprises in production. Deno (from Node’s original creator) tried to fix Node’s mistakes: secure by default, TypeScript out of the box, a sane standard library, no <code>node_modules</code> black hole. Bun went the other direction and optimised for raw speed and a batteries-included toolchain — runtime, bundler, test runner and package manager in one binary. I’ve moved scripting and CI glue onto Bun for the speed, kept production services on Node for the boredom, and that split is a perfectly defensible 2020s answer. The lesson is that “JavaScript is slow” or “JavaScript has no standard library” are complaints about a runtime, not the language, and you can often fix them by swapping the floor under your code rather than rewriting it. <h2 id="the-bad">The bad</h2> Dynamic typing scales badly. In a 50-line script, no types is liberating. In a 50,000-line codebase, it is a slow bleed of runtime errors that a compiler would have caught at your desk. <code>undefined is not a function</code> is the national anthem of JavaScript debugging. The community’s answer is TypeScript, and it is a good answer — but the fact that the standard fix for the language is a different language layered on top tells you something honest about the base. <code>npm install</code> pulls the world. A modest project routinely drags in hundreds of transitive dependencies, any one of which can be abandoned, compromised, or simply broken by a careless minor release. The <code>left-pad</code> incident in 2016 — where un-publishing an eleven-line package broke builds across the internet — was the moment everyone realised how deep the tower goes. Supply-chain risk here is not theoretical; it is Tuesday. The tooling churns. The framework and bundler landscape reinvents itself often enough that “JavaScript fatigue” became a recognised phrase. Pick boring, well-supported tools and ignore most of the noise; chasing every new framework is a hobby, not a strategy. <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 6 7 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-javascript" data-lang="javascript">// The single most common "bad" bug: silent type coercion console.log(0 == ""); // true — loose equality coerces console.log(0 === ""); // false — strict equality does not console.log([] + []); // "" — arrays stringify to empty console.log([] + {}); // "[object Object]" // The fix is a one-line habit: always use === and !==, // and lint for == with eslint's eqeqeq rule. </code></pre></td></tr></table> </div> </div><h2 id="the-ugly">The ugly</h2> <code>this</code> is a trap. What <code>this</code> refers to depends on how a function is called, not where it’s defined, and that single design choice has wasted more developer-hours than any other feature. Arrow functions (which inherit <code>this</code> lexically) defused most of it, but the footgun is still loaded for anyone who forgets. Type coercion is genuinely indefensible. <code>==</code> performs a baroque set of conversions that produce results no one wants. The fix is trivial — always use <code>===</code> — but the default being wrong is the kind of permanent scar the browser’s backward-compatibility promise leaves behind. The same instinct that makes me distrust silent coercion is why I distrust silent failures in shell scripts too, which I get into in <a href="/story/bash-the-good-bad-and-ugly/">Bash, the good, bad and ugly</a>: a language that hides its mistakes is a language that ships your mistakes to production. Floating-point money. <code>0.1 + 0.2 === 0.30000000000000004</code>. This isn’t unique to JavaScript — it’s IEEE 754 — but JavaScript having only one number type (until <code>BigInt</code>) means people reach for floats to represent currency and lose pennies. Store money as integer cents, always. Backward compatibility means the mistakes are forever. <code>var</code> hoisting, <code>typeof null === "object"</code>, automatic semicolon insertion that occasionally rewrites your intent — none of it can be removed without breaking pages from 2003. The language can only add, never subtract. So the cruft accumulates, and every new developer has to learn which 20% of the language to avoid. <h2 id="troubleshooting-the-bugs-that-waste-your-afternoon">Troubleshooting: the bugs that waste your afternoon</h2> After years of this, the recurring JavaScript bugs are predictable, which means they’re fixable: <ul> <li><code>undefined is not a function</code> / <code>cannot read property of undefined</code>. Almost always an async value read before it arrived, or a typo in a property name that dynamic typing happily allowed. Reach for optional chaining (<code>obj?.method?.()</code>) and adopt TypeScript on anything that outlives a weekend.</li> <li>A loop that “doesn’t wait”. <code>forEach</code> does not await async callbacks. Use a plain <code>for...of</code> loop with <code>await</code> inside, or <code>await Promise.all(items.map(...))</code> if order doesn’t matter. This one catches everyone exactly once.</li> <li><code>==</code> surprises. Turn on eslint’s <code>eqeqeq</code> rule and the problem stops existing.</li> <li>“It works in dev, breaks in prod”. Usually a dependency version drift or a build-tool difference. Lockfiles (<code>package-lock.json</code>) and pinning your Node version solve most of it.</li> <li>Mystery state in callbacks. Nine times out of ten it’s <code>this</code> bound wrong. Switch the method to an arrow function or bind explicitly.</li> </ul> The meta-lesson: lint aggressively, type your code, and pin your dependencies. JavaScript rewards discipline imposed from outside because the language imposes very little from inside. <h2 id="is-it-worth-it-who-is-this-for">Is it worth it? Who is this for?</h2> Yes — with eyes open. If you touch the web at all, JavaScript is not optional, and pretending otherwise wastes energy you could spend taming it instead. For front-end work it is the only game in town. For back-end work it’s a legitimately strong choice when your workload is I/O-bound and you value sharing code with the front end; it’s a weaker choice for CPU-heavy number crunching, where I’d reach for something else. My actual advice, distilled: write TypeScript, not raw JavaScript, on anything bigger than a script. Use <code>===</code> always, store money as integers, keep your dependency tree as shallow as you can stomach, and treat the framework hype cycle as background noise. Do that and the language is genuinely pleasant — fast to write, fast to run, runnable everywhere. Skip that discipline and the same ten-day origin story that made JavaScript ubiquitous will happily make your codebase miserable. It’s a language that gives you exactly as much rope as you ask for; the trick is knowing how much to ask for.

Written by Smarc

Founder and editor of vo.rs. A lifelong tinkerer who self-hosts far more than is sensible, hardens Linux boxes for fun, and prods the latest AI tools to see what they can really do. The how-to guides here are the notes Smarc wishes had existed the first time round.

Tagged#programming #javascript #web #tooling

Javascript, the good, bad and ugly.

Related Content

Go, the good, bad and ugly

TypeScript, the good, bad and ugly

Rust, the good, bad and ugly

Bash, the good, bad and ugly