I love how you could've made this video 25 minutes long with all that bs everyone doing novadays, but instead didn't waste everyone's time and simply delivered the news and addressed future questions by linking the article.
Just like Blender, I swear free open source products with a volunteer community that's listenning to the users needs and feedbacks are always the best.
cannot disagree more, the fact is that NodeJS has a massive ecosystem, a small change could break tons on dependencies... that's why it's evolving slowly. what is true is that TypeScript support has "maybe" come faster due to the competition, but maybe not because as you see it's "just" an option to strip types, no conversion from TS to JS (not really), this is kind of faster to implement and it could have been released a few months after Deno/Bun releases, however that is not what happened, we had to wait a years for that, but now it's becoming a reality. I am so happy that finally happened.
IMO, we have Deno to thank for taking the initiative to include TypeScript and Rust-based bundlers/compilers. Call me biased if you like, Rust has done for JS compilers what TypeScript did for JS code, which is achieving runtime safety. If they weren't the first to do it I'm not sure when we will ever see TS in node by default, notwithstanding that node being run by volunteers is doing an already great job.
It’s a great thing. Hope it will be added as a standard feature. And I hope there’s an opportunity to automise type check / lint ts code in order to use it with CI tools etc Ps there’s one thing I like in this approach especially developing frontend applications. I’ve replaced vue-cli with vite & was pleasantly surprised that I can develop vue applications with ts without type checks in dev mode. Previously, using webpack I had to wait until the entire project was builder and checked for types before the dev server was started, and with each new save there was also a type check. There were also difficulties with setting up ssr, but now it has all become much easier, and type checking can be done for production build only.
YAY, I knew it was coming out on the 8th, but wasn't sure of the exact time 23.6 was gonna be released.. Thank you for giving me the prod.. I think we just need to old-yellow typescript enums and we can be happy.
Since all it does is just ignore the types does this means a project can have some parts be typescript and others be javascript without any compilation/bundling? This would be awesome to migrate old projects slowly to typescript
I didn't see this in your blog. But when I was using this feature before I wasn't able to use this feature in node_modules. I have a package that I use that I call to build my project from a node_module. Did they fix that yet?
Only startup performance is affected. They’re using SWC so it will be crazy fast. Then that stripped version is byte code cached by V8 so the next run will be instant
@@mattpocockuk 100% this. I recommend bundling code that's destined for Lambda, just be sure to exclude any aws-sdk dependencies as those come for free.
JESUS christ finally no need for ts-node and it's utterly terrible bugs... I swear this thing must be deciding whether or not it wants to work based on quantum mechanics cause I couldn't find a single reason it randomly switched opinions. You start your day, test something out, it works just fine, you take a break, get some coffe, come back half an hour later and suddenly it doesn't recognise the .ts extension...
Congratulations Node... you've now (almost) got something that gives you a sub-standard alternative to Deno's default behaviour... that's ... erm... great... I suppose?????? ;)
That's great and all but just removing the experimental flag is not that revolutionary, because the functionality stays the same. I feel like the real next step is to add a flag that turns on typechecking (maybe without the additional linting that tsc does?)
@@mattpocockuk assuming typechecking should only be run once, that works, although using 2 commands just to run typescript code can be a bit confusing for beginners. The main problem for me is when I try setting up a nice dev environment with node's --watch flag and typechecking.
@@JankkPL You only need node index.ts now to run TypeScript code. Just run tsc --watch in one terminal and node --watch in another. Or run them in parallel with concurrently/pnpm.
@@rafael.aloizio1769 The benefit is so you can run your code WITHOUT seeing the type errors, which is a critically important way to get a fast feedback loop running.
Excuse me, but I do not understand why everyone so excited about this? Is it so hard to run 'npx tsx index.ts' or 'swc index.ts' after 'npm install @swc/cli'? Why anybody does not curious which exact version of TS is used on built in node's implementation? On this depends TS behavior. A lot of people speak about Deno and Bun TS support, but for some reason they don't speak about the thing, that you cannot independently manage TS version from your JS runtime version. For me native TS support is just cargo cult of people that find complicated running few more cli commands that give more flexibility and more expected TS behavior
> that you cannot independently manage TS version from your JS runtime version Node just strips the types, so it's somewhat decoupled from the TS version. > is it so hard to run 'npx tsx index.ts' It's annoying that tsx, ts-node, swc and the million other alternatives all have slightly different module resolution strategies and work in slightly different ways. They are hard to hook up to the debugger. They are just a compat layer that shouldn't exist.
@@mattpocockuk I don't know the situation on frontend, but on backend I never had any problems with TS setup, for example in NestJS it is made out of the box, so no manual setup needed, if I just need to launch something simple, I just use 'npx tsx'
I love how you could've made this video 25 minutes long with all that bs everyone doing novadays, but instead didn't waste everyone's time and simply delivered the news and addressed future questions by linking the article.
yep..... ive never seen a video from this channel before, but damn that was good - subscribed instantly 🙌🏼
RIP ts-node
It's amazing how some people are still using ts-node when tsx is a thing.
@@maelstrom57 Wait can you explain?
@@ivyZorzThere's a NodeJS library called tsx which is basically ts-node but faster and just better
@@hhhhhhhhhhhhhhhhhhhhhh is it better than esrun?
definitely will not be missed. Treating typescript as a first-party entity is the new default
The fact that node is made by volunteers blows my mind.
Just like Blender, I swear free open source products with a volunteer community that's listenning to the users needs and feedbacks are always the best.
This is such a win for the ecosystem. So excited
If we're being honest, node wouldn't have done something like this if other runtimes like Deno and Bun didn't come out and offer competition.
We can't know, but I think this narrative is lazy and unsubstantiated.
@@mattpocockukwhy is lazy to say that competition pushes technology further?
cannot disagree more, the fact is that NodeJS has a massive ecosystem, a small change could break tons on dependencies... that's why it's evolving slowly.
what is true is that TypeScript support has "maybe" come faster due to the competition, but maybe not because as you see it's "just" an option to strip types, no conversion from TS to JS (not really), this is kind of faster to implement and it could have been released a few months after Deno/Bun releases, however that is not what happened, we had to wait a years for that, but now it's becoming a reality. I am so happy that finally happened.
your short videos are JAM-PACKED & AWESOME
Good thing I like JAM
IMO, we have Deno to thank for taking the initiative to include TypeScript and Rust-based bundlers/compilers. Call me biased if you like, Rust has done for JS compilers what TypeScript did for JS code, which is achieving runtime safety. If they weren't the first to do it I'm not sure when we will ever see TS in node by default, notwithstanding that node being run by volunteers is doing an already great job.
Can we put breakpoints in .ts files and debug it like a normal .js file?
Yes
Yes, and it rocks
I remember the quote any which is not written in javascript will eventually be written in javascript
It’s a great thing. Hope it will be added as a standard feature.
And I hope there’s an opportunity to automise type check / lint ts code in order to use it with CI tools etc
Ps there’s one thing I like in this approach especially developing frontend applications. I’ve replaced vue-cli with vite & was pleasantly surprised that I can develop vue applications with ts without type checks in dev mode. Previously, using webpack I had to wait until the entire project was builder and checked for types before the dev server was started, and with each new save there was also a type check. There were also difficulties with setting up ssr, but now it has all become much easier, and type checking can be done for production build only.
Yeah, finally, it only took Deno and Bun to appear and push hard enough
YAY, I knew it was coming out on the 8th, but wasn't sure of the exact time 23.6 was gonna be released.. Thank you for giving me the prod..
I think we just need to old-yellow typescript enums and we can be happy.
Since all it does is just ignore the types does this means a project can have some parts be typescript and others be javascript without any compilation/bundling? This would be awesome to migrate old projects slowly to typescript
Yep, pretty sure that'll just work.
I didn't see this in your blog. But when I was using this feature before I wasn't able to use this feature in node_modules. I have a package that I use that I call to build my project from a node_module. Did they fix that yet?
What about performance?
Is this only for development phase? And push js files ih productions ?
Only startup performance is affected. They’re using SWC so it will be crazy fast.
Then that stripped version is byte code cached by V8 so the next run will be instant
Rip deno, rip bun
🤣I love that TS "support" is just a flag to strip it out! It's like a Monty Python sketch! Hopefully there's a flag to save the resulting files.
Welcome back bro
Okay? So Typescript is kinda pseudo native now?
Node v22 is available on AWS lambda. Is it possible to pass the flag (or maybe set an ENV var?) that turns on type stripping?
Definitely don't do this on lambda, you should be type stripping and minifying to squeeze the most juice out of your cold starts.
@@mattpocockuk 100% this. I recommend bundling code that's destined for Lambda, just be sure to exclude any aws-sdk dependencies as those come for free.
For fastest coldstart times, AWS advises bundling everything (incl. aws-sdk modules) in your uploaded zip.
What about emitDecoratorMetadata?
Flag needed
@philheathslegalteam it's supported? :O
Does it typecheck my files?
classic node, remove 1 flag, need another flag
But when it is in LTS?
It will be unflagged in 22, so whenever 22 becomes LTS
@@mattpocockuk u mean 24? because 22 is already LTS though!
@@statuschannel8572 Whoops, yes, 22 is LTS. So, soon!
tried it; doesn't work yet!
What was different about your setup to mine?
RIP ts-node, tsx, tsup, ts-jest and whatnot...
It's time for me to go back to node from bun 😅
Let’s remove ts-node.
Deno Deno Deno. I always using Deno much as possible.
y'all are like "rip tsx" which is funny because tsx is still needed for .tsx files lol
JESUS christ finally no need for ts-node and it's utterly terrible bugs...
I swear this thing must be deciding whether or not it wants to work based on quantum mechanics cause I couldn't find a single reason it randomly switched opinions.
You start your day, test something out, it works just fine, you take a break, get some coffe, come back half an hour later and suddenly it doesn't recognise the .ts extension...
Congratulations Node... you've now (almost) got something that gives you a sub-standard alternative to Deno's default behaviour... that's ... erm... great... I suppose?????? ;)
I'd say it's different from Deno's implementation - wouldn't say it's worse.
thanks sir
That's great and all but just removing the experimental flag is not that revolutionary, because the functionality stays the same. I feel like the real next step is to add a flag that turns on typechecking (maybe without the additional linting that tsc does?)
What's the benefit of having Node.js run typechecking? Just run tsc && node index.ts
@mattpocockuk what's the benefit of not having it? The other platforms do this by default, if so, is still needed to install typescript isn't it?
@@mattpocockuk assuming typechecking should only be run once, that works, although using 2 commands just to run typescript code can be a bit confusing for beginners.
The main problem for me is when I try setting up a nice dev environment with node's --watch flag and typechecking.
@@JankkPL You only need node index.ts now to run TypeScript code.
Just run tsc --watch in one terminal and node --watch in another. Or run them in parallel with concurrently/pnpm.
@@rafael.aloizio1769 The benefit is so you can run your code WITHOUT seeing the type errors, which is a critically important way to get a fast feedback loop running.
Rust mentioned!
Thank christ
Wow 1!
Coming from Bun, it’s no excitement as we already have it in Bun.. 😂
I was excited about Bun for two reasons: (1) Bun is awesome, and (2) it forces Node to up their game.
You always exaggerate the news. It's nice, but it's not even a big deal.
Your collection of Discworld books is too small. Shame.
It is!
FIRST!
But at what cost?
Excuse me, but I do not understand why everyone so excited about this?
Is it so hard to run 'npx tsx index.ts' or 'swc index.ts' after 'npm install @swc/cli'?
Why anybody does not curious which exact version of TS is used on built in node's implementation? On this depends TS behavior.
A lot of people speak about Deno and Bun TS support, but for some reason they don't speak about the thing, that you cannot independently manage TS version from your JS runtime version.
For me native TS support is just cargo cult of people that find complicated running few more cli commands that give more flexibility and more expected TS behavior
> that you cannot independently manage TS version from your JS runtime version
Node just strips the types, so it's somewhat decoupled from the TS version.
> is it so hard to run 'npx tsx index.ts'
It's annoying that tsx, ts-node, swc and the million other alternatives all have slightly different module resolution strategies and work in slightly different ways. They are hard to hook up to the debugger. They are just a compat layer that shouldn't exist.
The fewer extra tools needed, the better. It's really that simple.
@@maelstrom57 It has all sorts of good compounding effects in the ecosystem.
@@mattpocockuk I don't know the situation on frontend, but on backend I never had any problems with TS setup, for example in NestJS it is made out of the box, so no manual setup needed, if I just need to launch something simple, I just use 'npx tsx'
@@user-abc855 Nest is a framework and abstract away all these steps. try to setup an express app with typescript