JS is not worse than …

Let me start with the reason I’m quickly writing this post, by mentioning a great comment from Jason that I’ve recently read on twitter:

Beside developers of the “moaners gonna moan” category, and excluding WASM as generic target, it seems to me few Web developers keep forgetting whatever language they choose will inevitably end up transpiled as JS, bringing a whole new world of issues they might not even be aware of, issues that, however, could hit hard once deployed in production.

Most of them also believe their code is better, safer, or even faster, ignoring all those nobel sentiments live only on their own development environment, rarely reflected in the production code they ship to users.

CoffeeScript

As must to be mentioned revolutionary way to develop with a differentishprogramming language, CoffeeScript always had great ideas and dev friendly shortcuts, most of them inspiring for modern JS.

Nowadays though, it looks indeed like modern JS, except since everything is an expression, but with no const neither let declaration, there’s basically no way to guard anything in a scope, classes included.

# all valid
same = () -> true;
same = () -> false;

# still valid
class Wut
class Wut

# will it be scoped ?
test = () -> same = () -> null

o = Wut
console.log(
  test(o)(o) # null
);

On top of that, super has limited powers, compared to JS, and there is no sugar to define getters or setters, which is IMO™ an unnecessary limitation.

As much as it’s been a game changer at its time, and a honest hat tip for that, if I were you, I’d consider leaving this variant of modern JS, simply because it’s not really revolutionary anymore.

TypeScript

TypeScript, TS for short, is somehow the most popular choice between those developers liking types, but it’s also since ever quite problematic with that.

It’s not by design that TS has problems, it’s due its transpiled output logic.

TypeScript fails indeed most basic classes tests when you transpile those for backward compatibility:

class List extends Array {
  method() {}
}

console.log(new List instanceof List); // false

(new List).method();

// TypeError: (intermediate value).method is not a function
// ^ .......: oh, the irony!

“Yeah but …” … let me stop you there, in case it’s not clear: extendings builtins doesn’t breaks only with Array, it breaks with every builtin class, including DOM related one, hence “bye bye” Web Components and Custom Elements:

class MyElement extends HTMLElement {
  connectedCallback() {
    this.textContent = new Date;
  }
}

customElements.define('my-element', MyElement);
document.body.appendChild(new MyElement);

Try above basic code after transpiling it via TypeScript, and see errors that are likely not getting fixed any time soon.

And that, my fellow developers, is where your type safety go: you have now more hidden issues and limits than those you think types would solve for you.

But as remind note: there are no types in your production code, only transpiled code your IDE cannot spot, code that will fail where, and when, it matters the most.