You might not need TypeScript... (syntax)

Everyone loves types, Everyone loves autocompletion, Everyone loves getting warnings before they arise.

But nobody likes wasting time compiling stuff. Hopefully this will help convince you or your company that you don't actually need the TypeScript flavor syntax. So i have embedded the same editor used in VS-code to show you that you can have type safety with vanilla JavaScript and have the best of both worlds and play around with it.






First thing first

Enabling type safety

There are some hidden features available built right into VScode that not everyone knows about. They are so great that they are disabled by default as it almost seems like Microsoft wants you to use typescript instead and doesn't want you to use ESM or vanilla javascript.
Here are some features that should be enabled by default:

  • This can be added globally
  • Alternative it can be added to <root>.vscode/settings.json
  • Can be enabled per individual file (just to try it out)

You could also add a jsconfig.json to your project. jsconfig.json is a jsconfig.json is a descendant of tsconfig.json, which is a configuration file for TypeScript. jsconfig.json is tsconfig.json with "allowJs" attribute set to true basically.
Having it can help you generate d.ts files

Type Guard

TypeScript

JavaScript

Public / Private

TypeScript

  • Not truly private (Only soft private)
  • Unnecessary annotations
  • Should not be used anymore...
  • Unnecessary annotations

JavaScript

  • Truly private properties
  • Clear at first glance what are private by looking at one method
  • Simple: Everything that that has # is private, the rest is public
  • You don't even need to annotate that the '#name' is of type=string or that it's private with jsdoc, VS code can figure out by the constructors argument that name was of type string (judging by the default argument value)

Generics in JSDoc

TypeScript

  • Too compact to read
  • Doesn't Really make it more readable

JavaScript

  • Anyone with zero knowledge of jsdoc or typescript can understand whats going on by only looking at the JavaScript bits

Importing external / exported types directly in JSDoc

TypeScript

JavaScript

Annotating destructured parameters

TypeScript

JavaScript

Optional arguments

TypeScript

JavaScript

Don't respect dynamic import() when compiling to commonjs

CommonJS do support dynamic import() from commonjs since v12.17, TypeScript don't see it that way.`

TypeScript replace `import` with `require` and breaks esm-only imports

TypeScript

JavaScript

TypeScript don't support ESM very well...

Even doe you can transpile to es modules 1:1 with some target configuration, TypeScript is pretty bad at handling extensions and have totally ignored the problem ever since 2017 up until today and said: "We don't want to touch it, or automatically fix the extension problem, we rely on `require()` to do the job of resolving index and extension-less stuff" to summarize it shortly and marked it as "work as intended"

So developers did just simply add `.js` as recommended by the by some guides like the Pure ESM package.

  • Add {"type": "module"} to package.json
  • Add the `.js` extension at the end of imports

For Deno users this is also a big problem. They don't treat remote http import any differently than browser and requires explicit path to the other file and wants you to write `'./ModalBackground.ts'` and `../index.ts` - never `../` or `../index.js` when you only got a `index.ts` file

So, the best thing to do is to not to publish Noncompiled TypeScript packages. TypeScript adds compile time overhead so it will take longer time to load

TypeScript

  • There isn't any file './ModalBackground.js' file, only a ./ModalBackground.ts
  • What if you actually have `allowJs=true` and want to import a .js file? ignore the extension
  • What should it do when there is a `ModalBackground.js` and a `ModalBackground.ts` file in same directory, what file should it load, it's impossible to do: `import('ModalBackground.ts')`

JavaScript





Things TypeScript gets wrong

TypeScript

  • Something TypeScript really should be better at is Symbol.toPrimitive and how type casting really works in JavaScript.

JavaScript