Node FINALLY Supports TypeScript

แชร์
ฝัง
  • เผยแพร่เมื่อ 24 ธ.ค. 2024

ความคิดเห็น • 186

  • @jacoL8
    @jacoL8 4 หลายเดือนก่อน +193

    Bun’s biggest achievement is getting all the other run times to actually comply and make things devs want

    • @Frostbytedigital
      @Frostbytedigital 4 หลายเดือนก่อน +7

      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

    • @snuglife3697
      @snuglife3697 4 หลายเดือนก่อน +7

      competition good *nodding*

    • @goldforest06
      @goldforest06 4 หลายเดือนก่อน +2

      deno

    • @dedicatedserver8214
      @dedicatedserver8214 4 หลายเดือนก่อน

      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

  • @jurassicthunder
    @jurassicthunder 4 หลายเดือนก่อน +135

    bro is trapped behind Joe Rogan's red curtain.

    • @gercius
      @gercius 4 หลายเดือนก่อน +5

      That's crazy, man. Have you ever done DMT?

  • @rapzid3536
    @rapzid3536 4 หลายเดือนก่อน +73

    I trust they gave that 617 line blob a good security review.

    • @99.99.9
      @99.99.9 4 หลายเดือนก่อน +37

      Jia tan says it checks out

    • @JLarky
      @JLarky 4 หลายเดือนก่อน +7

      They have separate repo that generates that string, it was addressed in the PR comments

  • @samuelgunter
    @samuelgunter 4 หลายเดือนก่อน +192

    i've been able to type "script" my entire life, why do I need this change?

    • @simpingsyndrome
      @simpingsyndrome 4 หลายเดือนก่อน +5

      They want to compete bun lul

    • @trappedcat3615
      @trappedcat3615 4 หลายเดือนก่อน +23

      Your whole life? How do you node this?

    • @samuelgunter
      @samuelgunter 4 หลายเดือนก่อน

      @@trappedcat3615 I deno, I just do

    • @NatalieUwUOwO
      @NatalieUwUOwO 4 หลายเดือนก่อน +7

      Ba dum tis

    • @adnanearef2959
      @adnanearef2959 4 หลายเดือนก่อน +2

      @@simpingsyndromeit’s not compete but more like catching up with the flow.
      Bun is nowhere close to nodejs tho.

  • @BobFrTube
    @BobFrTube 4 หลายเดือนก่อน +133

    I much prefer the term "type annotation" rather than "strong types". Also "transpiler" rather than "compiler".

    • @copperbadge1
      @copperbadge1 4 หลายเดือนก่อน +1

      I second this.

    • @affanyunas7693
      @affanyunas7693 4 หลายเดือนก่อน

      yeah agree coz js is just scripts

    • @theairaccumulator7144
      @theairaccumulator7144 4 หลายเดือนก่อน +5

      @@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.

    • @gergoradeczki
      @gergoradeczki 4 หลายเดือนก่อน +3

      Yeah, a compiler would do much more than converting TS to JS.

    • @denysdorokhov6355
      @denysdorokhov6355 4 หลายเดือนก่อน +3

      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.

  • @SG_01
    @SG_01 4 หลายเดือนก่อน +47

    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.

    • @pairofrooks
      @pairofrooks 4 หลายเดือนก่อน +3

      It lacks parameterized types. 😢

    • @MamawDaGreat
      @MamawDaGreat 4 หลายเดือนก่อน +9

      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.

    • @noahhastings6145
      @noahhastings6145 4 หลายเดือนก่อน +3

      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.

    • @ElementalCode
      @ElementalCode 4 หลายเดือนก่อน +2

      Haxe feels like Action Script 4 and transpiles to pretty much anything

    • @builtbywalsh
      @builtbywalsh 4 หลายเดือนก่อน +1

      Why though? Who is asking for ActionScript? Why not embrace where the community is at.

  • @corvoswag
    @corvoswag 4 หลายเดือนก่อน +19

    It works nicely imo in Python that use similar type annotation.

    • @seanthesheep
      @seanthesheep 4 หลายเดือนก่อน +4

      @@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

  • @Mekelaina
    @Mekelaina 4 หลายเดือนก่อน +23

    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

    • @25w-g6c
      @25w-g6c 4 หลายเดือนก่อน +26

      they did not expect people using javascript outside of the browser

    • @jackzugna5830
      @jackzugna5830 4 หลายเดือนก่อน +13

      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.

    • @safarl45
      @safarl45 4 หลายเดือนก่อน +7

      @@jackzugna5830bro ur smokin crack

    • @jackzugna5830
      @jackzugna5830 4 หลายเดือนก่อน +6

      @@safarl45 Better than sniff JS.

    • @safarl45
      @safarl45 4 หลายเดือนก่อน

      @@jackzugna5830ts literally gets turned into JS in order for it to execute lmao

  • @re.liable
    @re.liable 4 หลายเดือนก่อน +4

    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

    • @RasmusSchultz
      @RasmusSchultz 4 หลายเดือนก่อน +2

      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
      @Will4_U 4 หลายเดือนก่อน +1

      tsx is super awesome, love that it just works out of the box

    • @RasmusSchultz
      @RasmusSchultz 4 หลายเดือนก่อน +1

      @@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.

    • @re.liable
      @re.liable 4 หลายเดือนก่อน

      Do you guys use tsx in production? Or do you still compile to JS and run via Node?

    • @RasmusSchultz
      @RasmusSchultz 4 หลายเดือนก่อน

      @@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.

  • @luciusrex
    @luciusrex 4 หลายเดือนก่อน

    i love C# and typescript! its so enjoyable to work with

  • @benheidemann3836
    @benheidemann3836 4 หลายเดือนก่อน

    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.

  • @gomesbruno201
    @gomesbruno201 4 หลายเดือนก่อน +9

    serious question here: are you guys using bun in production? I'm looking for some reason to not do it

    • @pranitmane
      @pranitmane 4 หลายเดือนก่อน +2

      I've seen some projects using it, but still large scale projects are not using it..

    • @shapelessed
      @shapelessed 4 หลายเดือนก่อน

      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.

    • @RonnieDenzel
      @RonnieDenzel 4 หลายเดือนก่อน +5

      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

  • @ProfMonkeys
    @ProfMonkeys 4 หลายเดือนก่อน

    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.

    • @seanthesheep
      @seanthesheep 4 หลายเดือนก่อน

      @@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

  • @ovflowd
    @ovflowd 4 หลายเดือนก่อน +2

    FYI, Theo, you can run the latest version of `master` of node with `npx node-nightly`

  • @marsharbour5906
    @marsharbour5906 4 หลายเดือนก่อน +3

    This is exactly how python handles annotations.

  • @MobiusCoin
    @MobiusCoin 4 หลายเดือนก่อน +11

    Do the video on the .ts thing! I remember the Fireship video on it and I just did not understand it.

  • @SandroCaya
    @SandroCaya หลายเดือนก่อน

    Great analysis, thank you! A bit off-topic, but I wanted to ask: I have a SafePal wallet with USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). Could you explain how to move them to Binance?

  • @ego-lay_atman-bay
    @ego-lay_atman-bay 4 หลายเดือนก่อน +8

    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.

    • @i3cheese
      @i3cheese 4 หลายเดือนก่อน

      Actually they are not ignored. They are evaluating and accessible at runtime. But yes, they are not checked for type correctness

    • @i3cheese
      @i3cheese 4 หลายเดือนก่อน +1

      You can check how fastapi or pydantic implemented

  • @akam9919
    @akam9919 4 หลายเดือนก่อน +2

    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
      @bobwilkinsonguitar6142 4 หลายเดือนก่อน

      Did you watch the video? It just strips types, you could almost just use a linter

    • @dealloc
      @dealloc 4 หลายเดือนก่อน +1

      @@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.

  • @protocol6
    @protocol6 4 หลายเดือนก่อน +5

    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.

  • @IronMaidzen
    @IronMaidzen 4 หลายเดือนก่อน +1

    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.

    • @hydrangea-sh
      @hydrangea-sh 4 หลายเดือนก่อน

      You use bun at work? I didn’t realize it was production ready!

  • @Nik-fl7lv
    @Nik-fl7lv 4 หลายเดือนก่อน

    Hey Theo, how do you add padding to your extensions icons in the VSCode?

  • @FlybelFideos
    @FlybelFideos 4 หลายเดือนก่อน +1

    .ts files are still a transport stream container format in my mind

  • @shaunfitzgibbon
    @shaunfitzgibbon 4 หลายเดือนก่อน

    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

  • @FeLiNe418
    @FeLiNe418 4 หลายเดือนก่อน

    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?

  • @l00k210
    @l00k210 4 หลายเดือนก่อน

    What about emitDecoratorMetadata? :(
    What about paths (mapping)?

  • @Iammrunkown
    @Iammrunkown 4 หลายเดือนก่อน

    The Node team is going nuts.

  • @jeremynewman7658
    @jeremynewman7658 4 หลายเดือนก่อน

    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.

  • @aghileslounis
    @aghileslounis 4 หลายเดือนก่อน

    Hey Theo, tell us what do you think about Cursor IDE? For me, it's quite dogshiet tbh.

  • @kamilmodest
    @kamilmodest 4 หลายเดือนก่อน

    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 :(

  • @barneylaurance1865
    @barneylaurance1865 4 หลายเดือนก่อน

    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?

  • @luketurner314
    @luketurner314 4 หลายเดือนก่อน +1

    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?

    • @seanthesheep
      @seanthesheep 4 หลายเดือนก่อน +1

      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

  • @barneylaurance1865
    @barneylaurance1865 4 หลายเดือนก่อน

    This isn't in an actual node release just yet, is it?

  • @KaiHenningsen
    @KaiHenningsen หลายเดือนก่อน

    This is one of these videos where I think Theo got the wrong end of the stick. The whole reason I use typescript is that I want to find my errors early. Why would I want to generate JS without checking, then? tsc is certainly not the slowest thing I'm waiting for.

  • @thegrumpydeveloper
    @thegrumpydeveloper 4 หลายเดือนก่อน

    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

  • @malamhari_
    @malamhari_ 4 หลายเดือนก่อน

    I wonder what browser Theo using here? It's pretty dope!

    • @binamralamsal
      @binamralamsal 4 หลายเดือนก่อน +1

      Arc

    • @malamhari_
      @malamhari_ 4 หลายเดือนก่อน

      @@binamralamsal you're right, thanks

  • @AlexandreMoreauLemay
    @AlexandreMoreauLemay 4 หลายเดือนก่อน +1

    But it doesn't. It doesn't have transformative support for Enum and other typescript generated code.

  • @sealone777
    @sealone777 4 หลายเดือนก่อน +16

    Now when will browser adapt typescript natively……

    • @simpingsyndrome
      @simpingsyndrome 4 หลายเดือนก่อน +5

      I think in year 2077 to support

    • @NateVolker
      @NateVolker 4 หลายเดือนก่อน +6

      The TC39 ECMAScript proposal for type annotations is in Stage 1 - Theo talks about it in the video

    • @trappedcat3615
      @trappedcat3615 4 หลายเดือนก่อน

      ​@@NateVolkerStage 1 near 2 years? Seems doa.

    • @dealloc
      @dealloc 4 หลายเดือนก่อน

      @@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.

    • @trappedcat3615
      @trappedcat3615 4 หลายเดือนก่อน

      @@dealloc Totally agree. I've lost hope for it, but anything can happen.

  • @SanderCokart
    @SanderCokart 4 หลายเดือนก่อน

    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.

  • @Md_sadiq_Md
    @Md_sadiq_Md 4 หลายเดือนก่อน +1

    Video recommendation : Why Typescript with Sequelize suvks

  • @afterschool2594
    @afterschool2594 4 หลายเดือนก่อน

    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.

  • @Candyapplebone
    @Candyapplebone 4 หลายเดือนก่อน +1

    Thank fucking god

  • @HypeLevels
    @HypeLevels 4 หลายเดือนก่อน +1

    pog?

  • @Bricefriha
    @Bricefriha 4 หลายเดือนก่อน

    this video gave me want to use Deno

  • @keenoogodlike
    @keenoogodlike 4 หลายเดือนก่อน +9

    Browsers should support TypeScript for the sake of humanity.

    • @RasmusSchultz
      @RasmusSchultz 4 หลายเดือนก่อน +2

      we have bandwidth to waste.

    • @nullbeyondo
      @nullbeyondo 14 วันที่ผ่านมา

      No. Browsers have nothing to do with what you code. You can even use Rust and compile to WASM if you want so how are browsers even related to this? Weird take.

    • @keenoogodlike
      @keenoogodlike 13 วันที่ผ่านมา

      @@nullbeyondo list the websites that use wasm and still make money

  • @YesInMyBackyard
    @YesInMyBackyard 4 หลายเดือนก่อน

    coffeescript should have fun

  • @linaori
    @linaori 4 หลายเดือนก่อน

    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.

    • @barneylaurance1865
      @barneylaurance1865 4 หลายเดือนก่อน

      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.

  • @gabrielbianchi2246
    @gabrielbianchi2246 4 หลายเดือนก่อน

    Do a video on .ts and .js on imports
    I never do that :P

  • @AndrewErwin73
    @AndrewErwin73 4 หลายเดือนก่อน

    bun baby!

  • @wattsfield1889
    @wattsfield1889 4 หลายเดือนก่อน

    Yees please make a vid about the .tsx extension thing

  • @madmaxdev
    @madmaxdev 4 หลายเดือนก่อน

    Why doesn't javascript come with native type system?

    • @seanthesheep
      @seanthesheep 4 หลายเดือนก่อน

      Because letting browsers statically enforce types is a forward compatibility and cross browser compatibility pain

    • @spartanatreyu
      @spartanatreyu 4 หลายเดือนก่อน

      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).

  • @benheidemann3836
    @benheidemann3836 4 หลายเดือนก่อน

    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).

    • @spartanatreyu
      @spartanatreyu 4 หลายเดือนก่อน

      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.

    • @benheidemann3836
      @benheidemann3836 4 หลายเดือนก่อน

      @@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.

  • @pandaunicorn2791
    @pandaunicorn2791 4 หลายเดือนก่อน

    I think i will just wait for internet2.0 and hope ecmasceipt will be somewhat normal

  • @DominikZogg
    @DominikZogg 4 หลายเดือนก่อน

    ts-node using swc is fine.

  • @JLarky
    @JLarky 4 หลายเดือนก่อน

    "keep using Bun"

  • @zoso25
    @zoso25 4 หลายเดือนก่อน

    So 13:35 is where he has his constipated faces catolouged.

  • @Maxjoker98
    @Maxjoker98 4 หลายเดือนก่อน

    Here I was, thinking that Javascript is the language of choice for the Javascript ecosystem, but according Theo it's TypeScript now. Oh well!

  • @kisaragi-hiu
    @kisaragi-hiu 4 หลายเดือนก่อน

    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.

  • @dehrk9024
    @dehrk9024 4 หลายเดือนก่อน

    Theo if you struggle with sleep in summer you should maybe buy a climate device:) you seem to not talk overwhelming fast anymore🤣

  • @ovflowd
    @ovflowd 4 หลายเดือนก่อน

    PSA: Node's implementation uses SWC.

  • @vercieli
    @vercieli 4 หลายเดือนก่อน

    Should we call it Node.ts

  • @GrimaldGorb
    @GrimaldGorb 4 หลายเดือนก่อน

    wdym?

  • @MonteLogic
    @MonteLogic 4 หลายเดือนก่อน

    WHAT!!!

  • @JC-yy5nf
    @JC-yy5nf 4 หลายเดือนก่อน +9

    My Benis hurts

  • @pengurrito7136
    @pengurrito7136 4 หลายเดือนก่อน

    so... add enums and namespaces to javascript.

  • @AD-wg8ik
    @AD-wg8ik 4 หลายเดือนก่อน

    tsc !

  • @affanyunas7693
    @affanyunas7693 4 หลายเดือนก่อน

    all code safe before compiled to js code. ts moment

  • @Fanaro
    @Fanaro 4 หลายเดือนก่อน

    Damn, TypeScript is that old...

  • @Zagoorland
    @Zagoorland 4 หลายเดือนก่อน

    You look more and more 80s

  • @ashmw2724
    @ashmw2724 4 หลายเดือนก่อน +3

    I'm always not first

    • @trappedcat3615
      @trappedcat3615 4 หลายเดือนก่อน +3

      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.

  • @zeocamo
    @zeocamo 4 หลายเดือนก่อน

    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.

  • @karappo_kun
    @karappo_kun 4 หลายเดือนก่อน +1

    So kinda like Python I guess.

  • @AndrewErwin73
    @AndrewErwin73 4 หลายเดือนก่อน +2

    "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.

  • @zx-sy1qh
    @zx-sy1qh 4 หลายเดือนก่อน

    The Simpsons already did this... sorry I mean Bun !!!

  • @VincentJenks
    @VincentJenks 4 หลายเดือนก่อน

    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.

  • @OryginTech
    @OryginTech 4 หลายเดือนก่อน +3

    I’m always first

    • @OryginTech
      @OryginTech 4 หลายเดือนก่อน

      And there’s nothing you can do about that.

    • @luis10barbo
      @luis10barbo 4 หลายเดือนก่อน

      the bot was first LMAO

    • @t3dotgg
      @t3dotgg  4 หลายเดือนก่อน +15

      You beat most of the spam bots, impressive

    • @luigibattaglioli6026
      @luigibattaglioli6026 4 หลายเดือนก่อน

      Want a cookie?

  • @PostNoteIt
    @PostNoteIt 4 หลายเดือนก่อน

    It's not "official typescript support" but rather "official typescript ignorance".

  • @Georgggg
    @Georgggg 4 หลายเดือนก่อน +1

    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.

  • @ivanmaglica264
    @ivanmaglica264 4 หลายเดือนก่อน

    Uff... binary blobs in code seems to me as an opportunity for another XZ supply chain attack.

  • @_D3adB0y_
    @_D3adB0y_ 4 หลายเดือนก่อน

    I still prefer vanilla js... There is so much extra I gotta type with typescript. It's annoying. *insert Old man yells at computer*

  • @quinndirks5653
    @quinndirks5653 4 หลายเดือนก่อน +3

    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.

    • @0.amonymous
      @0.amonymous 4 หลายเดือนก่อน +3

      Bro complaining about running "TSC", a build step of 3 seconds (10 seconds if on a huge project) lol

    • @jackzugna5830
      @jackzugna5830 4 หลายเดือนก่อน +1

      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.

    • @101Mant
      @101Mant 4 หลายเดือนก่อน +1

      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.

  • @Resistance_is_futile1337
    @Resistance_is_futile1337 4 หลายเดือนก่อน +4

    Typescript is unreadable

    • @AndDal-l7i
      @AndDal-l7i 4 หลายเดือนก่อน +1

      😂 no way you think no type checking is better

  • @safarl45
    @safarl45 4 หลายเดือนก่อน +3

    Typescript is for noobs LOL

  • @tosho_ait
    @tosho_ait 2 วันที่ผ่านมา

    TS is just crap. If you want to work in a crappy ecosystem just use Java, don't destroy JS!

  • @JTWebMan
    @JTWebMan 4 หลายเดือนก่อน

    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.

  • @chunkyMunky329
    @chunkyMunky329 4 หลายเดือนก่อน

    Boring

  • @ShootingUtah
    @ShootingUtah 4 หลายเดือนก่อน

    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.

    • @andrewps339
      @andrewps339 4 หลายเดือนก่อน +8

      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.

    • @101Mant
      @101Mant 4 หลายเดือนก่อน +1

      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?

    • @Frankablu
      @Frankablu 4 หลายเดือนก่อน

      @@101Mant Yes, yes I do. Because I know that type related errors are exceptionally uncommon. Nope, I demand actual documentation.

  • @vitalysuper3193
    @vitalysuper3193 4 หลายเดือนก่อน

    Node.ts

  • @ИванРагозин-я8я
    @ИванРагозин-я8я 4 หลายเดือนก่อน

    Bun

    • @SunsetTechuila
      @SunsetTechuila 4 หลายเดือนก่อน

      Bun

    • @copperbadge1
      @copperbadge1 4 หลายเดือนก่อน +2

      Buuuuuuuun. [dramatic stare into the camera]

  • @ihateheartbreak
    @ihateheartbreak 4 หลายเดือนก่อน

    just use go