4 ms·

The idea from the proposal is that types are used by other tools to type-check and runtimes would ignore them. It's not final yet but it's very likely that in f

by msoad 2y ago

The idea from the proposal is that types are used by other tools to type-check and runtimes would ignore them. It's not final yet but it's very likely that in future you can `node -e 'function foo(arg: string) {}; foo(42)'` but if your code has `enum` in it, Node.js or browser will throw an error

diggan 2y ago
But it's not specifically about enums, but anything from TS that generates code. You would need to stop using enums, parameter properties, namespaces (called out by the proposal) and probably more. Seems weird to me to decide you're OK with the build step and all the other complexity TS adds, but using enums is too much, because maybe in the future JS runtimes might be able to strip away types for you without a build-step. But we all have different constraints and use cases, I suppose it does make sense for what you're building.
- cbovis 2y ago
  It's not a hypothetical, it's here in Node 23: https://nodejs.org/docs/latest/api/typescript.html#typescript-features https://nodejs.org/docs/latest/api/typescript.html#typescrip....
  - diggan 2y ago
    Speaking about the specification, it's a proposal. Yes, some run ahead and implement proposals under experimental flags, doesn't make it any more/less hypothetical as the proposal can still be rejected rather than progressing.
    - mistercow 2y ago
      Come on, now. > maybe in the future JS runtimes might be able to strip away types for you without a build-step. You can't backpedal from that to "speaking about the specification". It's not future JS runtimes. It's a thing you can take advantage of right now.
- mistercow 2y ago
  I think the difference is just that (IME at least) those other features seem a lot more rarely used than enums. Enums are a feature that maps onto a common language concept, and which new TS devs reach for because they give first class support to a very common need. And the fact that you can usually do what they do more elegantly with other features is not as obvious, particularly because you can't do it the same way in a lot of other popular typed languages. Parameter properties and namespaces, on the other hand, are kind of wonky TS specific features that nobody expects to be there unless they specifically find them in the docs. Parameter properties offer a little bit of conciseness but don't fill a pressing need. Namespaces solve a problem that just doesn't actually come up that often, and few devs are going to go actively looking for them. Even the example code on typescriptlang.org doesn't show a very compelling case; they show "Validation" used as a namespace for classes that are already namespaced the low tech way by having "Validator" in their names. (Which isn't to say that the feature isn't ever useful; it's just that cases where someone would actually seek it out are niche.) All of that is to say that sure, enums are just one of a handful of features that will break in runtimes that simply strip out types, but they're also the main feature that's likely to trip people up.
- MrJohz 2y ago
  Namespaces are already pretty rarely used - mostly in older codebases in development as modern JS modules were still being developed and worked out. The Typescript compiler, for example, recently put a lot of work into getting rid of namespaces in their codebase and got a nice startup time improvement as a result. Parameter properties are I think still used quite heavily in Angular, but I don't see them much elsewhere. Again, they're a very old feature, and they don't play well with newer developments in the language (such as native private attributes), so it doesn't seem like much of a problem to avoid them as well. The other big TS-only feature is old-style decorators, but that shows the danger of relying too much on this TS-based syntax sugar. Decorators have gone through several revisions, and the version that Typescript implemented is long dead. But a number of codebases are still stuck using this legacy system because it's not compatible with the newer versions of decorators that will (eventually, hopefully) be implemented in browsers. The legacy system is still maintained, I believe, and you can still keep on using it, but you'll not get the benefits of using the same system as the wider Javascript ecosystem, and you'll not get the benefits of having the syntax be native to browsers, when that happens. In general, Typescript works best when you use it as simply a type annotation syntax for Javascript, and not as an additional layer of sugar on top of that. And clearly the Typescript developers see things similarly, because they've stopped implementing sugar-like features and have committed to only implementing the stuff that will also be implemented as new features in Javascript.
- WorldMaker 2y ago
  > because maybe in the future JS runtimes might be able to strip away types for you without a build-step. Not just the future. Node shipped this with an "experimental flag" in the last LTS and in Current it works without the flag (will ship in the next LTS without a flag). Deno has done something like this for years now, and Bun for nearly as long. The remaining question is if/when Browser support might also exist, which for now remains at Stage 1 discussions with the technical committee (TC-39).
awongh 2y ago
I get why people would want to push this forward in general, but except in a case down the road, many years from now, is there a real case right now for running your typescript code without compiling it? Maybe library compatibility? My first reaction is that this just further fractures the ecosystem, where some codebases/libraries will have TS that is required to be compiled and some will not, adding a third kind of TS/JS code that's out there.
- JimDabell 2y ago
  > except in a case down the road, many years from now We’re not talking about the distant future. Node shipped its first version supporting type stripping six months ago.
  - awongh 2y ago
    I'm not up to date on what people are working on, but I just mean that type stripping is probably not the final solution to a roadmap of node-typescript compatibility? That I would imagine there are other features being proposed that will continue to develop this compatibility?
    - JimDabell 2y ago
      The difference between type stripping and implementing other behaviour is precisely what is being flagged as a problem with enums in this thread. If you only have type stripping – which is the present day situation for Node users – then using enums will break TypeScript that you would otherwise be able to execute.
- mistercow 2y ago
  Being able to set up a node project like a web server without configuring or maintaining any build steps is pretty nice.

by msoad 2y ago

diggan 2y ago

But it's not specifically about enums, but anything from TS that generates code. You would need to stop using enums, parameter properties, namespaces (called out by the proposal) and probably more. Seems weird to me to decide you're OK with the build step and all the other complexity TS adds, but using enums is too much, because maybe in the future JS runtimes might be able to strip away types for you without a build-step. But we all have different constraints and use cases, I suppose it does make sense for what you're building.

cbovis 2y ago
It's not a hypothetical, it's here in Node 23: https://nodejs.org/docs/latest/api/typescript.html#typescript-features https://nodejs.org/docs/latest/api/typescript.html#typescrip....
- diggan 2y ago
  Speaking about the specification, it's a proposal. Yes, some run ahead and implement proposals under experimental flags, doesn't make it any more/less hypothetical as the proposal can still be rejected rather than progressing.
  - mistercow 2y ago
    Come on, now. > maybe in the future JS runtimes might be able to strip away types for you without a build-step. You can't backpedal from that to "speaking about the specification". It's not future JS runtimes. It's a thing you can take advantage of right now.
mistercow 2y ago
I think the difference is just that (IME at least) those other features seem a lot more rarely used than enums. Enums are a feature that maps onto a common language concept, and which new TS devs reach for because they give first class support to a very common need. And the fact that you can usually do what they do more elegantly with other features is not as obvious, particularly because you can't do it the same way in a lot of other popular typed languages. Parameter properties and namespaces, on the other hand, are kind of wonky TS specific features that nobody expects to be there unless they specifically find them in the docs. Parameter properties offer a little bit of conciseness but don't fill a pressing need. Namespaces solve a problem that just doesn't actually come up that often, and few devs are going to go actively looking for them. Even the example code on typescriptlang.org doesn't show a very compelling case; they show "Validation" used as a namespace for classes that are already namespaced the low tech way by having "Validator" in their names. (Which isn't to say that the feature isn't ever useful; it's just that cases where someone would actually seek it out are niche.) All of that is to say that sure, enums are just one of a handful of features that will break in runtimes that simply strip out types, but they're also the main feature that's likely to trip people up.
MrJohz 2y ago
Namespaces are already pretty rarely used - mostly in older codebases in development as modern JS modules were still being developed and worked out. The Typescript compiler, for example, recently put a lot of work into getting rid of namespaces in their codebase and got a nice startup time improvement as a result. Parameter properties are I think still used quite heavily in Angular, but I don't see them much elsewhere. Again, they're a very old feature, and they don't play well with newer developments in the language (such as native private attributes), so it doesn't seem like much of a problem to avoid them as well. The other big TS-only feature is old-style decorators, but that shows the danger of relying too much on this TS-based syntax sugar. Decorators have gone through several revisions, and the version that Typescript implemented is long dead. But a number of codebases are still stuck using this legacy system because it's not compatible with the newer versions of decorators that will (eventually, hopefully) be implemented in browsers. The legacy system is still maintained, I believe, and you can still keep on using it, but you'll not get the benefits of using the same system as the wider Javascript ecosystem, and you'll not get the benefits of having the syntax be native to browsers, when that happens. In general, Typescript works best when you use it as simply a type annotation syntax for Javascript, and not as an additional layer of sugar on top of that. And clearly the Typescript developers see things similarly, because they've stopped implementing sugar-like features and have committed to only implementing the stuff that will also be implemented as new features in Javascript.
WorldMaker 2y ago
> because maybe in the future JS runtimes might be able to strip away types for you without a build-step. Not just the future. Node shipped this with an "experimental flag" in the last LTS and in Current it works without the flag (will ship in the next LTS without a flag). Deno has done something like this for years now, and Bun for nearly as long. The remaining question is if/when Browser support might also exist, which for now remains at Stage 1 discussions with the technical committee (TC-39).

awongh 2y ago

I get why people would want to push this forward in general, but except in a case down the road, many years from now, is there a real case right now for running your typescript code without compiling it? Maybe library compatibility? My first reaction is that this just further fractures the ecosystem, where some codebases/libraries will have TS that is required to be compiled and some will not, adding a third kind of TS/JS code that's out there.

JimDabell 2y ago
> except in a case down the road, many years from now We’re not talking about the distant future. Node shipped its first version supporting type stripping six months ago.
- awongh 2y ago
  I'm not up to date on what people are working on, but I just mean that type stripping is probably not the final solution to a roadmap of node-typescript compatibility? That I would imagine there are other features being proposed that will continue to develop this compatibility?
  - JimDabell 2y ago
    The difference between type stripping and implementing other behaviour is precisely what is being flagged as a problem with enums in this thread. If you only have type stripping – which is the present day situation for Node users – then using enums will break TypeScript that you would otherwise be able to execute.
mistercow 2y ago
Being able to set up a node project like a web server without configuring or maintaining any build steps is pretty nice.