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?

[shacharRonZohar]

@baruchiro
I understand this thread is not a general discussion, and I apologize if my comment seemed that way, it was not my intention.

I may have been misunderstood, since I believe TS features help ALL projects, regardless of size, with some benefits being increasingly beneficial as the project grows.

As with all projects, I believe this project will highly benefit from the numerous features stated in the other comment, which directly affect both the user experience (less bugs make it to prod, it's easier to handle complex edge cases, etc), and the time/resource limits (with faster development and improved tooling, allowing the dev to focus on business logic instead of "did I send the correct param or not").

I will concede that the new ECMAScript features is the feature with the least likelihood of impact here, although we never know what the future may hold.

As for the build system, I believe it will barely be affected by it, especially since it already uses Vite & Rollup for these tasks, it can be as easy as enabling a plugin, although it needs a bit of research.

Lastly, I think defining types for every object will slow you down (although the advantages will be high), I also think it is the wrong approach, as types should be inferred as much as possible, and explicit types should only be written when absolutely necessary, which leads to a situation where many times you will simply write JS in TS files, with a bit of type annotations for params and the likes.

If it will help convey my message, I can try converting a small portion of the project to TS in a test branch, to show the simplicity, and maybe help you make a decision.

[baruchiro]

Thanks!

I think it will be valuable if you will convert a small piece of the code to TypeScript (but I won't promise you it will be accepted).

[shacharRonZohar]

sounds good!
I'll work on something and publish a branch so you guys can take a look, of course with no expectations, doing this for fun and to help reach a decision, whatever that decision may be :)

[shacharRonZohar]

sounds good! I'll work on something and publish a branch so you guys can take a look, of course with no expectations, doing this for fun and to help reach a decision, whatever that decision may be :)

Hey, just wanted to give an update, due to some personal circumstances I have been unable to start work on this.
I'm posting this here because as much as I would love to come back to it when I can, in the meantime I don't want to block it, so if anyone wants to work on this, feel free!

I'll give another update here if \ when I am able to continue work on this.