[Feature] Migrate extension to Typescript

[origranot]

Hey, I think we should migrate the extension into Typescript.

[baruchiro]

Hi, thanks for taking part in Overlay!

Please explain why we should migrate to TypeScript, what we will achieve, and what the price will be.

[shacharRonZohar]

Hi Baruch, I'm not the original poster of the question but I think I can lay out the typescript case pretty well:

TypeScript's static types make our code more robust and easier to read. As an example, consider a function that takes an object as an argument. In JavaScript, it's not immediately clear what properties the object should have, which can lead to errors. With TypeScript, we can define an interface for the object, making it clear what the function expects. This can significantly speed up onboarding time for new developers and make code reviews more efficient, while severely decreasing the mental overhead required by developers, allowing them to focus on solving actual problems.

TypeScript's type checking catches errors at compile-time. Imagine a situation where we're working with an API that returns an array of objects, and we've mistakenly assumed that a property always exists on the objects. In JavaScript, this would result in a runtime error, possibly after deployment. TypeScript would catch this during development.

TypeScript improves autocompletion, navigation, and refactoring. For instance, if we're using an object spread to extend properties in JavaScript, and we misspell a property, it would go unnoticed until runtime. TypeScript's editor integrations would underline the misspelled property, and the error would be evident during development. In my opinion, the tooling and developer experience enhancement that you get from typescript is one of it's strongest points.

TypeScript often includes new JavaScript features before they're fully supported. For example, typescript allowed us to use advanced features like optional chaining and nullish coalescing in a way that's safe and compatible with older environments, way before they were officially available as part of ECMAScript

// JavaScript: TypeError if `foo` or `foo.bar` is undefined.
console.log(foo.bar.baz);

// TypeScript with optional chaining: Safe and clear.
console.log(foo?.bar?.baz);

TypeScript is well-suited for large projects. Consider a large codebase where we're renaming a property on an object that's used in many places. In JavaScript, this would require manually finding and updating every usage, risking missing some. TypeScript's refactoring tools make this process safe and automatic, while immediately highlighting any errors that may occur

As for the build process, while TypeScript does require a compilation step, modern tools have made this largely irrelevant. For example, modern frontend tooling like Vite provides out of the box first class typescript support, ts-node offers JIT compilation of TS to JS, allowing for a smooth node dev experience, and many other tools exist that offer good solutions.

Furthermore, many integrated development environments (IDEs) provide built-in or plugin-supported TypeScript compilation, allowing us to see type errors in real-time as we code, similar to linter warnings in JavaScript.

Typescript is also pretty easy to pick up for any established JS dev, offering simple and intuitive syntax for most everyday uses, with more complex and "scary" features really only used by hardcore library maintainers.

The price to pay is seen in slightly slower development time while the team is acclimating to TS, although that time is quickly made up for, since after the project is set up and the devs are comfortable, development time speeds up significantly, way past what is possible for even the best JS dev.

In essence, TypeScript's benefits in terms of robustness, readability, error detection, tooling, future-proofing, and scalability outweigh the minor overhead introduced in the build process, which can be automated with modern tools, and the slight learning curve.

[baruchiro]

@shacharRonZohar Thank you for your detailed explanation!

This thread is not a general discussion between friends about which is better, but it is about this project, and what will be the best decision for it.
I see engineers debating at work about what language/framework/tool is "the best", but I think they're missing one part of our job- the challenge in our work is to connect our code to the reality (business, users, time/resource limit).

Regarding your comment, we're just asking what will be the best decision for this project at a specific time.
Is this project a "large-scale" project? Are the new ECMAScript features missing in this project? Is adding TypeScript will make our build more complicated to understand? Is defining types for every object in the system will slow us down without so many advantages?