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...
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?
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…
Unless someone is using some language extensions, transpiling from TS to an ECMAScript module using the ESNext target merely drops the type annotations.
If not running the exact same code being developed is an issue, it’s an easy fix.
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.
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…
🙈🙉🙊
I know, but I didn’t want to scare the children.
I also choose 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!
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.
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.
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.