[kilburn]

> To me, using TypeScript in React just felt needlessly cumbersome, especially with functional/hook based components.

Out of curiosity: can you explain how/why? My experience has been quite simple, especially if only using functional components and hooks:

  interface Props {
    prop1: string;
    prop2: number;
  }

  const Component : React.FC<Props> =
  ({prop1, prop2}) => {
    // types are inferred correctly
  }

Hooks have been similarly easy: React's core hooks auto-infer the proper types, and custom hooks built on them don't require any particular type-plumbing in my experience...

[KronisLV]

It's been a little while since i had to work in the React + TypeScript project (nowadays use Vue more often) so it's not fresh in my memory, but sure!

For starters, even your example shows the awkwardness somewhat, it is essentially the same as writing the following (if you don't need the interface elsewhere):

  const Component: React.FC<{ prop1: string, prop2: number }> =
  ({prop1, prop2}) => {
      return ...
  }

Suppose i want to add a new property: now i need to do it in two places (the interface definition, with either syntax). Want to remove one? Same story. Rename one? Sure, your IDE should let you do this, but the change is still necessary in two places. Why couldn't i do something like this instead (the answer is that the language is just not structured that way, but clearly having duplication for no good reason whatsoever isn't nice):

  const Component: React.FC(prop1: string, prop2: number) => {
      return ...
  }
  
  or
  
  const Component: React.FC(props: Props) => {
      return ...
  }

Contrast that with a pure JS implementation (which is bad because it doesn't tell you about the individual props or their types, but surely one can also imagine just a list of different prop parameters):

  function Component(props) {
      return ...
  }

Of course, that's more of a nitpick, but the code often reads worse than Java does in my eyes.

Another thing that i disliked was working with union types, especially when you're stuck with loosely defined objects in a legacy codebase, where you can't always work with properly structured definitions of "this one thing is a union of BASE FIELDS but also ADDITIONAL FIELDS FOR ENTITY TYPE A that won't be defined in separate places, because if we split it up for some reason this one library integration will fail to render UI components properly".

I started writing out more about that particular case, but realized that articulating precisely what was the problem in it and diving back into that older codebase to recreate code examples would take time and sadly i don't really care for doing that. But hey, JavaScript would let you just wing it and check each field individually before trying to access them, so you could let the code decide the behavior, not the type system, which is sometimes the path of least resistance. Personally, i think that strong type systems are always good in the back end, but i feel less strongly in that regard about front ends.

Also, i'm not sure that building TypeScript on top of JavaScript was the best idea: surely from a support/target platform perspective it was brilliant, but sometimes you get all sorts of awkwardness.

For example, the React TypeScript bindings themselves have something like the following:

  type Booleanish = boolean | 'true' | 'false';

Oh, and in regards to TypeScript in particular (though this is also annoying in Angular etc.), their implementation of even enums is awkward. Consider that in Java you can easily turn any string into an enum value if possible and can also have enums act as containers for additional data, for example: https://www.tutorialspoint.com/how-to-convert-a-string-to-an...