Yeah, for sure, I agree with all of this. I think the best way to write TypeScript is to really treat it like the tagline "JavaScript With Syntax For Types" - some of the extras TypeScript provided from before TC39 were active have much less relevance now.

We evaluated TS for a recent project but ended up with JS (and VueJS 3). I have a feeling it would have taken much longer to develop using TS, but lacking experience in TypeScript it's hard to say. I find JS pretty neat for exploratory programming.

I think this whole discussion of whether union types are better than enums sheds light on the issues I have with type script in general: It’s basically a JS extension (like coffee script btw — remember that?) that is supposed to make your life easier as a developer but instead introduces a huge amount of unnecessary complexity giving you even more head aches.

I’ve yet to see typical front end code that really benefits from strong typing or even just the use of enums. I tend to accept language limitations and focus on designing my programs around those instead of wasting my energy on fighting on niche language extensions…

I thought this is going to be about dependent types or the `infer` keyword(or any other badly documented feature like the latter).

There are features of the type system you should definitely avoid unless you're writing a library. Enums aren't it.

TypeScript has a lot of features that just generate cognitive overhead that could have been better spent just learning a different language.

I like TypeScript a LOT, but to be honest I only use about 10% of it. Anything more than that and it gets too confusing for the next developer in line to work on the code in my experience.

Const enums specifically are great, since they disappear on compile you can use them to internally document strings/numbers with verbose names/comments without the cost of a const variable that would appear after compilation.

As for the fact that types cannot simply be stripped out, I've found building using plain tsc and have the bundler target tsc's output directory. This separation is needed since most tools don't support TypeScript project references anyway which I find extremely useful for organizing internal modules.

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.

The arguments not to use them are implementation details of the tooling.

Well designed Abstractions are good, not bad…

I would also suggest to avoid too complex genrics, these tend to make te code unreadable and make the compilation super slow.

Usually generic code tries to make everything type safe but having some portions of your code be dynamic is completely fine imo.

As long as you are not using "const enums" JavaScript/TypeScript interop is not a real problem at all.

The private keyword is obviously preferable to "#" in environments in which you are targeting older ES versions.

I disagree with this. We have a reasonably large Angular application that is only going to get much bigger (hard to define what that means ... big telephony app with tens of thousands of customers). I am the lead and architect.

We use enums and private keywords. With the private keywords, all I care about is that it is logically correct. We use private when things are truly private, i.e. they are only called from within the same class and don't need to be made visible to the view template or outside of the class. I honestly don't care what this transpiles down to, the point for us at least is not to make things "truly private" (good luck with that in JavaScript). It's simply to compiler-enforce rules. We also have ESLint to ensure that our private fields are all below the public ones to keep things nice and neat.

I also enforce that we actually make things as public although that isn't needed, and I enforce returning void.

So instead of:

someMethod() {}

I have us use:

public someMethod(): void {}

Just to state what you intend.

I realize "I don't care what this transpiles down to" might really irk some people, but I really don't. In our C# back-end I am much more strict about this stuff, but in JS at the moment given the standardization of the #private fields and the fact I consider them really ugly, I honestly don't care. Just give me a clean code base that enforces we can't reference private fields and methods from our templates.

For enums, I recently wrote a method that does exactly what this article says not to do, use it for GET, POST, and PUT.

What would be a cleaner way to write this? If it has to be refactored into something much "uglier" I don't think I'd prefer it.

    this.downloadService.fileWithProgress(url, RequestType.post, ActionType.download, body)

This is a service I wrote that handles real-time progress (i.e. show an accurate progress bar when downloading files). I think this is clean and logical.

You can use const enum and the ts compiler will just replace any enum reference with its value inplace.

Enums are fine, just don't forget to use Object.freeze(enumName) afterwards!!

Apart from that, because Typescript has powerful union types, not using enum is perfectly fine as well, for example instead of:

    enum Relation { Less = -1, Equal, Greater }
    Object.freeze(Relation);

you could do instead:

    const Less = -1;
    type Less = -1;
    const Equal = 0;
    type Equal = 0;
    const Greater = 1;
    type Greater = 1;

    type Relation = Less | Equal | Greater;

Apparently you need the additional "type Less" etc. declarations, I would have thought it should work without.

As for private and #, the biggest disadvantage of # is that it is so slow currently. But that will change hopefully soon when # is not compiled as WeakMaps by TypeScript. I would hope they compile private to # later on, backwards compatibility be damned :-D

This whole thing feels basically grounded in purity over practicality. In general it's a good idea to write idiomatic TypeScript. Even when I agree with the given recommendations, the given reasons don't seem like the strongest ones.

I most strongly disagree with the recommendation against enums. Realistically, you will probably never run into a compiler bug from enum emit; maybe something like this might happen with a very complicated runtime feature, but enum emit is dead-simple and hard to get wrong (at least if your toolchain has any tests at all, which it presumably should). And they're generally convenient and fill a useful niche, especially numeric enums with implicitly assigned values. (I'm also curious what the article's authors think of const enums.)

Namespaces have been soft-deprecated, modules are pretty much just better, and so I quite agree that you shouldn't use them, though I'm not sure the risk of compiler bugs is the most compelling argument against. (It is more compelling than with enums, since the required code transformations are much less trivial.)

Decorators, especially with metadata, facilitate lots of useful things that otherwise just aren't possible in TypeScript. It's also the case (though the authors seem unaware of this) that they will never be standardized in the current form that TypeScript has them, because they were based on an earlier version of the design that has since been pretty explicitly rejected. The risk isn't that decorators are never standardized; if that happens then TypeScript will just keep the current design forever and things will be mostly fine. The risk is that they get standardized in an incompatible form and then you have an interesting migration ahead of you. TC39 won't do this lightly, but no one knows exactly what the future holds. So it is a tradeoff to think carefully about, though in the end reasonable people will disagree.

# vs. private is mostly a matter of style/taste, with two exceptions. First, if you have any code on your page that you don't trust not to be doing weird things, strongly consider #, since it provides protection against corruption of internal state. Second, if you have to support older browsers that don't support #, then don't use it; the compiler can downlevel it, but only at significant code-size and performance cost that you don't want to pay (and debugging it in the browser will also be annoying).

Do the authors also disfavor parameter properties? Those also require emit beyond just stripping types, but are super-convenient and useful and don't really conceptually complicate things.

Incidentally, the feature at the top of my own list of "TypeScript features to avoid" (other than namespaces and other soft-deprecated features) is something entirely different: conditional types. Most other advanced type-system features behave reasonably predictably most of the time, but conditional types are very demanding of maintainers' knowledge of fiddly type-system details. I'm not saying it's never worth it (and in particular the built-in utility types are usually fine even though they're conditional under the hood), but whenever possible I try to reach for something else.

tldr: avoid features in TypeScript which must emit runtime code when compiling to JavaScript - that is, any TypeScript-exclusive feature that’s not type annotations.

Honestly most of these features are really useful, and as someone who never wants to work in raw JavaScript, I wish they were just added to JavaScript instead. Why shouldn’t JavaScript have enums, namespaces, private modifiers which aren’t #, and decorators? JS already gets new features which break backward-compatibility, mine as well add features which fix compatibility with TypeScript.

The only point I take slight issue with is Avoiding Namespaces.

I can't speak for frontend code, but on the backend:

It feels at least somewhat obviously true that unique names are good. Even if you aren't operating in a language which has global imports (which is most nowadays), unique-as-possible names can help disambiguate-at-a-glance something like:

    const user: User = await getGoogleSsoUser();
    // 100 lines later...
    console.log(user.microsoftId); // wait why isn't that field available?
    // ok i'll fix this
    const googleUser = await getGoogleSsoUser();
    // obviously that makes sense; but what about the type?
    export function getGoogleSsoUser(): Promise<User> {}
    // wait... should that return a Google API user object? or our own user model?
    // let me scroll 200 lines up, ok its defined there, open that file... 
    // or just:
    export function getGoogleSsoUser(): Promise<GoogleUser> {}

Contrived example of course, but it's a broader pattern I see every day; there's a lot of overloaded terminology in programming.

But this gets hairy really quickly.

    // google will provide these types... but lets assume you're writing your own
    export type GoogleUserV1 = ...;
    export type GoogleAPIV1GetUserResponse = {
      user: GoogleUserV1,
    }
    export type GoogleAPIV1ListUsersResponse = {
      users: GoogleUserV1[],
      count: number,
    }
    // ok lets import them
    import { GoogleUserV1, GoogleAPIV1GetUserResponse, GoogleAPIV1ListUsersResponse } from "my/service/google";

First, the type names get really long, which makes them hard to read at a glance. Second; this cost is replicated anytime someone wants to import something. Third, they oftentimes become a seemingly randomly ordered set of words written like a sentence; why is it not "GoogleV1APIListUsersResponse" or "GoogleAPIListUsersV1Response"?

We can solve the second problem by doing an old-style wildcard import:

    import * as google from "my/service/google";
    const user: google.GoogleUserV1 = await getGoogleSsoUser();

But this almost always ends up stuttering, because the producer package still wants to guarantee unique-as-possible exported names, as asserted above. So we made problem 1 worse, and did nothing for problem 3.

With namespaces:

    export namespace Google {
      export namespace User {
        export type V1 { ... }
        export type GetResponse { ... }
        export type ListResponse { ... }
      }
    }
    // now to import it
    import { Google } from "my/service/google";
    const user: Google.User.V1 = await getGoogleSsoUser();

The symbol, as a whole, isn't shorter. But, it's easier to read (and write!). It also helps disambiguate where in the symbol each component of the type's name should reside, when the producer wants to for example add a new type or function.

The argument against presented by the article boils down to: it creates unnecessary fluff in the emitted javascript. That's a reasonable argument; it does. In practice, it's more nuanced. First: I've never seen it cause an issue. So, premature optimization, YMMV, etc. Second: the fluff is erased for types anyway; so it only becomes an issue for functional code defined like this (all of my examples were in types, but its easy to imagine a Google.User.List function). Third, though not a direct counterargument to the article: it's literally how Google organizes the types we've been talking about [1] (though, how they organize the functional code, I'm not sure).

[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

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.

The author misses I think an important point regarding enums: using a union type instead means you can't iterate the list of valid values without restating them in the value domain in a non-DRY fashion. The reason enum generates code is that it is both a type construct and a value construct... That ends up being useful in myriad contexts.

What is there left to use in the end? Type annotations?

Maybe recommend not to use Typescript altogether then. Their only reasoning for this seems to be that the features "be more likely to break when using build tools other than the official TypeScript compiler".

As long as it's stage 3 EcmaScript, I (and the TS team, AFAIK) wouldn't count that as TS syntax - that's actual ES for all intents and purposes.

Other than that it's mostly syntax that affects how your code runs - i.e. if you were to remove all syntax that TS adds, the code should still run without further modifications in any interpreter that understands ES. (And features like enums don't satisfy this condition, hence why they don't match TS's design goals.)

In my experience, most people who complain about TS slowing down development are devs who've been working with pure JS for a while and haven't gotten over the (relatively brief) learning curve to adopt TS.

Migrations, however, are always painful:

1) You're going to end up writing code that ends up being difficult to type later; to the extent that you and every single other developer on the team is disciplined enough to avoid that, you may as well adopt the typing ahead of time

2) The support & tooling for managing "halfway" migrated JS -> TS projects "exists", but is obviously inferior to just "buying in" all the way

If you haven't put in a huge amount of work yet, I'd strongly suggest pivoting to Typescript ASAP. I don't know how Vue handles it but it performs beautifully for React.

Well, typescript being a superset of JavaScript, you can use TypeScript compiler and just write plain JavaScript.

The only difference is that you’ll be warned when you write inconsistent (buggy) code. And that your IDE will autocomplete with only compatible values.

There is absolutely no way typescript slows down development, you’re just totally free to ignore any or all of it. But it will help you more than you imagine.

tbf, the only valid reason not to use ts today is if your code targets directly the browser without any build step and is referenced as is by your html.

Typescript compiler is first and foremost a type system for Javascript. It's not an independent language. In fact it broke backward compatibility many times to follow the ES spec.

> One should also understand the machine code that a traditional language compiles to and how the CPU executes it. Ultimately, your language compiles to machine code. /s

If libraries you use are all written in machine code, then sure, you should have an understanding of machine code. Your comparison clearly doesn't work here.

> No one should need or worry about what an abstraction compiles to unless they’re specifically working on that abstraction or there’s a language bug.

When an abstraction is that leaky, it's barely an abstraction. Typescript does force you to choose a Javascript version as a compilation target. Obviously you are forced to know what Javascript version supports what feature because Typescript isn't going to polyfill every missing feature depending on your Ecmascript target.

You mean ES4, the revenge ;)

Proxies and classes were definitely salvaged from ES4/ActionScript/Jscript.net.

We wouldn't be needing Typescript, had ES4 been adopted (ironically Microsoft was against it, because Silverlight...).

Someone definitely needs to write a book about the whole saga.

> But before that there were countless competing models for creating objects or object factories.

Java and C# had object factories even though in those languages classes could not be avoided. People wanted classes because they could not figure how to program without them.

> To pretend…

Don’t use this or new in your code and suddenly a tremendous amount of your code is exposed as unnecessary superfluous vanity. That isn’t making the language into something else.

  function createCar(spec) {
    const {speed} = spec;
  
    let position = 0;
  
    return Object.freeze({
      move() {
       position += speed;
      },
      get position() {
        return position;
      }
    });
  }

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 is a simple syntactic transformation.

    e.g. change 'enum' to 'const', add a '=' before the '{' 
    and use ':' instead of '='
    const HttpMethod = {
      Get: 'GET',
      Post: 'POST'
    };

    // now this no longer breaks
    const method = HttpMethod.Post;

Namespaces can be translated in almost the exactly same way.

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

I don’t really see the value proposition of having a compilation step that also prioritises readability when you have source maps.

I love Dart personally and I mostly see it’s compile to nonsense looking code as a feature not a bug because it’s an ACTUAL compilation step worked on by ex Chrome team members who understand V8 internals not just code splitting and running terser over it and calling it a day. Want to get the same compilation optimisations that Google uses to run all of their multi billion dollar ad business? Cool, that’s enabled by default out of the box. [1]

The part where Dart on the web falls over for me is that they have shitty support right now for modern web APIs. They are building against some ancient version of Chrome’s WebIDL files so you can totally forget about things like web components for example.

So in that sense it doesn’t feel like a sensible choice in 2022 for basic web development which is a shame because it’s otherwise probably the best developer experience I’ve ever seen.

[1] I say this somewhat theoretically, I don’t know that Dart is in anyway an obvious thing to point to in terms of web performance from what I had seen casually. I think their goal there you can write huge business critical applications with stupidly large code bases and still get good performance. But nobody’s experience after using Google Ads is to talk about how snappy it was.

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.

What do you mean by reproducing JEE? Leveraging OOP in your Javascript programs?

I really dislike this tendency of certain Javascript developers to qualify combining OOP with Javascript as "not understanding the language".

Good points about JS being a target and that currently evolving. Lots of people these days code without any knowledge of assembly, maybe one day JS will be like that too. On the other hand, if your risk profile is more conservative (like many companies), you may want to let early adopters try out this "JS-less" world before investing in it. Since TS has a huge focus on large projects, and thus large companies, being conservative here makes sense.

For Dart, I wouldn't be so enthusiastic when describing it. The VM, hot reload, and all of that are impressive, but I'm not impressed by the language itself. The language seems to be an incremental improvement on 2005 Java and 2005 JavaScript, which are themselves not great. For example, it lacks data classes (records) and sealed classes. It took a long time to get nullability, the type checker (and system) are not impressive (things can easily fail at runtime).

I have no idea where you are coming from unfortunately.

Generally speaking, a Javascript user has access to the same type script language features (including hints, auto-completion,...) as a typescript user.

Even the most primitive text editor supports language server protocol nowadays.

The library your interoperating with does not even have to be written in typescript if the author provided @typedef JSDocs.

const enums break this because no value of this type exists

Couldn’t agree more!

Explain the differences in the following to a new developer:

something - a regular variable

$something - just another regular variable with a fancy char

#something - now that’s a private variable

!something - this is… uhm… a regular variable cast to… eh… boolean, then inverted…

~something - type cast blah blah bit flipping magic

!!something - same as !something except inverted again, because using Boolean(something) is not 1337

//something - a comment

Yeah… personally, I much prefer the more explicit ways to write code. it’s cryptic enough as it is, why make it harder for your peers

Also classes don’t serialize nicely so they’re a headache when dealing with things like redux actions, api endpoints, storing in local storage or a db etc. POJOs are a lot smoother.

For a long time I avoided to use the same name for a type and a value because I was afraid of possible breaking change in the feature.

And then I realized that this is an intended feature of TypeScript: type merging. Here the type `Role` merges with the type of the value `Role :)

I don't know why you should care if it doesn't affect you.

At least TypeScript cares enough to have added the `isolatedModules` and the `preserveValueImports` flags:

https://www.typescriptlang.org/tsconfig#isolatedModules

https://www.typescriptlang.org/tsconfig#preserveValueImports

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.

All of that is possible with a string literal union though, surely?

But the peer who reviews your code will hate it.

const enums are one of the few cases where type information changes the emitted JS, something that's arguably a bigger problem than TypeScript-specific, but still just syntax sugar, syntax highlighted in the article.

Const enums are erased at compile time. If you have a reference to `MyEnum.VAR`, TS has to check whether the enum is a const enum, and if so, replace with something like `1 /* VAR */`. This means that the type information in one file (where the enum is defined) is necessary to determine the proper output of any file that uses it.

  import {Something} from './file';
  console.log(Something.PROP);

Honestly, I’m more waiting for WASM garbage collection to officially land as a standard.

It won’t get me DOM level access but I can at least move a lot of my code there. I’m also quietly hopeful that canvas based rendering can make some huge improvements in the next few years so it doesn’t feel like Flash 2.0 but I’m ready to at least start thinking about letting go of the DOM as the thing I have to care about.

Until then I’m having a good time with Lit (lit.dev) for building web apps that need to be super snappy and “web feeling” which is still basically every customer facing thing.

But in a dream scenario I would way rather be writing apps in Flutter which was at least built from the ground up for building complex user interfaces in a sensible way, but that whole ecosystem is still in some very early days on the web and isn’t a good choice right now for most things, hoping that changes in a few years as they also seem to be targeting the WASM + Canvas path and the web as a platform isn’t there on that yet and neither are they.

In the use cases where I most typically use enums, I don't want to think about the question of runtime representation; I just want a set of arbitrary symbols that are different from one another. Implicitly initialized numeric enums do this idiomatically and concisely.

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

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

I brought up symbols because ameliaquining's declared requirements match symbols to a T:

> I don't want to think about the question of runtime representation; I just want a set of arbitrary symbols that are different from one another.

I wouldn't know how such requirements translate into value for her. Personally, when I need a set of type-checked fixed values, I favour string literal unions because a readable runtime representation eventually comes in handy.

The only time I recall using symbols was in order to have a "newtype"-like construct, which is a different thing entirely.

Symbols are very well supported in TS today. You even get proper type enforcement and intellisense when using symbols as the names of methods and properties, for instance. Whether you should use them for enum-like purposes or not has more to do with how you want to use the values though. For instance using symbols for defining numeric protocol values doesn't make sense. Same for HTTP methods, where you are always ultimately passing a string down to the http client/server interfaces

> respective accessibility APIs that each platform exposes.

That's the problem, there isnt an accessibility API for the web, is there?

EDIT: At least not one that works without DOM

So... You have two declarations, one of which is a real array that's allocated at runtime. Is that really better than an enum?

Not to mention, there's a slight mental overhead to parsing this. When I see this code, I might wonder if there's a reason for this to be an array. I might wonder if the order is intentional.

An enum has a more clear intent. My only complaint is that enums are not string-by-default, so we end up writing our variants twice:

    enum MyType {
        A = 'a',
        B = 'b',
    }

    "use strict";
    var MyType;
    (function (MyType) {
        MyType["A"] = "a";
        MyType["B"] = "b";
    })(MyType || (MyType = {}));

    "use strict";
    const MyType = {
        A: "a",
        B: "b",
    };

This is the way, because iterating enums produces odd results due to a bidirectional mapping.

I had always used enums in TS until this year, but union literals are better.

I create my own enums with const objects, compute the type based off the object's values. So very similar this, just with an object as the source instead of an array.

I often use that approach but (especially when you're importing from a seperate package) the compiler will sometimes view MyType as just an alias for string and won't catch typos.

Am I missing something in how to use this?

The modern Javascript version of that would be the same as the compiled Typescript version, the const version doesn't do the same things.

The IIFE is creating an object only if it doesn't already exist, and adds "A" and "B" to it. "var" doesn't error on a redeclaration, so if MyType already existed you'll get a mashup of the two versions of it. Even if the const was switched to var in the second one, that would still be a straight replacement of the values instead of merging them.

I haven't used Typescript, but I imagine this style was used so enums could gain new values later in the code without having to worry about execution order.

> > Also, this approach does not suffer the problems described by the article. > > This argument doesn't hold water, unless you're taking a philosophical stance.

Respectfully, philosophy has nothing to do with this.

The argument that the other person made does, in fact, hold significant water. There are extremely long discussions about it on the Typescript GH repo.

.

> The argument is that most TypeScript features don't actually spit out JavaScript code and this one does.

No, it isn't.

.

> then "extra" JavaScript code is still being generated

I never said extra code was a problem. I have no problem with this.

What I said was that I found the code emitted by the enumeration stack to be problematic. You seem to have inferred cause (incorrectly.)

.

> Why should we care who generates the code?

Do you believe that I think a compiler should not generate code?

I never said anything of that form.

Genuinely, it's difficult to hold a discussion with people who read so deeply between the lines that they come to bizarre conclusions, then think those conclusions belong to the person on the other end of the wire.

.

> This argument only works when we're comparing to writing a string literal union type and no other supporting code for that type.

You're not talking about the same argument that I am.

.

> but more clearly communicates intent/semantics to your fellow TypeScript devs (including future-you).

I write documentation.