Why have all JavaScript developers not moved to TypeScript?
I asked this question on Twitter last week and got ~100 replies.
Sharing my learnings from the responses, as it gives insight into what keeps developers from migrating to new tech. Even when the alternative is better.
Let’s get into it.
TL;DR
- Conquering JavaScript first
- Vanilla JavaScript works
- Sorry, too soon
- Well, it depends
- ECMA is getting there
Conquering JavaScript first 👨🏫️
A lot of newbies and beginners gave the “I am still learning JS” response.
Understandably they don’t want to take up more than they can chew at the moment.
Most of them are interested in trying it out in future, whereas some were looking for guidance on if they should.
Vanilla JavaScript works 👌
Developers already working with JS, had a pressing question → “What’s the need?”.
They don’t plan to migrate due to having a large codebase written in JavaScript, ease of debugging, or simply because they are comfortable with JS as it gets the job done.
Their motto: “If it works, don’t touch it”.
Sorry, too soon 🕒
Some experienced JS developers have learned TypeScript in plans, but think the right time has not come yet.
Unlike developers who are not willing to migrate, these devs see value in TypeScript. Just that they didn’t get the right project yet, which justifies the learning curve.
Also, they are hoping that tooling (like support for running TS code natively in the browser) will improve in the future.
Well, it depends 🧐
Some developers have spent time learning TypeScript, but don't use it for every project.
As per them, it’s suited when:
- Working in a team
- Writing production apps
- Codebase is huge
They said "For personal projects and simple apps, TypeScript is an overkill".
ECMA is getting there 🏁
Lastly, a few responses were about ECMA 6 already supporting enough modernity to write clean code in JS.
These devs suggest, if you understand JavaScript well enough with tooling built around it, you don’t need TypeScript.
Also, they are hopeful that useful features in TypeScript will eventually be included in native JavaScript so why bother with 2 learning curves.
Wrapping up 📝
Share in comments your motivation to move or not move to TypeScript?
If you liked this post, you can follow me for more of these.
Oldest comments (44)
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
So you like JS as is 🙂.
Thanks for sharing!
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:
nullobject or implicit coercion happening when I don't want it (yes, you need additional validation layer for input data but nowadays you haveclass-validatorand similar libraries for that purpose so you can validate input data right away).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.
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:
unknown,any, or{}(although it is more strictly typed than, say, Python).Now, on the "why anyone would prefer strict types", well, there are plenty of informed reasons for that, the following list is not exclusive:
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
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.
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.
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>logicEditor 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.
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.
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
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)
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.
"practice doesn't make perfect, practice makes permanent."
I like that 😛
Very well said. I especially like the "practice makes... permanent" part, as well as the importance of building a solid foundation.
JS rn is works well enough for me
Havent felt the need to learn TS yet
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
:anyon 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? 😛
I totally relate, after using typescript on a project recently, you quickly start to enjoy knwoing exactly what is being returned :)
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.
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.
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.
Thank you for proving my point that you dont understand what superset means 🤦
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.
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:
anyfor that)Just wrote an easy guide
dev.to/fredysandoval/typescript-a-...
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.
If moving to typescript involves using
anyandts-ignore, it is better to stay with javascript :)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.
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.
When I see the title, I remembered this line from a song-
Translation:
Haha yes it's inspired from a Jayz song.