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

51–60 of 212 posts

Re: TypeScript Features to Avoid

#51

Post by activitypea »

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

Their reasoning is missing the forest for the trees. The point is that most TS features do not map easily to JS, making any interaction with the resulting code a pain. That includes any static analysis of the JS output (not all tools support TS, after all), debugging both with step by step and console logs, and monitoring in prod.

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

I've always used TS for the types and nothing more, and been happy with it. Seems to me that most of the JS community has come to adopt this approach over time, and I don't see what's bad about it.

Re: TypeScript Features to Avoid

#52

Post by chrismorgan »

For people that don’t see the problem and are happily using these features, here’s an explanation of the second problem with these sorts of features, additional to the “it’s not just JavaScript with types which is what the label said” reason which is the focus of the article.

The real trouble occurs when TypeScript implements something because that looks like the way things are heading, but then they don’t head that way, and JavaScript and TypeScript diverge incompatibly. The type stuff is generally fairly safe, and fundamentally necessary, but some of the other stuff they’ve added isn’t safe and isn’t… as necessary, at least. Decorators are the current prime case of this divergence problem: they added a feature because it was useful, lots of people wanted it, and that was what people expected JavaScript to get before long, and some were using already through a Babel extension but people were sad about having to choose between nifty features (Babel) and types (TypeScript); and then because they’d added something not in JavaScript, why not go a bit further? and so reflection metadata came along; and then… oh, turns out decorators are actually heading in a completely different and extremely incompatible direction in TC39 now, but people are depending on our old way and PANIC! It’s been a whole lot of bother that will continue to cause even more trouble, especially when they try to switch over to the new, if it gets stabilised—that’s going to be an extremely painful disaster for many projects, because “experimental” or not, it’s a widely-used feature of TypeScript.

This is not the only such case; there’s one other that caused a lot of bother comparatively recently, but I can’t think what it was (I don’t work in TypeScript much).

Sciter used what was loosely a fork of JavaScript when it started, and diverged, for quite decent reasons in some cases I will admit, but this divergence caused more and more trouble, until recently they gave up and switched to JavaScript, … except with a couple of incompatible deviations already and more on the table as probabilities. Sigh. I had hoped a lesson had been learned.

So yeah, I’m content to call these things misfeatures. TypeScript overstepped its bounds for reasons that seemed good at the time, and may even have been important for social reasons at the time, but you’re better to avoid these features.

Re: TypeScript Features to Avoid

#53

Post by mikojan »

austincheney wrote: post #42
mikojan wrote: post #20

Earlier quoted context omitted.

The Java crowd indeed gave us god awful classes. But before that there were countless competing models for creating objects or object factories. Obviously, JavaScript is an object oriented language, too. You cannot escape that fact if you are determined to make the browser paint anything. Classes effectively solved the "How?" To pretend you don't need object orientation in JavaScript is really trying hard to make Jav…

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

> Java and C# had object factories

Object factories were competing models (plural) for creating any object. A total replacement for classes and the like, not an augmentation.

Here's one such model:

  function createCar(spec) {
    const {speed} = spec;
  
    let position = 0;
  
    return Object.freeze({
      move() {
       position += speed;
      },
      get position() {
        return position;
      }
    });
  }
And so you'd find this or any other model or multiple competing models in the very same code base.

It sucked.

> Don’t use this or new in your code

You are going to be mutating the internal state of objects. Using this and new or not.

Re: TypeScript Features to Avoid

#54

Post by ameliaquining »

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.

Re: TypeScript Features to Avoid

#55

Post by activitypea »

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…

> you will probably never run into a compiler bug from enum emit;

That's true, but diagnosing other bugs is an absolute pain in the butt when your enum value at runtime is 0, 1, or 2. You get all of the readability of C with none of the performance :)

Re: TypeScript Features to Avoid

#56

Post by jannes »

oefrha wrote: post #47
jannes wrote: post #40

Earlier quoted context omitted.

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.

> It's true that enums are harder to support for alternative compilers. As long as it is supported — and at least esbuild does, who cares (as a user). Should I start avoiding every JS feature that is hard to implement in alternative JS runtimes?

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

Re: TypeScript Features to Avoid

#57

Post by chrismorgan »

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

Type annotations are the whole point of TypeScript. The rest is mostly distraction and historical decisions that made sense at the time but have aged poorly.

Re: TypeScript Features to Avoid

#58

Post by ameliaquining »

chrismorgan wrote: post #52

For people that don’t see the problem and are happily using these features, here’s an explanation of the second problem with these sorts of features, additional to the “it’s not just JavaScript with types which is what the label said” reason which is the focus of the article. The real trouble occurs when TypeScript implements something because that looks like the way things are heading, but then they don’t head that…

Did the other feature have anything to do with modules? If so, I can't really blame TypeScript too much for that, since the JavaScript ecosystem is pretty fragmented there and TypeScript has to support all the different things that are in use with a reasonable interop story. Build tools that work purely with JavaScript source code also have to deal with this problem.

Otherwise I'm not aware of any cases besides decorators where TypeScript did something that was incompatible with a later ECMAScript development.

Re: TypeScript Features to Avoid

#59

Post by _zooted »

Article makes no real good arguments about not using the private keyword. It's more descriptive and carries knowledge from other languages compared to putting a hashtag in front of a variable name.

Re: TypeScript Features to Avoid

#60

Post by leodriesch »

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.

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