Some observations of a skeptic taking TypeScript for a spin

typescript_observations_skeptical.md

Full-disclosure: I was highly skeptical of any benefit using TypeScript programming language to write source code, where I enjoy writing JavaScript source code from scratch, and I don't buy the claim that TypeScript is a "superset" of JavaScript.

I look at TypeScript and see a completely different programming language, from syntax to usage, and philosophy, compared to the JavaScript programming language.

Just to see for myself what the pros and cons are, I had to take TypeScript for a brief spin in my lab.

As is my protocol when trying or learning a new programming language or application, I start with I/O, reading standard input stream, writing standard output stream, handle standard error. I usually use the Native Messaging protocol to facilitate reading and writing streams.

• TypeScript is not up to date with JavaScript, e.g., resizable ArrayBuffer has been shipped in V8, SpiderMonkey, Node.js, Deno, Bun, and is exposed in the browser. TypeScript is still trying to merge a PR microsoft/TypeScript#58573 that establishes .d.ts files for resizable ArrayBuffer, and fixing ArrayBuffer.prototype.slice, SharedArrayBuffer.prototype.slice, Add empty arguments of ArrayBuffer/SharedArrayBuffer constructor types to ES2017.
• Because JavaScript/TypeScript runtimes rely on TypeScript official releases for type checking, deno check still throws errors when embedding an interface in the .ts file.

  error: TS2740 [ERROR]: Type 'ArrayBuffer' is missing the following properties from type 'ArrayBuffer': maxByteLength, resizable, resize, detached, and 2 more.
  const buffer: ArrayBuffer = new ArrayBuffer(0, { maxByteLength: 1024 ** 2 });
  

  Though deno, bun, and node --experimental-strip-types happily executes the .ts file. I suspect there might be a switch in some internal implementation details that checks if the JavaScript API is implemented, even if TypeScript isn't. This dependence on TypeScript official winds up meaning it becomes unclear when the TypeScript declarations are being applied and when they are not.
• More files to manage with official .d.ts files; and local .d.ts files, types for node, types for deno, types for bun, et al. That is basically duplicate hard coded TypeScript sitting there.
• No official TypeScript tool exists to convert error-free, linted JavaScript to TypeScript syntax microsoft/TypeScript#59439. I used a third-party Web site that says it does JavaScript to TypeScript conversion using "artificial intelligence", of all things https://www.codeconvert.ai/javascript-to-typescript-converter. That fact kind of gets rid of the "superset" claim, at least from my perspective, where the TypeScript syntax can't be generated from JavaScript syntax, directly, using some in-house tool. Compare QuickJS qjsc which accepts JavaScript and outputs C bytecode; Bytecode Alliance's wat2wasm, wasm2wat, wasm2c, wasm2json, javy.
• Running .ts files directly in a JavaScript/TypeScript runtime, bun is faster than deno, which is faster than node --experimental-strip-types.
• I can see some benefit in a central registry of types. However, when the underlying runtime is dependent on those types, and there is delay in providing those types, in nightly form, and ideally in unison with developer/nightly build JavaScript applications and runtimes, that necessarily means JavaScript is sitting around waiting on TypeScript downstream. Perhaps an ideal situation for Microsoft, not for developers on the edge testing and experimenting with new JavaScript features. TypeScript then is apparently ignored by the JavaScript runtimes, and the core JavaScript implementation takes over - which it could in the first place without TypeScript. So, there's a in issue with reliance on any centralized registry for downstream implementations that could be rolled out faster without TypeScript .d.ts files and work exactly the same, or better, particularly when type definitions omit properties and methods for whatever reason.

I think that's it. Impressed with TypeScript, no. Use again? Probably not, unless I'm forking and working with somebody elses code. I'll bundle to JavaScript as I have been doing and go on about my business in JavaScript world. Without rancor.

Typescript is trash