2020-04-21
1906
#typescript
William Lim
17435
Apr 21, 2020 ⋅ 6 min read

Discussing the over-engineering trap in TypeScript

William Lim Software developer.

Recent posts:

7 Common CSS Navigation Menu Mistakes And How To Fix Them

7 common CSS navigation menu mistakes and how to fix them

Navigation menu errors are common, even for seasoned developers. Learn seven common navigation menu errors and how to solve them using CSS.

Temitope Oyedele
Jun 13, 2025 ⋅ 6 min read
Comparing the top 5 React toast libraries

Comparing the top React toast libraries [2025 update]

Compare the top React toast libraries for when it’s more trouble than it’s worth to create your own custom toast components.

Nefe Emadamerho-Atori
Jun 13, 2025 ⋅ 16 min read
Comparison between TanStack Start and Next.js — two modern full-stack React frameworks with different architectural approaches.

TanStack Start vs. Next.js: Choosing the right full-stack React framework

TanStack Start vs. Next.js: both are powerful full-stack React frameworks, but they take fundamentally different approaches to architecture, routing, and developer experience. This guide breaks down their core features from SSR and data fetching to TypeScript support and deployment, to help you choose the right tool for your next React project.

Abiola Farounbi
Jun 12, 2025 ⋅ 8 min read
Angular v20 might seem boring…here are 5 reasons it’s not

Angular v20 might seem boring — Here are 6 reasons it’s not

While it may seem like a maintenance update, Angular v20 is packed with practical, production-ready upgrades that will enable us to build apps faster and with more confidence.

Yan Sun
Jun 12, 2025 ⋅ 8 min read
View all posts

6 Replies to "Discussing the over-engineering trap in TypeScript"

  1. I’d just like to add that at least IntelliJ and Atom both provide features like intellisense / unused import removal etc on es6 modules. You don’t need TS for just those features.

  2. The disadvantage is configuring typescript? I can do that in less than an hour, including webpacj and babel. The self-documenting nature of types makes your code so much readable and avoids stupid errors when you don’t know the structures you’re using, even if you wrote them 10 minutes ago. The sheer speed of typed development in excellent editors like VS code is already an extremely useful advantage, and of you take into account that your whole program can become type safe, it’s a no brainier to go for Typescript. JavaScript really becomes a scripting language, or a begginers language. Any serious project I’ve ever seen ends up migrating to Typescript unless it has robust testing set up, seasoned developers with a lot of knowledge of the project, and few changes or features over time. On top of all of this, it exposes you to typing (although structural, not nominal) which lowers the learning curve for statically typed languages. Embrace Typescript as soon as you can, or be forced into it later.

  3. “If your codebase is small, type checking can be more easily done in unit tests, using libraries such as Chai, without the need for TypeScript.”

    I know this isn’t what you are promoting here, but I have heard this before as an argument against moving to Typescript. However I don’t think unit tests can replace Typescript. It is not a good idea to expect the programmer who wrote the bugs to know exactly which unit tests to write in order to catch them. It is also much more difficult to write unit tests that would catch every type safety bug than to just use a language that makes it near impossible. And then write unit tests as well. You can focus your unit tests on behaviour rather than something the language and static analysis tooling could do for you instead.

    There are several entire classes of errors commonly seen in JavaScript code that will never be seen in Typescript code if configured well. For example, trying to call a method on an undefined variable. Yes, migrating to Typescript is a lot of work, but like the article says, you can do it a bit at a time and you still get some benefits along the way. 🙂

  4. Disclaimer: I work with that “even backend” thing called node.js and I find it fascinating compared to strongly typed languages like Java. MUCH less code does the exact same thing. Easier to read and write.

    Have you ever used a combination of eslint, JSDoc and webstorm? I had zero type errors thanks to that.

    Oh, and I sometimes write “string” or “number” in the name of the variable because I know I won’t be reassinging it (because I mostly use const). When type is important and comes from outside of a function, I do type checks.

    I follow KISS principle. Keep it simple, stupid (no offence meant).
    Small functions, small files, one function aims to do one thing at a time. One module does what it’s supposed to do, and nothing more. Types are defined via JSDoc.

    So far every time I thought about using TS I caught myself wondering what benefits it would bring. Found none for me personally so far. But it does make it harder to work – compile before execution, change file names, code becomes more verbose. It has its benefits but so far I’ve managed just fine with just js. And linter. And JSDoc. And unit tests. And open api docs. And type checks. And TS won’t remove the need of any of those.

    This could be different in front end. This could be different for your project and your contributors. This is just my experience.

    If the next project i work with uses TS, I’ll use it without an issue. If not, I won’t push for TS ASAP. I’ll aim to use the best tool for the job.

    The job being implementing business logic in an optimal way that scales well and doesn’t take a very long time to realize. Oh, and make sure you have unit, implementation and end to end testing. Don’t skip on tests, regardless of TS.

  5. The article doesn’t have enough experience I suppose. I started with Javascript and after moving to typescript there’s no turning back. Commercial projects are just too big to be maintained with Javascript. Typescript makes the development faster because your team members don’t have to know the code before hand and can safely write code that works as expected. In the high-tech industry everybody works with typescript. In react everybody works with typescript. That is the future and you better embrace it sooner than later

Leave a Reply