The switch(true) thing is a good example of something that is very janky that 99% of devs would never use. However, the fact that it did not work properly before and now does is still an objectively good thing. The language needs to be correct and this was a clear gap in the type narrowing system. Just because most people would intuitively go for if's does not invalidate the need to make this type of thing work properly. If I've learned anything is that just because I can't think of a use-case for something doesn't mean there isn't one. If the TS team decided to give this effort, I'm sure there was someone who had a very valid use case for it.
"That's the sound of bun having to support yet another thing" except this is already supported, its the bun import macro stuff you hated so much that you claimed change how JS does it they just implemented it before anyone else XD
Runtime support for `import type` in Bun/Deno/Node/browsers is not relevant. Type-only imports are a TypeScript-only concept that gets erased from the generated JS. So there's no need to talk about the effect of "resolution-mode" on Bun or any other runtime.
TS team are spending a lot of time shipping stuff that doesn't matter, I believe they need to work on the performance, I'm working on a codebase with 5k ts files and every time I'm trying to rename a symbol or use intellisense, it gets stuck forever. I'm pretty sure so many people having the same issue.
ok i get the appeal of inheritence & interfaces as a concept. but the example where the writer checks if the fn argument is an instance of a class which returns true only to get a run time error when invoking a method specifically defined in that class simply bc it implements an interface is terrible.
`import ... with ...` is a JS/ECMAScript feature already; TypeSript just added support for it (It was added to ECMAScript because import statements in vanilla JS already request the URL and interpret it as JS regardless of the file extension, so you couldn't do JSON imports at all. To add non-JS imports, they had to add new syntax to be backward-compatible with the existing JS import syntax. TS, on the other hand, can support both syntaxes, which makes the `with` syntax less useful in TS.)
Every new version of ES/JS/TS just feels like they're heaping crap on top of more crap. Using a language with a real type system is just plain easier. The language itself is slow as molasses, but there's no reason the tooling has to be slow as well. Heck, Microsoft could rewrite TSC in C# and it would be a huge improvement.
This why we can't have fast things. The runtime regenerates & reallocates those methods for each class instance. Instead of allocating a single class instance, you're allocated the class + N function instances. * Each of these functions is unique, yet, identical to all the others allocated in every other class instance. * The class size is bloated by + N unique pointer fields to those functions. * Since each method is unique, the runtime will never optimize or inline the methods. As far as it can tell, no two object, even though they have the same "Shape", have the same implementation. * The poor garbage collector... If your goal was to make it as slow and bloated as possible, about the only thing left you could still do is change the `Shape` midway through the objects lifecycle. Shape optimization was the only thing left the runtime could do, so if you want to kill that too: 1. Pick a field, ideally a non-null primitive that's referenced in a lot of places & assign an array to it. - Now pass your class "instance" to whatever static methods you have that aren't constantly regenerated (& may have actually stood a chance of getting optimized) to de-opt them all by blowing whatever assumptions the JIT may have made. - Bonus: If you suspect a function field by some miracle possibly got inlined, assign not a function to it, then trigger a code path that has up to this point only ever seen a function at that field offset. 2. If things are still too fast & that wasn't enough to de-optimize all the methods, force the object into hashtable mode by adding more fields to the object, then delete one the original fields. Ideally the first field so it'd have to shift everything down. If the runtime's fed up enough, it'll instead recreate it as a hashtable. - Pass your class instance (that's now a hashmap/table) to every method it was passed to in #1, ensuring whatever de-opt survivors there were earlier get what's coming to them for thinking they could be efficient.
Figured I'd be helpful now after my last comment. Ultimately in JS because of binding, generating function is unavoidable. But there's things you can do to minimize impact: 1. Declare the function outside of the class & in the constructor, do `this.field = (a, b, c)=> myfunc(this, a, b, c)` - This is by far most performant. Especially if you use exact arg counts (there is a slight hit if arg mismatch) - try to avoid referencing any variables besides `this` inside the call so only the class itself is captured. If not possible, in the class constructor do a `const captured = { this: this, other: myvar, .... }`, put everything you'll need inside it, & reference that same object for every other arrow function you assign in the constructor. 2. Put the function on the prototype and do a `this.function = this.function.bind(this)`. #1 is faster, but `bind` is prettier / less clever / more idiomatic. 3. Anytime there's a larger function or one that's called often and a candidate for inlining try to use the prototype whenever possible or functions that aren't unique/constantly generated such as static or module level functions. - Exceptions to this are functions that are immediately consumed at the callsite without leaking. For example: functions declared & passed inline to the likes of Array.map/filter, etc. 5+ years ago I went out of my way to ensure no arrow func was nested in a hot function or within a loop because of the garbage generated, but as of ~3 years ago it doesn't seem to matter. - The Cost is only paid if the function leaks out of the callsite scope, such as the case with setTimeout or an EventListener where it gets enqueued/put onto the heap somewhere. 4. Some function like setTimeout/setInterval take parameters, use them if you can.
it's crazy that lambdas close over this correctly in classes, but not in object literals because literals aren't scopes. it does make sense but it's so counterintuitive.
Please don't do this; it's such a waste of memory and garbage collector time. You're creating new versions of every function for every instance rather than just having one for all the instances.
Once again the state of imports and package resolutions in this damn language leaves me scratching my head. Can this really not be simplified, AT ALL? It just gets more complex as time goes on.
i guess the switch(true) stuff is for people who miss (cond () () ()... else) from Scheme? cond is alright but disguising chained ifs as pattern matching is horrible
About the instance field methods: there is (was?) indeed a usecase. In React Class Components you would write your event handlers (eg for onClick) as an instance field arrow function because of the issues with this. That way you always point to that field instead of creating a new function that captures this. Because of Function Components and hooks I haven’t used it for years. But as a memory optimization enthusiast you‘d probably like this more than useCallback.
Yeah, honestly, I think if you're not using inheritance (which I don't think I ever have in JS/TS), the semantics of closures assigned to fields are generally better and more intuitive. Using methods in callbacks is super weird, especially if the callback then gets assigned to a field of some class. If you do this.callback = something.method and then do this.callback(), the callback method will be called with "this" being the completely wrong object and type while it just works as expected with fields. You can use .bind() to fix it but it's not really great and easy to forget/unintuitive.
@ThePrimeTime the only time 5:30 is acceptable is if you have cases that fall into each other and frankly even that is not as easy to read so the savings there are nil.
the "is" keyword is to deal with the more FooBar side of strong types, it is there so we can make vaild good code that is type check without needing to add any the time. it is the ex. from C# with a Int16 can't be convert to a Int32? as Int32 is a sub type of the nullable ? type, and you need 5 lines of code to return a value because the complier need the Dev. help. a Type system is invalid if it need the dev. to do the complier job. so C,Cpp,C#,Java and Rust is all invalid languages that need to go back to the basement and fix stuff. OK.
I don’t understand why everyone thinks the ‘with’ keyword is the devil, but languages allowing implicit imports - like C# ‘using’ - that is almost the same thing but at a modular level. Both pollute the current namespace with another domain’s variables. This is the one important thing that Python does correctly, have explicit imports and discourage the use of the implicit import syntax when you only use a subset of what is available in a package. I feel that to create a language that is impossible to understand by reading the source code in a plain text editor, because you have no context where objects are coming from, is a poor design. Having the extra tools of an advanced editor/IDE shouldn’t give you the reasoning to ignore being able to read and understand code without having one.
Yes, JS is too slow for good tooling, but the appeal is that devs who primarily use JS can maintain and contribute to the tooling they use. Nothing wrong with learning a new language, but the mental shift is a barrier for a lot of people. This enables the users of a language to contribute to that language's ecosystem more easily, in a more comfortable way.
I don't hate javascript enough to ever mess with this crap. Holy hell, typescript looks absolutely awful. And those examples are some of the worst I've ever seen. Is it supposed to be some fun jokes, or just a showcase of the sad truth of typescript?
ohh man... This whole video is Prime disliking stuff because he don't understand them, Please dude, there is real usecases for this stuff, if you need to hate on it, please try to use the feature first.
I don't know if it translates to JS // TS land, but there was recently a video with C that showed there were some performance gains into the byte code with the switch statement instead of if/else. But being C it was only checking against one value, not multiple types. ua-cam.com/video/fjUG_y5ZaL4/v-deo.html
i haven't written a class in javascript since react hooks was released -> they only added classes to the language to help people out who are forced to use javascript but demand OO style/thinking -> don't even use it; it's terrible and pointless
When you say "I don't know what this means", that is exactly what it is.. you don't know.. I cannot compare JsDoc to TS not because one is lacking, but just because "I don't know what it is" 🤷♂. Quoting Neil deGrasse Tyson, "when you don't know something, the conversation should end there". Finally.. I agree with you, there could be improvements 💯
Ive found across my career, that nearly every tool sucks? Why do I think this? Because everytime i pick up a new tool and begin to master it, i learn how much it sucks. I use TS/JS almost every day and I hate it. Ive never used rust outside of learning the syntax and i love it. Im sure if i started to use rust, id hate it
@@hamm8934 Yeah so very true. It's always a "grass is greener on the other side" kind of thing, since you learn to hate certain problems and see other languages fix them. As far as TS, I think it's a pretty good language and most of it's faults are due to it having to be built on top of JS, which is a god awful language, quite possibly one of the worst languages. As for JS... my personal most hated thing is NaN. It's considered type number, and NaN == NaN is actually false for some godawful reason. It's such an abomination of logic that it defies even the reflexive property of equality. And NaN does not count as a null result when using the ?? operator either.
@@taragnor thats a fair hatred. I hate both TS and JS’s lack of clear error handling the most. I think this is one of the reasons junior js devs get a bad rep. Every time we on board a junior js dev, they are utterly shocked in their first PR review at all of the feedback around needing to handle errors everywhere. Especially for self taught devs, ive never seen tutorials ever handle all of the errors that come about from async functions, promises, try catches, vanilla dom manipulation, calling a method on an object that hasnt init yet, etc..
@@hamm8934 Yeah the error handling is terrible. Really I can't blame programmers for not handling errors because in TS/JS it's not apparent what functions can even throw in the first place. TS lets you be a bit better about that, because you can create some union types using the TS type system to return either a value or an error, similar to Rust's Result type, and that union then forces the caller to deal with the potential of an error (or at least be aware of it). The problem though is that solution just works in your own code. All the JS libraries and internal functions that it's built on don't use that pattern, so you're still forced to interact with the godawful error system.
Ok, Im investing all my chips in Elixir now.. Tired of js/ts world and this version definitely didn't help! (if that doesn't pan out then I go to go/rust, but till then.. nah)
Hi @ThePrimeTimeagen, have you ever performed a profile on typescript? I'm wondering where the worst performing parts are, besides it being written in JS of course, and how feasible would it be to add in WASM components via Neon to speed it up. As a way to transition the codebase to Rust or Golang or Zig. Anyway, thanks for reading.
Prime Bun got the with for import in version 1.0, and you make fun of them for it, now lets kick them a little more for not having something they got.... perfect... the perfect i hate on any thing i know understand.
typescript used to be this cool thing to describe your JS types, now it's just a full blown mess after PMs got involved and decided to forego semantic versioning from 2->3 i think. Proof that literally everything gets worse when managers get involved.
JavaScript is the only language I don't want to learn or use. Visual Basic is probably a better language. But unfortunately the entire web is based on JS. We are screwed.
Never been happier since dropping TS and returning to native JS. Maybe simplicity is worth the single hour of debugging per year caused by type issues :)
Write it in Rust then you can't run it in the browser without compiling to WASM or some crap. Clown takes living outside the context of the TypeScript project mission. But hey, it's a persona amirite?! What they are adding isn't crazy if you consider they are not building TypeScript for how you "should" write code, it's for how people "do" write code in JavaScript...
Duck typing: If it quacks like a duck, it is a duck.
Cow typing: It's a cow if we say it is
lmao i hope this rises to top comment
Banger comment
Yeah, I'm referring to it this way from now on. The term has been coined.
Conspiracy theory: The real reason they stopped parsing jsdocs is because they have started to see them as competition....
Just recently articles popped up for me about libraries switching to JSDoc.
Dark TypeScript strikes again
They should be scared of JSDoc.
@@datboijdopewhy? unless you’re writing a library it’s not very useful
JsDocs are check with tsc as well
As a non-Javascript, non-Typescript programmer I couldn't stop laughing through most of this video.
As the legend goes... he is still laughing to this day.
The switch(true) thing is a good example of something that is very janky that 99% of devs would never use. However, the fact that it did not work properly before and now does is still an objectively good thing. The language needs to be correct and this was a clear gap in the type narrowing system. Just because most people would intuitively go for if's does not invalidate the need to make this type of thing work properly. If I've learned anything is that just because I can't think of a use-case for something doesn't mean there isn't one. If the TS team decided to give this effort, I'm sure there was someone who had a very valid use case for it.
For just a hot second, I actually thought he'd be excited about TS 🤡
Thats the day we know the bodysnatchers got him
is there anything to be excited about it tho?
@@un9286 imo about ts in general yes although it's a compromised language because it's built on javascript, about ts 5.3 not really
@@un9286Newer is better?
I write my software in assembly because the perf enhancements will finally get me a sixth user.
"That's the sound of bun having to support yet another thing" except this is already supported, its the bun import macro stuff you hated so much that you claimed change how JS does it they just implemented it before anyone else XD
Runtime support for `import type` in Bun/Deno/Node/browsers is not relevant.
Type-only imports are a TypeScript-only concept that gets erased from the generated JS.
So there's no need to talk about the effect of "resolution-mode" on Bun or any other runtime.
TS team are spending a lot of time shipping stuff that doesn't matter, I believe they need to work on the performance, I'm working on a codebase with 5k ts files and every time I'm trying to rename a symbol or use intellisense, it gets stuck forever. I'm pretty sure so many people having the same issue.
Good lord i am so happy that since WebAssembly exists, we can use different languages in the frontend.
react-java here we come O.o
Be careful with wishes. You don't want Java Applate reborn in Wasm
Use c# to make things BLAZORly fast🎉
Web Assembly can't do a tenth of what JS can do.
@@maelstrom57not yet. Can't wait for Blazor wasm becoming as functional as React to leave js for good.
overriding hasInstance really is crazy, but Typescript is not to blame there, it is a quirk of JavaScript.
Javascript wrapper 5.3 released.
bun already has(? idk the whole story) import attributes. look up Bun Macros for example.
ok i get the appeal of inheritence & interfaces as a concept. but the example where the writer checks if the fn argument is an instance of a class which returns true only to get a run time error when invoking a method specifically defined in that class simply bc it implements an interface is terrible.
`import ... with ...` is a JS/ECMAScript feature already; TypeSript just added support for it
(It was added to ECMAScript because import statements in vanilla JS already request the URL and interpret it as JS regardless of the file extension, so you couldn't do JSON imports at all. To add non-JS imports, they had to add new syntax to be backward-compatible with the existing JS import syntax. TS, on the other hand, can support both syntaxes, which makes the `with` syntax less useful in TS.)
Good lord i am so happy that since WebAssembly exists, we can use different languages in the frontend.
helpful and insightful comment, thank you!
Switch true is kinda because JavaScript doesn’t yet have pattern matching, this gets you a little closer
I use TS to add type info to variables, attributes and function signatures. That's the point. Hard to understand why people want so much extra bs.
Every new version of ES/JS/TS just feels like they're heaping crap on top of more crap. Using a language with a real type system is just plain easier.
The language itself is slow as molasses, but there's no reason the tooling has to be slow as well. Heck, Microsoft could rewrite TSC in C# and it would be a huge improvement.
I always write class functions as fields, because then "this" just works without binding. I consider it the lesser of two evils.
This why we can't have fast things. The runtime regenerates & reallocates those methods for each class instance. Instead of allocating a single class instance, you're allocated the class + N function instances.
* Each of these functions is unique, yet, identical to all the others allocated in every other class instance.
* The class size is bloated by + N unique pointer fields to those functions.
* Since each method is unique, the runtime will never optimize or inline the methods. As far as it can tell, no two object, even though they have the same "Shape", have the same implementation.
* The poor garbage collector...
If your goal was to make it as slow and bloated as possible, about the only thing left you could still do is change the `Shape` midway through the objects lifecycle.
Shape optimization was the only thing left the runtime could do, so if you want to kill that too:
1. Pick a field, ideally a non-null primitive that's referenced in a lot of places & assign an array to it.
- Now pass your class "instance" to whatever static methods you have that aren't constantly regenerated (& may have actually stood a chance of getting optimized) to de-opt them all by blowing whatever assumptions the JIT may have made.
- Bonus: If you suspect a function field by some miracle possibly got inlined, assign not a function to it, then trigger a code path that has up to this point only ever seen a function at that field offset.
2. If things are still too fast & that wasn't enough to de-optimize all the methods, force the object into hashtable mode by adding more fields to the object, then delete one the original fields. Ideally the first field so it'd have to shift everything down. If the runtime's fed up enough, it'll instead recreate it as a hashtable.
- Pass your class instance (that's now a hashmap/table) to every method it was passed to in #1, ensuring whatever de-opt survivors there were earlier get what's coming to them for thinking they could be efficient.
Figured I'd be helpful now after my last comment. Ultimately in JS because of binding, generating function is unavoidable. But there's things you can do to minimize impact:
1. Declare the function outside of the class & in the constructor, do `this.field = (a, b, c)=> myfunc(this, a, b, c)`
- This is by far most performant. Especially if you use exact arg counts (there is a slight hit if arg mismatch)
- try to avoid referencing any variables besides `this` inside the call so only the class itself is captured. If not possible, in the class constructor do a `const captured = { this: this, other: myvar, .... }`, put everything you'll need inside it, & reference that same object for every other arrow function you assign in the constructor.
2. Put the function on the prototype and do a `this.function = this.function.bind(this)`. #1 is faster, but `bind` is prettier / less clever / more idiomatic.
3. Anytime there's a larger function or one that's called often and a candidate for inlining try to use the prototype whenever possible or functions that aren't unique/constantly generated such as static or module level functions.
- Exceptions to this are functions that are immediately consumed at the callsite without leaking. For example: functions declared & passed inline to the likes of Array.map/filter, etc. 5+ years ago I went out of my way to ensure no arrow func was nested in a hot function or within a loop because of the garbage generated, but as of ~3 years ago it doesn't seem to matter.
- The Cost is only paid if the function leaks out of the callsite scope, such as the case with setTimeout or an EventListener where it gets enqueued/put onto the heap somewhere.
4. Some function like setTimeout/setInterval take parameters, use them if you can.
it's crazy that lambdas close over this correctly in classes, but not in object literals because literals aren't scopes. it does make sense but it's so counterintuitive.
Please don't do this; it's such a waste of memory and garbage collector time. You're creating new versions of every function for every instance rather than just having one for all the instances.
its cool how they could make the worst import syntax even worst xD
funny a recent video by that Theo guy he was talking about why he liked that switch (true) syntax for TypeScript
So... Typescript is slowly evolving into Javascript??
With the amount of “features” they’re putting on it it’s looking more like Java
Once again the state of imports and package resolutions in this damn language leaves me scratching my head. Can this really not be simplified, AT ALL? It just gets more complex as time goes on.
It is the way it is not because it has to be this way, but because it has to be backward-compatible with all the bad decisions from the past 😔
switch(true) is amazing are you joking
i guess the switch(true) stuff is for people who miss (cond () () ()... else) from Scheme? cond is alright but disguising chained ifs as pattern matching is horrible
I switch true all the time. Way less ugly than else if
I do lots of runtime dynamic composition and analysis of objects and pattern matching and like most of this.
I think I hear DHH laughing somewhere
field as a function has the use of implicitly binding `this`. It was useful for react class components. But I agree the other syntax is better.
About the instance field methods: there is (was?) indeed a usecase. In React Class Components you would write your event handlers (eg for onClick) as an instance field arrow function because of the issues with this. That way you always point to that field instead of creating a new function that captures this.
Because of Function Components and hooks I haven’t used it for years. But as a memory optimization enthusiast you‘d probably like this more than useCallback.
Yeah, honestly, I think if you're not using inheritance (which I don't think I ever have in JS/TS), the semantics of closures assigned to fields are generally better and more intuitive. Using methods in callbacks is super weird, especially if the callback then gets assigned to a field of some class. If you do this.callback = something.method and then do this.callback(), the callback method will be called with "this" being the completely wrong object and type while it just works as expected with fields. You can use .bind() to fix it but it's not really great and easy to forget/unintuitive.
that's why you can use arrow functions.
@ThePrimeTime the only time 5:30 is acceptable is if you have cases that fall into each other and frankly even that is not as easy to read so the savings there are nil.
How is that different from subsequent if statements?
@@Nichiyoobikoelse if is ugly and less readable, I guess
they should just delete switch(true) and pretend it never happened
I actually like TypeScript but this update was so weird (and underwhelming, but I guess refinements and bug fixes are always needed).
the "is" keyword is to deal with the more FooBar side of strong types, it is there so we can make vaild good code that is type check without needing to add any the time.
it is the ex. from C# with a Int16 can't be convert to a Int32? as Int32 is a sub type of the nullable ? type, and you need 5 lines of code to return a value because the complier need the Dev. help.
a Type system is invalid if it need the dev. to do the complier job. so C,Cpp,C#,Java and Rust is all invalid languages that need to go back to the basement and fix stuff. OK.
I don’t understand why everyone thinks the ‘with’ keyword is the devil, but languages allowing implicit imports - like C# ‘using’ - that is almost the same thing but at a modular level. Both pollute the current namespace with another domain’s variables. This is the one important thing that Python does correctly, have explicit imports and discourage the use of the implicit import syntax when you only use a subset of what is available in a package.
I feel that to create a language that is impossible to understand by reading the source code in a plain text editor, because you have no context where objects are coming from, is a poor design. Having the extra tools of an advanced editor/IDE shouldn’t give you the reasoning to ignore being able to read and understand code without having one.
Yes, JS is too slow for good tooling, but the appeal is that devs who primarily use JS can maintain and contribute to the tooling they use. Nothing wrong with learning a new language, but the mental shift is a barrier for a lot of people. This enables the users of a language to contribute to that language's ecosystem more easily, in a more comfortable way.
you must be partially disabled if you can't learn a second language
dogs can only make dogfood and when given human food from faster humans they go nuts and dont eat dogfood anymore
what?@@39strife
@@39strife woof
JavaScript the backend is always the wrong answer
I don't hate javascript enough to ever mess with this crap. Holy hell, typescript looks absolutely awful. And those examples are some of the worst I've ever seen. Is it supposed to be some fun jokes, or just a showcase of the sad truth of typescript?
Dude... I almost puked while reading the `with` keyword functionality... You need to put up a disclaimer when recommending things to learn like that.
ohh man... This whole video is Prime disliking stuff because he don't understand them, Please dude, there is real usecases for this stuff, if you need to hate on it, please try to use the feature first.
I don't know if it translates to JS // TS land, but there was recently a video with C that showed there were some performance gains into the byte code with the switch statement instead of if/else. But being C it was only checking against one value, not multiple types.
ua-cam.com/video/fjUG_y5ZaL4/v-deo.html
switch(true) is a let wight match from Rust. you can throw in the default, and get the error if you got a null ref.
Probably because a 2D/3D vector can be represented as PointLike, it's not that cray
Looks like they're getting bored. Need to crank moar features of a language that's already ok.
4:30 well the ts extension is for typescript as well as a streaming protocol
i haven't written a class in javascript since react hooks was released -> they only added classes to the language to help people out who are forced to use javascript but demand OO style/thinking -> don't even use it; it's terrible and pointless
yeah... unfortunately this take only works in a world where you don't do performance
When you say "I don't know what this means", that is exactly what it is.. you don't know.. I cannot compare JsDoc to TS not because one is lacking, but just because "I don't know what it is" 🤷♂. Quoting Neil deGrasse Tyson, "when you don't know something, the conversation should end there". Finally.. I agree with you, there could be improvements 💯
Excited
You should consider you're talking about something that needs to implement the hardest gradual typing problem in the world.
That's hilarious how Prime is one of the most famous TS/JS haters and yet he doing a lot of it at work. So do I )
Ive found across my career, that nearly every tool sucks? Why do I think this? Because everytime i pick up a new tool and begin to master it, i learn how much it sucks.
I use TS/JS almost every day and I hate it. Ive never used rust outside of learning the syntax and i love it. Im sure if i started to use rust, id hate it
@@hamm8934 Yeah so very true. It's always a "grass is greener on the other side" kind of thing, since you learn to hate certain problems and see other languages fix them.
As far as TS, I think it's a pretty good language and most of it's faults are due to it having to be built on top of JS, which is a god awful language, quite possibly one of the worst languages.
As for JS... my personal most hated thing is NaN. It's considered type number, and NaN == NaN is actually false for some godawful reason. It's such an abomination of logic that it defies even the reflexive property of equality. And NaN does not count as a null result when using the ?? operator either.
I don't think that's funny or ironic. I imagine this is how a lot of people start disliking JS in the first place.
@@taragnor thats a fair hatred. I hate both TS and JS’s lack of clear error handling the most. I think this is one of the reasons junior js devs get a bad rep. Every time we on board a junior js dev, they are utterly shocked in their first PR review at all of the feedback around needing to handle errors everywhere.
Especially for self taught devs, ive never seen tutorials ever handle all of the errors that come about from async functions, promises, try catches, vanilla dom manipulation, calling a method on an object that hasnt init yet, etc..
@@hamm8934 Yeah the error handling is terrible. Really I can't blame programmers for not handling errors because in TS/JS it's not apparent what functions can even throw in the first place.
TS lets you be a bit better about that, because you can create some union types using the TS type system to return either a value or an error, similar to Rust's Result type, and that union then forces the caller to deal with the potential of an error (or at least be aware of it). The problem though is that solution just works in your own code. All the JS libraries and internal functions that it's built on don't use that pattern, so you're still forced to interact with the godawful error system.
Ok, Im investing all my chips in Elixir now.. Tired of js/ts world and this version definitely didn't help! (if that doesn't pan out then I go to go/rust, but till then.. nah)
Yeah, more JS Foot guns for "type-safe" TS.
const fetch = async (): x is Response {
return undefined;
}
JavaScript bros building frameworks like US adding one more lane to a highway hoping it will finally fix the traffic
switch(true) is amazing, what do you mean?
Supporting the Module Resolution modes will bei easy for bin, because IT already des. importing just works in bun. this is the best thing about bun
Daniel Rosewater is an epic name ngl
why he hate typescript?
He just hate JS, and TS is JS
As a Kotlin Dev I am wondering what is this shit...
I tried C, Rust, Javascript, Python, PHP, Julia, Dart and Go. The only programming language I'm not feel comfortable is Javascript.
The only thing malicious about JavaScript is how much memory and CPU it uses💀
I'm something of a typescript beta myself
Oh lookie here its my favourite zionist.
imagine not typing errors in try/catch statements and improving the switch(true) experience instead
How do you type a try-catch? Sounds like hell statically analyze that
Ain't nobody remembering all that
ts release "trust me bro"
next season: dark arc Prime goes full jvm
Isn't TypeScript a joke
ngl this guy is really handsome
What is a gosh darn statement
javascript with all those plugins feels like frankenstein
Hi @ThePrimeTimeagen, have you ever performed a profile on typescript? I'm wondering where the worst performing parts are, besides it being written in JS of course, and how feasible would it be to add in WASM components via Neon to speed it up. As a way to transition the codebase to Rust or Golang or Zig. Anyway, thanks for reading.
this is just straight up comedy now
New import syntax maybe for CSP😅
Prime Bun got the with for import in version 1.0, and you make fun of them for it, now lets kick them a little more for not having something they got.... perfect... the perfect i hate on any thing i know understand.
use bun
Excited
hi
switch(true) sounds like the 0[array] stuff in C;
Rescript gang
typescript took something bad (javascript) and made it worse.
typescript used to be this cool thing to describe your JS types, now it's just a full blown mess after PMs got involved and decided to forego semantic versioning from 2->3 i think. Proof that literally everything gets worse when managers get involved.
I've always wanted to do this : First!
I’ve got some terrible news for you
JavaScript is the only language I don't want to learn or use. Visual Basic is probably a better language. But unfortunately the entire web is based on JS.
We are screwed.
Never been happier since dropping TS and returning to native JS. Maybe simplicity is worth the single hour of debugging per year caused by type issues :)
no way
Write it in Rust then you can't run it in the browser without compiling to WASM or some crap.
Clown takes living outside the context of the TypeScript project mission. But hey, it's a persona amirite?!
What they are adding isn't crazy if you consider they are not building TypeScript for how you "should" write code, it's for how people "do" write code in JavaScript...
You sound like a switch (true) guy.
Waiting for ThePrimeTime soyjak
Wtf is this
🙀
Inlay hints are awful.
Fingers crossed stc, Ezno and Hegel shake up the type checking scene. Especially the latter two, I just wanna write JS with sound inferred types 🥲