JavaScript vs TypeScript: Why I Choose JavaScript

August 18, 2024

In modern front-end frameworks, many if not most have switched from using JavaScript to TypeScript. In my professional and personal experience I have chosen to dump TypeScript where ever I can. In the last year at work I was primary contributor to an internal developer portal. The base application is a basic NextJS application. When the project began we used the default TypeScript implementation. As we began creating React Components and writing HTTP calls to our headless CMS ContentStack, having to create interfaces and types just so the compiler wouldn't throw up became exhausting. At one point I had two full files full of these interfaces and type definitions.

The application isn't a large complicated project. There aren't lots of developers contributing to the project. If I get my way there will be very few other individuals contributing to the project. When I looked through the code and saw several :any types set in React components where we were doing a map on an array, I realized that we had a problem. We are using Material UI as part of our front-end framework and even in their code examples, they were using :any. I had to ask myself if any of it was worth the effort. In the end it was decided that TypeScript wasn't benefitting us and that we would rip it out. My prefered method is using JSDocs rather than type and interface definitions.

JSDocs like the following replaced those type and interce definitions.

/**
 * JSDocs were created to give a good description for what was being done
 * @param {string} uid - The unique identifier of the application
 * @param {string} appType - Indicates where it's an application, sdk, or api
 * @returns {Promise<object>}
 */
const myFunc = async (uid, appType) => {
    // ... execute code
}