TypeScript Features to Avoid • Hacker News Board

Re: TypeScript Features to Avoid

#81

Post by Vinnl » Thu, Jan 20, 2022, 2:40 PM UTC

This basically comes down to: avoid TypeScript features that clash with TypeScript's design goals. Specifically, the one to:

> Avoid adding expression-level syntax.

https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

And that makes sense to me. IMHO it's best to consider TypeScript as a tool that aims to help you write JavaScript by catching common errors; it's more like a linter than a separate language in that regard, and is what sets it apart from something like CoffeeScript, and helps it avoid falling into the same traps.

Re: TypeScript Features to Avoid

#82

Post by leodriesch » Thu, Jan 20, 2022, 2:42 PM UTC

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.

Re: TypeScript Features to Avoid

#83

Post by piaste » Thu, Jan 20, 2022, 2:43 PM UTC

ameliaquining wrote: post #71

leodriesch wrote: post #60

Earlier quoted context omitted.

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

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.

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

Re: TypeScript Features to Avoid

#84

Post by breatheoften » Thu, Jan 20, 2022, 2:44 PM UTC

Is anyone still using the class keyword in javascript or typescript? private field syntax doesn't matter in the first place if you don't use class {} anywhere ...

I feel like most of the typescript code i've been in recently looked like it needed 0 more class declarations.

Re: TypeScript Features to Avoid

#85

Post by yCombLinks » Thu, Jan 20, 2022, 2:46 PM UTC

He is completely incorrect about the purpose of enums. It isn't to simplify changing all locations of an occurrence. It is for defining domain concepts. It is to communicate to other code users, here is every allowed permutation of this type.

Re: TypeScript Features to Avoid

#86

Post by Zababa » Thu, Jan 20, 2022, 2:46 PM UTC

concerned_user wrote: post #5

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

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

That's what Typescript mostly is, that's where its success comes from. Type annotations for existing JS code. The vast majority of people need to type existing JS code, and compile to JS. A few minority need some specifics from the TS type system. Outside of that, there are other options.

Re: TypeScript Features to Avoid

#87

Post by jcelerier » Thu, Jan 20, 2022, 2:47 PM UTC

jannes wrote: post #40

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…

The TypeScript ecosystem is bigger than just the official compiler, though. Many projects use alternative compilers like esbuild or @babel/preset-typescript for their main pipeline and only use the official TypeScript compiler as a typechecker (with `--noEmit`, during CI). It's true that enums are harder to support for alternative compilers. Especially `const enum` seems to be harder.

yes, we should also restrict every C++ feature to what Borland Turbo C++ 3 supports too, since there are still school that teach that making it part of the C++ ecosystem.

Actually, as Amish communities are part of the human ecosystem, maybe we should also restrict anything we build in the real world to something that can be useful to the Amish and stop building anything requiring a power grid ?

Re: TypeScript Features to Avoid

#88

Post by gmiller123456 » Thu, Jan 20, 2022, 2:47 PM UTC

breatheoften wrote: post #84

Is anyone still using the class keyword in javascript or typescript? private field syntax doesn't matter in the first place if you don't use class {} anywhere ... I feel like most of the typescript code i've been in recently looked like it needed 0 more class declarations.

I use "class" all the time in Javascript (don't use Typescript at all), why wouldn't you?

Re: TypeScript Features to Avoid

#89

Post by auggierose » Thu, Jan 20, 2022, 2:49 PM UTC

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

Re: TypeScript Features to Avoid

#90

Post by gwbas1c » Thu, Jan 20, 2022, 2:53 PM UTC

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 worked with this for many years and this is a big lesson from experience" statement, so I wouldn't discount it.