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

181–190 of 212 posts

Re: TypeScript Features to Avoid

#181

Post by CognitiveLens »

ameliaquining wrote: post #54
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…

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

Could you expand on this? I can't think of places where a string enum would be less useful than a numeric, although I can think of places where numeric enums fall over, e.g. if you have a value that can be one of two different enums and you have to figure out which it is - runtime numeric enum values shouldn't be compared because they regularly have the same value.

Re: TypeScript Features to Avoid

#182

Post by comp_throw7 »

sgt wrote: post #137
kwinten wrote: post #113

Earlier quoted context omitted.

I can assure you that doing it in TS would not have been any slower and you would have gained all the benefits that static type checking brings with it. VueJS 3 in particular is much better suited to use TS than its predecessor (without any additional plugins).

Can probably add types later, and consider it once we get the project underway. I am not saying you are wrong, but I have heard TypeScript developers complain about the turnaround in development being slower.

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.

Re: TypeScript Features to Avoid

#183

Post by comp_throw7 »

I think enums should be avoided for a few reasons not described in the article (some of them are mentioned in other comments here).

1) Enums have a unique (and, imo, mostly undesirable) model for interacting with the rest of the type system, which isn't what you'd naively expect. If you try to treat an enum like an object-literal (`as const`) when it comes to type-level manipulation you're going to have a bad time.

2) Implicit numeric enums (i.e. the ones most people use by default because they require the least amount of typing) make adding new values a _backwards-breaking change_ if you insert them before existing values, and you send them over the wire. Let me repeat that: adding new values to an existing enum is a _breaking change_.

3) Giving a field or parameter an enum type will not actually cause the Typescript compiler to complain if you put in a value that's not part of the enum! Example:

``` enum Fruit { APPLE, BANANA }

interface FruitSalad { base: Fruit }

const salad: FruitSalad = { base: 5 }; ```

Assigning `5` to `base` (which, you might expect, would only accept `Fruit.APPLE` and `Fruit.BANANA` - and perhaps even `0` and `1` as valid values) is in fact something that the compiler will let through without complaint.

4) Debugging is a headache, since reverse-mapping them gives you... a number.

You might say that most of these problems are solved by using string enums - sure, but then why not use an object literal instead? To save yourself from needing to write a single additional type definition? IMO, that is not worth the issues you run into with respect to the first problem.

Re: TypeScript Features to Avoid

#184

Post by resonious »

iLoveOncall wrote: post #161
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…

> Enums IMO have no advantage over union types with string literals, e.g. `type Status = 'fulfilled' | 'pending' | 'failed'`. Well I would say having to not repeat and update your code everywhere when you change or add a possible value is a pretty big advantage.

In my experience, even if I do change an enum value I also want to change the name in code. Having enum { complete = 'finished' is a little weird so I just change it to enum { finished = 'finished' } anyway.

Re: TypeScript Features to Avoid

#185

Post by piaste »

JohnHaugeland wrote: post #160
piaste wrote: post #83

Earlier quoted context omitted.

If you truly don't care about the runtime representation, then it sounds the idiomatic JS/TS construct you actually want is Symbol() https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://www.typescriptlang.org/docs/handbook/2/everyday-type...

Symbol is an extremely heavy hammer. It's also difficult to use correctly. What value do you think it offers here?

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.

Re: TypeScript Features to Avoid

#186

Post by auggierose »

robpalmer wrote: post #175
auggierose wrote: post #89

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…

#private fields are not slow when used natively. It's true the down-levelled code that uses WeakMaps is slower. The decision to downlevel is in the hands of the user and is controlled by the tsconfig "target" option. The only environment that needs downlevelled #private fields is IE11.

Which value are you setting for target? I tried es2021, and it still doesn't give me native #. I cannot use esnext, because other stuff doesn't compile anymore.

Re: TypeScript Features to Avoid

#187

Post by ragnese »

JohnHaugeland wrote: post #169
ragnese wrote: post #165

Earlier quoted context omitted.

> Substantially. Look at the generated code for an enum. I'll give you that. It looks like the TS compiler (according to the playground site) spits out some code that's intended for maximum compatibility with older versions of JS, even when targeting newer versions (which makes sense, since nothing is technically wrong about it). It spits out: "use strict"; var MyType; (function (MyType) { MyType["A"] = "a"; MyType["…

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

Your comment said two things. You said that you don't like the generated implementation for enums and then you said "this approach does not suffer the problems described by the article."

The article listed literally one reason to not use enums, and that reason is because it requires to compiler to produce JavaScript code. So, if that's not what you're talking about, then I have no idea what "problems described by the article" you could possibly be talking about.

With all of your complaining about my response, you still didn't explain it.

Re: TypeScript Features to Avoid

#188

Post by yawaramin »

crabmusket wrote: post #177

> We recommend the new #somePrivateField syntax for a straightforward reason: these two features are roughly equivalent. The author of the article surely knows the significant difference between JS private fields and TS private fields: TS private fields can be easily circumvented, whereas JS private fields cannot. See TS playground link[1] I think this is a significant enough point that people should not be taught th…

I mean if you look at it like that, then yeah sure anything in TypeScript can ultimately be circumvented. Just like `unsafe` in Rust or `unsafePerformIO` in Haskell.

The point is that we as developers choose to respect the typechecker.

Re: TypeScript Features to Avoid

#189

Post by smoyer »

mhoad wrote: post #136
rezonant wrote: post #133

Earlier quoted context omitted.

I disagree with almost all of this, but I will say have you checked out Deno? It is in fact Typescript without the NPM ecosystem (amongst many other interesting aspects)

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…

Compiling Go to WASM is actually a viable way to write a SPA ... I've used it with material-components-web so you can certainly manipulate the DOM.

Re: TypeScript Features to Avoid

#190

Post by uzername »

leodriesch wrote: post #82
matt7340 wrote: post #31

I like these recommendations, especially around decorators, maybe I’ll start following them reviews Angular app oh

Nest also does this, seems very strange to bet on such an experimental feature. It's very convenient to use though.

Yes, Nest uses decorators and the reflect-metadata package to get information about them dynamically. Annotations/decorators in other languages are fine, but in JavaScript/Typescript I feel the risk of using them as a dead end feature. I'd like the proposal as much progress as possible, but it's been quiet. In the meantime, a Typescript Nest like system without annotations could be better.
Post reply on HN