You do a great job summarizing the changes in a bite-size but still massively helpful way. I have recently moved from .NET backend to learning Angular w/ TS, so I really appreciate the approachable content!
That;s cool and dandy.. but seriously 3:10 how did we get here ? This is not the promised land. It's horrible bloated code. The definition/description of the function is longer than the function itself.
Agreed. Checking what is the return type later feels natural and was never a problem - type guards are there for this very reason. Also the "ternary" syntax alone is already a bit convoluted, but what they created here is a monstrosity.
Typescript was not about making fewer lines on the screen. It was about making you check your homework. I'd rather have a long ass function definition than have to spend time fixing dumb type errors. (Unfortunately, typescript also messed this up since types can lie)
From everything I’ve seen it’s just typescript evangelist UA-camrs who preach against enums. They have this whole narrative of enums being dangerous and bad, none of them really go into detail about why. I have yet to find any real cases of enums being problematic if you use them how the docs say to use them. That Matt Pattock guy didn’t like them because if you have a function that takes in an enum it considers it an error if you pass in a separately typed enum or a string that has an equivalent value. Apparently enums have strange behavior if you use Object.keys(myEnum), but once again if you’re using enums how the docs say then you’d literally never do that. So yeah idk nothing wrong with TS enums to me.
Apologies if it was unclear. The erasable syntax only flag is what disables Enums from being used. I saw many speculate this could be the start of TypeScript removing these features.
@@JokeryEU Enums have the added benefit of reverse mapping, which can be useful in certain cases. Const enums (or enums not used for reverse mapping) can be replaced with const objects though, yes
4:30 the function overload "solution" isn't doing the same thing tho. With it, you could just return a string after checking if the value is a website, and it wouldn't complain even tho it's wrong and does not match what we define in the overload. With this new change, if you return a string after the type assertion for the block where its website, typescript will correctly fail to compile
Correct, overloads technically only works correctly when you guarantee the function returns those types. The conditional return method solves this and would correctly error if the function did not comply. Thanks for pointing this out, should have made it more clear 🙂
I tried out the conditional return and it works! If I flip the types in the return type expression to make it false, it'll tell me, "the path that is of type Person does not return a URL", that's so awesome!! but if it knows that, what's to stop them from automatically creating/inferring the return type generically Person -> string, Website -> URL??? That would be so cool!!
Unfortunately the PR author says: "Inferring such a type is more complicated than checking, and inferring such a type could also be surprising for users. This is out of scope." Understandable, but would be awesome to see one day, maybe a flag or something could help.
I didn't quite get it. Does supporting TS in the browser mean the browser can compile TS into a binary executable directly or does it have to covert it to JS first? I would assume that would make deploying TS code to the browser would make my apps slower. (I don't think even Deno does this but Bun does?) I am wishing for JS to disappear.
It would mean implementing a proposal in JavaScript like this: tc39.es/proposal-type-annotations/ Essentially, the typescript code you write would be treated as comments. This only works if the TypeScript syntax is erasable.
@@donwinston if it did that, then the js engines would have to not only track what language your using, but keep up with the syntax, which kind of ends up slowing down development of both run times and the languages involved. Personally, I think they shouldn't have even bothered with this, as JS and TS are VERY different beasts. Plus, what if I want to create my own superscript of JS or even typescript itself? Now, typescript has a far larger market advantage than it probably should. If I want to compete with typescript, I now have to make sure my syntax was compatible with what the JS runtimes can strip out. At the same time, I question the value that this will even provide. You still have to set up a your tsconfig. When shipping code to the browser, you likely will have to have a compilation step anyway in order to optimize the bundle size. I get that we want to reduce complexity in our build systems, but this feels like a bad way to do it. At a certain point, the only thing it is actually good for is just very simple prototyping or checking certain JS functionality but with limited typescript features. Feels bad man.
@@akam9919 Then browsers should just support TS directly and recognize the difference between .ts and .js files and act accordingly. Insisting on only JS is prohibiting progress. But apparently this is problematic because it requires numerous radical changes to how everything works. So I guess web assembly is the only way to use a language other than JS. But all you are doing with web assembly is sending strings of JS code to the browser similar to sending SQL strings to a db. Why bother? I think this sucks. JS is awful.
@@donwinston JS isn't bad, per se. Syntax wise, it's beautiful (except imports, those could be a bit more pythonic as it allows for a more natural flow for auto complete). The single-threaded runtime is a disadvantage, but 1) it's originally made for the web, 2) we have ways around this. The problem is all the edge stuff (i.e. stateful regex but only with the "g" flag, null is not identical to undefined, typeof null results in "object", etc). As for the "this is inhibiting progress point", you are being limited regardless by the API. Also, wasm is not the same as JS. They are VERY different. WASM can be called by JS, but they are not the same. As for the browser choice, if they are going to all the trouble of stripping out types, they might as well just run actual typescript instead of putting it in the spec. This is a bad decision waiting to happen. I wouldn't be surprised if this slows down the web a noticeable bit more since the syntax is now more complicated, and someone is now going to try to run a website without bundling or minifying their code because "oh the browser handles that". Even if consider that a valid point, your code has to go over the wire. Are we seriously considering leaving types in from other language? This is absurdity.
To summarize 1) you can now remove features from TS that you really want to use, for some future plan to run TS in the browser that is neither near nor would it change anything, because you’ll compile and minify anyways 2) in some weird complex case you might use once or twice in a year you now can write one line instead of four. And still no annotations on abstract methods. Meh.
@ I know, but I do not understand your point. Node.js for example will be getting first class typescript support, without nuking a lot of its features.
@@betterstack does anyone even use that name other than the committee and they choose that name cause oracle own the trademark. and nowadays its essential and most use ts rather than js so why not🙂
The conditional return type is horrible. Why in the world would someone write that ugly thing existing overloads? Overloads look so much clean and easy to understand. Typescript is getting uglier and uglier with every release.
You do a great job summarizing the changes in a bite-size but still massively helpful way. I have recently moved from .NET backend to learning Angular w/ TS, so I really appreciate the approachable content!
That;s cool and dandy.. but seriously 3:10 how did we get here ?
This is not the promised land. It's horrible bloated code.
The definition/description of the function is longer than the function itself.
Agreed. Checking what is the return type later feels natural and was never a problem - type guards are there for this very reason.
Also the "ternary" syntax alone is already a bit convoluted, but what they created here is a monstrosity.
Typescript was not about making fewer lines on the screen. It was about making you check your homework. I'd rather have a long ass function definition than have to spend time fixing dumb type errors. (Unfortunately, typescript also messed this up since types can lie)
Great short video with a lot cool tricks. I actually subscribed because of this video! Thanks
You forgot to address what's in the video thumbnail -- enums? I hope they're not going away, I like them and use them all the time.
From everything I’ve seen it’s just typescript evangelist UA-camrs who preach against enums. They have this whole narrative of enums being dangerous and bad, none of them really go into detail about why. I have yet to find any real cases of enums being problematic if you use them how the docs say to use them. That Matt Pattock guy didn’t like them because if you have a function that takes in an enum it considers it an error if you pass in a separately typed enum or a string that has an equivalent value. Apparently enums have strange behavior if you use Object.keys(myEnum), but once again if you’re using enums how the docs say then you’d literally never do that. So yeah idk nothing wrong with TS enums to me.
Apologies if it was unclear. The erasable syntax only flag is what disables Enums from being used. I saw many speculate this could be the start of TypeScript removing these features.
`as const` is way better. It's doing a better job at infering literal keys
Best way to avoid enums its just to make an object with key and value, since enums are the same thing
@@JokeryEU Enums have the added benefit of reverse mapping, which can be useful in certain cases. Const enums (or enums not used for reverse mapping) can be replaced with const objects though, yes
4:30 the function overload "solution" isn't doing the same thing tho. With it, you could just return a string after checking if the value is a website, and it wouldn't complain even tho it's wrong and does not match what we define in the overload. With this new change, if you return a string after the type assertion for the block where its website, typescript will correctly fail to compile
Correct, overloads technically only works correctly when you guarantee the function returns those types. The conditional return method solves this and would correctly error if the function did not comply.
Thanks for pointing this out, should have made it more clear 🙂
Thanks, very clear explanations.
I tried out the conditional return and it works! If I flip the types in the return type expression to make it false, it'll tell me, "the path that is of type Person does not return a URL", that's so awesome!! but if it knows that, what's to stop them from automatically creating/inferring the return type generically Person -> string, Website -> URL??? That would be so cool!!
Unfortunately the PR author says: "Inferring such a type is more complicated than checking, and inferring such a type could also be surprising for users. This is out of scope."
Understandable, but would be awesome to see one day, maybe a flag or something could help.
Nice video
GitHub Dark Dimmed!
I wish I could just (practically)write my web applications in Rust without the wasm glue code and access to multi threading
I didn't quite get it. Does supporting TS in the browser mean the browser can compile TS into a binary executable directly or does it have to covert it to JS first? I would assume that would make deploying TS code to the browser would make my apps slower. (I don't think even Deno does this but Bun does?) I am wishing for JS to disappear.
It would mean implementing a proposal in JavaScript like this: tc39.es/proposal-type-annotations/
Essentially, the typescript code you write would be treated as comments. This only works if the TypeScript syntax is erasable.
@@betterstack Oh, ok. that would work, but I believe type info would help a compiler generate a better executable in some way or maybe a faster one.
@@donwinston if it did that, then the js engines would have to not only track what language your using, but keep up with the syntax, which kind of ends up slowing down development of both run times and the languages involved. Personally, I think they shouldn't have even bothered with this, as JS and TS are VERY different beasts. Plus, what if I want to create my own superscript of JS or even typescript itself? Now, typescript has a far larger market advantage than it probably should. If I want to compete with typescript, I now have to make sure my syntax was compatible with what the JS runtimes can strip out.
At the same time, I question the value that this will even provide. You still have to set up a your tsconfig. When shipping code to the browser, you likely will have to have a compilation step anyway in order to optimize the bundle size.
I get that we want to reduce complexity in our build systems, but this feels like a bad way to do it. At a certain point, the only thing it is actually good for is just very simple prototyping or checking certain JS functionality but with limited typescript features. Feels bad man.
@@akam9919 Then browsers should just support TS directly and recognize the difference between .ts and .js files and act accordingly. Insisting on only JS is prohibiting progress. But apparently this is problematic because it requires numerous radical changes to how everything works. So I guess web assembly is the only way to use a language other than JS. But all you are doing with web assembly is sending strings of JS code to the browser similar to sending SQL strings to a db. Why bother? I think this sucks. JS is awful.
@@donwinston JS isn't bad, per se. Syntax wise, it's beautiful (except imports, those could be a bit more pythonic as it allows for a more natural flow for auto complete).
The single-threaded runtime is a disadvantage, but 1) it's originally made for the web, 2) we have ways around this.
The problem is all the edge stuff (i.e. stateful regex but only with the "g" flag, null is not identical to undefined, typeof null results in "object", etc).
As for the "this is inhibiting progress point", you are being limited regardless by the API. Also, wasm is not the same as JS. They are VERY different. WASM can be called by JS, but they are not the same.
As for the browser choice, if they are going to all the trouble of stripping out types, they might as well just run actual typescript instead of putting it in the spec.
This is a bad decision waiting to happen. I wouldn't be surprised if this slows down the web a noticeable bit more since the syntax is now more complicated, and someone is now going to try to run a website without bundling or minifying their code because "oh the browser handles that". Even if consider that a valid point, your code has to go over the wire. Are we seriously considering leaving types in from other language?
This is absurdity.
To summarize
1) you can now remove features from TS that you really want to use, for some future plan to run TS in the browser that is neither near nor would it change anything, because you’ll compile and minify anyways
2) in some weird complex case you might use once or twice in a year you now can write one line instead of four.
And still no annotations on abstract methods. Meh.
JavaScript is used not only in browsers
@ I know, but I do not understand your point. Node.js for example will be getting first class typescript support, without nuking a lot of its features.
As far as I know, type-level-only namespaces are valid with this flag. (51 sec)
Good catch! Made a mistake when I trimmed the full code snippet I had so the code there would technically work
I would never want to use conditional types. They just look confusing.
since javascript has a copyright issue then call javascript typescript hope ms wont have any issue
You don’t prefer ECMAScript? Nice ring to it 🤣
@@betterstack does anyone even use that name other than the committee and they choose that name cause oracle own the trademark. and nowadays its essential and most use ts rather than js so why not🙂
The second “feature” is just to fix horrifically bad code.
Create video on astro build 🎉
The conditional return type is horrible. Why in the world would someone write that ugly thing existing overloads? Overloads look so much clean and easy to understand. Typescript is getting uglier and uglier with every release.
overloads are not type safe in the implementation part, the conditional return type forces you to get the implementation right