DEV Community

Discussion on: The TypeScript Experience

View post
Collapse
 
jwp profile image
John Peters •

Your arguments are wrong in my mind and lumping C# in the same sentence discussing 'structural typing' is highly confusing.

Your obvious hatred for TypeScript simply means you need to bar yourself from those jobs.

In the meantime TypeScript shops get stronger and have none of the issues being red flagged here.

Collapse
 
lucamug profile image
lucamug • • Edited

Thank you for the comment. I found some sources associating C# type system with the TypeScript type system, but others do not. So, until that part is clearer I will remove both C# and Java from the list, thank you for pointing it out.

I don't hate TypeScript, I actually have been a promoter of it and pushed to have it adopted in all our JavaScript code at work. I think it is a valuable asset if you have a large JavaScript project.

Here I am trying to understand why people have these experiences with TypeScript.

Does any answers reported in the post sound familiar to you? Do you think there is something that can be done to change the TypeScript experience, especially when compared with languages that use HMTS?

Collapse
 
jwp profile image
John Peters •

The Javascript community in general, did not like TypeScript. They felt their comfort zones fading away. Understandable as Assembly Language programmers did the same thing when 2nd Gen languages arrived.

Javascript folks also tend to discount Java, C## and C++ people feel TypeScript is the least problematic way to join the Javascript family.

As far as really knowing any Language is to spend around 1.5 years using it daily. Only then will they really have a feel for what it can do.

Collapse
 
peerreynders profile image
peerreynders •

The comparison with C# comes up because

  • Anders Hejlsberg is the lead architect of C# and TypeScript
  • by implication:

"TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web."

That evokes the whole 2012 "ASP.NET with C#" theme. But at the very least it does imply that TypeScript was designed to feel familiar to established C# developers.

But then "TypeScript’s type system has evolved to model code written by native JavaScripters. The resulting system is powerful, interesting and messy."

… which lead to the value space (variable declaration space) and type space (type declaration space) divide - and lots of syntax to extract information from value space into type space.

const RNA_COMPLEMENT = {
  G: 'C',
  C: 'G',
  T: 'A',
  A: 'U',
} as const;

type DnaNucleotide = keyof typeof RNA_COMPLEMENT;
Enter fullscreen mode Exit fullscreen mode

Some of the tension comes from the fact that TypeScript offers more value (as in gets less in the way) as a JavaScript type linter than as a programming language.

Being able to "Just use JavaScript" (rather than having to compile it), while being able annotate types succinctly for occasional type linting should silence most criticisms. At this point JSDoc TS is seen as verbose (though @type gets close) and not all of TypeScript's features are necessarily easy to access from JSDoc/JavaScript (though that hasn't stopped projects from adopting it (most notably Preact for performance reasons)).

FYI: Deno 2.0 will skip type checking by default to improve start up performance.

I don't believe that TypeScript would have gotten as much traction as a pure type linting tool—as a programming language it brought a sense of familiarity to those with a background in statically typed languages and who were sceptical about trusting dynamically typed code.

Ideology 3:11

Type branding is sometimes used to approximate nominal typing:

Thread Thread
 
lucamug profile image
lucamug •

The "Ideology" video linked is very nice.

Related to it, it would be interesting to roughly categorize people that answered the Twitter thread in

  • People that only experienced JS
  • People that experienced JS and TS
  • People that experienced JS, TS, and a statically typed language like Java, not based on the Hindley–Milner type system
  • People that experienced JS, TS, and a sound static language like Haskell, OCaml, Elm, or F# based on the Hindley–Milner type system (where type annotations are mostly optional)
Thread Thread
 
peerreynders profile image
peerreynders •

On a side note:

A Gentle Introduction to Haskell, Version 98

"It's usually helpful to write down the type of new functions first;"

I always thought that it is useful to actually separate the type from the implementation - as opposed to the C-style conflation of both. So something like

/** @type {(string, boolean) => number} */
function sbn(s, b) {
  /* ... implementation details ... */
}
Enter fullscreen mode Exit fullscreen mode

seems perfectly reasonable - though familiarity with the mainstream, conflated syntax

function sbn(s: string, b: boolean): number {
  /* ... implementation details ... */
}
Enter fullscreen mode Exit fullscreen mode

creates a bias towards s: string "belonging together" even though they are just distinct aspects of the same positional argument:

  • s is the name the value of the positional argument is bound to
  • string is the type the positional argument is expected to be
Thread Thread
 
lucamug profile image
lucamug •

"It's usually helpful to write down the type of new functions first;"

Yes, it is interesting to note that devs that use languages where type annotations are optional end up with a mindset of writing type annotation first and the implementation after.

Programming languages influence the way we find solutions.