Nice article Adam. My thoughts are, that because Javascript is not a strongly typed language; we know that once Typescript is transpiled to Javascript, that the whole strong type argument fails.
But what is compelling about Typescript typing is that intellisense works as we type. Visual Studio Code automatically discovers all Properties. Functions, and Class types and their types needed to work. Its this interaction that preserves the illusion of strong typing. One simply cannot; for example, mistake strings for numbers or objects; (except for the type of 'any'. ) which restores ambiguity if desired
This means that Typescript can behave either way.
One may want to quantify the advantage of design time strong typing. The answer lay in the effort lost in finding run time errors where something expected didn't happen. When those issues are flagged at coding time we save an entire cycle of effort.
What's also interesting, is that most backends are Java, C#, or some other strong typed language. Even SQL is strong typed. It's much easier to map a backend model to the exact same strong type GUI side model. Some translation required e.g. number => int. Etc. But the conversion there is simple.
Finally there are 30 years worth of strong typers around. They are very comfortable with Typescript; which, allows them to ramp up much faster.
Today, I like Javascrpt but I believe its use as just a scripting language contributes to the messes I had to deal with in code. That code was just 3 years old. The first questions I had were didn't these folks ever hear about SOLID or even DRY. Didn't they know that monolithic code is immediate technical debt?
Why was JQuery so popular? The answer is it gave nouns to nameless objects. Why was Angular 1.0 so popular? Answer... it was the first to introduce binding concepts to Javascript world. Binding already being known by strong typers for 15 years before Angular.
Strong typing brings discipline to the table and it stops ambiguity of the untyped Javascript Object. Do we absolutely need it ? No, but some of us want it.
Oh, man... good thoughts and good feedback. I think I agree with everything here, and I won't regurgitate it, but there are a few points that struck me:
But what is compelling about Typescript typing is that intellisense works as we type.
I sooooo get this. About 7 years ago, I was writing a lot of PHP code in my free time on a huge side project. As I tended to do every couple of years, I reached a point where I said, "Let me reassess the IDE options that are out there." And that was the first time that I stumbled across JetBrains (and their PHP-specific IDE, PHPStorm). It's not an exaggeration to say that it transformed my code. Because PHPStorm was the first IDE I ever found that did an amazing job of discovering all of my loosely-inferred types in PHP. And once I realized that the IDE could ferret this stuff out, it incentivized me to actually write code that would better "mesh" with PHPStorm. And when I say that it "meshed" with PHPStorm, what I'm really saying is that my code became much more explicit in broadcasting to the IDE (or to other devs who found themselves slogging through my code) exactly what type of variable they were looking at.
Finally there are 30 years worth of strong typers around. They are very comfortable with Typescript; which, allows them to ramp up much faster.
I'm nodding my head. And I'm also a little bit chagrined. As one of those "grey-beard" developers, I can tell you, in React, what really groks in my mind - class-based components. They just kinda... make sense. I don't have a "problem" with function-based components. But soooo many times, the class-based paradigm seems to better "fit" what React defines as a "component".
But I know some hardcore TS fans who will try to shout you down over the use of that ugly, nasty, unthinkable class keyword in their React components...
Strong typing brings discipline to the table and it stops ambiguity of the untyped Javascript Object. Do we absolutely need it ? No, but some of us want it.
I totally understand and respect this comment. Good points - all of them.
Your statement on finding a tool that really helped and incentivized you to 'lean into it to get more out of it', resonates with me (to the moon and back).
My first experience with this concept was back in 1988. I had put out a production bug that cost millions to fix. I was so upset at myself I went to their huge on campus tech library and checked out every book they had on software testing. This book changed my carrier and confidence levels.
I learned how Unit Testing objectives made my code bullet proof. So I leaned into the concept more and more thoughout my career. It was a major boost all the way around.
Today, I still willingly embrace unit test, as there's no substitute for it.
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.
Nice article Adam. My thoughts are, that because Javascript is not a strongly typed language; we know that once Typescript is transpiled to Javascript, that the whole strong type argument fails.
But what is compelling about Typescript typing is that intellisense works as we type. Visual Studio Code automatically discovers all Properties. Functions, and Class types and their types needed to work. Its this interaction that preserves the illusion of strong typing. One simply cannot; for example, mistake strings for numbers or objects; (except for the type of 'any'. ) which restores ambiguity if desired
This means that Typescript can behave either way.
One may want to quantify the advantage of design time strong typing. The answer lay in the effort lost in finding run time errors where something expected didn't happen. When those issues are flagged at coding time we save an entire cycle of effort.
What's also interesting, is that most backends are Java, C#, or some other strong typed language. Even SQL is strong typed. It's much easier to map a backend model to the exact same strong type GUI side model. Some translation required e.g. number => int. Etc. But the conversion there is simple.
Finally there are 30 years worth of strong typers around. They are very comfortable with Typescript; which, allows them to ramp up much faster.
Today, I like Javascrpt but I believe its use as just a scripting language contributes to the messes I had to deal with in code. That code was just 3 years old. The first questions I had were didn't these folks ever hear about SOLID or even DRY. Didn't they know that monolithic code is immediate technical debt?
Why was JQuery so popular? The answer is it gave nouns to nameless objects. Why was Angular 1.0 so popular? Answer... it was the first to introduce binding concepts to Javascript world. Binding already being known by strong typers for 15 years before Angular.
Strong typing brings discipline to the table and it stops ambiguity of the untyped Javascript Object. Do we absolutely need it ? No, but some of us want it.
Oh, man... good thoughts and good feedback. I think I agree with everything here, and I won't regurgitate it, but there are a few points that struck me:
I sooooo get this. About 7 years ago, I was writing a lot of PHP code in my free time on a huge side project. As I tended to do every couple of years, I reached a point where I said, "Let me reassess the IDE options that are out there." And that was the first time that I stumbled across JetBrains (and their PHP-specific IDE, PHPStorm). It's not an exaggeration to say that it transformed my code. Because PHPStorm was the first IDE I ever found that did an amazing job of discovering all of my loosely-inferred types in PHP. And once I realized that the IDE could ferret this stuff out, it incentivized me to actually write code that would better "mesh" with PHPStorm. And when I say that it "meshed" with PHPStorm, what I'm really saying is that my code became much more explicit in broadcasting to the IDE (or to other devs who found themselves slogging through my code) exactly what type of variable they were looking at.
I'm nodding my head. And I'm also a little bit chagrined. As one of those "grey-beard" developers, I can tell you, in React, what really groks in my mind - class-based components. They just kinda... make sense. I don't have a "problem" with function-based components. But soooo many times, the class-based paradigm seems to better "fit" what React defines as a "component".
But I know some hardcore TS fans who will try to shout you down over the use of that ugly, nasty, unthinkable
classkeyword in their React components...I totally understand and respect this comment. Good points - all of them.
Adam...
Your statement on finding a tool that really helped and incentivized you to 'lean into it to get more out of it', resonates with me (to the moon and back).
My first experience with this concept was back in 1988. I had put out a production bug that cost millions to fix. I was so upset at myself I went to their huge on campus tech library and checked out every book they had on software testing. This book changed my carrier and confidence levels.
I learned how Unit Testing objectives made my code bullet proof. So I leaned into the concept more and more thoughout my career. It was a major boost all the way around.
Today, I still willingly embrace unit test, as there's no substitute for it.