All of a sudden typescript became popular overnight. It's now a somewhat requirement for dev. But I could see the reasons, you stated them well. Great video, thanks for this.
In the very first example, I fail to see how it is more readable. In contrast, it's a lot more to read through and separate, especially by the time I've finished going over the parameters and run into the ": boolean" and have to do the little context switch. I think if it was important to recall that my user was a Person, I might have named the variable 'person' or 'userPerson', but either way this additional information did not make the signature easier to read. And 'IResource' did not add *readability* to 'resource'. It did add something else but didn't make it easier to read I paused and wrote this as soon as it got to that part
take a slightly more complex situation like an arrow function that returns a promise of an array of users, then another one that returns a promise of a user with an id as a parameter, and a couple others that would almost always be useful for a basic api... Granted, looking at them directly you immediately know what's happening because there's either an axios or fetch call. but if the functions are being imported from elsewhere, having them typed will give you more information when hovering over it with your cursor without having to access the file in which they were declared. this is like documenting without documenting, will def improve readability for yourself and anyone who touches your code overtime.
@@alexis3170 I don't deny that you get more information. Maybe this is an argument about semantics. All I was saying is that the code being self-documenting or more informative or safer or more helpful are not the same as being more *readable*. To me readable means easy to read, not detailed
I think typescript is for people who don't write good javascript ... I mean, you know which type you get by clean naming... and with typescript you gotta write more boilerplate code, slows down development... I think it's just one of those fads like unit/e2e testing .... I'm sure all junior/medium devs are all up on it... but when developing on deadlines and such you really don't have time for typescript, just my opinion
I see where you're coming from and had the same opinions concerning Typescript but having made the decision to include it in our projects despite the crazy deadlines helped us immensely for the following reasons: 1. Good Typescript Code is mostly self-documenting. This goes for all React components that we built using TS. We didn't have to specify any array of acceptable values for our "variant" prop for our components using docstrings, for example. For pure functions, we simply had to write a line or two explaining what the function did overall and other members of the team were able to make use of our code without having to ask us about anything. 2. Intellisense and TS are best friends! You need to embrace the TS fad to truly experience the comfort and safety of having intellisense back you throughout the project. Not only does it save time you'd spend reading someone else's code, it also speeds up your typing process. Even better if you spend time storing the expected schema of your API responses in your code as it'll give you the speed and confidence to map API responses to anything you want like never before. If you've ever experienced good intellisense support while making use of any library, it's most likely because it was written in TS. 3. Type Security. Tight deadlines mean a lot of our time was spent working late hours trying to get stuff done. Working for that long makes you extremely error prone and I can recall so many instances where TS prevented me from making stupid mistakes that would've cost me hours to debug. This is especially true if you're trying to build on top of what your project members have already built. Despite this, there are things I'd look out for, 1. Overthinking. There's always this one guy in every team that wants everything in the project done in one arbitrary way. "Put all your interfaces in one file shared across your project!" "Make sure you prepend every interface with the uppercase 'I' ". In reality, TS doesn't really care how you do things and declaring types and interfaces within the same file they're being used is often the best approach, unless otherwise stated, as it gives other devs all the info they need about your code in one place. 2. Not using snippets. Most people hate the boilerplate that TS adds to your code but there are snippets that are smart enough to recognize that you're working on TS and supply you with the boilerplate right off the bat.
@@tanzimibthesam5861 It depends, mostly. In my situation, I work with a team that works remotely from different countries and it's inconvenient to get on a slack call for discussing every small, avoidable detail. Using TS helped me document my code without having to waste time with JSDocs. I could safely make PRs with breaking changes to my code and they'd be able to pick up on what changes were needed instantly, thanks to TS's vigilance
I would, but I am efficient with Typescript. It acutally takes me longer to write JavaScript since I dont have auto complete as well as having to deal with more bugs.
Hey, great video! Thank you. Btw, does renaming with F2 works out of the box for you? I have a project with TS on a mac and I can't see anything like this.
Bullshit. Even for smaller projects or prototypes Typescript saves lots of time by providing great autocompletion, blazing-fast IDE error feedback with better explanations what went wrong comparing to standard browser/node "Cannot do something of undefined". Because the thing is... you do not have to type explicitly absolutely everything. You can just tell TS the types where TS cannot implicitly predict by itself, and it will still work beautifully. So you do not have to waste time for advance type creating just like during writing in JS and still have those wonderful benefits of TS Tbh, Typescript is one of the best things that ever happened to JS and I cannot switch to vanilla JS anymore after writing in it for aboout 3+ years. For me now, writing code in plain JS is pure masochism
All of a sudden typescript became popular overnight. It's now a somewhat requirement for dev.
But I could see the reasons, you stated them well. Great video, thanks for this.
Hey, I also have a programming channel, I upload daily but I only have 33 subscribers. Do you have any advice?
Every time I watcha video on why I should use typescript it looks like a meme
5:21 No, I didn't. I'm too afraid with this superset up till now. This is why I watch this video, cause I took an interest to learn TypeScript.
In the very first example, I fail to see how it is more readable. In contrast, it's a lot more to read through and separate, especially by the time I've finished going over the parameters and run into the ": boolean" and have to do the little context switch. I think if it was important to recall that my user was a Person, I might have named the variable 'person' or 'userPerson', but either way this additional information did not make the signature easier to read. And 'IResource' did not add *readability* to 'resource'. It did add something else but didn't make it easier to read
I paused and wrote this as soon as it got to that part
take a slightly more complex situation like an arrow function that returns a promise of an array of users, then another one that returns a promise of a user with an id as a parameter, and a couple others that would almost always be useful for a basic api... Granted, looking at them directly you immediately know what's happening because there's either an axios or fetch call. but if the functions are being imported from elsewhere, having them typed will give you more information when hovering over it with your cursor without having to access the file in which they were declared. this is like documenting without documenting, will def improve readability for yourself and anyone who touches your code overtime.
@@alexis3170 I don't deny that you get more information. Maybe this is an argument about semantics. All I was saying is that the code being self-documenting or more informative or safer or more helpful are not the same as being more *readable*. To me readable means easy to read, not detailed
I think typescript is for people who don't write good javascript ... I mean, you know which type you get by clean naming... and with typescript you gotta write more boilerplate code, slows down development... I think it's just one of those fads like unit/e2e testing .... I'm sure all junior/medium devs are all up on it... but when developing on deadlines and such you really don't have time for typescript, just my opinion
Its not a fad its needed for big enterprise projects tbh.Yup if deadline is a thing there are technologies where you can get things a lot faster
I see where you're coming from and had the same opinions concerning Typescript but having made the decision to include it in our projects despite the crazy deadlines helped us immensely for the following reasons:
1. Good Typescript Code is mostly self-documenting. This goes for all React components that we built using TS. We didn't have to specify any array of acceptable values for our "variant" prop for our components using docstrings, for example. For pure functions, we simply had to write a line or two explaining what the function did overall and other members of the team were able to make use of our code without having to ask us about anything.
2. Intellisense and TS are best friends! You need to embrace the TS fad to truly experience the comfort and safety of having intellisense back you throughout the project. Not only does it save time you'd spend reading someone else's code, it also speeds up your typing process. Even better if you spend time storing the expected schema of your API responses in your code as it'll give you the speed and confidence to map API responses to anything you want like never before. If you've ever experienced good intellisense support while making use of any library, it's most likely because it was written in TS.
3. Type Security. Tight deadlines mean a lot of our time was spent working late hours trying to get stuff done. Working for that long makes you extremely error prone and I can recall so many instances where TS prevented me from making stupid mistakes that would've cost me hours to debug. This is especially true if you're trying to build on top of what your project members have already built.
Despite this, there are things I'd look out for,
1. Overthinking. There's always this one guy in every team that wants everything in the project done in one arbitrary way. "Put all your interfaces in one file shared across your project!" "Make sure you prepend every interface with the uppercase 'I' ". In reality, TS doesn't really care how you do things and declaring types and interfaces within the same file they're being used is often the best approach, unless otherwise stated, as it gives other devs all the info they need about your code in one place.
2. Not using snippets. Most people hate the boilerplate that TS adds to your code but there are snippets that are smart enough to recognize that you're working on TS and supply you with the boilerplate right off the bat.
@@RexGalilae would you use it even with strict deadlines
@@tanzimibthesam5861
It depends, mostly. In my situation, I work with a team that works remotely from different countries and it's inconvenient to get on a slack call for discussing every small, avoidable detail.
Using TS helped me document my code without having to waste time with JSDocs. I could safely make PRs with breaking changes to my code and they'd be able to pick up on what changes were needed instantly, thanks to TS's vigilance
I would, but I am efficient with Typescript. It acutally takes me longer to write JavaScript since I dont have auto complete as well as having to deal with more bugs.
Hey, great video! Thank you. Btw, does renaming with F2 works out of the box for you? I have a project with TS on a mac and I can't see anything like this.
ah, I'm trying to do this in a .vue file. well, seems like I have to wait for VueDX stable version for this:)
Bullshit. Even for smaller projects or prototypes Typescript saves lots of time by providing great autocompletion, blazing-fast IDE error feedback with better explanations what went wrong comparing to standard browser/node "Cannot do something of undefined". Because the thing is... you do not have to type explicitly absolutely everything. You can just tell TS the types where TS cannot implicitly predict by itself, and it will still work beautifully. So you do not have to waste time for advance type creating just like during writing in JS and still have those wonderful benefits of TS
Tbh, Typescript is one of the best things that ever happened to JS and I cannot switch to vanilla JS anymore after writing in it for aboout 3+ years. For me now, writing code in plain JS is pure masochism
I agree, its hard for me to write JavaScript now. But some people are not as proficient at TypeScript
Not buying it
i agree that its reduce the test, just because i never write a test 😅