3 ms·

I don't see the point. This proposal only goes halfway and large swathes of syntax (like enums) will not be supported. So it doesn't achieve its stated goal of

I don't see the point. This proposal only goes halfway and large swathes of syntax (like enums) will not be supported. So it doesn't achieve its stated goal of letting you run Typescript in the browser. The cost is making all JS engines implement the parser, raising the barrier for entry for new JS engines, and hampering innovation in the future by tying Typescript down to the slowest JS engine developer. The solutions we already have (typescript in comments, or lightweight dev servers like vite) aren't perfect, but they don't come with the gargantuan costs of types in JS.

neurotrace 5y ago
For better or for worse, features of TypeScript that generate code (like enums) are generally considered a mistake. I assume part of the idea here is that people would aim to target this particular subset so they can avoid compiling while in development and as such people would move away from those features. I like enums but you can get most of the same benefits with type RGB = 'red' | 'green' | 'blue'
- inbx0 5y ago
  Offtopic but I have to ask now that this came up, why do people even use enums instead of string literal type unions? The latter just seems so much simpler and more readable to me. You get the same type safety, pretty much the same or better performance, autocomplete works fine etc. One reason I've heard is that enums allow you to do rename symbol refactoring in all use sites, but like what How often do you need to do that? Once in a lifetime? Twice? And with string unions you can ofcourse also just rename it, TS will tell all the places that need fixing, and it'll take couple hours to go though 1000+ usages of it.
  - erikpukinskis 5y ago
    Enums aren’t interchangeable, which is either a good thing or a bad thing, depending. Let’s say I have an Icon component with props like: type IconProps = { size: “s” | “m” | “l” } And then let’s say I have a Button component but there’s no small size: type ButtonProps = { size: “m” | “l” } If I use string unions I can happy assign one size to another: const Button = ({ size }: ButtonProps) => ( <button><Icon size={size} /> ) If I used enums (ButtonSize and IconSize) then that would not be possible and TypeScript would complain. So the question is: Is that a bad thing? And the answer depends on your domain. If you have reason to believe that in your domain people are likely to map between two incompatible namespaces, then enums could help. And string unions could let through some bugs. In my experience that’s never been a real risk so I prefer string unions. The other thing enums can get you is you can rename the variable without changing the values. So if your strings are persisted to the database and you don’t want to change them, but you do want them to have a slightly new meaning, you could rename the enum key, and get the new name in code, while keeping the old string value.
  - neurotrace 5y ago
    I hear what you're saying but I'd rather not waste even those two hours ;) I agree with what @erikpukinskis said but I'll also add that I just like the way they read. It immediately tells me that there is a limited number of potential values that can be put in a place. If I see some arbitrary string then I have to wonder, if only briefly, if any arbitrary string can be plugged in there. // What does addTask take? Days of the week? // Time-sensitive identifiers like you'd see in moment.js? // I guess I'll check the definition or mock out a call to see addTask('Sunday', newTask) // vs. // Ah, it takes a day addTask(Day.Sunday, newTask) It's subtle and not super important but it makes me happy.
- throw_m239339 5y ago
  > For better or for worse, features of TypeScript that generate code (like enums) are generally considered a mistake. Considered a mistake by whom? they are valid Typescript. It's just creating yet another flavor of Typescript... and why straight out adopt that type syntax? Because it will please Typescript developers and Microsoft? All for what? being able to run that flavor of typescript without having to compile typescript files into Javascript? It would change nothing to the already complex build pipelines JS developers are already mandated to use for production. I agree with the parent, this is a bad proposal. What Typescript should do as an alternative is better support for JSDoc type analysis. I don't use typescript language, however I do use typescript compiler. https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported... Does it defeat the purpose of typescript? No, typescript is both a language AND a JavaScript static type analyzer.
  - neurotrace 5y ago
    > Considered a mistake by whom? The developers of TypeScript. TypeScript aims to avoid adding anything to the runtime as a result of the type system[1]. > It would change nothing to the already complex build pipelines JS developers are already mandated to use for production. You're right, it wouldn't change anything when you're building for production if you're doing things right. It would mean that you don't have to repeatedly compile your code while you're developing it though. > What Typescript should do as an alternative is better support for JSDoc type analysis. If you read the proposal you'll see they explain why expanding JSDoc is not ideal. Personally, I wrote a lot of JSDoc back before TypeScript and now I don't want to touch the stuff. TS is much more ergonomic and expressive. [1]: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
- trinovantes 5y ago
  I like the runtime generated enum code so that I can be somewhat lazy with generating options for <select> const options = Object.entries(MyEnum).map(([key, label]) => { key, label })
ketzo 5y ago
> So it doesn't achieve its stated goal of letting you run Typescript in the browser. At risk of running afoul of HN guidelines: did you actually read the post? The proposal does not add type checking to JavaScript. It adds type syntax. There is a huge, huge difference. Their proposal is to implement a comment-like type syntax. These types would be totally ignored at runtime. This isn't "run TypeScript in the browser"; this is "add syntactic sugar to vanilla JavaScript to get the development benefits of types without a build step." Yes, JavaScript engines would have to implement a parser for this syntax. Yes, this raises the barrier to building a new JavaScript engine. Does that mean JavaScript should add no new syntax ever again? No, of course not. So the question becomes one of cost-benefit analysis. And I think the TS team has submitted an extremely compelling argument for the benefits. Your comment acknowledges the existing benefits of types-in-comments; think of this proposal as a significantly nicer way to write those.
- 14u2c 5y ago
  In fact, this would be quite nice for TypeScript compile TO. JS engines could use the automatically generated type hints optimization, validation, reflection, etc.
- krapp 5y ago
  >Does that mean JavaScript should add no new syntax ever again? No, of course not. Yes? Yes. Maybe? At least not in cases where the language can already do things adequately, and the change is just a cosmetic improvement. Annotating comments already works, changing that just to have a syntax that looks like type hinting but isn't just makes the language worse in my opinion. I'd rather they just bite the bullet and add optional type hinting, and make the syntax do what it appears to. Otherwise, the necessary complexity of typing Javascript should be kept entirely out of the language itself - including special syntax to make things easier. Deal with Typescript and its peculiarities and the build step, if that's what you want to do, and annotate types in the existing comment syntax, but Javascript is an untyped language and should be remain absolutely, even aggressively agnostic about such things.
- exclipy 5y ago
  Yes I completely understand that it's not about adding type checking in the browser. My complaint is about adding type parsing in the browser. When I say "run typescript on the browser", I mean running code written in typescript syntax. Please read my comment again with that in mind.
Vinnl 5y ago
> This proposal only goes halfway and large swathes of syntax (like enums) will not be supported. "Large swathes" is really overstating it. The TS philosophy has been to avoid runtime behaviour for quite a few years now, and while there are a few features that made it in back when they weren't so strict about that yet, they wouldn't have added them today and have worked to add alternatives that do not modify runtime behaviour (like literal string union types). So it goes as much "halfway" as all TS development has gone for the past few years.

neurotrace 5y ago

For better or for worse, features of TypeScript that generate code (like enums) are generally considered a mistake. I assume part of the idea here is that people would aim to target this particular subset so they can avoid compiling while in development and as such people would move away from those features. I like enums but you can get most of the same benefits with type RGB = 'red' | 'green' | 'blue'

inbx0 5y ago
Offtopic but I have to ask now that this came up, why do people even use enums instead of string literal type unions? The latter just seems so much simpler and more readable to me. You get the same type safety, pretty much the same or better performance, autocomplete works fine etc. One reason I've heard is that enums allow you to do rename symbol refactoring in all use sites, but like what How often do you need to do that? Once in a lifetime? Twice? And with string unions you can ofcourse also just rename it, TS will tell all the places that need fixing, and it'll take couple hours to go though 1000+ usages of it.
- erikpukinskis 5y ago
  Enums aren’t interchangeable, which is either a good thing or a bad thing, depending. Let’s say I have an Icon component with props like: type IconProps = { size: “s” | “m” | “l” } And then let’s say I have a Button component but there’s no small size: type ButtonProps = { size: “m” | “l” } If I use string unions I can happy assign one size to another: const Button = ({ size }: ButtonProps) => ( <button><Icon size={size} /> ) If I used enums (ButtonSize and IconSize) then that would not be possible and TypeScript would complain. So the question is: Is that a bad thing? And the answer depends on your domain. If you have reason to believe that in your domain people are likely to map between two incompatible namespaces, then enums could help. And string unions could let through some bugs. In my experience that’s never been a real risk so I prefer string unions. The other thing enums can get you is you can rename the variable without changing the values. So if your strings are persisted to the database and you don’t want to change them, but you do want them to have a slightly new meaning, you could rename the enum key, and get the new name in code, while keeping the old string value.
- neurotrace 5y ago
  I hear what you're saying but I'd rather not waste even those two hours ;) I agree with what @erikpukinskis said but I'll also add that I just like the way they read. It immediately tells me that there is a limited number of potential values that can be put in a place. If I see some arbitrary string then I have to wonder, if only briefly, if any arbitrary string can be plugged in there. // What does addTask take? Days of the week? // Time-sensitive identifiers like you'd see in moment.js? // I guess I'll check the definition or mock out a call to see addTask('Sunday', newTask) // vs. // Ah, it takes a day addTask(Day.Sunday, newTask) It's subtle and not super important but it makes me happy.
throw_m239339 5y ago
> For better or for worse, features of TypeScript that generate code (like enums) are generally considered a mistake. Considered a mistake by whom? they are valid Typescript. It's just creating yet another flavor of Typescript... and why straight out adopt that type syntax? Because it will please Typescript developers and Microsoft? All for what? being able to run that flavor of typescript without having to compile typescript files into Javascript? It would change nothing to the already complex build pipelines JS developers are already mandated to use for production. I agree with the parent, this is a bad proposal. What Typescript should do as an alternative is better support for JSDoc type analysis. I don't use typescript language, however I do use typescript compiler. https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported... Does it defeat the purpose of typescript? No, typescript is both a language AND a JavaScript static type analyzer.
- neurotrace 5y ago
  > Considered a mistake by whom? The developers of TypeScript. TypeScript aims to avoid adding anything to the runtime as a result of the type system[1]. > It would change nothing to the already complex build pipelines JS developers are already mandated to use for production. You're right, it wouldn't change anything when you're building for production if you're doing things right. It would mean that you don't have to repeatedly compile your code while you're developing it though. > What Typescript should do as an alternative is better support for JSDoc type analysis. If you read the proposal you'll see they explain why expanding JSDoc is not ideal. Personally, I wrote a lot of JSDoc back before TypeScript and now I don't want to touch the stuff. TS is much more ergonomic and expressive. [1]: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
trinovantes 5y ago
I like the runtime generated enum code so that I can be somewhat lazy with generating options for <select> const options = Object.entries(MyEnum).map(([key, label]) => { key, label })

ketzo 5y ago

> So it doesn't achieve its stated goal of letting you run Typescript in the browser. At risk of running afoul of HN guidelines: did you actually read the post? The proposal does not add type checking to JavaScript. It adds type syntax. There is a huge, huge difference. Their proposal is to implement a comment-like type syntax. These types would be totally ignored at runtime. This isn't "run TypeScript in the browser"; this is "add syntactic sugar to vanilla JavaScript to get the development benefits of types without a build step." Yes, JavaScript engines would have to implement a parser for this syntax. Yes, this raises the barrier to building a new JavaScript engine. Does that mean JavaScript should add no new syntax ever again? No, of course not. So the question becomes one of cost-benefit analysis. And I think the TS team has submitted an extremely compelling argument for the benefits. Your comment acknowledges the existing benefits of types-in-comments; think of this proposal as a significantly nicer way to write those.

14u2c 5y ago
In fact, this would be quite nice for TypeScript compile TO. JS engines could use the automatically generated type hints optimization, validation, reflection, etc.
krapp 5y ago
>Does that mean JavaScript should add no new syntax ever again? No, of course not. Yes? Yes. Maybe? At least not in cases where the language can already do things adequately, and the change is just a cosmetic improvement. Annotating comments already works, changing that just to have a syntax that looks like type hinting but isn't just makes the language worse in my opinion. I'd rather they just bite the bullet and add optional type hinting, and make the syntax do what it appears to. Otherwise, the necessary complexity of typing Javascript should be kept entirely out of the language itself - including special syntax to make things easier. Deal with Typescript and its peculiarities and the build step, if that's what you want to do, and annotate types in the existing comment syntax, but Javascript is an untyped language and should be remain absolutely, even aggressively agnostic about such things.
exclipy 5y ago
Yes I completely understand that it's not about adding type checking in the browser. My complaint is about adding type parsing in the browser. When I say "run typescript on the browser", I mean running code written in typescript syntax. Please read my comment again with that in mind.

Vinnl 5y ago

> This proposal only goes halfway and large swathes of syntax (like enums) will not be supported. "Large swathes" is really overstating it. The TS philosophy has been to avoid runtime behaviour for quite a few years now, and while there are a few features that made it in back when they weren't so strict about that yet, they wouldn't have added them today and have worked to add alternatives that do not modify runtime behaviour (like literal string union types). So it goes as much "halfway" as all TS development has gone for the past few years.