Why are some big open-source projects like Turbo and Svelte dropping TypeScript in favor of vanilla JavaScript? Learn about the pros and cons of TypeScript#p...
Opinion from me, a JS beginner: Vanilla is good enough now. If your IDE lets you type common structures like document.getElementById("") with shortcuts, I find no need to use a framework. Also, vanilla works better in offline projects.
How is that related to TS? Aside from the fact that your comment might have just started a civil war (no, vanilla JS is not “good enough”, they created libraries for a reason) this isn’t about using libraries / frameworks. It’s about needing some system to handle type annotations to avoid falling in the bottomless pit of:
I literally don’t know what TypeScript is, lol. But the video says that Vanilla is an alternative to TS and I am a happy user of it. I thought it was some enterprise language that compiles to JavaScript for people who cannot handle document.getElementById("") but will happily add an abstraction layer on the wonky HTML-CSS-JS mess, just to have the compiler create really weird undecipherable minified JS… But I already said I’m inexperienced – don’t take advice from a $ hater whose biggest working website is this.
Then I guess this is what you get for talking about something without knowing what it is lol.
As another user pointed out, TypeScript is a different language (.ts extension) that extends JavaScript, meaning JS code is valid TS code, but TS adds various language features for type checking. Your editor is then able to interpret your code according to these type structures and warn you if you are making any stupid type errors like this one:
The problem many people have with TS (such as the “big projects” mentioned by Fireship) is that sometimes you end up having code that works but still have to do some weird type gymnastics to please the TS compiler and have it remove any errors and warnings.
That being said, frameworks that “create really weird undecipherable minified JS” do have their place, as they allow you to seamlessy do things that would be either very inelegant and verbose or significantly more complex in vanilla JS, but I won’t bore you with an excessively long wall of text.
PS: I love your Czech flag website. Had me jump on my chair when the music started blasting through my headphones.
Types support “programming at scale” - scale in the sense of larger code based or multiple people contributing.
If you’re hacking away at a script for a web page, then yeah, have at it.
If you’re supporting more than a few hundred lines of code or working on a team, you need types to codify and communicate information that can be verified with a compiler.
Whenever you see a larger codebase that is not strongly (or statically) typed, you generally will see unit tests that are verifying the types/structure of outputs.
As someone who has written some Python at work, whenever I need to work on some code without type hints, I spend way too much time trying to figure out what all the parameter types should be for functions. I can’t be the only one doing this though, I’ve seen functions that assume their inputs are strings receiving pathlib.Path on some uncommon branch that sure enough errors on some obscure user inputs.
I’ve been pushing mypy hard though. It’s not perfect, but it works well enough that it’s still worth using over not using. The biggest pushback has actually been from the amount of time we’d have to spend fixing type-related bugs instead of developing new features.
I have the same problem. Any time I use a dynamically typed language, whatever time I save not specifying the type, I’ll lose immediately when I have to hunt down what sort of data this function expects or chase down some error that a compiler would have caught in a statically typed language.
The summary uses the term “vanilla JS” in a weird way. It’s just to further denote it’s not TypeScript because TypeScript is a language that essentially extends JavaScript. It’s not a framework. This is about language choice of TS vs JS inside large complex libraries only.
Libraries tend to have a need for generic typing due to the nature of being code used by other code. So you get a lot of syntax craziness involving Type parameters.
You can still use the libraries mentioned in a TS project. They’re just not written in TS. TS and JS can be in the same project. Moreover, it even states this isn’t about developers using TS in non-library projects.
it’s fine to learn with. preferable even. I lead a team of devs writing/maintaining four related front-end applications and at a point you really need a better language.
Opinion from me, a JS beginner: Vanilla is good enough now. If your IDE lets you type common structures like
document.getElementById("")with shortcuts, I find no need to use a framework. Also, vanilla works better in offline projects.How is that related to TS? Aside from the fact that your comment might have just started a civil war (no, vanilla JS is not “good enough”, they created libraries for a reason) this isn’t about using libraries / frameworks. It’s about needing some system to handle type annotations to avoid falling in the bottomless pit of:
Uncaught TypeError: Cannot read property of undefinedI literally don’t know what TypeScript is, lol. But the video says that Vanilla is an alternative to TS and I am a happy user of it. I thought it was some enterprise language that compiles to JavaScript for people who cannot handle
document.getElementById("")but will happily add an abstraction layer on the wonky HTML-CSS-JS mess, just to have the compiler create really weird undecipherable minified JS… But I already said I’m inexperienced – don’t take advice from a$hater whose biggest working website is this.then perhaps you should learn about it before you offer your opinion
Then I guess this is what you get for talking about something without knowing what it is lol.
As another user pointed out, TypeScript is a different language (.ts extension) that extends JavaScript, meaning JS code is valid TS code, but TS adds various language features for type checking. Your editor is then able to interpret your code according to these type structures and warn you if you are making any stupid type errors like this one:
The problem many people have with TS (such as the “big projects” mentioned by Fireship) is that sometimes you end up having code that works but still have to do some weird type gymnastics to please the TS compiler and have it remove any errors and warnings.
That being said, frameworks that “create really weird undecipherable minified JS” do have their place, as they allow you to seamlessy do things that would be either very inelegant and verbose or significantly more complex in vanilla JS, but I won’t bore you with an excessively long wall of text.
PS: I love your Czech flag website. Had me jump on my chair when the music started blasting through my headphones.
Typescript is basically JavaScript with variable typing. That is, you have to explicitly declare that your variable is a string, int, float, etc.
This is an professional experience thing.
Types support “programming at scale” - scale in the sense of larger code based or multiple people contributing.
If you’re hacking away at a script for a web page, then yeah, have at it.
If you’re supporting more than a few hundred lines of code or working on a team, you need types to codify and communicate information that can be verified with a compiler.
Whenever you see a larger codebase that is not strongly (or statically) typed, you generally will see unit tests that are verifying the types/structure of outputs.
As someone who has written some Python at work, whenever I need to work on some code without type hints, I spend way too much time trying to figure out what all the parameter types should be for functions. I can’t be the only one doing this though, I’ve seen functions that assume their inputs are strings receiving
pathlib.Pathon some uncommon branch that sure enough errors on some obscure user inputs.I’ve been pushing mypy hard though. It’s not perfect, but it works well enough that it’s still worth using over not using. The biggest pushback has actually been from the amount of time we’d have to spend fixing type-related bugs instead of developing new features.
I have the same problem. Any time I use a dynamically typed language, whatever time I save not specifying the type, I’ll lose immediately when I have to hunt down what sort of data this function expects or chase down some error that a compiler would have caught in a statically typed language.
The summary uses the term “vanilla JS” in a weird way. It’s just to further denote it’s not TypeScript because TypeScript is a language that essentially extends JavaScript. It’s not a framework. This is about language choice of TS vs JS inside large complex libraries only.
Libraries tend to have a need for generic typing due to the nature of being code used by other code. So you get a lot of syntax craziness involving Type parameters.
You can still use the libraries mentioned in a TS project. They’re just not written in TS. TS and JS can be in the same project. Moreover, it even states this isn’t about developers using TS in non-library projects.
it’s fine to learn with. preferable even. I lead a team of devs writing/maintaining four related front-end applications and at a point you really need a better language.