I've already talked about how much I love TypeScript in some of my previous posts. It allows me to be more productive, but most importantly - it improves my development experience.
Basing on the recent trends, TypeScript NPM download stats, and the general "buzz" around it, I'd say a great many people agree with my opinion. But it doesn't mean that all do, as indicated by all the TypeScript critics out in the wild. That's why I think it's important to consider all different opinions regarding TypeScript, to determine what the future holds for now-successful JavaScript super-set.
Advantages
So, to try to determine what the future of any kind of product might look like, we first need to get to know its pros and cons to understand what kind of value it provides for the end-users.
In the case of TypeScript, I guess if you're reading this article, then you probably have already heard about most of its advantages, so I'll be brief.
Less (runtime) errors
The statically-typed nature of TypeScript is believed to result in fewer errors during runtime when compared to dynamic JavaScript. Common issues like typos, data inconsistencies, etc. can be easily caught by TypeScript during the compilation step.
Better development experience
Yet again, thanks to static typing, TypeScript can be used by modern code editors and IDEs (like VS Code) to provide the developer with almost real-time feedback, autocompletion and error highlighting.
Better code quality and documentation
Because correctly (i.e. strictly) set-up TypeScript forces you to add proper typings to all functions, classes, and other constructs, it almost automatically results in better code quality and documentation. Now, surely it won't bring from the dead the worst of the worst codebases, but when paired with proper naming strategy, TypeScript still performs better in this area than bare-bones JavaScript.
I told you I'm gonna be brief. ;)
Disadvantages
So, while TypeScript advantages are commonly-known, its cons and all the reasons why you might not want to use it - aren't. That's why I'd like to take a bit more time to discuss some of the more "popular" of these disadvantages (or should I say "believes") and possible contradictions related to them.
It doesn't fit JavaScript's dynamic nature
Because of TypeScript fundamental characteristics like static-typing and compilation, some say that it doesn't fit with the JavaScript's dynamic nature. JS is primarily the language of the Web, where nothing is static, changes happen all the time and data comes from multiple sources throughout time. TypeScript isn't suitable for such an environment... right?
There's a bit of truth in that claim, but it's a bit like saying that no statically-typed or complied language is good for any "dynamic stuff". That's obviously not true. Sure, there's a bit more work involved, but you can pretty easily create proper interfaces and other type structures to handle all the dynamic data in your codebase. And if you're not willing to do that then you can utilize the any type and "fallback" to what is pretty much just JS, while utilizing TypeScript features in all the other places.
TypeScript is usually misused
So, TypeScript with its any type is perfectly fine for any dynamic code, but this leads to another problem. The any type itself, while definitely useful in a great many cases, spreads quickly and violently when not used properly. This in result, leads to pretty much all TypeScript benefits being negated. Why even use TS, when you don't utilize its full potential?
This argument of TypeScript being commonly misused is very much realistic. Especially among TS new-comers coming from JS, or during JS to TS codebase transition, the use of any type often goes out of hand. However, a simple fact that some developers don't utilize TypeScript correctly is not a reason to not use/recommend the language to others. TypeScript any type is a feature that can work wonders - it can save time, help transition the codebase from JS, etc., but if and only when used properly.
TypeScript rewrites are a waste of time
Speaking of codebase rewrites, you most probably have heard the stories of
Big company X transitioning their codebase to TypeScript and catching Y percent more bugs before deployment while doing all this Z percent more efficiently.
These scenarios are quite common, but it's also well-known that rewrites of any kind result in a boost to the development experience and error minimization. So, why bother?
The time and resources required to convert JS codebase to using TS, while also familiarizing the entire team with the new tooling can indeed outweigh the potential benefits. Especially when working with huge codebases, TypeScript rewrites can even cause slowdowns and unnecessary confusion - especially when having top-of-the-line, well-tested, and well-documented JS code already.
With that said, it's not like there are no benefits to TypeScript rewrites. It's just that they're a bit more... long-term. After the initial hassle of rewriting everything with proper typings included, you can expect better and faster development experience down the road.
You can achieve the same results with JSDoc
The biggest incentive for using TypeScript for me is definitely the development experience that it provides when paired with proper coding software. But the truth is, it's not a TS-only feature. A well-known documentation format known as JSDoc can provide the same set of benefits (and some times even more), without a need for changing file extensions or "polluting" your JS code with custom TS constructs. Just good, old JavaScript comments.
If you haven't already seen it, here's a small example for you:
/**
* Example function description.
* @param {number} param1 - Number parameter description.
* @param {string} param2 - String parameter description.
* @returns {boolean} - Description of the returned boolean value.
*/
const exampleFunction = (param1, param2) => {
// ...
}
So, basically a multiline comment with special marking and some @tags for different things. It's that simple and with it, we've already properly documented our function with type information included! Sounds too good to be true, right? Where's the catch?
Turns out there's pretty much none. JSDoc is just really cool. It can easily be used to provide similar development experience to TypeScript, can be adopted incrementally without any compromises, and can also be used to further describe your code and even generate dedicated documentation from it!
But TypeScript still has some tricks in its sleeve. Check out the following comparison of TypeScript interface and variable type declaration vs JSDoc.
/** Description */
interface Example {
/** Description */
prop1: number;
/** Description */
prop2: number;
}
/**
* @typedef {object} SecondExample - Description
* @property {number} prop1 - Description
* @property {number} prop2 - Description
*/
/**
* @typedef {{prop1: number, prop2: number}} ThirdExample - Description
*/
const exampleVariable: Example = { prop1: 1, prop2: 2 }
/** @type {SecondExample} */
const secondExampleVariable = { prop1: 1, prop2: 2 }
/** @type {ThirdExample} */
const thirdExampleVariable = {prop1: 1, prop2: 2}
I think you already see where I'm going with it. TypeScript "syntactic sugar" while not necessarily more capable than JSDoc, is certainly much cleaner and plain better for defining complex types and interfaces. In addition to that, JSDoc can still be used with TypeScript for better describing your code, while types are handled the other way, or during the transition period from JS to TS codebase, without relying on any any types.
Lastly, even though you can configure your tsconfig.json to type-check JS files with the help of JSDoc as well, getting it into strict mode - the one in which TypeScript is the most well-known for - can yield results that are described as "surprising" by the official documentation (aka not working greatly).
So what's the future?
With all these pros and cons of TS in mind, I think we can now see where it's going. Honestly, as you've probably heard a couple of times now - TypeScript isn't going to replace JavaScript any time soon. Personally, I'd go even further than that and say that it'll never do - it wasn't even designed or meant to in the first place.
TypeScript builds on JavaScript as a solid foundation. It's meant to improve the development experience and code quality, but that's it. It was designed this way and this way it should stay. Because realistically, how would you even imagine native TypeScript support in the browser? It could speed up the execution time because of the additional typing information and potential optimization related to it, but would also increase the bundle size by a noticeable margin, slowing down the entire process of downloading and executing the code, thus negating any potential performance benefits. And if it was to compile to some custom, highly optimized format, then we'd lose the any type which is, after all, one of TypeScript's fundamental features, and potentially end up with just another WebAssembly (or should I say AssemblyScript).
To sum it up, I think TypeScript will continue to grow in popularity for the foreseeable future. It provides great development experience, doesn't have much competition, and enjoys high adoption rates among (especially new) open-source projects.
Bottom line
So, that's my opinion. But again, I'm a kind of guy who's capable of rewriting entire libraries in TypeScript just to get these somewhat negligible in such cases benefits. What are your thoughts on TypeScript? Are you using it? Why/why not? Do you see any additional advantages/disadvantages that I didn't mention? Leave all your thoughts in the comments below!
For more up-to-date TypeScript and web development stuff, follow me on Twitter, Facebook, and consider checking out my personal blog. Thanks for reading and happy typescripting! ;)
Top comments (38)
I'd probably go as far as to say that TypeScript may not necessarily be the ultimate "future" for JavaScript and web development, but it sure is the "present".
It shouldn't be. It's a crutch for devs coming from class-based, statically typed languages to JavaScript, lulls devs into a false sense of security in thinking they can hack JavaScript to behave like those other languages and not bother learning prototypes and dynamic types, adds tons of learning curve to and distracts newer devs from learning JavaScript proper, and those classes don't transpile nearly as cleanly (the same is true of ES6 classes, which were largely a concession to class-based OOP devs who couldn't fathom that JS has always been OOP, just not their flavor of it).
You know this reads as "old man yells at cloud"
Meh. I'll still know the only actual typing that matters after TypeScript's disappears in the transpiler, and my production code will be smaller because it's not the mangled garbage that "classes" turn into.
And given the likes that comment is getting, it seems I'm not the only old man yelling at it.
Unless it's performance sensitive code, what's the difference? If the developer time saved and bugs prevented is more than the bandwidth costs and time difference, it's worth it.
Anything that helps prevents bugs is not a "crutch", it's a developer productivity tool. Or correcting the analogy, it is a crutch, so that you don't trip and fall. It's not a bad thing. People make mistakes. Period. Admitting that and trying to prevent those mistakes is not a bad thing. Do you have all the unit tests for bugs that would be caught by the compiler? No? Then I don't trust your code. I don't care if you're Brendan Eich or someone junior.
Except that, in practice, this leads to convoluted codebases which are more difficult to organize, read, and maintain, much like the "object oriented JavaScript" (🙃) craze of the early-mid last decade and the silly MVC-for-the-sake-of-MVC projects it led to (which often, somehow, managed to be less readable than the spaghetti codebases they were refactored from).
This isn't jQuery or Underscore/Lodash which, as completely unnecessary as they are now, were handy convenience wrappers that ended up informing the development of JavaScript's own methods because of their utility.
This is "Can't handle JavaScript qua JavaScript? We got you fam. Feel free to hack at JS to make it behave like the language you wish it were." It's basically everything Kyle Simpson warned about in YDKJS.
Oh... And it's also (being generous, if you believe the survey results that half of all JS devs are using TypeScript) a way to immediately slash your available talent pool in half by requiring it.
Depends all on how you use it. Functions with typed parameters and indicating something as nullable or not is going to get you a good chunk of the benefit without straying too far from javascript. If you're doing objects for the sake of objects? Yeah, that can get convoluted if you're not disciplined. Stick with POJO and functional programming if you don't like classes.
Are you saying you never typoed a field? Or do you use jsdoc to make sure you get field names right? If not, what is your testing strategy to make sure you didn't get things wrong. How do you deal with maintenance?
If someone can't handle simple type definitions on function parameters and return types, they're not a dev I want to consider anyway. They don't have the required discipline or flexibility. If you've jsdoc'ed your code, you can understand enough of the syntax in like 5 minutes.
These should be documented anyway. I'd rather enforce the (much simpler, and more necessary) standard comment syntax of JSDOC than that plus a bunch of extra crap which isn't actually part of the language.
Pssst... They're still functions.
Sounds a lot like someone who not only expects, but insists on one language behaving like another, rather than using the language as designed (if it makes you feel any better, I've long said the same about Python devs and CoffeeScript - just, fortunately, it didn't take off nearly as much... Now, YirgaCheffeScript or SidamoScript? Count me in).
2.5 if it's JS. You should be using JSDoc (and linting) anyway.
But again, to give TS (utilities) some credit: ts-check (which recognizes JSDoc, and can be set for JavaScript) is a fantastic tool while coding in VS Code. I mean that sincerely.
And tsc is great for turning TS codebases into (at least semi-)usable(/fixable) JS/ES.
This is true, a lot of Typescript devs come from statically-typed languages and know how useful static types are for preventing a whole host of bugs.
This, however, is completely false. There's nothing in Typescript that forces people to skip learning the basics of Javascript. Typescript is a typed superset of Javascript. All valid Javascript is valid Typescript. Typescript is just a way of eliminating certain types of errors in Javascript. There's nothing that says that developers have to work one way or another using it.
Typescript has very good type inference and doesn't require actually writing it. You can work in a Typescript project and never write a single type definition. Implying that Typescript in any way affects newer devs' ability to learn Javascript is objectively false.
Nothing in Typescript requires that you use classes. ES6 classes were the result of a standards committee improving Javascript, not doing anything to cater to one specific audience. It's an optional extension of the language that you can use or ignore. Typescript neither encourages nor inhibits you from using it, but I think you'll find that the majority of Typescript developers don't use classes.
In conclusion, please educate yourself before you rant on something you have no clue on what you're talking about.
As usual, this comes off as someone who assumes I haven't worked on numerous projects written in TypeScript throughout the years, and haven't attempted to give it (and, as I mentioned in a previous comment, CoffeeScript) a fair shake. I have, repeatedly, and the benefits have never outweighed the drawbacks. Your beloved superset ends up not only being superfluous, but detrimental.
Time and time again, I've heard the same refrains:
Wait... I'm confused. I thought in TypeScript everything JavaScript was valid and good and... How is it something you believe improves JavaScript, that is now actually in the spec, is harder to use with this blessed superset thereof? While I don't share your opinion of ES6 classes, do you not see the contradiction here?
And nobody on the TS side seems willing to address the effect it has on both junior devs and talent pool.
I usually hear, as I did earlier in this thread, "not the type of dev I'd want to hire." That doesn't answer the question. So how do you create experienced JS devs? Is your answer to take experienced C# devs and plop them into JS via TypeScript?
And what about that other 50% (again, likely WAY higher) of JS devs? Do you just tell them their however many years of experience with JS are invalid if they don't write TypeScript?
And for the small startup and the dev(s) they're fortunate enough to find who they can afford with enough competence to build their product, do you impose TypeScript on them?
Because you write like someone that hasn't taken the time to actually give Typescript a shot and make very, very basic mistakes about how it works and what its purpose is.
You haven't given any reasons for it being detrimental.
Typescript is more capable of representing complex types and doing so with dependencies. That's not something you get with JSDoc; more npm modules have correct Typescript typings than JSDoc documentation. Typescript is also much more elegant, saving probably multiple kilobytes of space on a large project compared to JSDoc comments. Last, Typescript types everything by default, while JSDoc does the exact opposite. If you forget a JSDoc comment on a variable or a module doesn't have JSDoc types, then you're screwed. Typescript covers much more, is much safer, and is much more elegant.
I never said this, I said it gives you more type safety than whatever tool you're using currently. It's not 100% type safe (I doubt this is not possible), but it does prevent a large margin of errors from even happening, much moreso than JSDoc.
If you'd really used Typescript before you'd know that Typescript requires you to use runtime type-checking in order to limit down union types. It's encouraging better practices, not replacing them.
I again didn't say this, please avoid putting words in my mouth. I said the majority of Typescript developers I've encountered prefer to not use ES6 classes simply because there are other alternatives (e.g. a more functional flavor of Javascript) that work better for them with the same effects.
It... doesn't have any effect? It's just a tool. That's like saying ESLint or JSDoc has a significant effect on junior devs and the talent pool.
I didn't say this. You're sounding fanatical.
I didn't say I'd impose Typescript on anyone, but it wouldn't necessarily be a bad thing. Typescript isn't that hard to learn and doesn't take near as long to get started with as you're implying. It's just Javascript.
Are we really worrying about kilobytes? That's like arguing for SQL over NoSQL (not at all implying there aren't legitimate use cases) in 2020 because "storage is expensive."
You do know comments get stripped out of transpiled and/or minified JavaScript, right? And why aren't you worried about kilobytes of type definitions in not only your code, but every DefinitelyTyped definition dependency you're pulling down?
I literally quoted you saying ES6 classes are harder in TypeScript. NBD, and I'd say encouraging devs not to use them is a plus, but I'm not the one who called them an improvement to JavaScript, and making something harder (which is still commonly used in TS, seen it plenty of times) isn't the way to discourage it.
No, it's not.
I've said what I needed to say, based on years of experience in both JS and TS, and I know I'm not going to change the minds of people dead set on treating JS like another language built on completely different paradigms. So I'll leave by recommending they check out Ryan Dahl's (Node.js and Deno creator's) recent experiences and motivation for moving away from TS for Deno's internals, and especially Kyle Simpson's (YDKKS author's) comments (some of which are the same beefs I have) as to why that's a bad idea.
I'm not worried about it, I'm saying it saves space, both in the amount of code you have to read but also in the final sizes of the files you're working with. JSDoc comments are ugly, illegible, and not usable if you use them everywhere to get the same type safety you get from Typescript. JSDoc is a great way to document Javascript, but it is not in any way a replacement for Typescript if you care about type safety.
No, you didn't. I said this:
Not that Typescript classes are harder to use, but that most Typescript, and Javascript, users don't feel the need to use them.
Because it was better than the previous implementation of classes (having to use objects)? I mean... it's objectively an improvement to Javascript. If you can't acknowledge that, then you really don't need to be making any sort of comments on anythingJavascript-related.
Seeing something several times and it being 'common' in TS code are not the same thing. Please provide numbers that the majority of Typescript code uses ES6 classes solely (not just for working with a single library or for a single component, but as the base building block of an application) and then we can talk.
Here's the link to Ryan Dahl's experiences with Typescript. I'd recommend you actually read what you're sending me before commenting because he says this:
Kyle Simpson said this about Typescript:
Don't see any negative opinions here. Link to the tweet.
Please stop commenting. You're showing how uneducated you are on the topic and how little you really know. It's exhausting.
I'm sure it is exhausting having to edit your comments after I've pointed out a contradiction, so it looks like I fabricated your actual words as shared in the blockquote (yeah, you did that, the blockquote is exactly what you said... That's pathetic, dude), and cherry-picking the one lukewarm comment you could find from Simpson (among countless negatives) that you could drop to make it look like he supports TS.
But yeah, it is a complete waste of time to debate someone who has to stoop to such lows.
I'm not cherry-picking any comments from Simpson, I found a comment that said he is indifferent to Typescript.
As for the Deno post, I read the comment at the top of the document you sent me that says that the findings in the document shouldn't be used as a way to talk about the usefulness of Typescript. Again, here's the part quoted from the document:
Typescript was not the right choice for Deno's internals. Only for the internals, not for anything else, because the Typescript compiler resulted in some runtime inefficiencies for them. Almost nobody will hit that issue in production, and it's slowly being solved by rewriting TSC in Rust, like the swc project is doing. It is not cherry-picking for me to listen to the author's intent. I did not intend to make it look like he supports TS (that was implied nowhere in my comment). Please read my comments more carefully before assuming ill-intent.
Maybe you should read the resources you link (or quote, for that matter as well) before commenting on them. Similarly, maybe you should actually use a piece of software extensively, observing the community and projects surrounding it much more carefully, before making false, unsupported claims about the project's usefulness or capabilities. In the future, I'd highly recommend against doubling down on your claims when someone points out that they're wrong, using that as a sign that you need to educate yourself further on what you're talking about, instead of continuing to spout false assertions and FUD that might deter new users away from using a beneficial piece of technology. It's toxic, immature, and makes no one want to believe or take seriously any of your points.
Must be even more exhausting, putting forth that much effort to FUD my "FUD" (which couldn't possibly be based on numerous real life experiences over several years, because you disagree with me).
And Dahl's experience isn't nearly as uncommon as you would have people believe. That's why I referred to it. In this case, it's a matter of direct impact on a tool that more and more people are migrating to, away from Node. It's a BFD.
As for Simpson, he has expressed plenty of opinions unapologetically against TypeScript. As I said, it must have been exhausting to hunt down one snippet that was mere indifference.
And there's still the (pathetic) matter of editing a comment to make it appear that I made up a direct quote from you. It's OK. We all contradict ourselves at times, especially in the heat of an argument (and frankly, it wasn't that big of a deal until you resorted to the narcissistic, abusive boyfriend tactic of "I never said that!!!"). It's not ok to resort to virtual gaslighting when called on a contradiction (and again, a minor one until you went this route).
There's obviously nothing to be gained from continuing this "debate." You like TypeScript. I like actual JavaScript.
Let's not get any deeper in the weeds, so you don't have to resort to any more toxic behavior. On the whole, DEV's comments are extremely productive even when there is disagreement. This, on the other hand, is more akin to Reddit.
You provided no evidence to support your claims and severely misunderstood basic parts of Typescript. I doubt your life experiences were extensive enough for you to be able to make an informed decision on whether Typescript is useful for a project or not if you were unable to get basic things right.
Please provide evidence that this is the case. Are there any other experiences with Typescript that I should be reading about? Are tons of people using Typescript as a runtime instead of using as a compile-time tool, as it's usually intended to do?
Please provide links, I could not find any evidence of this.
This was taken from the first page of google:
There is literally no need to behave like this. It's toxic and I suggest you stop.
I like both. This is not an either/or situation, it's possible to like multiple languages at the same time.
I was not the one that compared the person I'm talking with to an 'abusive boyfriend'. And you're right, this conversation is done. Dev.to admins have been notified accordingly. Please stop with this behavior. It creates a toxic and unwelcoming atmosphere for those that are new to Dev.
Is it done or am I supposed to provide examples?
And tattling to the admins after you edited your comment and called me a liar for quoting it in its original form? The same admins who would be most likely to have a record of your edit?
Yeah. I'm done. Let them sort it out, but let the record show that I never attacked anyone personally (as you did many times, provable at least until you make more edits) unless calling out a quoted contradiction (which you then deleted) counts, until you continued that attack by calling me a liar with nothing but an edited comment to back up the claim (the aforementioned "virtual gaslighting," which apparently continues with you suddenly "taking the high road" immediately after yet another personal attack).
Feel free to get the last word in, as I'm sure you will.
Actually, that's not the only source of
any. Some other sources areObject.entries,Array.prototype.includesIMO, always have to keep in mind, that TypeScript's typing is not perfect, and may lead to false sense of security and reliance on TypeScript's suggestion. Best way is to do testings as if it is JavaScript, and defensive programming / validators, when required (e.g. accepting user's input will always need validation).
No where as strongly typed as a true static typing language, e.g. Kotlin/JS.
You have to enable either
// @ts-checkor somejsconfig.json/tsconfig.jsonsettings, as well.No where as convenient as TypeScript's interface IMO. However, a competitor is indeed Flow.
No.
There is no the future of web development.
There are many competing and co-existing futures, some of which may be more or less popular.
And even if it does become overwhelmingly popular for a time, that's only going to be for a time. :)
True
Many approaches to web development would exist as we progress
Companies would just have to use the ones that seem reasonable to them
I wonder what the tc39 folks think about typescript.
They already caved to classes, unfortunately.
When you got Jsdoc and serious naming strategy, types are a waste of time !
Just invest in code quality and forget typescript.
If I want crosscompile I have haxe/c#/rust/c++ that are more powerful than typescript.
Typescript are made for dev that does not know to write code without compilation...
Not really I would still stick to ES6 convention or future versions due to it being independent and affect a general amount of people who uses it.
I think Typescript have very successfully positioned itself as javascript that corporations and like minded companies prefer as they already like strongly typed C# and Java. Typescript allows JS to compete in similar space.
Have you worked in those messes of corporate C# and Java codebases? Three words: Resume driven development. There's a reason we still have O&G companies in Houston who are using ancient versions of both, often with AngularJS frontends they still haven't been able to migrate away from.
While I'm not going to debate the main question of this article, I will go on and describe my experience with TS.
I didn't plan to learn JS or TS. I just "had to", at some point, as my company made some sudden changes.
2 years later, I'm able to write pretty decent TS code, regardless of the frameworks used. However, I can't stand JS. It's a PITA for me to read / write plain JS.
But that's just my subjective experience. Maybe the fact that for many years I wrote Java and PHP code had something to do with how I perceive native JS.
God, I hope not
I certainly hope not, for all of the reasons I gave in my reply to @somedood and more.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.