If you can play a song on an instrument, you probably like that song. You’ve gotten to know it. You’re part of each other now.
Tech can be like that. I have my own little bag of technologies that I know fairly well, so I like them. I like them a little more than technologies I don’t know yet.
My recent journies in TypeScript have me thinking of this. I’m adding it to my bag. We’ve done a bunch of work at CodePen in it now and are converting our JavaScript code over as we see fit. Plus, I’m chugging right along on my Execute Program training and have done a few mini side-projects in TypeScript. This combination of real-world practice and academic study has gotten me largely up-to-speed in TypeScript land.
Soon, I’ll be at risk of liking TypeScript. I’ll be one of those who tell you, “once you go TypeScript, you’ll never go back”. Just kidding — please inform me if I become that obnoxious. I want to be measured about all this. No technology is above criticism (oh god, please tell me you know that).
I see the value in TypeScript. It provides type safety in JavaScript and DX in VS Code. Since JavaScript likely requires tooling anyway these days, it’s starting to be no more laborious to set up than whatever you’re doing for JavaScript already. Then once you are comfortable with the syntax and how to win battles with it, you bask in that value.
It remains fair to ask the question: is it really worth it? Is the time investment in learning worth it? Are the battles worth it? Are you preventing contributions? If there are complications to your pipelines, are they worth it? Is it costing you and your developers time or saving it?
I have lingering doubts about how many bugs are actually about types. Of all the JavaScript bugs I’ve fixed in my years, it honestly doesn’t feel like that many were about wrongly typed data being flung around. Some days it feels like a wild hoax that an entire meta-language was invented around solving these not particularly common bugs. Like if fifty things went wrong with your house last year, one of them was a woodpecker pecked a hole in your siding, so you spend three years building a woodpecker-proof wall around your house.
There are more valid criticisms as well. A recent thread on Hacker News started by listing four things that intersect with what I’ve mentioned, and the comments have plenty of people both defending and further criticizing it. The error messaging, in particular, is the source of many battles. How much time fighting those battles is worth it?
If I had to pick a side (I don’t), I’m narrowly on the side of TypeScript, particularly when the code is being written for others or there are more than a few developers touching the code. I’m a sucker for DX what can I say. But I’d like to avoid the trap of liking it, or choosing it, just because I know it. If I can.
As a recent convert to mypy in Python, I agree that type errors are rarely an issue in and of themselves (tho certainly not nonexistent!), but the most important benefit of good type info for me ends up being types-as-documentation. I get to spend less time looking at an old function I no longer closely recall to figure out exactly what sort of arguments it expects to receive; I’m forced to spend a little more time up-front defining a type for a nested object rather than YOLOing into loops; etc.
Basically, types are a simple form of documentation and unit tests, both of which are easy to skip normally but definitely hold value, and binding yourself to defining them is usually good discipline.
I think it depends on what you’re building. If you’re doing an engineering project, sure TypeScript. But most frontend development is actually an arts and crafts project more than an engineering project, and software engineers are the wrong people to be implementing the frontend. Web devs are*. If you think about it in these terms — with the frontend as an almost disposable, hot-swappable, ephemeral layer that you’ll be replacing next year anyway, I’d actually favor JavaScript.
TypeScript lets you handle complexity, but why even have large complexity and the frontend? Pull that out into other layers and let the frontend be nothing more than pretty-printed curl calls (with onclick handlers that make more xhr calls). This is just one way to think about things but it’s sure worked well for me over a career of 20 years spanning several FANG companies.
What is a web dev? Someone who’s allegiance belongs slightly more to “product and UX” than to “engineering”. Someone who’s highest value is “user empathy” as opposed to “engineering excellence.”
Apart from resolving bare import specifiers, I stay away from needing more build tooling to make my app run. If you go with a mostly buildless philosophy, which gets increasingly feasible with browsers progressing, typescript feels like a large commitment. Therefore I have chosen for JSDocs type annotations, a subpar developer experience perhaps because writing types in comments can be meh. However, I can lint it with Typescript and type issues won’t stop my app from working, comments always run ;). And I will just build type definition files when I am ready for publish. This also helps when I do testing or demoing or various other tooling that would require some kind of typescript compile plugin, the DX with regards to setting up my tools is definitely far superior even if it comes with having to write type annotations in comments. I also like that you can just write TS or D.TS files when you really want to, and import from those files in JSDocs w @typedef {import(…)}.
I think type safety is almost undeniably helpful and I’m glad there’s an alternative to being locked in by a typescript compile step.
https://timseverien.com/posts/2023-01-25-is-typescript-worth-it/
Would it not be better for DX to use a more serious tool like Webstorm which can pick up a lot of these autocompletions for you, instead of modifying an entire code base? In other words: Should DX not be the responsibility of the IDE / editor and not the code base?
Maybe! Perhaps that’s the choice of the team itself.
I think of this same kind of thing when I think of TMUX. We use TMUX at work because we can run one command, and it turns the terminal into a multi-panel thing running all sorts of other commands with filtered output.
I hate how TMUX looks and works, but I like what it does. What if I made my own terminal? It could make it have a proprietary command that you run that does what TMUX does, splitting all sorts of other commands up into separate panes and such, but mine will look pretty and work nicely.
But now the problem is that everyone HAS to use my editor in order for this to work.
That’s similar here. TypeScript theoretically makes it so it doesn’t matter what editor people are using, it’s baked into the build tools and commit hooks and CI and all that.
I see your point of forcing engineers to all use the same tool. In that case perhaps a PHPstan-like static analysis tool for JavaScript which runs off JSDoc may offload the complexity of validation and strict type checking to the build process and will integrate quite nicely into any editor including VSCode.
Appreciate you sharing your thoughts, it’s not easy to have a public opinion about this.
Hi Chris,
It would be disingenuous of me if I didn’t write this comment:
I was wrong and I’ve changed my mind: TypeScript should be recommended more. We’ve started implementing it in our smaller projects, and have immediately started seeing the benefits, and can see how it will pay off in the long run.