Everyone loves TypeScript. It “solves” many problems JS has, it is a “superset” of JS, it will make your code error-prone and pleasant to read. There are a lot of good reasons to use TypeScript, but I am going to give you 7 really good reasons not to.
It is risky
Wow. How can it be risky, if TypeScript adds type definitions and checks them at compile time? As well as IDE integration will warn you about any type mismatches? Exactly because of that. TypeScript will only check types at compile time and only types that are available. Any network calls, system libraries, platform-specific APIs and non-typed third-party libraries have no way of communicating with TypeScript. As you get used to having your types checked and not having to fully understand the code and the platform, errors and bugs will manifest themselves.
With JS, you make no assumptions about types, and you check the concrete value of the variable to make sure it is what you expect it to be. Or, if you do not care about its type in this particular case, you do not. In TS, you rely on the compiler to do it for you, but it can only check so much. You can combine the two ways, but what is the point then? If you will spend time writing definitions and then spend time writing code to ensure these definitions are maintained during runtime, why have them in the first place?
It is messy
Another paradox: the language that was supposed to bring clarity and readability to the codebase obscures it instead. To show you what I mean, check out some of these examples I found in popular open-source libraries:
This one is from the Redux library, and all these 4 lines do is assign nextReducer to currentReducer.
Next example if from the RxJS library. I do not know about you, but if I have to fight a tool that is supposed to help me, I do not think this is a good tool.
It does not solve the problem
TypeScript is said to solve JavaScript’s problems. But it does not. Dynamic typing was never a problem in JavaScript, but many other gotchas such as NaN === NaN being false, semicolons being optional or not optional, a linebreak changing an object definition into a scope, syntactic sugar in place of OOP are indeed problems. TypeScript does nothing to solve them, but introduces yet another standard, further polarizing the JS community.
Even under the assumption that the lack of typing in JS is a problem, TS does not solve it. Do you know what does? Java, C, C# and other compiled languages. They can safely guarantee strong typing at compile time and runtime. Interpreted languages are just not capable of it.
It is not a superset, it is a subset
TypeScript is something that compiles into JavaScript, it cannot be a superset by definition. It limits what you can do with JavaScript and obscures its strong sides while providing a fake peace of mind. If you really want to be a great developer, do not settle for a comforting lie and try to understand the true power of JavaScript and its flexibility.
It is open-source, but nothing more
Many reasons for using TypeScript state that it is open-source. That is true, TS compiler is distributed under MIT license. But it is still controlled by Microsoft, a giant monopolistic corporation, and its open-source advancements are nothing but a marketing move. Do not confuse open-source with democracy: Microsoft is still free to do anything you want with TS, and you are just here to watch. JS, on the other hand, is governed by an international committee and will not change anything without the community’s approval.
But big companies use it…
I cannot believe that some people consider this a reason. Big companies also use legacy codebases, commit tax frauds and discriminate against women. Why all of a sudden them using TypeScript is a good example?
But it has more features…
Not anymore. True, when TS was first introduced in 2012, it had features like classes, still not available in JS. But JS had come a long way since then, and now TS is struggling to keep up. If there is anything missing in JS, there is a babel plugin to do it.
Thank you for reading, I hope you liked this article! For more info about advanced concepts in JavaScript check out my other posts:
- To infinity and beyond with JavaScript Proxy API
- Builder pattern in JavaScript
- Deep dive into ES6 Symbols
Interesting article. Thanks for sharing!
Really good article. I think Typescript had a reason to exist when it was created 2012. Nowadays, it is true that it offers fewer advantages, we deserve a better alternative but… it’s a religion in hype.
Thanks to god! There are some people thinking as me.
I am agree with all of your arguments, and think as Johnny too: “It’s a religion like”
This seems like a pretty biased article to me.
Risky? It’s meant to be a help you catch some things earlier, it should not replace your tests which should catch issues whether using JS or TS
Messy? It can be used in a way that is pretty visually verbose e.g. in a complex library. This is generally to give user of the library and the IDE a more discoverable and informative experience when using the library. Actually using it in your application, it is often very clean syntactically and at a glance describes what something is.
Doesn’t solve the problem? Humans are the ones writing JS. It is very easy during development of an application that you miss something innocuous which causes a runtime error. Risk of this is dramatically increased if refactoring a large project with similar named code structures. So it goes a long way to reducing human mistakes from dynamic typing
It’s not a superset, it’s a subset? Same point as above, humans are the subject here, not Typescript itself. It allows humans to state and enforce a super set of functionality like abstract classes and methods, JS adds and is planning to add some of this into JS which is great and ideal. But in terms of the code written and delivered, it offers a superset of ways to write code that does exactly what you intend and can’t be written in the wrong way (by another developer)
But big companies use it? They often have high standards, have the goal of making money and want to use the best technology available. It surely lends some credibility to TS that hugely successful tech companies see the advantages.
If you are responsible for a large project with multiple developers where you want to continuously want to refactor it by applying your latest knowledge to have the best platform it can be – you can easily see the value it offers.
Team members can share explicit definitions of their code with others. This is great for other develops as the code becomes much more discoverable and you have reduced their ability to cause unintended problems using your code via strict type annotation.
You can also refactor with confidence, personally I have done Ctrl+F replaces when I have accidentally changed the name of a variable with a similar but different name. Typescript flags this in the IDE, giving you much more confidence and increasing the quality of your code.
Why might not want to use it:
– Rapid prototyping
– Easier debugging via straight JS
– Straight JS may have better performance since you explicitly structure your code compared to whatever Typescript generates.
There are reasons to use it and not to use it but it’s a balance. All or nothing one way or the other is self defeating
Yes, I agree it is biased (after all, I post my personal view on the matters on this blog). And I am not saying you cannot make TypeScript work. What I mean is that this is not a solution for the inherent JS problems, and it is possible to create a sound codebase without depending on TypeScript. As for the big companies, do they really produce quality software? I mean, TypeScript is from the same company that wrote Windows, and while Windows is very robust and gets work done, I would never go as far as suggest it works as good and as predictable as Linux/macOS
There’s so many more reasons that that.
I can’t think of any reason TO use TypeScript. It’s demonstrates a fundamental misunderstanding of programming to purposefully “convert” a loosely typed language into a strongly typed ones. As if the open community of computer scientists that are responsible for the evolution of JavaScript just keep just “forgetting” to add types to their loosely typed, dynamic language.
What is the practical difference between a double and a float type in C? The answer to that question is the original reason for using types, and it’s something that JavaScript developers, thankfully, do not need to worry about.
Not to mention that it is not compiled, it’s transpiled. It’s converting one language into another one. What you end up with is still JavaScript – it’s just JavaScript written by an algorithm with a whole bunch of polyfill and/or other unnecessary bloat inserted in order to accommodate the programmer (as opposed to accommodate the solution to the problem). This is the wrong tool for any job and especially any job that is performance sensitive.
Good programmers should know more than one language and be comfortable with multiple programming paradigms. If you need TypeScript in order to feel comfortable with your code base, that problem exists between the chair and the keyboard.
The ultimate sophistication is simplicity. TypeScript is a huge swing and miss from the corporation that also bought the web Internet Explorer and Silverlight. Why would anyone want to insert a layer of complexity into their build process in order to program in a different language than the one natively interpreted by the client? It seems so ridiculous I can’t believe it’s so popular. I would pass, but unfortunately it seems it’s so hot right now with hipster front-end developers, I’ve got no choice but to use it.
The thesis of this post seems to be: “Typescript doesn’t solve every problem, so don’t use it.” I mean, no technology solves _every_ problem, but Typescript prevents a whole heck of a lot of bugs in my experience. And thus should be used in most JS circumstance while — as with any technology — understanding its limitations. It’s one more tool in the quality arsenal. Alongside unit testing and, of course, thoughtful software design.
What I meant to say is “typescript does not solve JS problems but creates new ones, so don’t use it”. Carefully designed JS code prevents a lot of bugs in my experience, and TS will just mitigate the symptoms of a rotten codebase for a while, but will not make the problems go away, as it is no substitute for clean code.
Sure wish they’d just add types to js itself. “let int x = 3” or something like that. Would sure solve a lot of problems.
This is a brave article; very courageous to put your views out there like this, knowing the combative responses and disagreements you’re inevitably going to have to face. I appreciated the article. It was a fun read and had some good points. And I must agree, I can’t see even a halfway-decent reason to write in TypeScript. I’ve searched high and low, and that’s even one of the reasons I found your article to begin with: searching for a reason to use it. But all I’ve found is very clearly dumb opinions and faulty appraisals.
There’s this weird thing I see all the time in the opinions of TypeScript users, which is that they feel it’s a great, clear improvement over ECMAScript, but then they say stuff that proves, in detail, that they don’t understand ES or loosely-typed functional programming very well. They make comments and describe concepts that just don’t make any sense to those who have a sound education in ES. They talk about it like it needs more data types, like an old strongly-typed language from the 1970s, as though there isn’t a great reason NOT to have more data types.
So as far as I understand it, TypeScript solves a problem that ES writers should not have. And for those who DO have that problem, the real problem seems to be that they have the wrong idea about how to write ES. They see TypeScript as a solution because they write in a style where it becomes a solution to the problems they are having, but if they used the language as it should ideally be used, they wouldn’t even have personal experience with those problems to begin with.
It’s really hard to explain this stuff to people who like TypeScript. It’s like explaining to Java or C# writers that they don’t need to use classes in ES, and that by using classes in ES, they’re just wasting their time enormously. People who have that mentality just think it’s what has to be done. And people who love strong typing seem to be the same way. It’s very difficult to convince them that they’re only hurting themselves by trying to enforce additional data types in a language that was designed to be used without them.
Thank you for your kind words!
How can typescript be a superset of JS if it just breaks some aspects and essence of the of the language itself? TS is nonsense and makes lazy programmers for JS env. While it surelly gives some help for ppl using code in finding parameters and there respective ‘types’, I don’t like this. There are reasons why ECMA don’t officialize types in a dynamic typed language.
Very well said. I’ve never been a fan of Typescript, Adobe’s strongly typed ecmascript based AS3 implementation however, was excellent in comparison.
Great article. as a front end developer for 10+ years Typescript is the worst thing ever invented.
They try to change this beautiful language, and it’s very sad that new developers learn only Typescript and have no idea how to use Javascript.
Companies depend too much with it, a good developer that is in control of his code doesn’t need it, and it will soon leave this world I’m sure.
Glad that there are some ppl that thinks typescript can be an overhead and see it as a burden.
jsdoc, default arguments, async and // @ts-check goes a long way with doing typing without typescript.
TypeScript adds an overhead. makes the project bigger, will always be in the shadow of the next version of JS and have to keep up with all new changes + it don’t “actually” run anywhere without being transpiled to js in the first place. so you can’t import only the necessary source file in the browser without having to include the hole compiled bundle.
I like build-less toolchain where it can run directly in the browser. I only mostly do minification at the deploy stage. saves me quite a bit of time.
it honestly feels like typescript is trying to fit a square into a circle and invading our beloved dynamic typed javascript place.
I’ve personally seen TypeScript make developers more lazy, they rely too much on it which leads to worse understanding of the code, worse understanding means writing worse code. I only like one thing from TypeScript and that is seeing types defined on parameters, but JSDoc already fixes this issue. TypeScript also happens to strangle JavaScripts into this rigid non-dynamic code. Don’t get me started on the misleading error messages and bugs also.
TypeScript is a bad implementation of type safety in a language which should never should of been statically typed.
What people should be focusing on are tests… tests tests tests. TypeScript will never save you at runtime.
thank God that at least someone had the balls to say it. Just give it sone more time to follow on the coffeescript steps
It is too risky: io-ts, runtypes and other libraries bridge runtime type validation with Typescript’s static type checker.
It is messy: Any code can be messy, cherry picking awkward examples doesnt say much. Also be mindful that awkward written JavaScript may result in awkward TypeScript definitions trying to map it. Summary, fix your JavaScript.
It does not solve the problem: JavaScript does indeed have many problems. TypeScript solves a great many of them through excellent tooling. TypeScript can assert the interior of your codebase is sound (if you write sensible code the complier can assert), for exterior io interactions. See io-ts or similar.
It is not a superset, it is a subset: It’s sharing 99.99% parity with JavaScript. While not strictly a superset, its so inline with vanilla JavaScript, the disparities are so niche, the majority of developers would be hard pressed to find them.
It is open source but nothing more: Did you expect something else? Also, what’s with the Microsoft bashing. It’s not 1999 anymore. There are far bigger and user hostile monopolies to worry about these days.
But big companies use it: Indeed, and big companies have big codebases and big teams that need to coordinate around those big codebases. TypeScript provides adequate tooling that JSDoc comments and poorly written JavaScript documentation dont.
But it has more features: It has no more features than JavaScript, not should it. Early revisions of the compiler had class syntax and ESM-ish module imports before JavaScript. The compiler needed to map to a variety of module systems for it to be useful, and it did so with a unified import/export syntax we take for granted today. The only significant feature TypeScript has that JavaScript doesn’t (other than a amazingly flexible, next gen type system) is enums.
TypeScript is an astonishing language. The sophistication of its type system has progressed to the point where not only is it able to map to pretty much every quirky JavaScript pattern, it’s become programmable to the point you can write language parsers with it (see ts-sql).
I wouldn’t write off TypeScript, above and beyond JavaScript, the language is doing innovative things that may not be obvious at first glance. Ironic in a way, as many of these innovations seem a direct result of staying ruthlessly true to JavaScript. Go figure.
Thank God for an article that shows typescript for what it actually is. It’s for an*l back end developers who think they are full-stack because they learnt some js/react. The same ones who can’t stand that JS is loosely typed and that variables don’t need their types defining.
I hate JS stack…if someone finds it offensive should look elsewhere because they’re not the creator or take that insult personally.
I like web assembly because you can work on a single language and WASM is supported by all the browsers. Even Apple (ah another culprit who destroyed good plugin base stack) is onboard. Blazor looks good but microsoft has to iron out few things e.g. AOT lined up for the .Net 6 release with few other enhancements.
Google got flutter but it is mainly a mobile development platform (web support is weak in terms of UI component libraries for web).
Adobe actionscript & flex (mxml markup) were pretty good SPA platforms (really enjoyed it but apple killed it). Still wondering if WASM was available and they can convert the actionscript and flex mxml to WASM.
I understood the value of typescript prior to ES6, but once ES6 introduced classes natively in the language, there went a major part of TypeScript’s advantage right out the window. But with native support for classes in the language, what TypeScript gives us now is two competing methods for doing the same thing. Redundancy.
I too would like to see type declarations for function parameters, but not at this cost.
funny how that typescript code just shows more documentation. I just don’t want to fly blind when I code and not have to look up every github page or library or whatever to figure out what the hell is inside this object. strongly typed languages got that figured out. they don’t want to search all the time. they want you to properly sign your obejcts and methods and then your done! DO THIS JOB ONCE SO NOBODY ELSE HAS TO ANYMORE is the slogan. I’m already sick of JS because of this BS.
in addition to what i just wrote. react is doing the best with what js is providing them. literally nothing. that’s why they have to come of with this mess of a method signature. go learn C# or Java if you ever want to see real strongly typed languages…
And just like that. Im not longer alone. I hate TS.
Wow, this article is a sack of bullocks.
I’m not going into the details, because most of the people already explained it, but no. 6 is especially cringy – you’re bringing up someone’s argument for using typescript, present a counter-argument and then pose it as an argument for not using typescript. That is some serious logic fornication, my lad
I love this article. I totally agree. I’d like to add one more simple reason. TypeScript makes a simple problem too complex unnecessarily. Simply the code shows it. I don’t understand why many dumb assholes of mt.stupid level on Dunning–Kruger effect back the garbage up as the industry standard. What the f*ck is happenning in the software industry? I say the rich gurus are dead with their money throwing their leadership and philosophy to the waste bin. They don’t have time to educate the mt.stupid levels because they have to enjoy the rest of their life with their money. I hate this situation.
Is there anything of which one can say, “Look! This is something new”? It was here already, long ago; it was here before our time. – Ecclesiastes 1:10
Exactly this is happening in the software industry. Tons of intellectual gurus made a lot of great things already in the history but I see many naive mt.stupid levels in many big companies are too ambitious to repeat unnecessary jobs in downgraded way. They never learn from the history. Because they never respect the history. They believe they can make the better result without knowing the history, without any wisdoms. But the industry already has been messed up.
“If you can’t explain it simply, you don’t understand it well enough.” – Albert Einstein
TypeScript is a bloated annotation framework. Its MS second attempt to control javascript. Its JScript 2.0 The basics of what it tries to achieve could be achieved by a better version of JSDoc or a new annotation framework via code comments. WHY DID they ever introduce classes into the JS core language???? A prototype language?? You can fake a class system/library with the core Object functionality (take a hint from Smalltalk). A transpilers should never be a part of you core design process (I can understand existing code). Look into dynamic meta programming instead. The originators put Java in the name purely for marketing reasons. Not so 20 years later it could morph into a shittier version of a shittier version (self/java) of Smalltalk. Unfortunately, TypeScript and Javascript have so much momentum we will be forced to work with them until the sun consumes us.
Your arguments are really weak.
Big corporations are risk adverse and are slow to adapt programming languages. Usually ones that are battle tested and large in the market. This means there are jobs, which is a great reason to use a language.
Also, the idea that a typed language means you don’t have to understand the codebase is nonsense
I love brutal articles like this lol.
As part of looking busy on the bench, I recently finished a Udemy course on Kotlin, and just now finished a really long tutorial on TypeScript. There was a surprising amount of overlap in features, but I cannot say they generated an equal amount of enthusiasm from me.
Kotlin was a blast. My impression was, “whoever wrote this has done a pretty good job cherry-picking the best language features and leaving out the worst.” Not to mention the balance between succinct syntax and readability. That was done really really well. At one point, I found myself googling whether there were plans to port React and Redux to Kotlin on my phone, while I waited in line for my covid shot. Yes, there are.
On the other hand, when I finished TypeScript on the other hand, which I am only learning for employability purposes, the very first thing I clicked after downloading my worthless completion certificate was this article.
I do think TypeScript has value, for big projects that happen to have some very dumb coders, it is a way of forcing them to interact with your code in a way you intended. I also disagree with the “makes lazy” arguments above, because it seems to me that TypeScript is the type of thing that would excite the kind of people who hold on to receipts, and have beautiful super-organized binders from every college class they ever took still on their bookshelf 10 years later. And, I thought some TypeScript features were kind of cool, like decorators and abstract classes. But that is as far as my praise goes. Overall, it feels like a lot of extra work to avoid mistakes that wouldn’t be made if people took pride in their work.
Great article, good comments but if not TypeScript to help with some of the runtime errors caused by types what is the alternative?
ReasonML – https://reasonml.github.io/
Thank you for this article. Since i learned of TS I always thought there was something deeply wrong about it. Among other things the one I hate the most is that it becomes quickly incredibly hard to read, I mean JS can get messy but when you add TS in the mix it becomes ridiculous. Bending a dynamic type language in the shape of a static one is the wrong answer to a barely existing problem. Just to make a point, imagine a TS for python and your inner laugh will answer to any doubts you might have harboured until now.
If anything I would add type hints to JS and that would be more than enough to add some clarity to the code when needed .
TS is more intuitive and helps with typing errors and parameters. lol
See the example of using the Image component of NextJS
Error:
Type ‘{ src: string; alt:string; }’ is not assignable to type ‘IntrinsicAttributes & ImageProps’.
Type ‘{ src: string; alt:string; }’ is not assignable to type ‘ObjectImageProps’.
Types of property ‘src’ are incompatible.
Type ‘string’ is not assignable to type ‘StaticImport’.ts(2322)
Correction, add image dimensions as described in TS error message. lol
TS for me honestly is not worth the extra effort of settings…
JS is love.
I quickly gave up on TS when I spent more time debugging typescript issues than my own application code. total waste of time and overhead. I found it useful for exploring large codebases of open source projects and autocomplete on my own. If you want autocomplete use JSdocs.
I like TS because it makes my diffs larger when I open pull requests, so I look like I’m doing a lot of work.
Otherwise it is an abomination.
Typescript is total hype of corporate tech development, I spend more time debugging to make typescript happy than actually debugging code. Granted we need types but as an integral part of the language not as another layer to JS. Total bullshit in my opinion, JS is great for rapid development and shipping, TS is not — my opinion, not fact!
A great article. It absolutely describes my experience with Typescript. I work for the “big companies” with a user base of 60 M and Typescript has brought us CONSIDERABLY more work with a CONSIDERABLE restriction of the possibilities. The benefit is incredibly small. This is my experience with the use of typescript after 6 years and a team of over 100 people.
I come to this article from time to time to remember that there are other people out there not falling into the weird cult-like group thinking that is putting a lot of people into the TS bandwagon.
After using it in several projects, I can see some of its advantages, but the overall cost-benefit is not at all what I see is being suggested by so many blog articles and comments from people trying to push for it.
you really can find any opinion on the internet
Good luck with your untyped scripts.
We’re being too polite here and we need to stop. TS is garbage. It’s a crutch meant to appease devs who aren’t comfortable working outside of their first language which was no doubt declaratively typed and learned at a school where the profs spew the same old BS about declarative being somehow massively superior. In reality, TS, is a great way to alienate JS talent. It creates a lot of unnecessary noise in the code. And it’s a serious drag. Literally on time, a drag.
And quite frankly, it’s rude.
I started with JS. And in the last decade+ I’ve learned many other languages. Not once did it occur to me to try to make the Java or the C# I was working with more like JS. It never bothered me that they weren’t dynamically typed. Because what a ridiculous thing to worry about, when much of the language’s design paradigm is so obviously framed around such a core aspect of it.
And who are these people shackling JavaScript with all of this absurd and unnecessary cruft? Do they know better about all possible language designs than Brendan Eich and Guido Van Rossum? Have JS and Python devs been struggling for all these decades to write respectable apps because our languages didn’t have declarative types?
Stop being a wuss and learn the language that was put in front of you. You might learn a thing or two about the language you’re most comfortable with. Just as JS devs confined primarily to the front end web for years, learned a lot more about JS by respecting and learning other languages to handle back end problems, it’s time college grads primarily of the C# and Java flavors, AND THEIR PROFESSORS, adulted the !@#$ up and stopped being wusses about JS.
I get it. Doug Crockford made you feel like it was okay to be an asshole and insist everything be more like what you’re most familiar with. It’s not. Learn the language that was put in front of you. It’s actually pretty damned good if you give it a chance and no, it’s not a “flaw” that it doesn’t have declarative types. It’s quite thoroughly intentional and has served the language well for many years. A good UI language needs to be expressive and it needs to get to the point fast. Many would say the same about a good glue language.
This feels so light…
If you don’t understand a language it doesn’t mean it’s shit!
The first example makes so much sense if you think in a structured / OOP manner, and not a functional one…
i really hope you’re trolling, if you are then you’re a genius, if not, you’re a retard
Strongly typed is better than loosely typed, unless doing a small prototype. So unless your entire codebase is a prototype, you should probably be using a strongly typed language.
To all the folks saying strong typed languages are better than weak typed languages. Agreed, go with Go. TS is garbage and I hope it dies soon. Go is superior over TS in virtually every way from typing to interfaces and from testing to building.
“As you get used to having your types checked and not having to fully understand the code and the platform, errors and bugs will manifest themselves.”
This has always been the argument through ages everytime a high order language abstracts a lower level language. I have my qualms with Typescript, but you’re not pointing out a Typescript problem. You’re basically asserting that the developers will become ignorant and stupid to basic concepts that are cross cutting to all languages. You gave API calls as one example of this. That’s true in all languages. As soon as you integrate with an external system that doesn’t support WSDL or Open API then yeh of course you don’t have any compile time guarantees. Developers understand those boundaries regardless of language. So if you’re talking about Typescript calling into a JS library without typedefs, they’re 100% aware that has no compile time checking and will be cautious. Being mindful of what is and isnt guaranteed in a context is what computer science is all about. Whenever I use something like Typescript, I’m creating a fence where certain risks and errors are no longer possible. I’m decreasing the number of bugs by decreasing the surface area of code that certain classes of errors are possible. Where those errors can still occur is not more likely, and in fact I can afford to put more effort into QA’ing those areas.
You’re assertion would be like saying we shouldn’t use unit tests because it allows developers to not put effort into coding and somehow allows them to be stupid because they’ll only rely on the unit tests to tell them if they did it right.
The fact that you spend longer debugging typescript errors means that you don’t really know typescript.
The one who knows typescript shouldn’t have problems in fixing typescript errors, and in most cases, typescript errors shouldn’t even occur.
So, for every person who says they spend more time debugging typescript errors, the answer is simple. You don’t know it and that’s why you hate it.
TypeScript worsen the debugging process for most of the time, not whom the one debug don’t know TypeScript, is the one who wrote the code do not understand TypeScript fully, TypeScript usually result in so-called freshgrad code…. copy-and-paste without thinking, data structure without planning, procedures without organizing.
Thank you for this article I agree with you.
if you write your code in a function your code going to be better. you need to only function for every situation, for example
const age => isNumber(age) ?? 0;
above function not a variable it is only function and return a number, if function not a number return another number this main this function return a number or zero we need to only thinking and we need to know what are we doing.
my english is not better sorry? I hate to typescript because typescript is a different another language. typescript not javascript, if you want like typescript alternative you can learn reason/reasonml good alternative to typescript.
integer boolean example in javascript
const age = (param) => Number.isSafeInteger(param) // return true or false
console.log(“only string: “,age(“asd”)); //false
console.log(“string number: “,age(“33”)); //false
console.log(“number but only integer: “,age(33)); true
Amen! I was about to write the same. I think people who hate typescript actually hate themselves because they don’t understand 🙂
On a serious note… people who work in a professional environment must know that code should be maintainable and easily understood by the rest of the team (and future developers). So I don’t understand how you can achieve this with pure JS and don’t use any types.
My only guess is that most developers who commented on this article and bash typescript are just developing personal little websites and have no experience in bigger projects. Otherwise I can’t understand.
Types add a level of readability to code. And it shortens the feedback loop. The faster you know you will run into issues, the better. Who can be against that??
Everyone claiming people that dont like TS dont work on large projects need to just stop.
TS has a place in JS full stack, that place is just on the back end. for front end it is absolutely overkill.
honestly the overhead on the backend makes me just want to use Go at that point.
the “large companies are using this argument” is really played out. If you actually worked at one of them youd know they are usually the LAST thing you want to be modeled after, and any of the good work coming out of them usually comes from independent orgs within that company that get to break all the corporate rules anyways to build the bleeding edge stuff
Well done on seeing through the BS. Oh lordy! The number of firms I’ve worked for who went with the “big company” argument until I asked… “do you have their budget?” Suddenly they needed to make tangible and well-founded arguments.
What they were usually trying to say was, “look – they’re a commercial enterprise: there’s a big user base so they can’t just shaft us!” I then would calmly ask how many developers remembered Visual Basic 6 and what migration paths they had to VB.Net. I would even broaden the question: what sort of development experience in migration did *any* programmer (for MS or any other company) experience when upgrades were due. Of course then, every single programmer there realized that the “they can’t just shaft us” argument is complete nonsense. Those who were management based hold-outs I asked, “do you remember how you were dead set on having Google Wave used as the company information exchange? What happened to that?”
In short, there was no one technology that *anyone* could point to that had “everything” covered. The question then became this: was it something we could afford to migrate to that offered any sort of proven commercial maintainability. That question is objectively answerable by looking to suckers… eerrrr… I mean *pioneers* who tried first and learning from their mistakes. It also meant doing (boooorring!) *metrics*, and measuring the “hype vs reality”. The cost of learning something new was then revealed to be staggering in most places. Learning something slowly and migrating with caution was 75% of the time the “economical way” forward, while maintaining, documenting and improving existing code. Improving helpdesk documentation. Etc. etc. Boring stuff.
Going to shiny new closed standards was, conversely, a great way of making money for a few players who offered “prison love” for support, and generally enjoying short term upheaval for long term counter-productivity. Even with technologies that were definitely an advantage (like .NET family over previous offerings for app development) the costs were *massively* underrated. Few firms realized this and fewer soberly assessed their means of development pragmatically. I remember them fondly as the ones who continued to make a profit without retrenching more than half of their dev teams… Oh well…
Thanks for your article. I noticed a number of these points at a glance myself regarding TS and its marketing/usage, but precious few seem to have acknowledged them. I got here quickly, but note: I still look to see what educated others have to say – and that’s after most half a lifetime of experience in knowing what to look for. Sadly, many, many just don’t seem to know what to look for, and of course I had to sift through the endless minutia of key-hole opinions regarding the language (good and bad) before seeing something that looked more like my objections and to see if they were indeed founded. And to allay my fears of confirmation bias I see you’ve offered tangible and verifiable backing on you ideas from credible others (another absolutely rarity these days!)
Frankly I only see arguments over tech becoming more religious and less factual as years go on. The bikeshed looks great brown, I suppose, and stupidity and marketing look to have definitively beaten common sense! 😉 But to my old eyes, TypeScript looks, plain and simple, like an “acquisition” technology from the MS of old. MS designed it and maintain in. And lo! It’s now finding its way into more and more previously JS-based “open source” MS projects, very much *after* they started out in JS to acquire their following… How very unexpected…
Haha! My apologies to MS, but some of us have seen this movie / ridden this ride before! 😉
I guess it’s getting easier for MS to do this as general ignorance of their history grows – is white-washed by the company itself, motivated by token acts of desperation-driven “reform” in business practices – which to the trained eye, look a lot like a re-badge of the “same old same old”. Another factor facilitating this sort of behaviour is, to put it as politely as possible, a general increase in the ignorance of programmers as barriers to entry for development become ever lower and the ignorance of the diversity of tech ecosystems in the wild and their underpinning computer science concepts become higher. Easier to use technology is a “good thing”, of course – to some degree. But virtually nothing is ever really all one thing or another. As people with less experience might quickly find the advantages of type-driven development, they might not quite understand the evolution of non-typed. It might also not occur to them that some things (positive) about type-free development have cemented themselves over time as “scripting”; they might not even quite understand that scripting is inherently (and by name / definition) intended as a higher level, lighter, less “enterprise application” level of programming endeavour overall, which has, over time, become now somewhat an arbitrary distinction.
We could “credit” MS with driving this series of changes since AJAX onwards. JS was never *designed* nor intended for use as “the single unifying language of all things” – but claiming a replacement to it could possibly begin with a single monopolistic company’s plaything following an ownership paradigm which allowed their previously notorious anti-trust actions can only come from a place of most profound ignorance.
Unlike the writing of your detractors, I note your review is more based on fact than trend, which makes it positively refreshing. Thanks for your efforts.
One small thing I might note is your statement “TypeScript is something that compiles into JavaScript, it cannot be a superset by definition” does kind of need a caveat. If I programmed in C, I could easily use assembler declarations (like ASM command) to pass through assembler code in that C program. I could therefore argue – in a way – that by allowing the same instruction-set as the compiler’s target, that the C language was a ‘superset’ of assembler: the commands of assembler were part of/actionable by the C language compiler. It’s not really so murky a way to think really, but it needs the ASM command to effectively allow the C compiler to pass on processing to a lower-level of compilation. But looking at it in reverse does make things somewhat more clear: unless you’re writing a C compiler, (and tenuously arguing that using that library is a “language feature” of assembler itself – a most backward argument) you can’t really see assembly code (assembler instructions) as being a “superset” of the C standard language. Yes, everything must end up coming under the final umbrella of “machine code binary that dissembles to assembly” – you can’t say C will compile to something that isn’t part of assembly code as actionable code (unless you’re going to furnish an interpreter also written or compiled to (ultimately) more machine code.
So in your situation, you could say: “TypeScript’s instructions only result in JS code in execution, and JS can be passed through, making TS proponents arguments that it is “a superset” rather facile, and only meaningful in the sense the language *adds* to javascript, and therefore doesn’t necessarily negate any of the potential dangers inherent in programming that underlying language badly.”
I think that facet of your argument did come out in the course of your article, but didn’t leap out as immediately nearby the “superset” statement as it probably could have. In essence: superset/subset realtionship not meaningful in isolation; if you need to or have to use JS with or underneath a language, this inherently weakens the case for using it unless it offers fundamental improvements in the length / power of the syntax. The long and short is, it’s sort of pointless to program in one language in terror of another if you know you have to program in both in the end anyway. It’s a non-solution, unless you can see a definite advantage in the economy of using the “safe” language predominantly.
And that’s the case that typescript seems to categorically fail to make as far as I can see. Most dev work using new languages on old interpreters involves this issue: it’s like rose-scented perfume in toilets without the deodorizer component. All you needed to do was just either clean the toilet or open a window – now it stinks of roses *and* crap
The only people who like TypeScript are those who don’t understand the most basic concepts of JavaScript. “Oh, it doesn’t have types” – No shit, buddy! And that’s not an accidental bug, it’s a core feature!
If in this century I still had to tell the computer that a number is a number and a text is a text… for f*ck’s sake… quit moaning and just learn proper JS, it’s been long overdue. This “types” crap belongs in the bin, where it should have never come out of.
My GOD I am so grateful to find so many people thinking clearly through the BS. I completely agree with the fact that TypeScript is just a bad choice for most if not all projects. So the biggest takeaways are things I also talked about in the past:
1. network types are never a guarantee, and therefore typescript does nothing to help with that
2. typescript obscures code, which makes it a lot more expensive to develop new features, or maintain/improve or debug existing ones. It adds 10-20% dev time at least, on average
On top of this there are a few issues you didn’t mention, but I think are worth mentioning:
1. the cost of having strict types is much higher than the occasional slip-up you might encounter if you’re not using TS. It’s the equivalent of creating a car factory for the purpose of fixing a few cars but you were missing a few tools in the garage. Typescript is a giant clusterfck that people add to their projects for a false sense of security
2. typescript is often used as a crutch for bad architecture: if you have event rabbit holes running wild in (for example) your app, or if you have giant functions and you’ve never heard of the Single Responsibility Principle or low coupling, of course you’ll need types. Otherwise you can’t do anything. But as soon as you clean up your codebase a little and use Redux or any kind of centralized event orchestration and data store, types are literally a waste of time. They add no value, even obscure existing code, and it takes a lot of time to get all the complex types right and debug them, all just to fix a problem that doesn’t really exist.
I really don’t understand how so many engineering managers are ok with, or even encourage this horrifying investment in Typescript.
I’ve heard many times from devs that they don’t “need” TypeScript, and invariably their code is an unmaintainable mess. This article reads as if it’s written by someone who learned TS begrudgingly and never understood its strength.
Monopolist, big companies discriminate women……. Leftist post, i hope you analize your life
It is quite odd to here about languages that Y cannot be a superset of X because Y compiles to X. If this were so there could be no superset HLL languages build on top of lower level languages such as assembler or all those languages build on top of C or on top of the JVM. Each general language is a turing machine. I can build any language I like that offers all that is in a basic abstract turing machine and much else besides on top of any turing machine or equivalent language. This is a ground truth of our entire profession.
I also read in this post that an interpreter cannot possibly implement type safety, that only a compiler can. Absurd. A compiler is only a type of interpreter. It interprets source code into machine code that is then run. That adds no fundamental capability to what a run time interpreter can do. If anything it limits run time knowledge and capability. In a very real sense it is “interpreters all the way down”.
All that said I find typescript a lame attempt to do something like Java, which I find an extremely boring language, in web front end code. It makes a set of limiting choices over what can be done in javascript itself. Those choices are for the type of language I find too stiff and not so productive or fun to program in.
Goodness. What an awful lot of people complaining about a language they really quite obviously don’t understand.