If you want a job writing JS in 2021, then yes, you should be proficient with TS. That said, there's not really a whole lot to it, other than pre-defining types for function arguments and objects using a couple extra syntax elements. It's actually less efficient when writing, but it's significantly more efficient when testing and debugging, because issues tend to become glaringly obvious. And many developers will attest that it helps force them to write better initial code.
That said, I stick with JS and I'm perfectly happy doing so.
To learn some basics, and get started using it, yes.
Understanding TypeScript in depth is not as easy. It's a language with many features (some of which were not designed to make the language great, but to be able to cover the quirks of JavaScript), and a sophisticated type system.
Sophisticated type systems always take some time to really understand. TypeScript's has various features you don't find in many modernish OOP languages, such as structural typing, control flow based type analysis (like Rust), and reasonably sophisticated generics.
I use Haskell professionally for almost 10 years (including teaching it as consultant and contributing to GHC), and am quite familiar with many OOP languages, so I guess I have a reasonable background for "learning" TypeScript. I use it regularly, but I'm certainly still "learning" it for a while now.
TypeScript's error messages can be huge, and tougher to understand than nominal-typing systems, as you need to get used to diving into the structures of types instead of being told that type Dog isn't type Camel.
Another challenge is that there are multiple ways to achieve a type-related goal in TypeScript, and it isn't always obvious which one you should go for. One such example that a friend brought up yesterday is when to use unions vs enums [1]. As you can probably tell from that post, even diving into this topic alone can take an afternoon, and the answer will also change over time as TypeScript improves and adds features. To me, having properly "learned" a language implies knowing those things, as your decisions will make it into the APIs that you and others will use longer-time.
So my point is that TypeScript is far from trivial.
But it doesn't have to! Spending a couple months to learn something well is a great investment if it makes you more productive for years.
TypeScript is a great improvement over JavaScript, and I'd recommend anyone using JavaScript to learn and use it.
Seconded. But with an asterisk - I've found, as I've learned more and written more TypeScript, that I write significantly less object-oriented code overall. I use a lot more interfaces and a lot more types, and I use runtypes to describe domain objects (to combine runtime validation and static typing).
Classes are still useful, of course, as encapsulations of state, but I don't remember the last time I wrote something polymorphic in TypeScript that didn't feel faintly wrong. Coming from a Java/C# background, the "easy path" in TypeScript feels to me like it nudges you more towards compositional architecture (which is a good thing!).
Comments
If you want a job writing JS in 2021, then yes, you should be proficient with TS. That said, there's not really a whole lot to it, other than pre-defining types for function arguments and objects using a couple extra syntax elements. It's actually less efficient when writing, but it's significantly more efficient when testing and debugging, because issues tend to become glaringly obvious. And many developers will attest that it helps force them to write better initial code.
That said, I stick with JS and I'm perfectly happy doing so.
If you know any modernish OOP language and JS, “learning” TS will take about an afternoon.
To learn some basics, and get started using it, yes.
Understanding TypeScript in depth is not as easy. It's a language with many features (some of which were not designed to make the language great, but to be able to cover the quirks of JavaScript), and a sophisticated type system.
Sophisticated type systems always take some time to really understand. TypeScript's has various features you don't find in many modernish OOP languages, such as structural typing, control flow based type analysis (like Rust), and reasonably sophisticated generics.
I use Haskell professionally for almost 10 years (including teaching it as consultant and contributing to GHC), and am quite familiar with many OOP languages, so I guess I have a reasonable background for "learning" TypeScript. I use it regularly, but I'm certainly still "learning" it for a while now.
TypeScript's error messages can be huge, and tougher to understand than nominal-typing systems, as you need to get used to diving into the structures of types instead of being told that type Dog isn't type Camel.
Another challenge is that there are multiple ways to achieve a type-related goal in TypeScript, and it isn't always obvious which one you should go for. One such example that a friend brought up yesterday is when to use unions vs enums [1]. As you can probably tell from that post, even diving into this topic alone can take an afternoon, and the answer will also change over time as TypeScript improves and adds features. To me, having properly "learned" a language implies knowing those things, as your decisions will make it into the APIs that you and others will use longer-time.
So my point is that TypeScript is far from trivial.
But it doesn't have to! Spending a couple months to learn something well is a great investment if it makes you more productive for years.
TypeScript is a great improvement over JavaScript, and I'd recommend anyone using JavaScript to learn and use it.
[1]: https://stackoverflow.com/questions/40275832/typescript-has-...
Seconded. But with an asterisk - I've found, as I've learned more and written more TypeScript, that I write significantly less object-oriented code overall. I use a lot more interfaces and a lot more types, and I use runtypes to describe domain objects (to combine runtime validation and static typing).
Classes are still useful, of course, as encapsulations of state, but I don't remember the last time I wrote something polymorphic in TypeScript that didn't feel faintly wrong. Coming from a Java/C# background, the "easy path" in TypeScript feels to me like it nudges you more towards compositional architecture (which is a good thing!).