I like this take. Because while I use a ton of bun now there's certain environments that I'm only able to use node. Unfortunately those same environments are on node 18 and it'll be a while before I see these changes in the places I actually use node
Still can't get over how fast bun is. I am working on a server application that has to be fast, tried rewriting it to Go recently, but it ended up running slower than bun.
@@seeibeWell, bun is written in zig, also don't forget that go still has an garbage collector that has a non negligible execution time. Also if you want it to be memory efficient, I have noticed that rust performs best here ( don't confuse memory efficiency with memory safety ), and speeds are comparable to c++. Zig however has a different approach then c
@@psveagle nah it's actually because bun just does way less and has less features so there is less abstraction and less overhead. Zig isn't magically faster than C++ when both are compiled to machine code, in fact over a huge sample size Zig would be slower because the compiler and libraries are less mature and haven't squeezed out the last bit of performance yet. Also all the Zig code is just a wrapper around JSC which is slower than V8 at runtime even though it's faster at startup which nobody cares about because you're starting your app once and it's going to take several seconds or minutes either way.
@theairaccumulator7144 idk what is the magic juice bun does, but for my use cases where most of the run time is spent in pure functions, it is orders of magnitude faster than node with v8. It's very likely some very smart jit optimizations.
@@affanyunas7693 is it tho? JS frameworks are more complex than anything I've seen in any other language except C++ and Rust. It's real hardcore programming, far from scripting.
But typescript itself is using the term "compiler", not transpiler. You have "compilerOptions" in tsconfig.json, tsc command, so it's definitely not Theo who misused the terms. No idea if it's misused in case of Typescript and Microsoft.
Curiously, there is another ECMAScript language that supported type annotations way before TypeScript came along, and that is ActionScript, used by Adobe Flash. I wonder if you can now use some ActionScript as well.
I mean, it's already dead. Even before the shutdown of flash, AS was already declining. Although there are still some companies that uses action script and most of them are gaming.
@@corvoswag I feel like Python's typing ecosystem is kind of poor because there are multiple type checking tools that behave slightly differently, and a lot of libraries don't provide type stubs
Im not a web dev, and ive not done much with web stuff. So take this for what it is. Why did JavaScript not have static types in the first place? It seems like every dynamic/flexible typed language reinvents static types eventually
JS was born for browser use, initially it was only used to modify some DOM data. There were no critical elements and not many libraries, today for a simple "hello world" you can have hundreds of dependencies, so a common system is needed to maintain type consistency in all these libraries and avoid type checking at runtime.
This reminds me a lot of how type hinting and other annotations work in python. Ignored in execution, but accessible to other tools and frameworks to make the lives of engineers easier. Whether it is IDEs better able to provide useful information and suggestions about the code you are working on, mypy doing static type checking, or things like FastAPI using the type hints to produce OpenAPI documentation and drive behavior, it has been super powerful and useful. I love this functionality in Python and how it has evolved and it seems like this will be similarly powerful and useful in the world of javascript.
@@ProfMonkeys Type annotations in Python aren't ignored during execution; the type expressions are evaluated during runtime to enable tools to do the analysis you mention. This means that, especially in earlier versions, using types in Python has a performance cost. I think it's better in recent versions though
I believe the reason for using WASM over native was actually due to tool chain complexity (I recall this was commented on the PR if anyone wants to fact check). Node already supports WASM, but they don’t support Rust in their toolchain. Therefore, it’s easier to ship WASM than Rust. I don’t think binary size reduction was cited or is the main reason. Yes SWC core platform binaries are bigger, but node only needs to ship one of them. Also, to my knowledge, there’s no native equivalent to SWC WASM typescript at present. However, comparing like for like, the full native and WASM versions are on the same order of magnitude, so I think it would be possible to ship an SWC native typescript binary which is similar in size to the WASM binary.
Thoughts on the tsx package? Not the file type. It's like ts-node but better (in my limited experience) My Node flow currently consists of - tsx for running Typescript - tsconfig.json made from Matt Pocock's cheatsheet - `pnpm tsc` and `pnpm eslint src` for typechecking and linting
TSX works great. I don't know why Node even needs this feature - the problem was already solved, and I'm sure all the edge cases around module import/export are going to surface in this new implementation soon enough. But for some reason, in the JS world, nothing is ever good enough, even if it's working perfectly - we have to constantly start over and wait for another 3-5 years for the new thing to mature, at which point at least two new competing projects will have started over again. We're getting nowhere.
@@Will4_U yep, there is literally no setup - one npx command and you're set. I really don't know why this needs to be built in other than for the sheer perception of Node keeping up with alternatives - most of which are actually behind in a number of areas. built in support for TS really seems to be purely about perception.
This reminds me of how python handles types. Python supports type hints, but they are ignored in execution. They did support type aliases in 3.12, but I'm pretty sure those are also ignored.
Seems like a good idea. I resist using TypeScript in smaller projects because, as far as I'm concerned, it's not script if you have to compile it. I'm ok with my IDE doing linting and type checking for me but if I can avoid a full on build process and maintaining separate source and deploy trees, I will.
As far as I know, some builtin module replacements for node's ones are not there yet and could break things. Put it simply, it's not 100% compatible with node and people don't want to risk some libs not working correctly for them.
Well I've been testing it out in both CI/CD and have tried using it in our team and it works fine,but it should be pointed out that it is still far from being fully adopted So,my advice,it's best to use it in personal projects to avoid compatibility issues in production,at least till it is maturely adopted
My only concern is how this will affect typescript's development and ability to add new features and syntax. As far as I'm concerned, browser and node should be doing their own seperate things than defining where and how TS/flow/the-language-that-"one day"-replaces-TS describes its types and syntax. Of course, they could use their own build tools and such, but depending on how this spec is done, anyone with a new idea and syntax that doesn't play well with most transpilers will be effectively forced to create their own compiler which could slow adoption. Meaning the only way for their stuff to work would require typescript to add support and consequentially force venders to update their transpilation process...assuming they will even try.
@@bobwilkinsonguitar6142 I think his point is that TypeScript would have to support new syntax in order to be able to effectively remove types. Consider the case of the pipeline proposal (this is not based on any spec, but is a likely candidate for how TypeScript provide interopability): let json = (pkgs[0] as Package) |> npa(%).escapedName |> (await npmFetch.json(%, opts) as JSONPackage); Without the knowledge about the pipeline syntax, TypeScript would not have any structural knowledge about the AST to know where to the strip types, without possibly resulting in syntax errors in the output JS. To prevent errors like that it would need to build and AST and traverse that AST to then rewrite the nodes and remove them. It's not as simple as using a Regex to replace types. By adding TypeScript as a dependency, you effectively would have to wait for TypeScript to ship the support for these syntax features in order to use them. Though, TypeScript has been really good at keeping up with proposals (implementing support before wide adoption, and working with ECMAScript to align goals), so we'll see what the outcome of this will be.
we exclusively use bun in my company and i also moved over for private projects and one of the reasons for this move was the ability to run a ts file without setup. Before bun we had a "runTsFile" project on our git server .... because the setup is so painfull on node.
One of the nicest things you get from TypeScript (Aside from typing obviously) is the ability to change the JavaScript target from one version to another especially when a new version of JavaScript is released without having to rewrite all of your Typescript. Once upon a time it was pretty painful to maintain JavaScript code and upgrade to a new version. I feel like adding type annotations to JavaScript just so you can paste your TypeScript code somewhere to make it run as JavaScript is Kludgy, Lazy and sets a pretty dangerous precedent not to mention sowing confusion. It seems pretty pointless to me. I would rather see more tooling and support for WASM personally. Compile from your language of choice to WASM and skip that part in the browser. Win/Win.
by running the pnpm typecheck, how do you get around the issue that nextjs needs the next-env.d.ts, which requires a pnpm run build or a pnpm run dev to create the next-env.d.ts file ? whenever I try run typecheck without doing a build first it fails
I wish browsers could have if not a proper JVM as "script engine" (instead of V8), but at least GraalVM thingy (which is for Java/Kotlin native). So we could write with a really type-safe Kotlin with type-checking on runtime rather than transpiling everything into JS eventually which means your code will never be type-safe at runtime :(
When using types that span multiple lines and node throws an exception. Do the lines in the stack trace match actual lines in the ts file or are they offsetted because types are discarded?
Please ECMAScript people just accept the proposal. Although I love backwards compatibility, I think this is the time for JS to do breaking changes for the sake of future.
If you don't add an extension to you TypeScript files, what happens with import/require? I mean if the files that contain TypeScript code do not have extensions, how does TypeScript and Node handle that in import and require?
I think they're still discussing this but you'll probably have to use .ts for .ts files. Omitting the extension was only possible because TypeScript would leave the import untouched when compiling individual TypeScript files to JavaScript files in the same directory, which people don't really do anymore
@@trappedcat3615 It's not as pressing of a feature and adds additional complexity to the language syntax. The point is figuring out the tradeoffs. Getting syntax incorrect would result in a broken language that would be difficult to change without breaking backwards compatibility-and you cannot break the web. These things takes several years to pass even Stage 1, let a lone Stage 2. As an example, the pipeline operator proposal was in Stage 1 for 5 years after multiple attempts at getting it in for Stage 2 and that just some version of the original proposal, not the entire thing.
Great. Now if only they can backport it to browsers. Wouldn’t want to actually run ts in prod but for a quick copy paste to console it’d be hard to beat
Turning types into comments sounds like a really bad idea to me. As a developer I want my code to error when it's the wrong type, and code not erroring when the wrong type is given is just going to turn into massive headaches. I don't agree with copy/paste reasoning either. I expect _a lot_ of issues/questions that will break stuff because people don't understand that's just a comment while reading like it isn't.
You can still run TSC to get the errors whenever you want. And there's no reason that can't be built into a framework (probably as an option) if you want to be blocked from executing any code with type errors.
Node's REPL is still garbage*, but this is nice. *: no import statements (= it doesn't even support ES6 properly); strip-types also leaves out REPL support. Literally impossible to do interactive development with without manually rewriting stuff or transpiling away import statements. I literally use Deno just for the REPL.
It did in ES4, but Micro$oft didn't want to support it so it never came out. (Micro$oft back then was like the Apple of today, incredibly hostile to developer and standards, trying to gangpress others into using their own version of something for their own profit margins and the detriment of everyone else) Then Steve Ballmer left and Micro$oft became Microsoft, and the internal experiment that became Typescript was allowed to be open sourced. Google which was working on something similar called AtScript saw what Microsoft was developing, talked with them and were able to convince Microsoft to make some slight tweaks to the language so that Google could use it in their Angular 2+ framework. Now everyone's on the same page that following standards (as far as the js ecosystem is concerned) is the best way forward. Now the JS ecosystem has native type support in Typed Arrays for chunks of contiguous memory and DoD (Data-oriented Design), and WASM (for portable optimized AOT bytecode).
"it's necessarily what we are using in the browser for all of our web apps...", um...we are necessarily NOT using it in the browser. TypeScript is a linter and not recognized by any browser.
Is it “cool” to commit binary blobs to version control, or a vector for supply chain attacks 😅 (I know WASM is sandboxed, but this still doesn’t seem sensible in the wake of recent malicious exploits).
The xz binary blobs in the xz attack had no source available code so no one could easily verify what was in them, and the malicious binary was also split, obfuscated, and disguised. The difference between this and the xz suppy chain attack is the binary blob has corresponding code that builds into the exact same binary blob and that verifiable blob is loaded and run directly, nothing is obfuscated.
@@spartanatreyu Thanks for the info. I’m aware of the differences. Yes, in theory someone can verify the binary corresponds to the actual source, and I’m sure that only trusted individuals will be allowed to commit binary modifications unchecked (just like xz). There’s also currently no way to escape the WASM sandbox directly AFAIK. However, - the binary is built and committed manually - there’s no automated checks to verify the binary matches the source - a compromised binary could inject arbitrary code into people’s application code, which would then be immediately run by node The consequence of failure is potentially very large, and just like xz we are relying mostly on one maintainer judging off the commits. Let me lay out a scenario: - Amaro continues to be shipped in Node but maintained in a separate repo - Amaro continues with one maintainer - That maintainer burns out - Someone offers to help - Years later, they gain trust and are allowed to update the binary blob (a tedious manual chore) - They commit dozens of legitimate updates - Finally, they commit some code to the binary only which injects an eval of some remote malicious code into the application JS Sound familiar? Personally, I feel that we shouldn’t be rolling these kinds of dice on a project the size of Node. This should be 1) in the main repo, 2) automated, not manual.
All these mental gymnastics just reinforces for me, that TypeScript is crap. No real safety, no runtime type checking. It’s a validator. After decades with strict typing in other languages, I was so excited to go full-JS and enjoy the flexibility and simplicity. I don’t need the explicit type crutches. Microsoft has succeeded in infecting JS and has made it a tedious mess.
I hate Typescript. It turns development into bureaucracy in enterprise-Java style. OOP out of nowhere and ton of boilerplates. Last time it happened, I couldn't resist that endless dumpster fire by myself and left company.
I like javascript because there's no compilation step. I also don't like typescript because it is developed by microsoft. I think there are things we can still do to support dynamic typing better, but everyone's focus has been on doing static types. There's a reason to do a dynamically typed language, and I think it's because it's actually easier, if your editor supports it. But no one has ever seen an editor support a dynamically typed language in human history. So far the only support has been for typescript, and javascript is only vaguely supported through typescript's static types... But javascript is capable of dynamic typing variables! Nobody seems to care, though. Except me.
The type problem was born from the stupidity of developers, for a simple "hello world" you can have hundreds of dependencies and every developer wants to be sure of which variables go into his library, he doesn't trust his user at all. Imagine having a math library and someone throws strings into it, finding the error is a mess because you don't know if the problem is yours or a bug in the library. Also you want to avoid type checking at runtime to make the code cleaner and more performant.
I've found that the reality is only a very small percentage of variables need to be dynamic types, most variables remain the same type, or union of types, through their lifetime. Most type systems have a way to type those variables, Any in Python or dynamic I'm C#. I find typed code much easier to read, much easier to work with since you don't need to look the docs for functions all the time to see what they accept and return. Plus all the errors caught by the editor and type checking. I've found static where possible, dynamic where necessary the best approach.
I disagree that TypeScript one. I still see many projects and applications in only JavaScript. It also takes longer and isn't always the choice for small prototype apps. In his world it has one but in the real world that isn't the case.
I've never understood using typescript on the client. You rarely actually need it, if ever. If you're using a type safe language on the server like Java, Go, whatever, why the hell do you even care about type safety on the client? I've worked on some pretty dang complex applications that deal with insurance policy stuff and never once felt like I lacked anything using vanilla JavaScript. The server should be doing the things where type safety matters, the client is just taking things and making it useful for display. I really think typescript is only good for those people that want to basically use js on the server as well as the client, but at that point just use a better, faster language on the server! IDK maybe I'm dumb but typescript is basically useless when there are other, better languages for the hard lifting on the server and JavaScript is more than enough and flexible on the client for a reason. Let me know how I'm wrong.
Have you ever used TS? Saves hours of time, being ensured that the variable that I’m using has the values/types that I expect… prevents so many bugs. Honestly, your comment sounds like someone who’s never built out a project with TS.
It's the same argument for typing anywhere. Do you want to spend hours tracking down a bug that static type checking could find in seconds? Do you want your editor to be able to find a whole class of bugs as you type them? Do you want to know the inputs and outputs of a function from the signature?
Bun’s biggest achievement is getting all the other run times to actually comply and make things devs want
I like this take. Because while I use a ton of bun now there's certain environments that I'm only able to use node. Unfortunately those same environments are on node 18 and it'll be a while before I see these changes in the places I actually use node
competition good *nodding*
deno
I love that I don’t have to setup a whole tsconfig and compile and deal with that. Can just run the typescript directly on backend
I trust they gave that 617 line blob a good security review.
Jia tan says it checks out
They have separate repo that generates that string, it was addressed in the PR comments
congrats to bun for pushing them to finally do it
Still can't get over how fast bun is. I am working on a server application that has to be fast, tried rewriting it to Go recently, but it ended up running slower than bun.
@@seeibe It's because Bun is written in Zig!
@@seeibeWell, bun is written in zig, also don't forget that go still has an garbage collector that has a non negligible execution time.
Also if you want it to be memory efficient, I have noticed that rust performs best here ( don't confuse memory efficiency with memory safety ), and speeds are comparable to c++.
Zig however has a different approach then c
@@psveagle nah it's actually because bun just does way less and has less features so there is less abstraction and less overhead. Zig isn't magically faster than C++ when both are compiled to machine code, in fact over a huge sample size Zig would be slower because the compiler and libraries are less mature and haven't squeezed out the last bit of performance yet. Also all the Zig code is just a wrapper around JSC which is slower than V8 at runtime even though it's faster at startup which nobody cares about because you're starting your app once and it's going to take several seconds or minutes either way.
@theairaccumulator7144 idk what is the magic juice bun does, but for my use cases where most of the run time is spent in pure functions, it is orders of magnitude faster than node with v8. It's very likely some very smart jit optimizations.
I much prefer the term "type annotation" rather than "strong types". Also "transpiler" rather than "compiler".
I second this.
yeah agree coz js is just scripts
@@affanyunas7693 is it tho? JS frameworks are more complex than anything I've seen in any other language except C++ and Rust. It's real hardcore programming, far from scripting.
Yeah, a compiler would do much more than converting TS to JS.
But typescript itself is using the term "compiler", not transpiler. You have "compilerOptions" in tsconfig.json, tsc command, so it's definitely not Theo who misused the terms. No idea if it's misused in case of Typescript and Microsoft.
bro is trapped behind Joe Rogan's red curtain.
That's crazy, man. Have you ever done DMT?
i've been able to type "script" my entire life, why do I need this change?
They want to compete bun lul
Your whole life? How do you node this?
@@trappedcat3615 I deno, I just do
Ba dum tis
@@simpingsyndromeit’s not compete but more like catching up with the flow.
Bun is nowhere close to nodejs tho.
Curiously, there is another ECMAScript language that supported type annotations way before TypeScript came along, and that is ActionScript, used by Adobe Flash. I wonder if you can now use some ActionScript as well.
It lacks parameterized types. 😢
I mean, it's already dead. Even before the shutdown of flash, AS was already declining. Although there are still some companies that uses action script and most of them are gaming.
ActionScript was the first ever programming language I learned in high school game design class...... That's it. No eulogy. I'm not sad it's dead.
Haxe feels like Action Script 4 and transpiles to pretty much anything
Why though? Who is asking for ActionScript? Why not embrace where the community is at.
It works nicely imo in Python that use similar type annotation.
@@corvoswag I feel like Python's typing ecosystem is kind of poor because there are multiple type checking tools that behave slightly differently, and a lot of libraries don't provide type stubs
Im not a web dev, and ive not done much with web stuff. So take this for what it is.
Why did JavaScript not have static types in the first place? It seems like every dynamic/flexible typed language reinvents static types eventually
they did not expect people using javascript outside of the browser
JS was born for browser use, initially it was only used to modify some DOM data. There were no critical elements and not many libraries, today for a simple "hello world" you can have hundreds of dependencies, so a common system is needed to maintain type consistency in all these libraries and avoid type checking at runtime.
@@jackzugna5830bro ur smokin crack
@@safarl45 Better than sniff JS.
@@jackzugna5830ts literally gets turned into JS in order for it to execute lmao
i love C# and typescript! its so enjoyable to work with
This reminds me a lot of how type hinting and other annotations work in python. Ignored in execution, but accessible to other tools and frameworks to make the lives of engineers easier. Whether it is IDEs better able to provide useful information and suggestions about the code you are working on, mypy doing static type checking, or things like FastAPI using the type hints to produce OpenAPI documentation and drive behavior, it has been super powerful and useful.
I love this functionality in Python and how it has evolved and it seems like this will be similarly powerful and useful in the world of javascript.
@@ProfMonkeys Type annotations in Python aren't ignored during execution; the type expressions are evaluated during runtime to enable tools to do the analysis you mention. This means that, especially in earlier versions, using types in Python has a performance cost.
I think it's better in recent versions though
I believe the reason for using WASM over native was actually due to tool chain complexity (I recall this was commented on the PR if anyone wants to fact check). Node already supports WASM, but they don’t support Rust in their toolchain. Therefore, it’s easier to ship WASM than Rust. I don’t think binary size reduction was cited or is the main reason. Yes SWC core platform binaries are bigger, but node only needs to ship one of them. Also, to my knowledge, there’s no native equivalent to SWC WASM typescript at present. However, comparing like for like, the full native and WASM versions are on the same order of magnitude, so I think it would be possible to ship an SWC native typescript binary which is similar in size to the WASM binary.
FYI, Theo, you can run the latest version of `master` of node with `npx node-nightly`
Thoughts on the tsx package? Not the file type. It's like ts-node but better (in my limited experience)
My Node flow currently consists of
- tsx for running Typescript
- tsconfig.json made from Matt Pocock's cheatsheet
- `pnpm tsc` and `pnpm eslint src` for typechecking and linting
TSX works great. I don't know why Node even needs this feature - the problem was already solved, and I'm sure all the edge cases around module import/export are going to surface in this new implementation soon enough. But for some reason, in the JS world, nothing is ever good enough, even if it's working perfectly - we have to constantly start over and wait for another 3-5 years for the new thing to mature, at which point at least two new competing projects will have started over again. We're getting nowhere.
tsx is super awesome, love that it just works out of the box
@@Will4_U yep, there is literally no setup - one npx command and you're set. I really don't know why this needs to be built in other than for the sheer perception of Node keeping up with alternatives - most of which are actually behind in a number of areas. built in support for TS really seems to be purely about perception.
Do you guys use tsx in production? Or do you still compile to JS and run via Node?
@@re.liable tbh I've never used Node in production. I live in Denmark, and employers generally want C# or PHP, sometimes Java, but almost never Node.
This reminds me of how python handles types. Python supports type hints, but they are ignored in execution. They did support type aliases in 3.12, but I'm pretty sure those are also ignored.
Actually they are not ignored. They are evaluating and accessible at runtime. But yes, they are not checked for type correctness
You can check how fastapi or pydantic implemented
Seems like a good idea. I resist using TypeScript in smaller projects because, as far as I'm concerned, it's not script if you have to compile it. I'm ok with my IDE doing linting and type checking for me but if I can avoid a full on build process and maintaining separate source and deploy trees, I will.
Do the video on the .ts thing! I remember the Fireship video on it and I just did not understand it.
This is exactly how python handles annotations.
Browsers should support TypeScript for the sake of humanity.
we have bandwidth to waste.
serious question here: are you guys using bun in production? I'm looking for some reason to not do it
I've seen some projects using it, but still large scale projects are not using it..
As far as I know, some builtin module replacements for node's ones are not there yet and could break things.
Put it simply, it's not 100% compatible with node and people don't want to risk some libs not working correctly for them.
Well I've been testing it out in both CI/CD and have tried using it in our team and it works fine,but it should be pointed out that it is still far from being fully adopted
So,my advice,it's best to use it in personal projects to avoid compatibility issues in production,at least till it is maturely adopted
My only concern is how this will affect typescript's development and ability to add new features and syntax. As far as I'm concerned, browser and node should be doing their own seperate things than defining where and how TS/flow/the-language-that-"one day"-replaces-TS describes its types and syntax. Of course, they could use their own build tools and such, but depending on how this spec is done, anyone with a new idea and syntax that doesn't play well with most transpilers will be effectively forced to create their own compiler which could slow adoption. Meaning the only way for their stuff to work would require typescript to add support and consequentially force venders to update their transpilation process...assuming they will even try.
Did you watch the video? It just strips types, you could almost just use a linter
@@bobwilkinsonguitar6142 I think his point is that TypeScript would have to support new syntax in order to be able to effectively remove types. Consider the case of the pipeline proposal (this is not based on any spec, but is a likely candidate for how TypeScript provide interopability):
let json = (pkgs[0] as Package) |> npa(%).escapedName |> (await npmFetch.json(%, opts) as JSONPackage);
Without the knowledge about the pipeline syntax, TypeScript would not have any structural knowledge about the AST to know where to the strip types, without possibly resulting in syntax errors in the output JS. To prevent errors like that it would need to build and AST and traverse that AST to then rewrite the nodes and remove them. It's not as simple as using a Regex to replace types.
By adding TypeScript as a dependency, you effectively would have to wait for TypeScript to ship the support for these syntax features in order to use them. Though, TypeScript has been really good at keeping up with proposals (implementing support before wide adoption, and working with ECMAScript to align goals), so we'll see what the outcome of this will be.
we exclusively use bun in my company and i also moved over for private projects and one of the reasons for this move was the ability to run a ts file without setup.
Before bun we had a "runTsFile" project on our git server .... because the setup is so painfull on node.
You use bun at work? I didn’t realize it was production ready!
.ts files are still a transport stream container format in my mind
One of the nicest things you get from TypeScript (Aside from typing obviously) is the ability to change the JavaScript target from one version to another especially when a new version of JavaScript is released without having to rewrite all of your Typescript. Once upon a time it was pretty painful to maintain JavaScript code and upgrade to a new version.
I feel like adding type annotations to JavaScript just so you can paste your TypeScript code somewhere to make it run as JavaScript is Kludgy, Lazy and sets a pretty dangerous precedent not to mention sowing confusion. It seems pretty pointless to me. I would rather see more tooling and support for WASM personally. Compile from your language of choice to WASM and skip that part in the browser. Win/Win.
But it doesn't. It doesn't have transformative support for Enum and other typescript generated code.
The Node team is going nuts.
by running the pnpm typecheck, how do you get around the issue that nextjs needs the next-env.d.ts, which requires a pnpm run build or a pnpm run dev to create the next-env.d.ts file ? whenever I try run typecheck without doing a build first it fails
What about emitDecoratorMetadata? :(
What about paths (mapping)?
coffeescript should have fun
If the ECMAscript type annotations proposal passes does that mean TS will switch from being a proper superset of JS to being a proper subset?
Video recommendation : Why Typescript with Sequelize suvks
Hey Theo, tell us what do you think about Cursor IDE? For me, it's quite dogshiet tbh.
Hey Theo, how do you add padding to your extensions icons in the VSCode?
I wish browsers could have if not a proper JVM as "script engine" (instead of V8), but at least GraalVM thingy (which is for Java/Kotlin native). So we could write with a really type-safe Kotlin with type-checking on runtime rather than transpiling everything into JS eventually which means your code will never be type-safe at runtime :(
When using types that span multiple lines and node throws an exception. Do the lines in the stack trace match actual lines in the ts file or are they offsetted because types are discarded?
Please ECMAScript people just accept the proposal. Although I love backwards compatibility, I think this is the time for JS to do breaking changes for the sake of future.
Here I was, thinking that Javascript is the language of choice for the Javascript ecosystem, but according Theo it's TypeScript now. Oh well!
If you don't add an extension to you TypeScript files, what happens with import/require? I mean if the files that contain TypeScript code do not have extensions, how does TypeScript and Node handle that in import and require?
I think they're still discussing this but you'll probably have to use .ts for .ts files. Omitting the extension was only possible because TypeScript would leave the import untouched when compiling individual TypeScript files to JavaScript files in the same directory, which people don't really do anymore
Now when will browser adapt typescript natively……
I think in year 2077 to support
The TC39 ECMAScript proposal for type annotations is in Stage 1 - Theo talks about it in the video
@@NateVolkerStage 1 near 2 years? Seems doa.
@@trappedcat3615 It's not as pressing of a feature and adds additional complexity to the language syntax. The point is figuring out the tradeoffs. Getting syntax incorrect would result in a broken language that would be difficult to change without breaking backwards compatibility-and you cannot break the web.
These things takes several years to pass even Stage 1, let a lone Stage 2. As an example, the pipeline operator proposal was in Stage 1 for 5 years after multiple attempts at getting it in for Stage 2 and that just some version of the original proposal, not the entire thing.
@@dealloc Totally agree. I've lost hope for it, but anything can happen.
I think i will just wait for internet2.0 and hope ecmasceipt will be somewhat normal
this video gave me want to use Deno
This isn't in an actual node release just yet, is it?
can you do a video on NextJS with older browsers and a package called CoreJS. My NextJS app gets tons of globalThis errors in Sentry, thats why.
pog?
I wonder what browser Theo using here? It's pretty dope!
Arc
@@binamralamsal you're right, thanks
Great. Now if only they can backport it to browsers. Wouldn’t want to actually run ts in prod but for a quick copy paste to console it’d be hard to beat
So 13:35 is where he has his constipated faces catolouged.
Theo if you struggle with sleep in summer you should maybe buy a climate device:) you seem to not talk overwhelming fast anymore🤣
Thank fucking god
PSA: Node's implementation uses SWC.
My Benis hurts
Turning types into comments sounds like a really bad idea to me. As a developer I want my code to error when it's the wrong type, and code not erroring when the wrong type is given is just going to turn into massive headaches. I don't agree with copy/paste reasoning either. I expect _a lot_ of issues/questions that will break stuff because people don't understand that's just a comment while reading like it isn't.
You can still run TSC to get the errors whenever you want. And there's no reason that can't be built into a framework (probably as an option) if you want to be blocked from executing any code with type errors.
Node's REPL is still garbage*, but this is nice.
*: no import statements (= it doesn't even support ES6 properly); strip-types also leaves out REPL support. Literally impossible to do interactive development with without manually rewriting stuff or transpiling away import statements. I literally use Deno just for the REPL.
"keep using Bun"
So kinda like Python I guess.
ts-node using swc is fine.
Damn, TypeScript is that old...
Do a video on .ts and .js on imports
I never do that :P
Should we call it Node.ts
bun baby!
Why doesn't javascript come with native type system?
Because letting browsers statically enforce types is a forward compatibility and cross browser compatibility pain
It did in ES4, but Micro$oft didn't want to support it so it never came out.
(Micro$oft back then was like the Apple of today, incredibly hostile to developer and standards, trying to gangpress others into using their own version of something for their own profit margins and the detriment of everyone else)
Then Steve Ballmer left and Micro$oft became Microsoft, and the internal experiment that became Typescript was allowed to be open sourced.
Google which was working on something similar called AtScript saw what Microsoft was developing, talked with them and were able to convince Microsoft to make some slight tweaks to the language so that Google could use it in their Angular 2+ framework.
Now everyone's on the same page that following standards (as far as the js ecosystem is concerned) is the best way forward.
Now the JS ecosystem has native type support in Typed Arrays for chunks of contiguous memory and DoD (Data-oriented Design), and WASM (for portable optimized AOT bytecode).
The Simpsons already did this... sorry I mean Bun !!!
You look more and more 80s
Yees please make a vid about the .tsx extension thing
"it's necessarily what we are using in the browser for all of our web apps...", um...we are necessarily NOT using it in the browser. TypeScript is a linter and not recognized by any browser.
Is it “cool” to commit binary blobs to version control, or a vector for supply chain attacks 😅 (I know WASM is sandboxed, but this still doesn’t seem sensible in the wake of recent malicious exploits).
The xz binary blobs in the xz attack had no source available code so no one could easily verify what was in them, and the malicious binary was also split, obfuscated, and disguised.
The difference between this and the xz suppy chain attack is the binary blob has corresponding code that builds into the exact same binary blob and that verifiable blob is loaded and run directly, nothing is obfuscated.
@@spartanatreyu Thanks for the info. I’m aware of the differences. Yes, in theory someone can verify the binary corresponds to the actual source, and I’m sure that only trusted individuals will be allowed to commit binary modifications unchecked (just like xz). There’s also currently no way to escape the WASM sandbox directly AFAIK.
However,
- the binary is built and committed manually
- there’s no automated checks to verify the binary matches the source
- a compromised binary could inject arbitrary code into people’s application code, which would then be immediately run by node
The consequence of failure is potentially very large, and just like xz we are relying mostly on one maintainer judging off the commits. Let me lay out a scenario:
- Amaro continues to be shipped in Node but maintained in a separate repo
- Amaro continues with one maintainer
- That maintainer burns out
- Someone offers to help
- Years later, they gain trust and are allowed to update the binary blob (a tedious manual chore)
- They commit dozens of legitimate updates
- Finally, they commit some code to the binary only which injects an eval of some remote malicious code into the application JS
Sound familiar?
Personally, I feel that we shouldn’t be rolling these kinds of dice on a project the size of Node. This should be 1) in the main repo, 2) automated, not manual.
wdym?
so... add enums and namespaces to javascript.
it is not a compiler, it is a linter then remove all the type stuff in the output file.
so Typescript linter and type remover.
all code safe before compiled to js code. ts moment
tsc !
WHAT!!!
I'm always not first
2nd or 3rd place requires extra precision. You have to anticipate when first is going to make a move. You have good form and landed this nicely.
I still prefer vanilla js... There is so much extra I gotta type with typescript. It's annoying. *insert Old man yells at computer*
All these mental gymnastics just reinforces for me, that TypeScript is crap. No real safety, no runtime type checking. It’s a validator. After decades with strict typing in other languages, I was so excited to go full-JS and enjoy the flexibility and simplicity. I don’t need the explicit type crutches. Microsoft has succeeded in infecting JS and has made it a tedious mess.
It's not "official typescript support" but rather "official typescript ignorance".
Uff... binary blobs in code seems to me as an opportunity for another XZ supply chain attack.
I hate Typescript. It turns development into bureaucracy in enterprise-Java style.
OOP out of nowhere and ton of boilerplates.
Last time it happened, I couldn't resist that endless dumpster fire by myself and left company.
I like javascript because there's no compilation step. I also don't like typescript because it is developed by microsoft. I think there are things we can still do to support dynamic typing better, but everyone's focus has been on doing static types. There's a reason to do a dynamically typed language, and I think it's because it's actually easier, if your editor supports it. But no one has ever seen an editor support a dynamically typed language in human history. So far the only support has been for typescript, and javascript is only vaguely supported through typescript's static types... But javascript is capable of dynamic typing variables! Nobody seems to care, though. Except me.
Bro complaining about running "TSC", a build step of 3 seconds (10 seconds if on a huge project) lol
The type problem was born from the stupidity of developers, for a simple "hello world" you can have hundreds of dependencies and every developer wants to be sure of which variables go into his library, he doesn't trust his user at all. Imagine having a math library and someone throws strings into it, finding the error is a mess because you don't know if the problem is yours or a bug in the library. Also you want to avoid type checking at runtime to make the code cleaner and more performant.
I've found that the reality is only a very small percentage of variables need to be dynamic types, most variables remain the same type, or union of types, through their lifetime.
Most type systems have a way to type those variables, Any in Python or dynamic I'm C#.
I find typed code much easier to read, much easier to work with since you don't need to look the docs for functions all the time to see what they accept and return. Plus all the errors caught by the editor and type checking.
I've found static where possible, dynamic where necessary the best approach.
Typescript is unreadable
😂 no way you think no type checking is better
I’m always first
And there’s nothing you can do about that.
the bot was first LMAO
You beat most of the spam bots, impressive
Want a cookie?
I disagree that TypeScript one. I still see many projects and applications in only JavaScript. It also takes longer and isn't always the choice for small prototype apps. In his world it has one but in the real world that isn't the case.
Won* ?
Typescript is for noobs LOL
Boring
I've never understood using typescript on the client. You rarely actually need it, if ever. If you're using a type safe language on the server like Java, Go, whatever, why the hell do you even care about type safety on the client? I've worked on some pretty dang complex applications that deal with insurance policy stuff and never once felt like I lacked anything using vanilla JavaScript. The server should be doing the things where type safety matters, the client is just taking things and making it useful for display. I really think typescript is only good for those people that want to basically use js on the server as well as the client, but at that point just use a better, faster language on the server! IDK maybe I'm dumb but typescript is basically useless when there are other, better languages for the hard lifting on the server and JavaScript is more than enough and flexible on the client for a reason. Let me know how I'm wrong.
Have you ever used TS? Saves hours of time, being ensured that the variable that I’m using has the values/types that I expect… prevents so many bugs.
Honestly, your comment sounds like someone who’s never built out a project with TS.
It's the same argument for typing anywhere.
Do you want to spend hours tracking down a bug that static type checking could find in seconds?
Do you want your editor to be able to find a whole class of bugs as you type them?
Do you want to know the inputs and outputs of a function from the signature?
@@101Mant Yes, yes I do. Because I know that type related errors are exceptionally uncommon. Nope, I demand actual documentation.
Node.ts
Bun
Bun
Buuuuuuuun. [dramatic stare into the camera]
just use go