How did you switch from JavaScript to TypeScript?

See, by doing that step forward you'll try type hints on your own and make your own opinion!

Type hints are a great feature and most languages (compiled or not) implement them, JS is catching up at a different pace, as every language has it's own context and market niche (though everything that can be coded in JS will eventually be coded in JS 😂) hence it's own priorities (usually and ideally driven by the users but some times it's otherwise tbh).

I'd suggest you to create a project using TSPragma + JSDoc and then another one with TS alone, where you'll be able to choose whether you want to stick with type hints or take advantages of other TS features -if any works on your context- this way you'll be able to discern in which situations TS is still valuable when we finally get type hints in JS 😁

PS: looking forward to read new posts and see how this adventure goes!

Best wishes

I was afraid of someone asking this after submitting the comment 😂😂

As I said it won't probably work 100% with OOP, reasons and examples down below and non-OOP examples for comparison.

What is Tree Shaking?

From mdn:

Tree shaking is a term commonly used within a JavaScript context to describe the removal of dead code.

It relies on the import and export statements to detect if code modules are exported and imported for use between JavaScript files.

In modern JavaScript applications, we use module bundlers (e.g., webpack or Rollup) to automatically remove dead code when bundling multiple JavaScript files into single files. This is important for preparing code that is production ready, for example with clean structures and minimal file size.

How

To safely omit code the bundler needs to be 100% sure that the discarded code is not being accessed anywhere in the bundle.

There are several ways in which this can be accomplished but 100% accurate escape analysis isn't feasible because the bundler would need to inspect every module in the graph in a way that's even more deep than most type checkers.

Little disclaimer

So I was writing everything on my smartphone's notepad when I stumped into this reddit discussion - This guy Manbeardo explained it pretty well so I'll just copy paste the comment and link the source, all credits on this examples to this guy Manbeardo.

Explanation and examples

In order to safely omit code, the bundler needs to be certain that the omitted code isn't accessed anywhere in the bundle. There are several ways that can be done, but maximally accurate escape analysis isn't feasible because the bundler would need to inspect every module in the graph in way that's more comprehensive than most type checkers.

Here's a bunch of examples of code where methodB can safely be omitted, but with different levels of analysis required:

ES6 module shaking:

// BagOfMethods.ts

export function methodA() { ... }
export function methodB() { ... }

​// entryPoint.ts
import {methodA} from 'BagOfMethods';

methodA();

In this case, it's very evident to the bundler that methodB can be omitted because it's never even imported.

Destructuring assignment using commonjs:

// BagOfMethods.ts

class BagOfMethods {
  methodA() { ... }
  methodB() { ... }
}

module.exports = new BagOfMethods();

// entryPoint.ts
const {methodA} = require('BagOfMethods');

methodA();

In this case, the bundler can still determine safety solely by looking at statements where BagOfMethods is imported, but it requires slightly more sophisticated analysis.

Dynamic access plausible:

// BagOfMethods.ts

class BagOfMethods {
  methodA() { ... }
  methodB() { ... }
}

module.exports = new BagOfMethods();

// entryPoint.ts
const BagOfMethods = require('BagOfMethods');

BagOfMethods.methodA();

In this trivial example, it's pretty clear that methodB isn't going to be called, but it's possible to access methodB on a subsequent line, so we have to process the rest of the module in order to find that BagOfMethods never escapes this module and this module never calls methodB. Things get hairy when BagOfMethods escapes in the next example.

Indirect dynamic access plausible

// BagOfMethods.ts

class BagOfMethods {
  methodA() { ... }
  methodB() { ... }
}

module.exports = new BagOfMethods();

// BagUser.ts

type Bag = {
  methodA: () => void
};

class BagUser {
  constructor(bag: Bag) {
    bag.methodA();
  }
}

module.exports = BagUser;

// entryPoint.ts
const BagOfMethods = require('BagOfMethods');
const BagUser = require('BagUser');

new BagUser(BagOfMethods);

Now, in order to determine that methodB isn't called, we'd have to either:

• Potentially traverse the entire module graph every time we evaluate a module for potential omissions
• Store a lot of metadata about what every module does

We're getting into the realm where the bundler needs to do as much or more analysis than the TypeScript type checker. If you're aware of a bundler that's built from the ground up to support TypeScript, I'd be excited to hear about it.

Dynamic access

// BagOfMethods.ts

class BagOfMethods {
  methodA() { ... }
  methodB() { ... }
  methodC() { ... }
}

module.exports = new BagOfMethods();

// entryPoint.ts
const BagOfMethods = require('BagOfMethods');

function pickMethod() {
  if (Math.random() > 0.5) {
    return 'methodA';
  } else {
    return 'methodC';
  }
}

BagOfMethods[pickMethod()]();

We don't have to expand the graph in this case, but we're getting deep into typechecking weeds again before we can determine that methodB isn't called.

And the potential complications go on. As an engineer looking at code, it's labor-intensive and error-prone but plausible to manually identify methods that can safely be omitted. For webpack to catch all those cases, it'd need a type inference engine that's at least as powerful as TypeScript's.

Dynamic?

Now it's me, Joel again. While the examples above cover a great deal of bits around the topic, I'm adding a quick example after re-reading them twice.

import myClass from 'myFile';

myClass[variable]();

If you do so it won't be possible to tree shake it, because it's using a static analyzer behind the scenes so any method described by variable is possible at runtime.

When using functions it's quite easy:

import { myFunction } from 'myFile';

// here we'll have acess to myFunction but nothing else

Remember that in JavaScript, like in other languages like Python, everything's an Object, extending the example above you could do:

const myObject = {
  myFunction: (n, n2) => n+n2,
  myProperty: 'I am a prop',
  anotherFunction: () => 'that returns a text'
}

and it's perfectly fine, now if you access the properties it's ok for the static analyzer but if you do something like myObject[variable] it won't be tree shaked either.

With that in mind, it's safe to say that code that's purely procedural or functional won't be much of a trouble for the static analyzer whereas certain OOP edges and whatnot can be hard to deal with (just in case this is agnostic to declarative vs imperative or expressions vs statements -whatever you like to call it- that are often defined as paradigms as well).

wrap up

Last but not least, I'd suggest you to check your bundler capabilities and configurations in regards of tree shaking.

Certain use-cases exemplified in this comment are possible to overcome when tree shaking and are described here for educational purposes (so we all understand the challenges and limitations) specially if you avoid certain practices.

Please note that the websites of bundlers often explain what the tool does -in a vague way to be honest- but not what it doesn't, so some statements may already be solved since the last -and only- time I had to deal with this in deep detail.
For that, if you find something that can update my knowledge on the topic I'd be grateful if you share it 💖.

The limits on tree shaking your code will depend on:

• Your code itself.
• The capabilities of the bundler.
• The configuration that's available to you.
• Your will to maintain the configurations during the development process

In regards of the last point, sometimes the benefits of not having to care are greater than the benefits of saving a couple of kb in your bundle 😅

All that covered, whether you use -or should use- OOP or not depending on the situation is a totally different discussion.
I consider FP to be much more understandable and maintainable -even though I don't always use FP myself- but that's my subjective opinion based solely on my experience.

If you ask me, code in the paradigm you feel more comfortable with, being multi-paradigm is one of the most important reasons to love JS IMHO.

Best regards 😁

PS: This comment could be a post lol

TS adds some OOP stuff that's not available in JS core API, one example of these could be interfaces.

Actually typescript is widely known for NOT losing backwards compatibility or any breaking changes in the first place...

Love it. At very first i was struggling with it, but now i do understand what am i doing and what for, devtut.github.io/typescript/gettin...

Well,

it took me 4-6 months to get things going, but I'm still making mistakes and finding myself spending time fixing typechecks where I'm 100% sure it would pass. But any is not an option in our project so I have to hunt down how to transform, extend etc. to make it pass the checks.