TypeScript: Is the Juice Worth the Squeeze?

What is TS?

(Skip if you really know it) “TypeScript is JavaScript with syntax for types“, a superset of JavaScript that adds optional static typing to the language. This can help to catch errors early in the development process.

What is not TS?

Is not a replacement for JavaScript (like many make it sound like), nor is a front-end solution to avoid non-type related errors, check types at runtime or a replacement for good OOP.

My Experience with TS

Let me kick off by stating that I have no qualms with TypeScript. I’ve employed it in several projects and can vouch for its strengths as a tool. Yet, along the way, I’ve stumbled upon a fair share of complexities it drags into a project. Depending on the tech stack, the additional layers could be seen as adding a bit more than just a dash of overhead, not only in the setup but also in blending it smoothly into the workflow.

Just for reference, I will be referring to TypeScript as “TS” and JavaScript as “JS”.

Here’s my take on this journey with TypeScript. While your experiences might sing a different tune, I believe these points are worth a pause and ponder:

1. Learning Curve: Unlike other languages that have Type-Check built in, JS does not have that out of the box thus using TS to fill that void, and yet, JavaScript and TypeScript are separate entities, which adds an extra step to not only JS but also to the developer trying to embrace that additional layer TS brings. While TS, it’s adept at catching errors at compile-time, it demands a steep learning curve, especially for developers accustomed to dynamic typing or those coming from other languages where typing is better integrated and more streamlined. Sometimes, I feel there is so much Ts to write that it takes away from what actually made JS so cool to work with, which is being simple and easy to understand. I cannot stop to think that this reminds me of other tools in the past trying to come up with separate solution, like LiveScript (not alive) or CoffeeScript (still alive, somehow), remember those? or better yet having to learn all of those just to actually create JS?… Painful, very painful.
2. Too Many Distractions: In projects rich in logic or functionality, the extra TypeScript code, files, and settings can be quite distracting. For every JS file penned, there’s almost an equal amount of TS code tagging along. While I love the idea of enforcing correct types, it often makes me question the merit of adding this heavy workload to most projects if they only work at build time, almost in a controlled environment, so what about beyond that 😐 and rather than trying to come up with completely separate solution, what about better pushing JS into actually have built in support for Types just like PHP, Weak, Dynamic and Strong (strict)?
3. Configuration: Like many Full-Stack developers, juggling multiple projects with different stacks, requirements, and purposes is part of the game. In an ideal world, once TypeScript is set up in one project, it could magically replicate in others. However, reality is less forgiving. Many projects tote along a host of dependencies that may or may not be TS-friendly, requiring the creation of Type definitions (not cool!). And then there’s the task of marrying compiler/framework settings. I frequently use Webpack, Vite, and Laravel Mix (built on top of Webpack) to compile and do all build steps. They are great, up until TS steps in, making the configuration of each project a real chore with a slew of plugins, dependencies, and tweaks.
4. Verbosity: The extensive type declarations and interfaces, though useful, can lead to verbose code which may hinder readability.
5. Overhead and Development Speed: I get what TS aims to accomplish, and I like it, largely because I also engage with PHP frameworks where PhpCs (the equivalent to JsDocs + Eslint) and strong typing are the required. The hiccup comes since TS and JS aren’t fully integrated; although from the same family, they feel and work apart. So, is it worth adding so much overhead to the project if TS can only enforce the Types at build time and then not carry over to the front end where it will actually interact with other code? Or having to check for TS syntax and complexities issues while trying to concentrate on actually writing JS? I don’t know, just like CoffeeScript story, only time will tell.
6. Complexity: I’m not only a Full-Stack Dev, but also a Project Manager so managing dev teams is also part of my job and experience. One of the things that are very obvious with mixed teams, is that all developers have different backgrounds and skill levels. Some may be better at back end, some at front end but at some point, they meet along the way to work on the same project. That’s where all comes down to a bottle neck. For those that know Ts like they know the Bible (ok, at least Ts) it may be ok and natural to take on code with Ts, but for those coming from other sources or skill levels this is a challenge and painful reminder that somethings while with good intentions, they introduce unnecessary complexity. I think this article will explain better this point: The unnecessary complexity on the Front end | by Eduardo Ottaviani Aragão | Aug, 2023 | Medium
7. Is not just me, others feel the fatigue as well: As a Full-Stack Dev, the idea of unifying my workflow and ease of programming for back and front end has always been a dream. That’s why I try to keep complexities down and maximize my focus on the code logic I enjoy writing. We cannot deny that many other layers are now part of the development process to help us write better code, but also, we cannot deny that when there are too many layers, we begin dreading writing code. And for me, that’s what TS is doing, it makes me not love what I do, and I hate that. In my opinion, if you are truly a passionate dev, you would get out of the gray zone and start adding simple things like JsDocs (IDE have a great support for this to the degree of almost doing the same job as TS) or applying better OOP and patterns to projects. I think here is an example that I, may not be the only one when it comes to feel this way about this fatigue: Turbo 8 is dropping TypeScript (hey.com)
8. Side Effects: Many times, when using different sources, libraries, etc, is nearly unavoidable to get Ts and Non Ts mixed together. Please don’t think this is intentionally done, but the way some dependencies have been created. I started to notice that the IDE was complaining about a “types” definition file in vanilla JS projects. I thought that somehow the extensions I have in VsCode to support TS (yes, I do write some libraries in TS) were going haywire, weird. I Google the issues, but it only related to TS files not Vanilla… After hours of frustration trying to figure the error notification, as it turns out, one of the vendor dependencies files was a Ts file, so it cascaded to the entire project, something very unwanted 🙁
   
   PS, I do mention a lot of PHP features that in my view would be nice to adopt in JS, like the flexibility to have Type Strong functionality when required because to a degree the syntax and programming format of both are not too far apart, and now that JS is strongly moving to backend, I think this is the perfect opportunity to beef up the language. And… yes, PHP can be “strict typed”, but also dynamically and also weak (loose) typed, or a combination of the last two, but that’s a different discussion, here is quick resource https://www.phptutorial.net/php-tutorial/php-strict_types/ and here: https://medium.com/@erlandmuchasaj/weak-typing-vs-strict-types-in-php-f2b36e0e4659)