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

11–20 of 212 posts

Re: TypeScript Features to Avoid

#11

Post by throw_m239339 »

withinboredom wrote: post #7
throw_m239339 wrote: post #3

Earlier quoted context omitted.

I completely disagree with that article. Instead of "avoid this or that", one should be understanding how Typescript compiler works and not treat it as a blackbox. Ultimately, Typescript does compile to Javascript. One cannot use Typescript without understanding Javascript, since every single Javascript library is not written in Typescript.

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

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.

Re: TypeScript Features to Avoid

#12

Post by wdb »

dmarchuk wrote: post #8

I've never had any issues with enums, namespaces or private keywords (can't speak for decorators as I haven't used them yet). Although I do understand the reasoning for using the '#somePrivateField' rather than 'private somePrivateField'. But features like enums are part of the reason why we even have tools like TypeScript, because JavaScript lacks these features.

I wish TypeScript somehow would use #-private fields underwater when compiling code. `#field` is pretty confusing; I keep thinking it's a comment and it looks ugly

Re: TypeScript Features to Avoid

#13

Post by wdb »

austincheney wrote: post #4
armchairhacker wrote: post #2

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

This is how ES6 got classes. Developers wanted JS to be some other language they favored more. In that case specifically people were really hoping to make the language look and feel like Java, probably because they were trained in Java and couldn’t figure out functions as first class citizens.

I always thought it was because of ActionScript 3

Re: TypeScript Features to Avoid

#14

Post by 01acheru »

> it has to generate new JavaScript code that doesn't exist in the original TypeScript code

That’s nonsense, the code is there otherwise what are we talking about?

You just need to understand how some TS features map to JS, that’s all.

Re: TypeScript Features to Avoid

#15

Post by moystard »

throw_m239339 wrote: post #9
austincheney wrote: post #4

Earlier quoted context omitted.

This is how ES6 got classes. Developers wanted JS to be some other language they favored more. In that case specifically people were really hoping to make the language look and feel like Java, probably because they were trained in Java and couldn’t figure out functions as first class citizens.

I think class were needed because too many developers were creating their own (incompatible) class systems on top of prototypal inheritance (which is more verbose). The problem with Typescript is that too many Typescript developers don't understand Javascript itself, which is an completely different issue. That and the obsession for some to reproduce JEE everywhere including in the browser...

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

Re: TypeScript Features to Avoid

#17

Post by conaclos »

Replacing TS enum with JS objects is really tedious:

  type HttpMethod = keyof typeof HttpMethod

  const HttpMethod = {
      GET: "GET",
      POST: "POST",
  } as const
It is even worse with int enum:

  type HttpMethod = Extract

  const HttpMethod = {
      GET: 0,
      POST: 1,
      0: "GET",
      1: "POST",
  } as const
My personal "avoid"-rules are:

- Avoid enum with negative integers because it generates code that cannot be optimized by the JS engine

- Prefer ESM modules to namespaces, because the first can be tree-shaked.

Re: TypeScript Features to Avoid

#18

Post by throw_m239339 »

wdb wrote: post #13
austincheney wrote: post #4

Earlier quoted context omitted.

This is how ES6 got classes. Developers wanted JS to be some other language they favored more. In that case specifically people were really hoping to make the language look and feel like Java, probably because they were trained in Java and couldn’t figure out functions as first class citizens.

I always thought it was because of ActionScript 3

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.

Re: TypeScript Features to Avoid

#19

Post by chrismorgan »

01acheru wrote: post #14

> it has to generate new JavaScript code that doesn't exist in the original TypeScript code That’s nonsense, the code is there otherwise what are we talking about? You just need to understand how some TS features map to JS, that’s all.

I think you may have misunderstood the complaint, which is perfectly valid. A few paragraphs earlier:

> The downside to enums comes from how they fit into the TypeScript language. TypeScript is supposed to be JavaScript, but with static type features added. If we remove all of the types from TypeScript code, what's left should be valid JavaScript code. The formal word used in the TypeScript documentation is "type-level extension": most TypeScript features are type-level extensions to JavaScript, and they don't affect the code's runtime behavior.

And:

> Most TypeScript features work in this way, following the type-level extension rule. To get JavaScript code, the compiler simply removes the type annotations.

> Unfortunately, enums break this rule.

And then there is an explanation about why this is important: it makes life hard for tooling, especially fast tooling; for in the absence of such features, JavaScript tooling can support TypeScript with little bother, just dropping the TypeScript bits and getting equivalent JavaScript; but in the presence of such features, they have to either use tsc (slow!) or implement more TypeScript-specific stuff.

Compilation of most TypeScript features to JavaScript simply removes the TypeScript bits. Enums, however, have to be transformed, adding to the output JavaScript something that was not in the source JavaScript.

Re: TypeScript Features to Avoid

#20

Post by mikojan »

austincheney wrote: post #4
armchairhacker wrote: post #2

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

This is how ES6 got classes. Developers wanted JS to be some other language they favored more. In that case specifically people were really hoping to make the language look and feel like Java, probably because they were trained in Java and couldn’t figure out functions as first class citizens.

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 JavaScript into an entirely different language.

Post reply on HN