TypeScript Features to Avoid • Hacker News Board

Re: TypeScript Features to Avoid

#61

Post by kesslern » Thu, Jan 20, 2022, 1:47 PM UTC

leodriesch wrote: post #25

Despite the large amount of criticism in the comments here I think that the point the article makes here is pretty valid. The described features are not what TypeScript itself wants to be, and I think if it wasn't for backwards compatibility the team would remove some of them. IIRC namespaces as well as the `import = ` syntax come from a time where ESM wasn't a thing yet but a module system was very much needed. So n…

One advantage of enums is that you can iterate over all possible values of an enum, but not a union type.

Re: TypeScript Features to Avoid

#62

Post by smoyer » Thu, Jan 20, 2022, 1:48 PM UTC

The arguments against the four language features in this article all boil down to it not being Javascript. If I wanted to write in Javascript, I'd use files with a .js extension. If you've picked Typescript, I don't think you should worry about whether your code is also valid Javascript "if you remove all the type information" (who's going to do that anyway.)

Unless you're a solo developer, what's more important it to agree on languages and conventions that apply to your team's projects. Once that's done, any change to the team's work process should be a conscious, measured decision.

Note that I also used CoffeeScript 10ish years ago and still consider it to be a superior experience to working in plain-old Javascript.

Re: TypeScript Features to Avoid

#63

Post by donatj » Thu, Jan 20, 2022, 1:49 PM UTC

The reasoning behind most of this, that the output JS is not a strict subset of the input is silly and imho represent a misunderstanding of what Typescript is going for. It’s a full fledged language that compiles to readable JS, not just annotated JavaScript.

There are many features in Typescript where it simply isn’t just outputting a subset of the input, and many of them are the best parts of Typescript.

If you just want JavaScript with types, there are other languages that do that, but Typescript offers so much more.

Re: TypeScript Features to Avoid

#64

Post by cobertos » Thu, Jan 20, 2022, 1:55 PM UTC

kesslern wrote: post #61

leodriesch wrote: post #25

Despite the large amount of criticism in the comments here I think that the point the article makes here is pretty valid. The described features are not what TypeScript itself wants to be, and I think if it wasn't for backwards compatibility the team would remove some of them. IIRC namespaces as well as the `import = ` syntax come from a time where ESM wasn't a thing yet but a module system was very much needed. So n…

One advantage of enums is that you can iterate over all possible values of an enum, but not a union type.

You can if you derive the union from a const array using indexed types.

  const MyTypeValues = ['a', 'b'] as const;
  type MyType = typeof MyTypeValues[number];

MyType is now a type 'a' | 'b'

Re: TypeScript Features to Avoid

#65

Post by chrismorgan » Thu, Jan 20, 2022, 1:57 PM UTC

cromwellian wrote: post #36

tuyiown wrote: post #24

Earlier quoted context omitted.

I see the next to zero codegen in typescript as a strategy: it removes all discutions about languages features besides typing, guarantees next to zero issues in production in case of code generation bug, making compiler deliveries safe and avoid need of coordination in toolchain.

Enums and namespaces are hardly complex code gen or generate 'issues'. People would often manually namespace in JS a few years ago, and namespaces and enums can really just be seen a lightweight holder object instances. Indeed, enums in Java are class instances. Besides, there is an straightforward way to remove enums from a program just like removing type annotations: Inline them as static fields of an object. There…

Trouble with your const there as written is that you don’t have a type that’s equal to "GET" | "POST". Fortunately, this can be done without repetition or too much bother:

  const HttpMethod = {
      Get: 'GET',
      Post: 'POST',
  } as const;
  type HttpMethod = (typeof HttpMethod)[keyof typeof HttpMethod];

Maybe wrap the `{…} as const` in Object.freeze(…) for good measure.

It’d be really nice if they’d improve the ergonomics on this in some way (`type Values = T[keyof T]` would reduce it to `type HttpMethod = Values`, which is a start but not enough), to make it a genuine and suitable alternative to enum (minus the other frippery that’s generated) and const enum (because it’s pure JavaScript, not an extension).

Re: TypeScript Features to Avoid

#66

Post by fuzzy2 » Thu, Jan 20, 2022, 1:59 PM UTC

mikojan wrote: post #45

fuzzy2 wrote: post #41

Earlier quoted context omitted.

But const enums are gone after compiling. They're just namespaced constants that are inlined. I don't see how this could cause any problem.

That's precisely the problem. It makes the enum invisible to JavaScript users.

Yes, as it should be. There are no enums. Instead, you can pass in any of the documented strings (or whatever the base type is). Even inside TypeScript, an enum is really just a union type on steroids.

When you expose TypeScript code to JavaScript consumers you absolutely must validate all incoming data anyway, whatever type you declare.

Re: TypeScript Features to Avoid

#67

Post by spoiler » Thu, Jan 20, 2022, 2:00 PM UTC

leodriesch wrote: post #60

ameliaquining wrote: post #54

Earlier quoted context omitted.

Numeric enums are a lot more useful than string enums, in my view.

I like string enums, since they are self-documenting, I guess int enums are smaller when sent over network. Could you expand on that?

Why do you find them self documenting?

Usually it's just

    enum Method {
      Get = "GET"
      // ...
    }

I usually always put doc comments on enums and their variants.

Regarding why numeric ones are (only sometimes) more useful than string values: bit flags comes to mind, faster comparison of numbers than strings (not always tho... unless this is a misconception, but I don't believe so), you mentioned smaller bundle size already.

As for "auto" enums: the fact they're numbers now is an implementation detail. They could be unique Symbols in a future versions of typescript. You can do that manually now too, but I'm talking about the automatic (without assignment) syntax.

Regarding article: I... Half-agree. But I'd not completely disregard/avoid enums. At the very least, they can be useful to help model some behaviours/states in more readable, accessible, and coherent way (Other comments went into a more in-depth defence of enums, thought).

Re: TypeScript Features to Avoid

#68

Post by a_humean » Thu, Jan 20, 2022, 2:00 PM UTC

antihero wrote: post #35

chrismorgan wrote: post #19

Earlier quoted context omitted.

I think you may have misunderstood the complaint, which is perfectly valid. A few paragraphs earlier: > The downside to enums comes from how they fit into the TypeScript language. TypeScript is supposed to be JavaScript, but with static type features added. If we remove all of the types from TypeScript code, what's left should be valid JavaScript code. The formal word used in the TypeScript documentation is "type-lev…

esbuild seems to support enums fine

It doesn't support one variant of them, const enums for example. That ties you to tsc emit. Its pretty clear that if the tsc team could they would remove enums and favour literal unions.

Re: TypeScript Features to Avoid

#69

Post by [deleted] » Thu, Jan 20, 2022, 2:00 PM UTC

kesslern wrote: post #61

leodriesch wrote: post #25

Despite the large amount of criticism in the comments here I think that the point the article makes here is pretty valid. The described features are not what TypeScript itself wants to be, and I think if it wasn't for backwards compatibility the team would remove some of them. IIRC namespaces as well as the `import = ` syntax come from a time where ESM wasn't a thing yet but a module system was very much needed. So n…

One advantage of enums is that you can iterate over all possible values of an enum, but not a union type.

[deleted]

Re: TypeScript Features to Avoid

#70

Post by _under_scores_ » Thu, Jan 20, 2022, 2:04 PM UTC

Personally I don't get the argument against enums. From what I can tell it's purely to do with the symantics of what Typescript is, rather than any inherently bad property of enums.