Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript Features to Avoid

executeprogram.com

Post reply on HN
Print view View original

141–150 of 212 posts

Re: TypeScript Features to Avoid

#141

Post by ragnese »

activitypea wrote: post #43
baryphonic wrote: post #33

> 1. Avoid Enums What? This is IMO bad advice. Having a sum type is quite handy for general type-checking, at least insofar as the type truly is an enumerated type (i.e. all possible values are known at design-time). There have been times when TypeScript enums have been indispensable to me when declaring the external interface to some client-facing API. Whatever the API boundary is, a sum type is useful. Also, TypeSc…

What are the advantages of enums over a string literal union? I can only see disadvantages.

Unfortunately, neither (string) enums nor string literal unions are supersets of each other when it comes to functionality. But, IMO, string-only enums are generally better.

You can't test if a given string is an element of a union without writing a custom helper and/or allocating a runtime array of the values.

On the other hand, if you don't need to test unknown strings, then union types disappear at compile time, whereas enums are compiled to real, runtime, objects.

Enums don't look like naked strings in the code. Frankly, it's just nicer on my brain to see `return Color.Red` than `return "red"` and wonder if "red" is just some random text or if it has semantic meaning. Hopefully your IDE is smart enough to take you to where "red" is defined as part of a union type when you want to see other options. Granted- the most popular editors ARE smart enough to do that, but that doesn't help when just reading code with my eyes instead of my hands, or in patches/diffs.

Re: TypeScript Features to Avoid

#142

Post by heisenbit »

ameliaquining wrote: post #49

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…

> Decorators, especially with metadata, facilitate lots of useful things

Angular 2 would look very different without it.

Re: TypeScript Features to Avoid

#143

Post by mhoad »

Zababa wrote: post #139
mhoad wrote: post #128

Earlier quoted context omitted.

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…

> I don’t really see the value proposition of having a compilation step that also prioritises readability when you have source maps. It's to increase adoption. Some people still remember migrating to coffeescript and away from it. It's in line with tsc accepting regular JS files, the degrees of strictness, things like that. Typescript is optimized to be adopted by the maximum number of people, which in turn increases…

If you’re going to be working in a multi language code base I am with you. Handing people garbage looking generated or compiled code and saying work with this is going to require a solid set of well defined interfaces at a minimum and maybe like you said even giving up all of that and having to make one thing look like the other. All of what I said was under the assumption that you don’t need to think about JavaScript again.

Im making the argument that JavaScript is a target that we have all been collectively forced into due to the limitations of the web as a platform but short to medium term horizon that is changing where things like WASM are maturing and will let a lot of new options flourish (.NET folks seem to be probably leading this charge currently)

But just stopping to think about the implications of that kind of changing landscape and what’s coming, I don’t think aiming for 100% JS interop not just from a code perspective but it also the entire tooling and developer ecosystem perspective is going to be as important.

Again, I just think people are somewhat forced to at the moment because the web has always been a one language show. That wasn’t because JS was the best choice but rather a limitation of the platform itself which is already in the early stages of changing.

For Dart specifically I kind of get what you’re talking about I guess because it’s pretty commonly referred to as the best bits of JS and Java put together while ditching the worst parts of each so it’s clearly aimed at productivity for application sized code bases rather than something low level but again… that’s literally why they have a proper complication step because getting it down to something a lot more low level is exactly what a compiler is for. That doesn’t feel weird to me at all, that actually feels like an incredibly sensible choice.

Re: TypeScript Features to Avoid

#144

Post by ragnese »

cobertos wrote: post #64
kesslern wrote: post #61

Earlier quoted context omitted.

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'

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',
    }

Re: TypeScript Features to Avoid

#145

Post by IshKebab »

dbrgn wrote: post #46
baryphonic wrote: post #33

> 1. Avoid Enums What? This is IMO bad advice. Having a sum type is quite handy for general type-checking, at least insofar as the type truly is an enumerated type (i.e. all possible values are known at design-time). There have been times when TypeScript enums have been indispensable to me when declaring the external interface to some client-facing API. Whatever the API boundary is, a sum type is useful. Also, TypeSc…

Unfortunately TypeScript's enums have various shortcomings compared to powerful sum types in languages like Rust: - https://stackoverflow.com/questions/40275832/typescript-has-... - https://github.com/microsoft/TypeScript/issues/32690 In a TS codebase I'm currently working on, we have the policy of never using "plain" TS enums. Instead, we have a tool that generates our own enum objects using a schema and a generator…

Rust can't do your second example yet either. Enum variants are not distinct types. It's a commonly requested feature though so hopefully soon...

Re: TypeScript Features to Avoid

#146

Post by The_rationalist »

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…

No post body was provided.

Re: TypeScript Features to Avoid

#147

Post by russellsprouts »

ragnese wrote: post #125
cypressious wrote: post #107

Earlier quoted context omitted.

Have you tried `const enum`? See https://www.typescriptlang.org/docs/handbook/enums.html#cons... > Const enums can only use constant enum expressions and unlike regular enums they are completely removed during compilation. Const enum members are inlined at use sites.

I remember reading somewhere that the TypeScript devs considered const enums to be a mistake and recommend against using them. I don't remember why, though.

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.

Re: TypeScript Features to Avoid

#148

Post by pfooti »

colejohnson66 wrote: post #28
EMM_386 wrote: post #23

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 wit…

> 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. It’s not just JavaScript. With reflection in C# and Java, you can mess around with private variables from outside the classes. For Java, this can have some pretty interesting results, such as 2+2 being equal to 5 .[0] The whol…

I mean, I don't know if you can do this with modern c++, but I would occasionally do this when I was being aggressive in my c++ tweaks:

    #define private public
    #import
then you can interact with your class private fields all you want.

Re: TypeScript Features to Avoid

#149

Post by kodemager »

gwbas1c wrote: post #90
maronato wrote: post #16

The article's premise is wrong imo. Typescript is a superset[1] of javascript, so typescript-only syntactic sugar is entirely to be expected. [1]: https://github.com/microsoft/TypeScript (repo description)

Not saying I agree, but this is a completely valid viewpoint. When I initially saw Typescript, I thought the point was to add features from strongly-typed languages and then transpile into Javascript. (IE, a more modern version of GWT, a Java to Javascript transpiler.) The point of the article, though, is that Typescript works best when its extensions to the language can simply be dropped. That's clearly a "we've wor…

I recently picked up TypeScript and I sort of agree with the author. It’s just so much cleaner to use Types instead of enums. That being said, I don’t think enums are bad if there is a good reason to use them. Checking if something is a type of X isn’t one such thing in my opinion, but that’s probably religion.

Namespaces mKe no sense to me. It’s probably because Microsoft drives TypeScript, but even though I was a C# developer for 10 years before moving on, they’ve just always been terrible to me. Their functionality is the sort of thing that is nice in theory, but really terrible in real world projects that run for years with variously skilled developers in a hurry.

Private is silly to me, but this is mostly because classes are silly to me. I can see why you’d want it if you use a lot of classes, I just don’t see why you would do that unless you’re trying to code C# in TypeScript. One of the things I loved the most about switching from C# to Python was how easy it was to use dictionaries and how powerful they were. The combination of TypeScript interfaces, Types and maps is the same brilliance with type safety. But once again, it’s sort of the thing where classes sometimes make sense, and when they do, so might private.

Re: TypeScript Features to Avoid

#150

Post by ragnese »

russellsprouts wrote: post #147
ragnese wrote: post #125

Earlier quoted context omitted.

I remember reading somewhere that the TypeScript devs considered const enums to be a mistake and recommend against using them. I don't remember why, though.

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 th…

Thank you for the answer! I won't waste your time because I'm sure the answer is somewhere on the web, but off the top of my head, I don't understand why TS "has" to emit different JS. I would've assumed that the entire point of a const enum is to inline the raw value in the emitted JS, and thus, the programmer should be careful to remember/know that the code is dealing with raw ints/strings.
Post reply on HN