- cross-posted to:
- typescript@programming.dev
- cross-posted to:
- typescript@programming.dev
You must log in or # to comment.
The title makes it seem like it’s a wide spread thing in the industry but according to the video it’s 3 frameworks.
Yeah, it’s additional work but I’ve found that really convoluted or complex type definitions usually mean you should consider refactoring. Of course this is a bit different when it comes to developing frameworks where you might want to support a bunch of different use cases.
Maybe I’m biased because I’ve been using TS ever since it first came out.
And Rich Harris (Svelte) said, it’s an issue for people in his position, aka, people making tools for developers - he fully expects and respects that the end users (developers using those tools) don’t really experience the downsides.
That said, I feel like we’re seeing a lot of versions of complaints about how big the stacks are getting, how big the foundation is that we “need” just to get started. That desire for minimalism is core to the developer mentality imo, it makes us good at our jobs. I think we’re going to see more paring down and culling in the coming months/years.
And once again, clickbait YouTuber spreading bullshit appears
Clickbait - The silent killer
Soon on Netflix (probably)
You won’t believe how many people watched it!
Here is an alternative Piped link(s): https://piped.video/watch?v=5ChkQKUzDCs
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source, check me out at GitHub.
I haven’t dealt with a larger JS/Node Project in a while, but I like this approach to using TS features in JS.
so he does all of this because he dislikes transpiling because supposedly it makes debugging etc harder? does he know about sourcemaps?
he also says he doesnt like type information in his code, so he adda them as comments. the type information is still there, how is this an improvement?
The issue with transpiling is that the code that’s running in production is not necessarily the one that’s been tested. A source map doesn’t fix that.
I loathe this line of reasoning. It’s like saying “unless you wrote assembly, compiling your code could change what it does.”
Guess what, the CPU reorders/ellides assembly, too! You can’t trust anything!
Haha, what is this, the 90s?
Assembled instructions aren’t even the lowest non-hardware stage in instruction execution. There’s proprietary microcode sitting a level below your typical x86 ISA.
And even then, what if—God forbid—the hardware has errata. A line has to be drawn somewhere between trusting that what you write is logically correct at all stages below it. If someone is unable to trust that the environment they wrote code for works, they better start learning how to create PCBs and writing for FPGAs.
🙈🙉🙊
I know, but I didn’t want to scare the children.
I also chose to pretend it’s just little gnomes moving the bytes around. Less magic.
What are electrons, but a miserable pile of little magic gnomes? But enough talk… have a upvote!
Unless someone is using some language extensions, transpiling from TS to an ECMAScript module using the
ESNexttarget merely drops the type annotations.If not running the exact same code being developed is an issue, it’s an easy fix.
Ugh? Why shouldn’t it be the same code?
Because Browsers can’t run Typescript, they run JavaScript. That’s why the intermediate conversion step isneededd.
But your tests are running on the compiled code too. Nothing can be tested but handwritten assembly, with such approach
That approach was mentioned in the video.
I do this daily and believe me when I say that I’d trade my kidney for the ability to use TS natively. This looks good on paper but jsdoc notation has lots of flaws and you literally can’t do some things with it. Also, it doesn’t check if the function actually does the thing you described so it needs manual review every time it’s changed.
Nah. Waste of time imo
good. typescript has always caused us more headache than it worth in all my projects. I bill my clients extra for it if they make me work on it.
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 ahater whose biggest working website is this.I literally don’t know what TypeScript is
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.
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.
