DEV Community

I’ve Got 99 Problems but Learning TypeScript Ain’t One

Void⚡ on December 07, 2022

Why have all JavaScript developers not moved to TypeScript? I asked this question on Twitter last week and got ~100 replies. Sharing my learn...

Read full post

Jon Randy 🎖️ • Dec 7 '22 • Edited

Why?

Because I don't want to give up the freedom and speed that not having strict types gives you. Seriously, I used strictly typed languages a lot before coming to languages like JS... and they feel so utterly restrictive in comparison.

Why anyone would prefer strict types is beyond me

Nikola Stojaković • Dec 7 '22 • Edited

And as someone who worked extensively on dynamic typed code bases I have an opposite question - why would anyone prefer dynamic typed languages on anything bigger than a small hobby project?

I prefer static typed languages because:

I can focus on my work instead of worrying about possible runtime issues caused by trying to access null object or implicit coercion happening when I don't want it (yes, you need additional validation layer for input data but nowadays you have class-validator and similar libraries for that purpose so you can validate input data right away).
Algebraic data types (which are supported by TS) allow me to easily model my business rules and, with the help of compiler, ensure that I'm following that rules everywhere.
Code is self documenting. I don't need to use JSDoc or annotate my code with Flow (yuck) to know what's happening one year later. It's right there in the code.

I keep hearing this argument that static typed languages are slow to work with - it is slow at the start but saves you time in the long run. For example, I worked on Rails code bases - good luck trying to guess what magical trick Rails pulled which caused something you wrote to work in a completely different way than you thought about it.

We see that more and more languages are adopting type annotations (Ruby with RBS, Python and PHP with type hinting, even ECMAScript is in the process of adopting type annotations etc). There is a reason why we don't have many enterprise applications written in Django or Rails but rather in ASP.NET or Spring. Types matter.

Andrés Correa Casablanca • Dec 8 '22

I'm not trying to change your mind with my response, but I believe that your take on how typing works on TypeScript might be misguided:

It's not really strictly typed, we have very vague types, such as unknown, any, or {} (although it is more strictly typed than, say, Python).
The way it works with types is much more flexible than what we can usually find in languages such as Java or C++, as typing in TS is not "nominal", but "structural".
On top of that, features such as "union types", "conditional types", and "mapped types" (which usually don't exist in traditional imperative typed languages) create a huge difference in flexibility and expressiveness.

Now, on the "why anyone would prefer strict types", well, there are plenty of informed reasons for that, the following list is not exclusive:

They reduce the amount of logic errors in our code. For example, they make it easier to implement techniques such as "making illegal state unrepresentable". But of course they go further than just allowing this.
They act as documentation.
They make it easier for autocomplete/intellisense features to work properly and much better than in strictly dynamic languages.
They act as a very powerful aid for people with attention problems, such as ADHDers.

Jon Randy 🎖️ • Dec 8 '22 • Edited

Note that my original comment is really in response to the tweet, not the article heading.

I understand very much how it works, and have used it. It just really rubs me the wrong way and takes all the joy out of working with JS

darkyelox • Dec 10 '22

The joy you talk may be good for small or micro projects like a simple web page, an small libraries and so but for big projects were many people is involved it may be a big problem for everyone working in the same codebase, trust me I have suffer so much with enterprise projects working with bare JavaScript and tons of undocumented and random objects with random properties. My point is I know what you mean but it depends of the kind of project, is only my advice.

Ashley Sheridan • Feb 8 '23

This is what I've found. Working on smaller things, it's sometimes easier to work in plain JS. However, for codebases that start at a large size, or are expected to scale to that, I would prefer TS.

One thing I do find that TS encourages me to do is to use typed objects instead of generic arrays or JSON blobs. This is something I utilise in other loosely typed languages as well, like PHP. It gets me into a good habit of thinking about the data my objects hold, how it can hold it, and when that data is available. Using generic JSON, I tend to fall into the trap of adding/amending properties too much during runtime, which leaves me in the position of needing to write more code to verify that what I _want _to use is in a state that I _can _use it.

Void⚡ • Dec 7 '22

So you like JS as is 🙂.

Thanks for sharing!

Jerry • Dec 13 '22 • Edited

There are plenty of reasons to prefer strict types:

Defining strict contracts in your inputs and outputs (ie this function takes in string return a string etc)
Reducing run time issues (type checker will make your code fufill those contracts)
No more typeof arg === <type> logic
Editor autocompletion and reference

Is it better for a small team ?

Probably not... if you have a small codebase and you are only one working on it then it might not be that helpful.

Where it shines is large teams (5+ people) working on same codebase.

Matthijs Wensveen • Dec 13 '22

I think TS solves a lot of what people consider to be restrictions by having very powerful type inference. This means that you usually don't have to define your object types or return types upfront. I often don't like the boilerplate of statically typed languages, but I don't have this problem with TS at all.

Rense Bakker • Dec 7 '22

In my personal experience, devs who refuse to learn typescript don't understand the meaning of the words: "it's a superset of JavaScript". It really quite literally is just JavaScript with type safety. Nothing more, nothing less. It doesn't add any other functionality beyond that and that decision was made on purpose. Some developers however are so religious, that they will dismiss anything beyond what they're already doing.

Mike Talbot ⭐ • Dec 7 '22

I learned it, I don't like it, I've gone back to JS in which I am significantly more productive. That's unless I have to use it for some project in which case, its fine. I prefer to document my functions with JSDoc because that's more useful than types alone and less effort.

Rense Bakker • Dec 8 '22

Thank you for proving my point that you dont understand what superset means 🤦

Mike Talbot ⭐ • Dec 8 '22 • Edited

LOL, if you really think this proves that point then you are really confused. In order to use the additional features one needs to define types, defining types is additional work that I find pointless and wasteful in most circumstances - therefore I do not use this feature of the superset. I do allow typescript compiler to read my JS as of course that helps with intellisense, but by not bothering to try to convince the compiler I know what I'm doing I save effort and end up with easier to read code that works just fine.

In the past it was the case that TypeScript allowed the use of more modern JS constructs, but Babel and the advancement of browsers has rendered that set of really quite useful superset features irrelevant.

crowdozer • Dec 7 '22

I put it off for a long time because it looked hard to learn. Brackets in function definitions? ".d.ts" files? Wtf? It looked like it would be a lot of overhead, a lot of configuration, lots to think about...

In reality, it was really easy and only required a few quick searches to figure out some of the jargon. Most of TS comes naturally I feel lol.

It made me a lot more productive and comfortable. I really don't understand the view that TS slows you down or that it's overkill for front end projects which seems to be a fairly common view. Maybe I'm just "doing it wrong" but it really doesn't take that long to set up and configure, even defining really complex types only takes a moment. I could see it being overkill if your app isn't that data driven, like if all you had was a blog or something. But a CMS or something with complex business logic definitely benefits from TS.

I appreciate that it's totally configurable as opt-in. For those situations where the type isn't actually that important, or you're working with vanilla js code, I can always just tell the compiler to allow js files, allow implicit any, or don't and slap an :any on something explicitly. It's not black or white, all or none, you know? I like that.

It's funny, PHP's typing made TS's typing feel natural to me, but going back to a PHP project, it makes me wish they supported more of TS's features. Oh, this function returns an array? an array of what? you can't tell me? 😛

Orion3D • Dec 14 '22

I totally relate, after using typescript on a project recently, you quickly start to enjoy knwoing exactly what is being returned :)

Jean-Michel 🕵🏻‍♂️ Fayard • Dec 7 '22 • Edited

There is a saying that "practice makes everything perfect" and I vehemently disagree with it. What is true is that "practice makes everything permanent".

Whether the things you permanently learn are good or bad on the long term is the responsibility of your teacher. Or yours if you don't have one. A good teacher will insist that you learn the "basics" right. Like when I learned to dance tango, they insisted for months and years that I learned to walk correctly, tango style. Not to do things that impress people that know nothing about the dance. This was annoying but it was right.

What you call the basics is in fact your foundation. Learn the right things like static typing and unit tests and you will have the right foundation.

Don't do that, and well, do you remember what they say about houses you build on sand? It is much harder than you think to unlearn the bad practices once they have solidified in your head.

crowdozer • Dec 7 '22

"practice doesn't make perfect, practice makes permanent."

I like that 😛

Vincent A. Cicirello • Dec 7 '22

Very well said. I especially like the "practice makes... permanent" part, as well as the importance of building a solid foundation.

Jatin Sharma • Dec 7 '22 • Edited

I used to think that why would I learn Typescript when I can do everything with JavaScript. About 2 month ago I was just going through typescript's docs and i mind was 🤯 with so many things such as generics, interface, etc.

Learning typescript is not that hard. Using it could depend on your project. If your project is small like 2-5 pages then go with JS on the other hand if it's big then i would recommend using typescript.

Typescript is very useful for open source project. And it's up to you to use it. No one is forcing you.

BTW I am writing an article to explain Typescript's most of the topics with some great example. You can follow me for that (Shameless Plugin)

Raí B. Toffoletto • Dec 7 '22

Sometimes I use JS, sometimes TS... I write TS thinking of JS and JS thinking in TS. You can write both clean or spaghetti code in both languages. Use what makes sense to you and the project. For example if you're mixing those with PHP or C# having to set the TS tooling may not make much sense. For my personal projects nowadays I will always go for TS. But I agree with noobies, master JS first and maybe another Static typed language... then TS will feel natural.

leob • Dec 10 '22

Using it on a new project now, and once you get the hang of it it just starts feeling "natural", it does not feel like a hassle/restrictive/cumbersome, you start seeing the benefits, and at some point you won't want to go back to JS - that's my personal experience. More or less learned it "on the job" gradually picking it up, not that hard.

Jatin Sharma • Dec 8 '22

When I see the title, I remembered this line from a song-

I got 99 problems Honday oday ch plus tere nakhray ney tin so

Translation:

I got 99 problems, they are bases plus your acts are 300 (shot towards a girl).

Void⚡ • Dec 8 '22

Haha yes it's inspired from a Jayz song.

ImTheDeveloper • Dec 8 '22

I've been back and forth a few times mainly due to legacy projects running plain js

One thing that hits me every time I go back to ts is my brain melt down of how to structure files and the project to best use the types I've defined (separate type files or interfaces to share)

I'm positive by reading over other people's projects I'll pick that up easy enough but I feel like I drop right into that swirl we all used to have with the "how do I structure my js project" but now there's these new files I want to be mindful of.

Liz Flemmings • Dec 10 '22

Typescript is not difficult to learn. Whether you use it will depend on your project. If your project is tiny, such as 2–5 pages, use JS; nevertheless, if it is large, I would suggest typescript.

I used to question why I should learn Typescript when JavaScript can do anything. I was reading through TypeScript's documentation around two months ago, and my head was racing with all the different concepts like generics and interface.

A great tool for open source projects is typescript. And how you use it is up to you. Nobody is pressuring you.

By the way, I'm currently working on a piece explaining Typescript's main concepts with some excellent examples. You may adhere to me for that (Shameless Plugin)

Fyodor • Dec 8 '22

When you TypeScript you work. When you JavaScript you play. Experience matters.

Kevin Gilpin • Dec 8 '22

What I like about TS is that it’s easy to adopt slowly. I didn’t have to learn any of the fancy features to get started - in fact I still haven’t learned a lot of it. Just adding basic types and classes and function type signatures has made the code more robust, quicker and easier to write and maintain, and it makes the code editor smarter as well. If I find the type system frustrating me in some way I can fall back to unknown and any - I’m not a perfectionist in that way :-)

Jay • Dec 11 '22

I could see legitimate use cases for Typescript with a Node app or API that is going be consumed by other teams within an organization, but I’ve flatly said no to a couple developers that I manage that we will not be using it in our main React-based web app. No one thus far has been able to make a compelling case as to why it would be useful enough from a cost/benefit perspective for build user interfaces when we control the structure of the data. Conversely, I’ve been involved in several projects over the years where using TypeScript was a net negative for developer productivity.

Liftoff Studios • Dec 7 '22

JS rn is works well enough for me
Havent felt the need to learn TS yet

Aung Myat Moe • Dec 9 '22

Typescript is safe for runtime?
LoL

Mehdi Raash • Dec 7 '22 • Edited

I come from dynamic language background. I definitely go with TS for any project.
Every decision is a trade-off, in general. If your code gets a bit bloated or learning it could impact your productivity, I totally understand it, but instead, you'll save a lot of time of yourself based on reasons bellow:

TS warns most of the runtime error while coding.
TS helps forces you to think of edge cases(ofc you should stop using any for that)
Speaking of the libraries you use in your project, you will have the benefit of auto-fill of features and methods(although JS devs are using libs might not know TS is helping to that)
you're code gets documented(by defining the type), so I think in this way the code is more readable(this might not be felt by early TS devs)

You'll get the benefit of the TS by the day one that you use it, said by Anders Hejlsberg (creator behind TS project)

rxliuli • Dec 7 '22

The trend of the times, whether they are willing or not can't change anything, just like they can't change the development of ai

Drew Knab • Dec 8 '22 • Edited

Dynamic typing isn't bad. Your team probably just writes bad code.
Strict typing isn't slow. Your team is probably just bad at formalizing the domain.

I've worked in PHP, JS, Elixir, C#, and TS amongst other things. Your type paradigm doesn't matter.

We just prefer the one that makes us feel fuzzy.

EECOLOR • Dec 14 '22

@codewithvoid Interesting no one mentioned the cost of TypeScript.

Some time ago I wrote an article: We’re not writing our code in TypeScript, why?

Even when the alternative is better.

This is a tricky statement. I'm sure you could defend that position for a specific definition of the word 'beter'. But when including certain factors using TypeScript is not better.

Volodymyr Yepishev • Dec 7 '22

If moving to typescript involves using any and ts-ignore, it is better to stay with javascript :)

Jesus Guerrero • Dec 7 '22

I am somewhere in between. Coming from C# the freedom and the pace of a dynamic language was in part was attracted me to js/php. Following good practices, naming conventions and good functions was good enough.

I feel that obviously the ball is moving to TS as dev we have move. I just don't get why the over reaction of how good TS really by just adding types (js docs were/are really good at it) Interfaces and Generics are powerful though.

But to be honest I think is one of those polarizing tools that once you get used to it in a day to day work it is hard to go back.

Dan Jones • Dec 14 '22

When I can do:

<script type="application/typescript">
  // ....
</script>

Without any transpiling, I'll consider it.

Matt Ellen-Tsivintzeli • Dec 13 '22

Type notation isn't particularly useful.

Muhammad Sifat Hossain • Dec 13 '22

I haven't conquered JS yet but all of my projects are written in TypeScript. Long live Types. I can't explain how much it helps me to avoid silly and subtle bugs.