Typescript enforces better coding practice by design and prevents the kind of crazy stuff you see in JavaScript projects.
If you work in a company with contractors or developers at multiple levels of ability, TS will always increase productivity across the team.
Articles like this usually seem to forget that people are inherently fallible and lazy. TS enforces rules that keep the windows from being broken (to steal the uncle Bob metaphor)
"Typescript enforces better coding practice by design and prevents the kind of crazy stuff you see in JavaScript projects."
I haven't found that to be true tbh - Almost all Typescript projects I have both seen and been a part of seem to follow standard class based organisation. I would argue that Typescript really pushes people down the class route and then they end up with the same old problems with classes we've all had with large codebases and classes.
Now - you can definitely CAN work without classes in TS but if you say it "enforces better coding practice by design" I would have to disagree. It is most definitely not a crutch for inexperience.
If the majority of people thinks that TypeScript is awesome and productive (according to surveys), then so be it, why try to convince people otherwise because you don't agree with it? We don't need to change your mind and neither us.
All the comments in this "article" are just that, subjective, including mine. The only positive thing here is people pointing out good points based on actual data, not assumptions like this article.
No matter how clean code you write, once you reach certain threshold you'll run into problems with JavaScript. There is a good reason why it's one of the most hated languages, and TypeScript makes working with JavaScript codebase much easier in the long run.
I don't know why you think I'm just assuming it - I actually have experience working with a bigger code base written in JavaScript and TypeScript (our front-end part is written in JavaScript, and back-end is in TypeScript).
I doubt anyone can give a specific proof for this and we can all talk from our experiences. As I answered before, this is my experienced combined with the stories I have read on this topic (dynamic vs static / strong typed systems) written by more experienced software engineers and I'm definitely not saying this is something written in rock and I would like to see examples where this is not true.
Right now I'm working on an e-commerce system written in TypeScript. I don't know how much lines of code it has nor I think it's important here. What I can say for sure is that it makes me much more productive to know upfront if there is some potential problem with my code instead of running into problems in runtime. Time which I would have to spend debugging the problem may not be high, but it adds pretty quickly. At the start it took me more time to properly structure my code, but in the long run, I believe I saved much of my time.
I'm not saying that just using JavaScript will bring you the problem - what I'm saying is that bigger, properly structured TypeScript code base will prevent you from running into the problems which could happen to you more often with the same code base written in JavaScript.
As I said before, writing in strong / static typed language is not a substitute for the proper structuring of your code base, but my personal experience is that it's much more productive to write and manage huge code bases in TypeScript than in the JavaScript. If you think otherwise, I would like to hear your experiences on this topic too.
2vue.runtime.esm.js:1887 TypeError: Cannot read property 'members' of undefined
at e.r (about.js:259)
at e.value (siema.min.js:1)
at s.next (about.js:111)
at click (about.vue?1da6:1)
at nt (vue.runtime.esm.js:1854)
at HTMLImageElement.n (vue.runtime.esm.js:2178)
at HTMLImageElement.Yi.a._wrapper (vue.runtime.esm.js:6876)
it @ vue.runtime.esm.js:1887
rt @ vue.runtime.esm.js:1878
tt @ vue.runtime.esm.js:1839
nt @ vue.runtime.esm.js:1861
n @ vue.runtime.esm.js:2178
Yi.a._wrapper @ vue.runtime.esm.js:6876
about.js:259 Uncaught TypeError: Cannot read property 'members' of undefined
at e.r (about.js:259)
at e.value (siema.min.js:1)
at about.js:76
This is from your site.
If members had type Member[]? this would have been caught by typescript, and you'd be forced to check whether it was defined.
It only took me a minute on your site to find that, what else do you suppose is lurking in there that could've easily been caught pre-runtime?
Thanks Nikola for sharing your view, I really understand what you're saying.
My point of view about TS is that it adds extra code... and from my experience: extra code = more work and more time consumed (no matter how it is).
I always see the LOC as a liability, not an asset.
I don't know why you think I'm just assuming it - I actually have experience working with a bigger code base written in JavaScript and TypeScript
I saw your GitHub has 17 contributions in the last year (and mostly on non JS code), it's something you might want to change... cuz people do judge on that (sorry for judging too fast).
I'm not saying that just using JavaScript will bring you the problem
You just laid your hands on the blind spot that I saw in this whole discussion (from other devs in this topic).
Which is (dynamic vs static) typing langs will solve the problem, it's not.
I believe the whole discussion should be about the architectural & design decisions and the developer expertise.
Yes, you're absolutely right about how TS introduces better design decisions.
I faced exactly the same experience when using C# then Python. I said C# (and ASP Core) tells you exactly how to do things, but Python gives you all the flexibility and power to do things in anyway.
In time, I realized that I finish my projects in Python on time much more faster that what I did on C#!
Why? cuz I transferred that knowledge (of doing things the right way) from C# into a language that allows me to do me doing things in anyway.
And that is ultimate power, and the only catch is as you know:
“It only took me a minute on your site to find that, what else do you suppose is lurking in there that could've easily been caught pre-runtime?”
Hahahahahahaha hahahaha hahaha 😂 these fools with their “TypeScript is not helpful” crap. 💩I can just imagine how hard it would be to understand their codebase.
...undefined objects during runtime aren't necessarily going to be caught by your static type checker. if the api changes and leaves out that key object, what good did your type system do?
Do you have evidence to back up your claim? My admittedly personal experience with tens of thousands of lines of typed code would lead me to believe otherwise, however I'd love to hear your side of the story!
This is my personal conclusion reading the experiences of more experienced software engineers + my personal experience working on the custom Node.js e-commerce platform.
I believe that, once you reach certain point in the project (I'm not talking about specific number of lines of code nor any other specific metric), dynamic typed language will actually slow you down a bit, because you'll deal with errors which would be eliminated right at the start in strongly typed environments. Of course, I'm not saying that this could be a substitute for following good practices, but it's much easier following good practices in a language which enforces good practices and prevents yoy from making stupid mistakes, like adding number and string. Yes, you should write your code in a manner that won't allow such things to happen that much, but from a personal experience, this is much more easily done in TypeScript, and even though I had to write more code, in the long run it made me more productive.
Nevertheless, I would like to hear your experience from working on huge codebases in JavaScript (or any other dynamic typed language) and the ways in which you addressed such problems. If I had to write enterprise level software my first choices would definitely be static typed languages, and not TypeScript, but if I had to work inside JS ecosystem, I would definitely choose TypeScript for such task.
Lucas, do you have evidence to back up you claim? Historically, speaking most JS engineers I know forget that the code on nome_modules wasn't written by them yet still count it as lines of code.
So it would nice do see your proof, remember you are defending your thesis here.
3M is the number of github issues, not all of them bug fixes. Researches were forced to recheck manually if it is a bug fix or not
Each is then manually assessed to determine whether or not it really is an attempt to fix a bug (as opposed to a feature enhancement, refactoring, etc.)
but they picked enough of them to make sure this is statistically significant result
To report results that generalize to the population of public bugs, we used the standard sample size computation to determine the number of bugs needed to achieve a specified confidence interval. On 19/08/2015, there were 3,910,969 closed bug reports in JavaScript projects on GitHub. We use this number to approximate the population. We set the confidence level and confidence interval to be 95% and 5%, respectively. The result shows that a sample of 384 bugs is sufficient for the experiment, which we rounded to 400 for convenience.
@stereobooster
I wasn't asking for support that type systems finds bugs, I was asking that the author of the article defend any of his points. :p
However, if I were to extrapolate the information from that article it would be that two years ago, when TypeScript was still new and lacking a large following (not many public modules were properly typed back then), it still had a significantly positive impact. If they ran that study again today I would imagine the results to be significantly higher, just from the new features in TypeScript let alone the number of fully typed libraries that now exist in DefinitelyTyped.
Sorry for my late reply, and thanks a lot @stereobooster
for the explanation 🙂
Besides that the researcher is a guy from Microsoft (which could make the research a bit biased), and I'm not a math expert.
But the confidence interval is affected by the variation & the sample size.
And, I find 400 bugs to be a ridiculously small sample size and you know that bugs can vary to an infinite interval.
Of course static typing would discover some bugs, but everything comes at a price.
The Price (blind spot that the research is not looking at):
Supposing the numbers were very accurate, Is the extra effort (using static typing) worth it (the discovery of 10% bugs)?
That 10% of bugs, are they really hard to discover bugs? or just ones that you would open the browser and you would find them right away?
Generally, bugs that devs find valuable to discover are the logical ones, not the syntax or statically-typed ones.
Typescript would require you to write more code.
And hey, LOC (lines of code) is a liability, NOT an asset... means that extra code need to be maintained.
I just started a discussion from a different angle here (feel free to join):
Programming languages enthusiast. Author of Learn Type Driven Development: https://www.packtpub.com/application-development/learn-type-driven-development
Besides that the researcher is a guy from Microsoft (which could make the research a bit biased
Yaser, firstly, there are three co-authors on the 'To type or not to type' paper, and two of them are listed as being at the University College London, and one at Microsoft Research. Now, you could argue that the Microsoft Research guy is pushing TypeScript because some other team in Microsoft makes it. Far-fetched, but sure. So then why would the paper say that both TypeScript and Flow were about equally effective? Flow is made by Facebook. Wouldn't that go against your bias argument?
But the confidence interval is affected by the variation & the sample size. ... And, I find 400 bugs to be a ridiculously small sample size
Well, that's how statistical analysis works. You don't need to trust this paper, calculating a sample size for a statistically-significant result is a well-known technique. Go to surveymonkey.com/mp/sample-size-ca... and plug in the numbers (population size 3 million, confidence level 95%, error margin 5%), you will get the same sample size 385.
The Price (blind spot that the research is not looking at):
Nope, they looked at it.
Is the extra effort (using static typing) worth it (the discovery of 10% bugs)?
The extra effort was timeboxed deliberately: they decided to look only at bugs that could be fixed by applying very simple types within a 10-minute window.
are they really hard to discover bugs? or just ones that you would open the browser and you would find them right away?
These were bugs that were shipped to and reported in production. So they passed all quality-control methods that the projects already had in place.
Typescript would require you to write more code. ... And hey, LOC (lines of code) is a liability, NOT an asset... means that extra code need to be maintained.
Unit tests also require you to write more code. That's a liability, don't write unit tests! ;-)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Brilliant one, Lucas 👌
It's just so simple:
Wanna write clean code?
Learn how to write "clean code", NOT "static typed code".
Wanna write more reliable code?
Learn how to write tests.
Typescript enforces better coding practice by design and prevents the kind of crazy stuff you see in JavaScript projects.
If you work in a company with contractors or developers at multiple levels of ability, TS will always increase productivity across the team.
Articles like this usually seem to forget that people are inherently fallible and lazy. TS enforces rules that keep the windows from being broken (to steal the uncle Bob metaphor)
"Typescript enforces better coding practice by design and prevents the kind of crazy stuff you see in JavaScript projects."
I haven't found that to be true tbh - Almost all Typescript projects I have both seen and been a part of seem to follow standard class based organisation. I would argue that Typescript really pushes people down the class route and then they end up with the same old problems with classes we've all had with large codebases and classes.
Now - you can definitely CAN work without classes in TS but if you say it "enforces better coding practice by design" I would have to disagree. It is most definitely not a crutch for inexperience.
Well said. You rewrote my whole article in four lines!
This is called "subjectivism".
If the majority of people thinks that TypeScript is awesome and productive (according to surveys), then so be it, why try to convince people otherwise because you don't agree with it? We don't need to change your mind and neither us.
All the comments in this "article" are just that, subjective, including mine. The only positive thing here is people pointing out good points based on actual data, not assumptions like this article.
You can write clean code and still find static type checking helpful. These aren't mutually exclusive.
Who said that "they are mutually exclusive"?
I just stressed on focusing on the goal (clean code),
Cuz "static typed code" != clean one
And hey, many people just mix those two!
No matter how clean code you write, once you reach certain threshold you'll run into problems with JavaScript. There is a good reason why it's one of the most hated languages, and TypeScript makes working with JavaScript codebase much easier in the long run.
Nikola, my friend...
It's not right to assume that there is some "threshold" without having a solid proof (aka running into one).
Cuz really, tons of companies are doing just fine with the normal JS... not just fine, but actually PERFECTLY FINE.
Even us (Coretabs Academy), we are doing really great with the normal JS, and we super barely have problems.
I mean, before throwing such assumptions about "long-run" and "large codebase", please try it and see how it goes.
Hey Yaser,
I don't know why you think I'm just assuming it - I actually have experience working with a bigger code base written in JavaScript and TypeScript (our front-end part is written in JavaScript, and back-end is in TypeScript).
I doubt anyone can give a specific proof for this and we can all talk from our experiences. As I answered before, this is my experienced combined with the stories I have read on this topic (dynamic vs static / strong typed systems) written by more experienced software engineers and I'm definitely not saying this is something written in rock and I would like to see examples where this is not true.
Right now I'm working on an e-commerce system written in TypeScript. I don't know how much lines of code it has nor I think it's important here. What I can say for sure is that it makes me much more productive to know upfront if there is some potential problem with my code instead of running into problems in runtime. Time which I would have to spend debugging the problem may not be high, but it adds pretty quickly. At the start it took me more time to properly structure my code, but in the long run, I believe I saved much of my time.
I'm not saying that just using JavaScript will bring you the problem - what I'm saying is that bigger, properly structured TypeScript code base will prevent you from running into the problems which could happen to you more often with the same code base written in JavaScript.
As I said before, writing in strong / static typed language is not a substitute for the proper structuring of your code base, but my personal experience is that it's much more productive to write and manage huge code bases in TypeScript than in the JavaScript. If you think otherwise, I would like to hear your experiences on this topic too.
This is from your site.
If members had type
Member[]?this would have been caught by typescript, and you'd be forced to check whether it was defined.It only took me a minute on your site to find that, what else do you suppose is lurking in there that could've easily been caught pre-runtime?
Thanks Nikola for sharing your view, I really understand what you're saying.
My point of view about TS is that it adds extra code... and from my experience: extra code = more work and more time consumed (no matter how it is).
I always see the LOC as a liability, not an asset.
I saw your GitHub has 17 contributions in the last year (and mostly on non JS code), it's something you might want to change... cuz people do judge on that (sorry for judging too fast).
You just laid your hands on the blind spot that I saw in this whole discussion (from other devs in this topic).
Which is (dynamic vs static) typing langs will solve the problem, it's not.
I believe the whole discussion should be about the architectural & design decisions and the developer expertise.
Yes, you're absolutely right about how TS introduces better design decisions.
I faced exactly the same experience when using C# then Python. I said C# (and ASP Core) tells you exactly how to do things, but Python gives you all the flexibility and power to do things in anyway.
In time, I realized that I finish my projects in Python on time much more faster that what I did on C#!
Why? cuz I transferred that knowledge (of doing things the right way) from C# into a language that allows me to do me doing things in anyway.
And that is ultimate power, and the only catch is as you know:
@maxinertia
Does that affect the end-user in any way (would he see any unexpected result)? NO
Then, do I care? NO
Yaser,
Just because something doesn't affect the user now, doesn't mean it won't affect it later or cause another, seemingly unrelated error.
That was hilarious, you caught him off guard with that bug.
“It only took me a minute on your site to find that, what else do you suppose is lurking in there that could've easily been caught pre-runtime?”
Hahahahahahaha hahahaha hahaha 😂 these fools with their “TypeScript is not helpful” crap. 💩I can just imagine how hard it would be to understand their codebase.
...undefined objects during runtime aren't necessarily going to be caught by your static type checker. if the api changes and leaves out that key object, what good did your type system do?
Do you have evidence to back up your claim? My admittedly personal experience with tens of thousands of lines of typed code would lead me to believe otherwise, however I'd love to hear your side of the story!
This is my personal conclusion reading the experiences of more experienced software engineers + my personal experience working on the custom Node.js e-commerce platform.
I believe that, once you reach certain point in the project (I'm not talking about specific number of lines of code nor any other specific metric), dynamic typed language will actually slow you down a bit, because you'll deal with errors which would be eliminated right at the start in strongly typed environments. Of course, I'm not saying that this could be a substitute for following good practices, but it's much easier following good practices in a language which enforces good practices and prevents yoy from making stupid mistakes, like adding number and string. Yes, you should write your code in a manner that won't allow such things to happen that much, but from a personal experience, this is much more easily done in TypeScript, and even though I had to write more code, in the long run it made me more productive.
Nevertheless, I would like to hear your experience from working on huge codebases in JavaScript (or any other dynamic typed language) and the ways in which you addressed such problems. If I had to write enterprise level software my first choices would definitely be static typed languages, and not TypeScript, but if I had to work inside JS ecosystem, I would definitely choose TypeScript for such task.
Lucas, do you have evidence to back up you claim? Historically, speaking most JS engineers I know forget that the code on nome_modules wasn't written by them yet still count it as lines of code.
So it would nice do see your proof, remember you are defending your thesis here.
Here you go blog.acolyer.org/2017/09/19/to-typ...
cc @yaser
I haven't gone through the research paper, and I skimmed the article real quick...
Could please correct me if I'm wrong:
Out of 3 million bugs they picked only 400 and studied them to reach that conclusion, right?
3M is the number of github issues, not all of them bug fixes. Researches were forced to recheck manually if it is a bug fix or not
but they picked enough of them to make sure this is statistically significant result
If you want more researches check this article dev.to/baetheus/thank-you-next-typ...
@stereobooster I wasn't asking for support that type systems finds bugs, I was asking that the author of the article defend any of his points. :p
However, if I were to extrapolate the information from that article it would be that two years ago, when TypeScript was still new and lacking a large following (not many public modules were properly typed back then), it still had a significantly positive impact. If they ran that study again today I would imagine the results to be significantly higher, just from the new features in TypeScript let alone the number of fully typed libraries that now exist in DefinitelyTyped.
Sorry for my late reply, and thanks a lot @stereobooster for the explanation 🙂
Besides that the researcher is a guy from Microsoft (which could make the research a bit biased), and I'm not a math expert.
But the confidence interval is affected by the variation & the sample size.
And, I find 400 bugs to be a ridiculously small sample size and you know that bugs can vary to an infinite interval.
Of course static typing would discover some bugs, but everything comes at a price.
The Price (blind spot that the research is not looking at):
Supposing the numbers were very accurate, Is the extra effort (using static typing) worth it (the discovery of 10% bugs)?
That 10% of bugs, are they really hard to discover bugs? or just ones that you would open the browser and you would find them right away?
Generally, bugs that devs find valuable to discover are the logical ones, not the syntax or statically-typed ones.
Typescript would require you to write more code.
And hey, LOC (lines of code) is a liability, NOT an asset... means that extra code need to be maintained.
I just started a discussion from a different angle here (feel free to join):
Will Typescript Make Your Software Bug Free?
Yaser Al-Najjar ・ Aug 13 '19 ・ 1 min read
Yaser, firstly, there are three co-authors on the 'To type or not to type' paper, and two of them are listed as being at the University College London, and one at Microsoft Research. Now, you could argue that the Microsoft Research guy is pushing TypeScript because some other team in Microsoft makes it. Far-fetched, but sure. So then why would the paper say that both TypeScript and Flow were about equally effective? Flow is made by Facebook. Wouldn't that go against your bias argument?
Well, that's how statistical analysis works. You don't need to trust this paper, calculating a sample size for a statistically-significant result is a well-known technique. Go to surveymonkey.com/mp/sample-size-ca... and plug in the numbers (population size 3 million, confidence level 95%, error margin 5%), you will get the same sample size 385.
Nope, they looked at it.
The extra effort was timeboxed deliberately: they decided to look only at bugs that could be fixed by applying very simple types within a 10-minute window.
These were bugs that were shipped to and reported in production. So they passed all quality-control methods that the projects already had in place.
Unit tests also require you to write more code. That's a liability, don't write unit tests! ;-)