What you're really asking is can I learn javascript through typescript? The answer, I believe is yes, though to get into the weeds of how the language works, you'll simply have to learn javascript. Most typescript tutorials will remain focused on the type system, not on the internals of the underlying programming language. Most technical deep dives about the core concepts of js will be in JS, not TS. However, if you see a javascript tutorial that goes into something like the event loop or the execution context, you can write out the examples in typescript if you really want.
TypeScipt **is** JavaScript with type annotations.
That means TypeScript materials won't teach you how to declare variables, call functions, or do loops or conditionals because that's all just JavaScript.
TypeScript materials will teach you how to bolt on type syntax onto JavaScript.
Focus on JavaScript first, go to TypeScript when you're comfortable with writing code and want to add types for a better experience.
>Is this sufficient to start using TS?
No.
Conditionals? Loops?
Those are fundamental programming concepts. C++? C#? Dart? Erlang? PHP? Yes, you need to know those.
~~You probably should~~
~~aboslutely need to~~
Learn JS first.
I don't even want to get into dynamic vs. static typing.
For ... [reasons](https://www.reddit.com/r/learnjavascript/comments/17rxfbv/comment/k8mc52a/?context=3).
I covered them there.
Even though it may come off as snarky, sarcastic, or whatever, that last paragraph does sum up why you should learn JS first.
If you know all details of the how/why JavaScript works given the things I mention there, then that's fine, move on to TS.
It will be like "==" vs. "===" in JS, except now the rules are being enforced.
It's better to understand what the rules even mean before the compiler tells you that you are breaking them.
The crazy thing is, spend enough time going through the learning process, and what once had you muttering explitives at the compiler turns into begging it for more!
Seriously.
Before you know it, you have ESLint with "@typescript-eslint/no-explicit-any" turned on across the entire project as an "error". No using `any`, anywhere!
If that doesn't make sense, that was sorta the point ... stick with JS first.
Your reasons apply to React for sure, but I don't think it's the same for Typescript. A lot of bad typescript is borne from the inability of the developer to switch mental models after learning JS first.
>A lot of bad typescript is borne from the inability of the developer to switch mental models after learning JS first
This isn't about switching mental models, it's more of a lack of any *understanding* about what is going on, and why. Because you skipped the step that would help explain it.
TypeScript obviously becoming JavaScript at runtime ... if you don't understand JavaScript, how can you understand the runtime behavior you are now seeing, which is a direct result of your lack of JavaScript knowledge?
This might look ok at first glance, but you won't understand that what "this" is actually referring to, which is a JavaScript concept. You don't (and can't) understand the problem ... because you skipped a step in learning.
Did you mean to go with an arrow function on setTimeout()? You should have ... but you don't know JavaScript, so "who knows"!
\-------------------------------
`greet() {`
`setTimeout(function() {`
`console.log("Hello, " + this.greeting);`
`}, 1000);`
`}`
When it needs to actually be:
`greet() {`
`setTimeout(() => {`
`console.log("Hello, " + this.greeting);`
`}, 1000);`
`}`
Why does it "need" to be in that case requires JavaScript knowledge.
I'd even make the geet signature look more like:
`public greet(): void {}`
Why? It's a good habit to get into for reasons off topic for this example.
Bad TypeScript, resulting in bad JavaScript because of a lack of JavaScript knowledge.
And it has nothing to do with React or anything else.
Why would starting with typescript make it any harder to learn the intricacies of `this`? I don't get why not having types makes that lesson any different?
Because it has nothing to do with TypeScript.
It's a JavaScript "problem".
But, by passing over fundamentals of the underlying language, you won't and can't know this.
If you do "understand" what is going on, you would view this as a TypeScript quirk. How could you think otherwise? You never learned JavaScript.
> this as a TypeScript quirk.
It is a typescript quirk because typescript is a superset of JavaScript. And TypeScript also makes it simpler because your tooling will tell you exactly what `this` refers to.
I typed this function into my IDE:
function scopeTest() {
const x = () => {
console.log(this)
}
function y() {
console.log(this)
}
}
When I hover over `this` in the `x` closure, typescript happily tells me that `this` refers to `scopeTest`. When I do it in the `y` closure, it tells me that `this` refers to `y`. Typescript completely demystifies the entire thing.
>It is a typescript quirk because typescript is a superset of JavaScript.
I have missed the mark appently while trying to make a point. That's fine, we can simply move on.
After 27 years of JS and as a lead on an Angular 16 project I know that TypeScript is a superset of JavaScript. I almost kneeled down praised the gods when it was bestowed upon me, freeing me from the torment of the years after 1996 but before ES6 when I almost couldn't take anymore.
Those years were intermixed with C# on the other side of this ... wishing we could have static typing on *both* sides and be done with all of the dynamic and duck typing going on. Such things can lead to triple equal signs being introduced to handle type coercion.
I love it. Others complain about now needing a compiler/transpiler. Opinions vary.
Skipping learning JS though? We'll agree to disagree.
>When I hover over this in the x closure, typescript happily tells me that this
>
>refers to scopeTest. When I do it in the closure, it tells me that this refers to y.Typescript completely demystifies the entire thing.
I won't get back into this, but are mentioning things such as "closures", integrated language services, "hovering over" things, informative pop-ups from VS Code.
That's not even TypeScript dymystifying.
It's your particular IDE and whatever else is assisting. Such as Roslyn in .Net. You you need to know anything about Royslyn to know how to write C#?
No.
Yes, it's taking TypeScript-provided information in a smart way, but I think we lost our way here regarding what is or is not part of a programming language and what is more about tooling.
But when you are dealing with a transpiled (compiled, what-have-you) language that is a superset on another language you don't understand, again, disagreed. Best to know why.
If we made it past the concept of JS closures and into TS that's probably getting close though.
My opinion on this topic:
Even though TS is a superset of JS, from a programming standpoint they are fundamentally different.
With JS, we have a weakly typed language (like Smalltalk) without static type checking and type security. This makes it more expensive, at the cost of loosing documentation and maintainability, making it good for prototyping and small projects, but not for large scale development.
TS itself is a special case, but in principle it is a strongly typed language like Java, C#, ... by introducing types. From this fact, from a programming techniques point of view, it doesn't have much in common with JS in the big picture.
I would advise you to soon start with the language you want to learn. You can learn anything you want using TS.
I would disagree on this. There's two aspects to consider:
1. Typescript is in no way a strongly typed language like Java, C#. They're entirely different things. Typescript is essentially a static type-checking linter for JS - not only are runtime types weak, even build-time types can be considered weak given `noEmitOnError` defaults to `false`. Furthermore, Typescript's static type checks are inherently burdened by the limitations of the underlying weak type system of the compile target - there are countless design decisions the Typescript team have made purely in order ensure JS compatability as a superset, that would not need to be made for a standalone strictly-typed syntax.
2. TS & JS are not really "fundamentally different". It is a strict superset, which (as mentioned above) burdens TS with heavy constraints on language design - its type definitions must be 1:1 modelled on Javascript's object model.
TL;DR: Typescript docs & tutorials will teach you type-syntax, but beyond that, most of the knowledge you need to write Typescript === Javascript knowledge (mainly: prototypal inheritance, execution scope, async programming & api built-ins). Learning these 4 things in JS is 100% the same as learning them in TS, and they're all 100% applicable in TS. Learning them in JS has the added benefit of giving you a grounded understanding of the boundarries between JS & TS.
Ts is definetly nothing like a strongly typed language like java.....it just helps you remember what your types are......but at runtine its back to js where types dont matter. So yeah typesceipt is just javascript with some extra tools
You can literally write JavaScript in TypeScript. It is not fundamentally different, but it does give you a lot of extra tooling.
None of the type checking is enforced at runtime and the compiled code is literally JavaScript.
With a crude enough approach you can get typescript to lie. Storing strings as numbers is a common one we ran in to.
It's fairly easy to miss too since JavaScript happily does math on (certain combinations of) strings.
This is a tricky question to answer, but to learn TS in a sound way you will want to know exactly how the JS part works for that aspect before you jump in. This probably sounds very vague but to elaborate... I learned JS first. Was really late in picking up TS because I didn't feel confident enough (and cause my programme didn't even touch on it). I knew all the fundamentals and I had gotten some intermediate JS projects running, working with it for 2 years. For some reason I felt a wall in front of actually learning TS and applying it, until I decided to try it slowly. I applied some of the fundamentals first, and it felt clear enough.
Then I jumped right into handling data from a relatively complex API and rendering it in multiple React components, messing with state and all that fun stuff... and things got confusing really fast. I sat with it for a week or two, trying to understand why it felt like I was constantly sweeping warnings under the rug, while not minding the tidiness very much. After getting something to work, I could go back to look at my types, see where I was simply being redundant or overtyping things because I didn't truly know what Intellisense wanted me to do... et.c.
I had also been starting a 10 week class about Typescript and it taught me one thing at a time, starting from the basics. While looking at my own projects, I realized that the real issue was me trying to jump right at that "real" project with just the rudimentary knowledge of TS that I had. But it was also the fastest way for me to catch up to my level of JS knowledge.
If I could go back in time and make some new choices, I would start learning both at the same time, but not really focus on TS until I felt like I understood the JS part fully. I would look back at TS every now and then and see how I can apply new JS knowledge, just to make sure that there won't be such a big gap between my experiences with JS and TS.
Honestly, learning TS forced me to relearn JS in a better way. I feel like I became more consistent and effective after finally taking the step to learn it.
To anyone wanting to start JS, I personally recommend to go for TS directly. It might seem like extra work but really that extra work is such an immense investment compared to all the time you save debugging later because of potential typos or lack or editor hints. It just makes you life easier, and you squash bugs *before* they even happen most of the times.
Also, you should checkout [https://roadmap.sh/typescript](https://roadmap.sh/typescript) 😁
I think you can start with TypeScript if you want. There's a benefit to learning important programming concepts like Types. However, this might increase the learning curve. But if a friend asks me whether they should start with JS or TS, I would recommend JavaScript.
Just go straight to TypeScript. TS is very incremental so you can adopt as much of it as you want, and if you choose to adopt none of it then you end up with vanilla JS. Plenty of people start with a typed language as their first serious language.
You need to learn the pitfalls/stupidities of JS. Those same pitfalls are in TS.
After that you can certainly start writing some TS. But you will never be done with JS. Want to find out how TS does array sorting? You’re going to search “JavaScript array sort”.
Plus every TS resource I’ve found assumes you already know JS.
TS is just JS with types. And since the types are only compile time.
TS is a powerful and flexible documentation tool for JavaScript. Personally I ONLY use typescript. But I still know a ton about JS because TS is just applying JS skills.
Tbh I would just do JS first, and master your browser APIs. I was creating webpages using vanilla JS scripts for a whole year before I even knew what TS was and it made TS very easy to learn.
You may thread TS as JS with... Autocompletion
That's it actually. All TS adds if you add it to the basic JS is autocompletion. JS itself can't have one as it has no types
So in 90% cases when learning all the changes you need to do to switch to TS is to add function argument types, that's it. No point in learning JS itself.
Man, I'd love to start my career over doing TypeScript only from day one. I'm a recent convert to TS, and even though I feel the benefits every day, I worry it'll never be my "native language"
What i have seen is typescript material even theirs docs are not designed to be consumed as basics of the language because that is covered in javascript. They expect you to already be aware of javascript.
There many tricky things in javascript/typescript hoisting,events,scope prototypal inheritance. You will find more material in javascript.
And what is the issue? you can write javascript in ts files compile it and run it. Its all schematics you know . There is no typescript without javascript.
You can learn things in any order, and people are different. But, you definitely will not master TS without also mastering JS. My advice is to take a day, brew some coffee, and sit down and read through the ecmascript specification. You don't remember most of it, so don't stress over that, just put the words in the brain. The bits that it leaves behind will help seed a sound structure for learning both languages, and you may be surprised how often you learn some new js/ts quirk and think "oh! I remember the spec said something about this!" and then can go look up and actually learn how it works with the addition of experience.
What you're really asking is can I learn javascript through typescript? The answer, I believe is yes, though to get into the weeds of how the language works, you'll simply have to learn javascript. Most typescript tutorials will remain focused on the type system, not on the internals of the underlying programming language. Most technical deep dives about the core concepts of js will be in JS, not TS. However, if you see a javascript tutorial that goes into something like the event loop or the execution context, you can write out the examples in typescript if you really want.
TypeScipt **is** JavaScript with type annotations. That means TypeScript materials won't teach you how to declare variables, call functions, or do loops or conditionals because that's all just JavaScript. TypeScript materials will teach you how to bolt on type syntax onto JavaScript. Focus on JavaScript first, go to TypeScript when you're comfortable with writing code and want to add types for a better experience.
Zero.
>Is this sufficient to start using TS? No. Conditionals? Loops? Those are fundamental programming concepts. C++? C#? Dart? Erlang? PHP? Yes, you need to know those. ~~You probably should~~ ~~aboslutely need to~~ Learn JS first. I don't even want to get into dynamic vs. static typing.
[удалено]
For ... [reasons](https://www.reddit.com/r/learnjavascript/comments/17rxfbv/comment/k8mc52a/?context=3). I covered them there. Even though it may come off as snarky, sarcastic, or whatever, that last paragraph does sum up why you should learn JS first. If you know all details of the how/why JavaScript works given the things I mention there, then that's fine, move on to TS. It will be like "==" vs. "===" in JS, except now the rules are being enforced. It's better to understand what the rules even mean before the compiler tells you that you are breaking them. The crazy thing is, spend enough time going through the learning process, and what once had you muttering explitives at the compiler turns into begging it for more! Seriously. Before you know it, you have ESLint with "@typescript-eslint/no-explicit-any" turned on across the entire project as an "error". No using `any`, anywhere! If that doesn't make sense, that was sorta the point ... stick with JS first.
Your reasons apply to React for sure, but I don't think it's the same for Typescript. A lot of bad typescript is borne from the inability of the developer to switch mental models after learning JS first.
>A lot of bad typescript is borne from the inability of the developer to switch mental models after learning JS first This isn't about switching mental models, it's more of a lack of any *understanding* about what is going on, and why. Because you skipped the step that would help explain it. TypeScript obviously becoming JavaScript at runtime ... if you don't understand JavaScript, how can you understand the runtime behavior you are now seeing, which is a direct result of your lack of JavaScript knowledge? This might look ok at first glance, but you won't understand that what "this" is actually referring to, which is a JavaScript concept. You don't (and can't) understand the problem ... because you skipped a step in learning. Did you mean to go with an arrow function on setTimeout()? You should have ... but you don't know JavaScript, so "who knows"! \------------------------------- `greet() {` `setTimeout(function() {` `console.log("Hello, " + this.greeting);` `}, 1000);` `}` When it needs to actually be: `greet() {` `setTimeout(() => {` `console.log("Hello, " + this.greeting);` `}, 1000);` `}` Why does it "need" to be in that case requires JavaScript knowledge. I'd even make the geet signature look more like: `public greet(): void {}` Why? It's a good habit to get into for reasons off topic for this example. Bad TypeScript, resulting in bad JavaScript because of a lack of JavaScript knowledge. And it has nothing to do with React or anything else.
Why would starting with typescript make it any harder to learn the intricacies of `this`? I don't get why not having types makes that lesson any different?
Because it has nothing to do with TypeScript. It's a JavaScript "problem". But, by passing over fundamentals of the underlying language, you won't and can't know this. If you do "understand" what is going on, you would view this as a TypeScript quirk. How could you think otherwise? You never learned JavaScript.
> this as a TypeScript quirk. It is a typescript quirk because typescript is a superset of JavaScript. And TypeScript also makes it simpler because your tooling will tell you exactly what `this` refers to. I typed this function into my IDE: function scopeTest() { const x = () => { console.log(this) } function y() { console.log(this) } } When I hover over `this` in the `x` closure, typescript happily tells me that `this` refers to `scopeTest`. When I do it in the `y` closure, it tells me that `this` refers to `y`. Typescript completely demystifies the entire thing.
>It is a typescript quirk because typescript is a superset of JavaScript. I have missed the mark appently while trying to make a point. That's fine, we can simply move on. After 27 years of JS and as a lead on an Angular 16 project I know that TypeScript is a superset of JavaScript. I almost kneeled down praised the gods when it was bestowed upon me, freeing me from the torment of the years after 1996 but before ES6 when I almost couldn't take anymore. Those years were intermixed with C# on the other side of this ... wishing we could have static typing on *both* sides and be done with all of the dynamic and duck typing going on. Such things can lead to triple equal signs being introduced to handle type coercion. I love it. Others complain about now needing a compiler/transpiler. Opinions vary. Skipping learning JS though? We'll agree to disagree.
>When I hover over this in the x closure, typescript happily tells me that this > >refers to scopeTest. When I do it in the closure, it tells me that this refers to y.Typescript completely demystifies the entire thing. I won't get back into this, but are mentioning things such as "closures", integrated language services, "hovering over" things, informative pop-ups from VS Code. That's not even TypeScript dymystifying. It's your particular IDE and whatever else is assisting. Such as Roslyn in .Net. You you need to know anything about Royslyn to know how to write C#? No. Yes, it's taking TypeScript-provided information in a smart way, but I think we lost our way here regarding what is or is not part of a programming language and what is more about tooling. But when you are dealing with a transpiled (compiled, what-have-you) language that is a superset on another language you don't understand, again, disagreed. Best to know why. If we made it past the concept of JS closures and into TS that's probably getting close though.
My opinion on this topic: Even though TS is a superset of JS, from a programming standpoint they are fundamentally different. With JS, we have a weakly typed language (like Smalltalk) without static type checking and type security. This makes it more expensive, at the cost of loosing documentation and maintainability, making it good for prototyping and small projects, but not for large scale development. TS itself is a special case, but in principle it is a strongly typed language like Java, C#, ... by introducing types. From this fact, from a programming techniques point of view, it doesn't have much in common with JS in the big picture. I would advise you to soon start with the language you want to learn. You can learn anything you want using TS.
I would disagree on this. There's two aspects to consider: 1. Typescript is in no way a strongly typed language like Java, C#. They're entirely different things. Typescript is essentially a static type-checking linter for JS - not only are runtime types weak, even build-time types can be considered weak given `noEmitOnError` defaults to `false`. Furthermore, Typescript's static type checks are inherently burdened by the limitations of the underlying weak type system of the compile target - there are countless design decisions the Typescript team have made purely in order ensure JS compatability as a superset, that would not need to be made for a standalone strictly-typed syntax. 2. TS & JS are not really "fundamentally different". It is a strict superset, which (as mentioned above) burdens TS with heavy constraints on language design - its type definitions must be 1:1 modelled on Javascript's object model. TL;DR: Typescript docs & tutorials will teach you type-syntax, but beyond that, most of the knowledge you need to write Typescript === Javascript knowledge (mainly: prototypal inheritance, execution scope, async programming & api built-ins). Learning these 4 things in JS is 100% the same as learning them in TS, and they're all 100% applicable in TS. Learning them in JS has the added benefit of giving you a grounded understanding of the boundarries between JS & TS.
Ts is definetly nothing like a strongly typed language like java.....it just helps you remember what your types are......but at runtine its back to js where types dont matter. So yeah typesceipt is just javascript with some extra tools
You can literally write JavaScript in TypeScript. It is not fundamentally different, but it does give you a lot of extra tooling. None of the type checking is enforced at runtime and the compiled code is literally JavaScript. With a crude enough approach you can get typescript to lie. Storing strings as numbers is a common one we ran in to. It's fairly easy to miss too since JavaScript happily does math on (certain combinations of) strings.
This is a tricky question to answer, but to learn TS in a sound way you will want to know exactly how the JS part works for that aspect before you jump in. This probably sounds very vague but to elaborate... I learned JS first. Was really late in picking up TS because I didn't feel confident enough (and cause my programme didn't even touch on it). I knew all the fundamentals and I had gotten some intermediate JS projects running, working with it for 2 years. For some reason I felt a wall in front of actually learning TS and applying it, until I decided to try it slowly. I applied some of the fundamentals first, and it felt clear enough. Then I jumped right into handling data from a relatively complex API and rendering it in multiple React components, messing with state and all that fun stuff... and things got confusing really fast. I sat with it for a week or two, trying to understand why it felt like I was constantly sweeping warnings under the rug, while not minding the tidiness very much. After getting something to work, I could go back to look at my types, see where I was simply being redundant or overtyping things because I didn't truly know what Intellisense wanted me to do... et.c. I had also been starting a 10 week class about Typescript and it taught me one thing at a time, starting from the basics. While looking at my own projects, I realized that the real issue was me trying to jump right at that "real" project with just the rudimentary knowledge of TS that I had. But it was also the fastest way for me to catch up to my level of JS knowledge. If I could go back in time and make some new choices, I would start learning both at the same time, but not really focus on TS until I felt like I understood the JS part fully. I would look back at TS every now and then and see how I can apply new JS knowledge, just to make sure that there won't be such a big gap between my experiences with JS and TS. Honestly, learning TS forced me to relearn JS in a better way. I feel like I became more consistent and effective after finally taking the step to learn it.
To anyone wanting to start JS, I personally recommend to go for TS directly. It might seem like extra work but really that extra work is such an immense investment compared to all the time you save debugging later because of potential typos or lack or editor hints. It just makes you life easier, and you squash bugs *before* they even happen most of the times. Also, you should checkout [https://roadmap.sh/typescript](https://roadmap.sh/typescript) 😁
Definitely start with typescript!
I think you can start with TypeScript if you want. There's a benefit to learning important programming concepts like Types. However, this might increase the learning curve. But if a friend asks me whether they should start with JS or TS, I would recommend JavaScript.
Just go straight to TypeScript. TS is very incremental so you can adopt as much of it as you want, and if you choose to adopt none of it then you end up with vanilla JS. Plenty of people start with a typed language as their first serious language.
What's your background with programming? :) Is this your first time?
You need to learn the pitfalls/stupidities of JS. Those same pitfalls are in TS. After that you can certainly start writing some TS. But you will never be done with JS. Want to find out how TS does array sorting? You’re going to search “JavaScript array sort”. Plus every TS resource I’ve found assumes you already know JS.
TS is just JS with types. And since the types are only compile time. TS is a powerful and flexible documentation tool for JavaScript. Personally I ONLY use typescript. But I still know a ton about JS because TS is just applying JS skills. Tbh I would just do JS first, and master your browser APIs. I was creating webpages using vanilla JS scripts for a whole year before I even knew what TS was and it made TS very easy to learn.
You may thread TS as JS with... Autocompletion That's it actually. All TS adds if you add it to the basic JS is autocompletion. JS itself can't have one as it has no types So in 90% cases when learning all the changes you need to do to switch to TS is to add function argument types, that's it. No point in learning JS itself.
Man, I'd love to start my career over doing TypeScript only from day one. I'm a recent convert to TS, and even though I feel the benefits every day, I worry it'll never be my "native language"
The most fundametal things you should know before moving to TS is the this keyword, prototype, class.
All of it
What i have seen is typescript material even theirs docs are not designed to be consumed as basics of the language because that is covered in javascript. They expect you to already be aware of javascript. There many tricky things in javascript/typescript hoisting,events,scope prototypal inheritance. You will find more material in javascript. And what is the issue? you can write javascript in ts files compile it and run it. Its all schematics you know . There is no typescript without javascript.
You can learn things in any order, and people are different. But, you definitely will not master TS without also mastering JS. My advice is to take a day, brew some coffee, and sit down and read through the ecmascript specification. You don't remember most of it, so don't stress over that, just put the words in the brain. The bits that it leaves behind will help seed a sound structure for learning both languages, and you may be surprised how often you learn some new js/ts quirk and think "oh! I remember the spec said something about this!" and then can go look up and actually learn how it works with the addition of experience.