Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Microsoft

Node.js 'Type Stripping' for TypeScript Now Enabled by Default (hashnode.dev) 63

Posted by EditorDavid from the not-my-type dept.
The JavaScript runtime Node.js can execute TypeScript (Microsoft's JavaScript-derived language with static typing).

But now it can do it even better, explains Marco Ippolito of the Node.js steering committee: In August 2024 Node.js introduced a new experimental feature, Type Stripping, aimed at addressing a longstanding challenge in the Node.js ecosystem: running TypeScript with no configuration. Enabled by default in Node.js v23.6.0, this feature is on its way to becoming stable.

TypeScript has reached incredible levels of popularity and has been the most requested feature in all the latest Node.js surveys. Unlike other alternatives such as CoffeeScript or Flow, which never gained similar traction, TypeScript has become a cornerstone of modern development. While it has been supported in Node.js for some time through loaders, they relied heavily on configuration and user libraries. This reliance led to inconsistencies between different loaders, making them difficult to use interchangeably. The developer experience suffered due to these inconsistencies and the extra setup required... The goal is to make development faster and simpler, eliminating the overhead of configuration while maintaining the flexibility that developers expect...

TypeScript is not just a language, it also relies on a toolchain to implement its features. The primary tool for this purpose is tsc, the TypeScript compiler CLI... Type checking is tightly coupled to the implementation of tsc, as there is no formal specification for how the language's type system should behave. This lack of a specification means that the behavior of tsc is effectively the definition of TypeScript's type system. tsc does not follow semantic versioning, so even minor updates can introduce changes to type checking that may break existing code. Transpilation, on the other hand, is a more stable process. It involves converting TypeScript code into JavaScript by removing types, transforming certain syntax constructs, and optionally "downleveling" the JavaScript to allow modern syntax to execute on older JavaScript engines. Unlike type checking, transpilation is less likely to change in breaking ways across versions of tsc. The likelihood of breaking changes is further reduced when we only consider the minimum transpilation needed to make the TypeScript code executable — and exclude downleveling of new JavaScript features not yet available in the JavaScript engine but available in TypeScript...

Node.js, before enabling it by default, introduced --experimental-strip-types. This mode allows running TypeScript files by simply stripping inline types without performing type checking or any other code transformation. This minimal technique is known as Type Stripping. By excluding type checking and traditional transpilation, the more unstable aspects of TypeScript, Node.js reduces the risk of instability and mostly sidesteps the need to track minor TypeScript updates. Moreover, this solution does not require any configuration in order to execute code... Node.js eliminates the need for source maps by replacing the removed syntax with blank spaces, ensuring that the original locations of the code and structure remain intact. It is transparent — the code that runs is the code the author wrote, minus the types...
"As this experimental feature evolves, the Node.js team will continue collaborating with the TypeScript team and the community to refine its behavior and reduce friction. You can check the roadmap for practical next steps..."

Node.js 'Type Stripping' for TypeScript Now Enabled by Default More | Reply

Node.js 'Type Stripping' for TypeScript Now Enabled by Default

Comments Filter:
  • What then becomes the point of writing typescript in the first place if you are just going to strip it at runtime with no type checks? I guess you still get the benefit of type checks in your IDE, but I still feel like compiling your TS before running will continue to be the way most devs go as there are other benefits of doing so.

    • There's still a build/compile step with most modern frameworks. If you're using React for instance, you *have* to transpile all that JSX stuff into JS, because the browser won't know what to do with all that HTML in the JS.

      This is just about letting your code run *after* all the build/type check steps you've already run ... or (in a less serious project, where maybe all you care about is your IDE warnings) ... even if they haven't.

      • Strictly speaking correct.
        But the browser can - aka the programmer can make the browser - load the JSX compiler into the browser and compile it on the user side.

        This is just about letting your code run *after* all the build/type check steps you've already run
        Hm, I understood it the other way around. They want to have most of the compiler toolchain run on the server side under the orchestration of noce.js. And the developer can just deploy TypeScript - did I understand it wrong?

    • Well, for me, this means I can work with someone who wants to use TS without issue. Before this change, my Node.js code doesn't have a build step, so if someone comes in and tries to add TS to the project, they are demanding I now slow myself down by rebuilding all the time. This is unacceptable. And this is what MS wants.

      And to be clear, TS doesn't enforce anything, so it's exactly the same as running it stripped through Node.js.

    • What then becomes the point of writing typescript in the first place if you are just going to strip it at runtime with no type checks?

      Well, that's ultimately what any compiler does. Machine code for any mainstream CPU has no type checking.

      • Umm, compilers dont operate at runtime and they do type checking during compilation, they dont just ignore the types.

        • Your reading comprehension skills are well below par. Go back and read the OP and my reply to try to get at least an inkling of what we were discussing.

          • Re: (Score:2)

            by Viol8 ( 599362 )

            My comprehension is fine thanks. You're conflating apples and oranges.

            • Where did I say compilers operate at runtime? I didn't. You simply got an idea in your head that had nothing whatsoever to do with what you read.

              I told you to carefully re-read the messages, not just come back and re-assert your misconceptions.

    • What is the point of writing in ANY programming language ifit always ends up in C -> machine code where types are basically groups of bits?

  • Back to Java again (Score:4, Interesting)

    by AlanObject ( 3603453 ) on Sunday January 19, 2025 @12:09PM (#65101089)

    TypeScript has reached incredible levels of popularity and has been the most requested feature in all the latest Node.js surveys.

    I find irony in the fact that for many years that Java was derided and dismissed for being type-strict in favor of Javascript and Python that were fully type free. I never understood the issue, except for comments like "Python doesn't insult your intelligence" by telling you what to do or something.

    Now all these wonderful languages are getting layers of specification and processing added onto them that makes them fully typed-checked -- just like Java. Javascript/ECMAscript has Typescript and CoffeeScript and Python evolved conventional libraries like Typings, Pydantic and @dataclass.

    Perhaps the strict approach that Java took was right to begin with, no?

    • Maybe. Typescript is excellent for large applications, but I still think strictly typed JS for all use cases would be overkill and a huge mistake.

      • Maybe. Typescript is excellent for large applications, but I still think strictly typed JS for all use cases would be overkill and a huge mistake.

        Define "large". I'm working on a backend TS project that is at ~20K lines of code (what I'd call "small+" or not quite medium sized) and it's a pain and causing issues as we grow. If I were assigned to work on a TS project that I'd call large (100K+ lines), I think I'd walk away and look for a different job. My view is that the type part of the language is fairly decent and helpful. The real problems come from the Javascript foundation underneath, but since TS has to have the JS parts, it's really a bad cho

    • Re:Back to Java again (Score:5, Interesting)

      by machineghost ( 622031 ) on Sunday January 19, 2025 @12:36PM (#65101139)

      It's all about the tooling.

      TypeScript lets Javascript code get all the benefits of Java IDEs: for instance, you can autocomplete arguments (and then have your IDE yell at you if you put the wrong type in them). Javascript itself lacks the information to do that, but virtually every major library provides it (in the form of type files).

      What this amounts to is that the average JS dev *doesn't* have to use types at all, and they can still leverage all those tooling benefits. If they want those tooling benefits in their project, they can adopt Typescript ... but even then they can decide how strict they want to be about adopting it (eg. some teams allow the "any" type, some don't).

      At the end of the day we have the full flexibility to use whichever level of type strength we want, and still get most of the benefits of typing regardless ... unlike Java devs who are stuck in "super-strict" typing, 100% of the time (unless you use Groovy or JRuby or something).

      • "TypeScript lets Javascript code get all the benefits of Java IDEs"

        So does JSDoc, and you get it without build bloat or non-standard code.

        • JS Doc is more limited in what it can express, so it won't be an option for everyone ... but yes, and this is just another example of:

          we have the full flexibility to use whichever level of type strength we want

      • JavaScript has the same benefits from the IDE, as TypeScript or Java.
        There is no difference in auto completion, etc.

    • Wait, you're comparing a OO based strictly typed language that doesn't run in the browser to a prototypal delegation based loosely typed language that does?

      CoffeeScript was an abomination, BTW.

      • CoffeScript was like a good kick unter the pants It is as abomination in itself but did wonders for the future career of the stagnant stubborn JavaScript standards committee. All of CoffeeScripts good features (except for indentation-ala-
        Python) was incorporated into JS leaving a much better language. You can see CoffeeScripts bootprint under JavaScripts butt all the time now

        One thing about CoffeeScript, it became popular when JQuery was a big deal and some syntax and features catered for that.

      • CofeeScript is a very nice language.

        If you do not like it, you do not need to use it.'

        But C++ perhaps is an abomination, or JCL.

        However I find it a bit insulting towards the inventors/implementors to call a language and abomination.

    • If money is on the line, types are your friends (Score:4, Insightful)

      by Somervillain ( 4719341 ) on Sunday January 19, 2025 @01:23PM (#65101223)

      TypeScript has reached incredible levels of popularity and has been the most requested feature in all the latest Node.js surveys.

      I find irony in the fact that for many years that Java was derided and dismissed for being type-strict in favor of Javascript and Python that were fully type free. I never understood the issue, except for comments like "Python doesn't insult your intelligence" by telling you what to do or something.

      Now all these wonderful languages are getting layers of specification and processing added onto them that makes them fully typed-checked -- just like Java. Javascript/ECMAscript has Typescript and CoffeeScript and Python evolved conventional libraries like Typings, Pydantic and @dataclass.

      Perhaps the strict approach that Java took was right to begin with, no?

      Having done massive projects in Java, Python, node.js and others...yeah, Java is the leader for a reason. It's always been fashionable to shit on Java...at least in the last 25 years...and without a doubt, there are opportunities for improvement. However, the top contenders have all been far worse and have some HORRIBLE design decisions.

      If you're the only one who will ever work with it?...do what you like...node.js is fine..so is python, brainfuck, or go find something rarer like ada or fortran...no one cares about your playtime. When money is on the line?...well, it's honestly rare to have the same person maintain the app for all of perpetuity...thus you need to plan ahead.

      As a greying veteran of web-facing development, here's the lifecycle of success....Some sharp guy writes an amazing app that's very popular. Investors love it...funding pours in...the product is a success. That sharp guy starts committing less and less to the project. He gets promoted...retires...or goes to a fresh new challenge somewhere else. However, even if an app is stable, it's never DONE. There's always new features being added or minor bugs found or...most importantly...the dreaded lib updates for security patches. FEW libraries take backwards compatibility seriously...that's just a consequence of open source. Google's JavaScript libs change signatures all the time. The Spring Framework is HEINOUS about breaking methods for no clear reason between major releases. Only Java EE took it seriously...and well...they fell out of fashion. Python libs have the same issue as does every JavaScript lib I've ever heard of. It may take 5 years, but you will need to refactor code in order to keep it patched

      Now...with a compiler?...that's easy. When Spring breaks something, I find it instantly. It is annoying, but it takes up a day...maybe 2 of my time....and then it's done forever. When Google breaks one of their many JavaScript libs?...well...I hope you wrote good unit tests? For ever upgrade I've been a part of of seen from a distance, if a method signature changes, you're losing days hunting down every reference and behavior change if the application is of significant size.

      All developers write REALLY GOOD unit tests, right? No developer has ever rushed a product to meet a deadline without PERFECT Unit tests right?...such a thing is unheard of!!!

      Yup..all developers write good unit tests

      All developers comment their code as well, right?

      So yeah, the genius who wrote your app has either left the company or is promoted so high he hasn't touched it for 5 years. Now it's your problem to update all the dependencies. In Java? I can change one line in a maven file and tell you everything that broke. Can you do that in Python? What about node.js?...the answer is no...you'll be spending a LONG time combing through finding all the places you need to adjust.

      OK, so that's my opinion and explanation and reasoning, but don't just take my word for it...I work for a major tech company that has major projects in every major language under the sun. We've got projects in Java, python, c, node.js,

      • The python and node.js teams ALWAYS miss their deadlines...by far more than the Java/C/C++/Go teams. They have more bugs...they have more issues...and this is not unique to my company. This is my experience across many companies and matches the experiences of every developer I talk to.

        That is not to blame on the language(s) - you are simplifying to much.

        All developers write REALLY GOOD unit tests, right? This nails it more.
        Unit tests - as they are plaguing modern development (yes, in Java they are 85% or mo

        • Fix the damn engine! Your damn problem is not the team, it is a broken engine/process - no maintenance - or not good enough (aka no teaching/training to the team), no evaluation if that damn ship actually is worth it (switch language?) and so on.

          Simple response: why does the Java, C++, C, Kotlin, Scala, and Go teams do a much better job meeting their deadlines and deliverables? If the engine is broken, why is it so much more broken for them?

          Look, you have strong opinions that may be right or wrong, but a statement like

          Then obviously: the dead lines are set wrong!!! (Who actually is still working with deadlines instead of agile? No idea. I would quit instantly).

          ...well...you come off like a Primadonna. The deadlines are negotiated with the teams based on their estimates, but no...money is not infinite. We're a profitable tech company. We need to stay profitable to pay employees, ex

          • Simple response: why does the Java, C++, C, Kotlin, Scala, and Go teams do a much better job meeting their deadlines and deliverables? If the engine is broken, why is it so much more broken for them?
            I do not know. As I do not know your team, nor your project.

            The rest of your post simp!y supports my points: they are bad at estimating.

            Does not matter what (type of) language you use. You should be able to somehow adequately estimate your time?

            If the deadlines are "generous" does not matter. The time you need i

            • You're missing the point. The point the parent post is trying to make is that the reason they are bad at estimating is inherent to the language. This kind of makes sense as we all know that the later a bug is caught, the more it costs to fix. Therefore bugs being caught by the compiler are cheaper than bugs caught at runtime. I suspect the reason those teams estimates are far worse is because their margin for error gets blown out of the water because the language are not helping them avoid, catch and diagno

      • Now...with a compiler?...that's easy. When Spring breaks something, I find it instantly. /quote

        Ugh. I have to disagree with this. While Java itself is well-typed, this existence of reflection has been abused (and hence the benefits of strong typing are no longer there). My personal experience with Spring/Hibernate, etc... is it is just about impossible to find the root cause of many, many problems without a whole lot of experience with the technologies. I recently was tangentially on a project to upgrade a project from an old version of Spring to a new one... and (to put it kindly), the migration was vastly underestimated. Part of that was due to changes in the API - but that was just fixing the compilation. We still had a huge amount of runtime errors - precisely because of all the reflection. It was painstakingly difficult to find all those problems.

        • Now...with a compiler?...that's easy. When Spring breaks something, I find it instantly. /quote

          Ugh. I have to disagree with this. While Java itself is well-typed, this existence of reflection has been abused (and hence the benefits of strong typing are no longer there). My personal experience with Spring/Hibernate, etc... is it is just about impossible to find the root cause of many, many problems without a whole lot of experience with the technologies. I recently was tangentially on a project to upgrade a project from an old version of Spring to a new one... and (to put it kindly), the migration was vastly underestimated. Part of that was due to changes in the API - but that was just fixing the compilation. We still had a huge amount of runtime errors - precisely because of all the reflection. It was painstakingly difficult to find all those problems.

          Your point is valid, but I will counter with this...how long did it take you to find? Spring dependency violations SUUUUCK...but...I've found them all on startup. Spring usually eagerly loads things and my unit tests catch all of them quickly. That's not the case with Python/node.js. So while they may take longer to fix than we'd like, which is your point...they're found quickly.

          When Google changed one of their backed JS libs...they just changed various function signatures...not sure the reason why.

    • Perhaps the strict approach that Java took was right to begin with, no?

      No. Look at all the slow, bloated "bean" frameworks that had to be created for Java, which all use runtime reflection in order to get around its brittle type system.

      • Typing is only "brittle" for playpen coders who dont know what they're doing.

        • No True Scotsman would ever use Java Beans.

          • Well
            assuming you mean an irish coffee, you are probably right.

            Regarding Java - the programming language - basically every Java data class is a Java Bean - how ever in general no one anymore implements "property changed" stuff, as that is only useful (if at all) in Desktop pr mobile App conext.

      • That was because JavaScript s type system was very rigid. To compare TypeScripts typing to that in Java is like comparing a Ferrari to a Model T Ford

    • ```
      "Python doesn't insult your intelligence" by telling you what to do or something.
      ```

      Except if you hit that spacebar and break your loops and stand a 5% chance of seeing it.

      But a typed language with no definition of how types work? Oh, lordy.

      I was surprised to hear in a lunduke video a few months back that Java complied only uses 2.5x as much cpu and energy as the same benchmarks coded in c. All of the scripting languages were 60x (Perl) worse or worse than that. 75x for python, etc.

      • To make Java use 2.5x the time/energy as C, then you need an pretty odd used case.
        In real world examples, they are basically the same.
        And to be real the same: you have to compare Java with a similar C++ program'
        It is kind of impossible to have a Java program without classes and free floating functions, like C.

        • To make Java use 2.5x the time/energy as C, then you need an pretty odd used case.
          In real world examples, they are basically the same.

          Wrong. There's actually been extensive research on this, mostly done by Amazon who is trying to cut their energy costs.

          And to be real the same: you have to compare Java with a similar C++ program'

          And it's been done, extensively.

          https://aws.amazon.com/blogs/o... [amazon.com]

          Java consumes roughly twice as much energy as C, and that's not even counting the cost of the JRE itself. Also, C++ is 30% less energy efficient than C.

          The only language that compares well with C in terms of energy efficiency is in fact Rust.

          It is kind of impossible to have a Java program without classes and free floating functions, like C.

          That's because Java sucks. Shit, even C# allows this. But for whatever reason you've g

          • To consume twice as much energy, you need to use double the time.
            Not even you can be so stupid not to grasp that.

            Java is not half as fast as C, it is more or less the same.

            No idea about your C# comment. C# started as a Java clone, the original .Net VM was a Java VM clone. Except for allowing unsigned primitive types. Yes, every bytecode was the exact same one. They did not even change the enums that represented byte codes.

            If you actually know nothing about a topic, you perhaps should simp!y stay silent?

            • To consume twice as much energy, you need to use double the time.

              No, that's definitely not true. Aside from what I already linked, here's one you might be more willing to listen to since it's published by somebody else in your reich:

              https://www.adesso.de/en/news/... [adesso.de]

              The data is all there, see for yourself, though the non-reich version it's based on is far more comprehensive, but you've already shown that you don't trust anything outside of your reich. As an example to this, your linkedlist driven code is going to be less energy efficient not only because it takes longer t

    • The problem is that the majority of vocal users are not the competent or wise ones... eventually at some point the committees are run by incompetents trying to please the fool demographic. This is how stuff degrades over time. Problems solved get undone and repeated creating an endless cycle which produces new languages, fads, etc. Mistakes accumulate permanently or you become "rigid" and "old" causing the fools to migrate so they can be free to be fools. Older people get grumpy and "conservative" for good

    • t get it. How do you run Java in a browser?

      • There wasch time when Java did run in a Browser. It was called an Applet

        • Running an Applet is not "running in the browser".
          You never had access to the DOM from an Applet. Unless you trickily tricky routed that via JavaScript.

        • Applet support was discontinued in 2015, and for good reason. And even when they were supported, they weren't actually running in the browser context, they were simply a separate app launched by the browser. The Applet had no access to the DOM or browser storage. It *did* have unlimited access to your local machine, which (unlike JavaScript) made it a huge security risk.

          So no, not really a way to run Java in a browser. This ability remains JavaScript's primary advantage: it runs on any hardware, any browser

      • You use webassembly... https://www.baeldung.com/java-wasm-web-assembly

        • That's all fine and good, for the set of Java language features supported by the transpiler.

          DOM access isn't among those things, because the Java bytecode, or JRE itself, doesn't know about the browser DOM. Same goes for session cache and storage.

          Finally, there are always tons of edge cases with transpilers. They come out of nowhere and bite you when you're not expecting it, and you end up spending lots of time trying to figure out why your code won't work, when really it's a scenario that the transpiler it

    • Typescript’s type system is much more advanced and better than the one in Java it is hard to overstate.

    • Java was derided and dismissed for being type-strict
      Java was never dismissed for that.
      It was dismissed to be over verbose.
      Needing to write public everywhere where things obviously are "supposed to be" public, and private everywhere where things supposedly are private - instead of having sensible defaults and falling back to needing a keyword when it does not fit.
      See Kotlin and Groovy. Everything is opposite around than Java. You add a public to a thing that is private by default, and that is not even 99% of

    • Personally I find Java too many different files and then a bit slow to startup and generally sticky to run (yet another VM to size :-( ). However, I'd take that any day of the week over the steaming pile of turds that is node.js. Anyone chosing Node for production wants their head examining.

      What I will give Node is that it's very handy for building "compiled" apps (React/Angular/Vue, etc). So as a dev tool, it's good, but my god, never, ever run that crap in production.

    • I understand the aversion to typing - but such projects are typically small and/or academic examples IMHO.

      I work in a team that maintains a fairly large Angular webapp - over a dozen modules, and components multiple 10s if not over 100 by this time (I should go count the stuff sometime...) One benefit I see oh, about every day, regarding typing is the self-documenting aspect of it. It gets harder and harder to know exactly what you need to put into a function or get out of it, as data get passed around.

      Obv

  • Deno is the new Node (Score:2, Insightful)

    by Qbertino ( 265505 )

    It fixed everything that was borked with Node and supports native TS.

    I recommend Deno for anything mission critical. Node is outdated.

  • Divisive issue (Score:3)

    by Going_Digital ( 1485615 ) on Sunday January 19, 2025 @02:37PM (#65101389)
    It seems that the debate over strict types is never going to be reconciled. Personally I would like to see TypeScript run natively in browsers and simply run.ts files with strict typing and .js without. It would give people the freedom to choose and remove the transpiring step from TS.

    • Typescript is just a band-aid, and a hassle-prone one at that.

      I'd rather have actual types built-in to the language, rather than an author-time type system that gets stripped away during compilation.

  • Now if I could just copy and paste snippets of Typescript into the browser console to test them out

  • Coffee Script is its own language, see: https://coffeescript.org/#over... [coffeescript.org]
    It transpiles to Javascript. It is a bit inspired by Smalltalk and Python.

    While TypeScript is its own language too, it is basically an enhanced JavaScript with static type checking. The syntax and most language constructs are just the same as JavaScript. It looks surprisingly (or not so surprising) like Java, too - or more precisely, Kotlin.

  • The last four projects I led all had typescript frameworks. I would never have chosen that, but I was not the architect. But because I spent three decades in development I like to keep up on what we're doing.

    The ocean of dependency problems, endless security warnings, and the absolutely impenetrable spiderweb of nonsensical complexity that comes built into even trivial efforts is just so stupid I'm glad that I don't have to touch it.

    I thought jDeveloper 10 back in the day, with its oceans of horrible xml, r

    • That's a key rule professionals go by. I'd do very much the same with anything, especially technologies that like reinventing the wheel, such as the Jamstack crew. But I'd do _exactly_ the same with Java.

      The upside of the Jamstack vis-a-vis Java is that it's document-centric, open standard and cross-platform from the get-go and everybody has a runtime for it in their pocket. URLs are also a very quick and easy, flat out trivial means of distribution. ... And port 80 is always open. ... And so forth.

      If I had

Slashdot Top Deals

"Pay no attention to the man behind the curtain." -- Karl, as he stepped behind the computer to reboot it, during a FAT

Close