9 ms·

This is incredibly impressive but I also simultaneously find it kind of depressing. In my not so humble opinion, typescript is already way too complicated and g

This is incredibly impressive but I also simultaneously find it kind of depressing. In my not so humble opinion, typescript is already way too complicated and getting worse thanks to its velocity. A better approach would be to kill typescript's velocity by identifying a stable subset of the language that provides the vast majority of its benefits and optimize the heck out of a parser for that smaller language. This approach would be both easier and more sustainable since it would cap the language complexity making it easier to maintain and/or write alternative implementations.

serverlessmania 4y ago
At this point, TS is becoming C# V2
Zaskoda 4y ago
I find this comment validating. Most of the languages I've used start to click and feel good after a while - but it feels like this just won't happen for me with typescript. I'm clearly missing some fundamentals and I'm not even sure what it is I need to go study.
- evandwight 4y ago
  What doesn't click? I've found it pretty intuitive, though I've explicitly avoided making complicated types.
  - randomdata 4y ago
    The type erasure. You get this nicely expressive type system that can encode all sorts of useful metadata, and then you have to recreate it all again by hand in 'Javascript' to access it at runtime. Say I have `type Foo = 'bar' | 'baz'` and want to validate that an input string is within the set of Foo. Why can't I just enumerate the type to determine the valid values at runtime?
    - scotty79 4y ago
      For me it's a great feature because it means that the code has purely javascript semantics not influenced by andy generic type magic that happens on compile time. Occasionally I bump in the same things as you when I'd like to have some JS code generated on the basis of TS type information. I think there could be some preprocessing tools that could generate JS validators on the basis of TS code. Now, trying Rust I strongly appreciate this separation. In Rust what your code DOES might depend on what you are going to do in the future with the result it returns. It's really shocking for me and makes finding errors really hard when the spot of the error messages jumps wildly across large chunk of your code as I change it. I really prefer TS philosophy of "types are for you and your text editor and the actual code is for runtime".
- soiler 4y ago
  Can you explain why you feel that way? I only know JS and TS, and I love TS. With both languages, I understand I'm missing out on a lot, but I kind of assumed that was normal with my level of study (that is, reading in depth to fix bugs or make new features, and generally no further).
brundolf 4y ago
TypeScript is complicated because JavaScript is complicated. As long it's sticking to the core goal of giving JavaScript static types in a practical way, complexity is unavoidable. I think what you want is a new language. (I say this not as a dig against TypeScript or the way it's been designed; I just think the parent wants it to be something fundamentally different from what it is)
- zem 4y ago
  as someone working on a python type checker I can second this. we get occasional complaints that some feature is too complicated or too liberal, and the answer is usually "it works this way because python works this way, we are trying to support as much valid python as we can even if it's hard to express in terms of static types".
- hajile 4y ago
  People would benefit more from a stricter subset of JS that has decent performance characteristics and actually sound typing.
  - AA-BA-94-2A-56 4y ago
    I agree, but I can't help but think of that meme about there being N+1 standards. The introduction of a stricter subset of JS will make Javascript more complicated, not less. I hate that, because honestly Javascript and the web would benefit form removing a lot of the cruft.
    - sli 4y ago
      > I hate that, because honestly Javascript and the web would benefit form removing a lot of the cruft. This is the primary argument against worrying about N+1 standards. We know it's bad, if we simply do nothing at all, we know it will get worse. We can and should at least try.
      - esprehn 4y ago
ajkjk 4y ago
Can't agree. Typescript already has a better type system than a lot of languages in common usage, but it's not good enough and we run into issues all the time because it's not powerful enough. It can probably stop adding features someday, but IMO that day is at least a few years away, when it is actually solving the problem of type safety in web development fully.
- ajkjk 4y ago
  In particular, supporting nominal typing, fixing the way index types work, and fixing the story of debugging type failures on giant unions come to mind, but there are countless others. (Don't @ me, my day job is a few versions behind and I can't remember what's in the latest version, but there are plenty of other things if not these.)
  - culi 4y ago
    Yeah I think the new `satisfies` operator and improvements to type inferences in the latest version likely resolve a lot of your concerns. TypeScript also supports some really advanced typing I've yet to see in other languages like template literal types (don't @ me, I mostly work with dynamic languages at my current job). I feel like even the TS docs haven't caught up to the full power of TS's full featureset
  - svieira 4y ago
    FYI, TypeScript already supports nominal types, but the ways in which you "spell" `nominal` are a little unintuitive: 1. Use an enum 2. Use an intersection with an enum and literally anything else (except a number) 3. Use a private field (only works with classes) 4. Use a `declare const FOO: unique symbol` keyed object intersected with anything else (works with everything including numbers, lots of boilerplate to declare a new nominal type).
    - ajkjk 4y ago
      I'm aware of some of those, but I think they're all suboptimal compared to actual nominal types. In particular iirc you can't use your nominal/branded type as a map key in a type-safe way.
smasher164 4y ago
My favorite language in this category is MLscript. The best part is that type-checking it is decidable! https://github.com/hkust-taco/mlscript https://github.com/hkust-taco/mlscript
no_wizard 4y ago
how is it getting worse, exactly? I know it has features (all of which are optional) that can auto-generate code, but it _doesn't_ require being used. You can, and largely most do, use it just for the syntax for typing. Is there something inherent with TypeScript that is causing issues that you can point to?
thiht 4y ago
That’s not my experience. If anything, I think the Typescript experience improves with each release: typings get more precise, the type system becomes more expressive and allows to simplify the type declarations that used to be more complex, and best of all, what worked before still works. And in most cases, you’re good to go with the basics, you just know that if you need to declare a complicated type, Typescript got your back.
- esperent 4y ago
  I agree that Typescript improves with each release as I and the people I work closely with use it, because we use the KISS approach to typing so we rarely do use new features, but when we do need them they're useful. But then I find some third party code which seems to use the kitchen sink approach to typing, AKA the "look at how smart we are" approach, and it's a nightmare to understand. A type system is supposed to make code easier to work with, by the time you're spending more time understanding the types than the actual code there's something wrong. In these cases I wish Typescript was more limited and I would gladly give up a lot of the new stuff to enforce simple types across the ecosystem. That said, I don't really have an opinion on who is at fault here - coders for writing overly elaborate types, or Typescript for allowing them.
  - citrons 4y ago
    Also agree, with each release I get an "Eureka effect" that now I can solve the type issue I strugled couple months ago trying to create to just make some highly used function safer/easier to use for the developers. Example the new satisfies and some upcomign "as const" features to generics I'm looking forward to
  - goto11 4y ago
    > That said, I don't really have an opinion on who is at fault here - coders for writing overly elaborate types, or Typescript for allowing them. Backwards compatibility is to blame. Typescript was designed to support a number of patterns which was already used in JavaScript. For example events are registered in the DOM like `element.addEventListener("click", (ev) => ...)`. The type of the callback will depend on the string passed as the first argument, so the type system need to support literal strings as type discriminators which is a weird feature not necessary in most other languages. If the API had been designed with static typing in mind from the beginning, it would have been designed differently and wouldn't need such a complex type system.
ywei3410 4y ago
Have you heard of ReScript [1]? [1] https://rescript-lang.org/ https://rescript-lang.org/
MuffinFlavored 4y ago
> typescript is already way too complicated and getting worse thanks to its velocity Is it safe to say a non-zero portion of "the community" is headed the direction of: write it in _____ + compile it to WASM + glue DOM stuff to it with some sort of JS bridge?
- peatfreak 4y ago
  This sounds interesting to me, especially as somebody who was exactly zero interest in learning anything other than regular JS (i.e., no TypeScript, CoffeeScript, or any other JS-extension languages). Is this some kind of pattern, and do you know of any examples that show this?
  - giobox 4y ago
    I see a comment like this every time someone mentions WASM and have to eye-roll a little. Yes transpile-to-WASM techniques exist, but as someone like yourself with a self-professed inability to learn TypeScript, I don't think you are going to enjoy living on the edge of webdev with WASM either... The tooling is nowhere near as mature for one, which is always problematic when starting from a position of little knowledge. Just search github.com and you will find countless example repos for many languages, but understanding typescript first is probably a more productive use of most people's time. If you work in web-tech, I consider avoiding JS and TS to be almost negligent to some extent in 2022.
    - deleted 4y ago
      [deleted]
Waterluvian 4y ago
The thing about TypeScript (or any language) is that one needs to recognize that many features aren’t for us normals. They’re for library developers doing all kinds of wild type stuff. I remember my eyes glazing over at the template literal typings and such. But someone on the discord was like, “if it seems overwhelming, you’re probably not the audience. But you’ll end up using it by using a library that leverages it.” Always check ts-essentials for the ideal abstractions built with the wild new features.
kupopuffs 4y ago
Is it honestly more complicated than, say, a browser?
scotty79 4y ago
The funny thing is that TypeScript still has some way to go to be capable of fully expressing JS semantics. This shows that even most complex statically typed languages are way simpler than some dynamic languages.

serverlessmania 4y ago

At this point, TS is becoming C# V2

Zaskoda 4y ago

I find this comment validating. Most of the languages I've used start to click and feel good after a while - but it feels like this just won't happen for me with typescript. I'm clearly missing some fundamentals and I'm not even sure what it is I need to go study.

evandwight 4y ago
What doesn't click? I've found it pretty intuitive, though I've explicitly avoided making complicated types.
- randomdata 4y ago
  The type erasure. You get this nicely expressive type system that can encode all sorts of useful metadata, and then you have to recreate it all again by hand in 'Javascript' to access it at runtime. Say I have `type Foo = 'bar' | 'baz'` and want to validate that an input string is within the set of Foo. Why can't I just enumerate the type to determine the valid values at runtime?
  - scotty79 4y ago
    For me it's a great feature because it means that the code has purely javascript semantics not influenced by andy generic type magic that happens on compile time. Occasionally I bump in the same things as you when I'd like to have some JS code generated on the basis of TS type information. I think there could be some preprocessing tools that could generate JS validators on the basis of TS code. Now, trying Rust I strongly appreciate this separation. In Rust what your code DOES might depend on what you are going to do in the future with the result it returns. It's really shocking for me and makes finding errors really hard when the spot of the error messages jumps wildly across large chunk of your code as I change it. I really prefer TS philosophy of "types are for you and your text editor and the actual code is for runtime".
soiler 4y ago
Can you explain why you feel that way? I only know JS and TS, and I love TS. With both languages, I understand I'm missing out on a lot, but I kind of assumed that was normal with my level of study (that is, reading in depth to fix bugs or make new features, and generally no further).

brundolf 4y ago

TypeScript is complicated because JavaScript is complicated. As long it's sticking to the core goal of giving JavaScript static types in a practical way, complexity is unavoidable. I think what you want is a new language. (I say this not as a dig against TypeScript or the way it's been designed; I just think the parent wants it to be something fundamentally different from what it is)

zem 4y ago
as someone working on a python type checker I can second this. we get occasional complaints that some feature is too complicated or too liberal, and the answer is usually "it works this way because python works this way, we are trying to support as much valid python as we can even if it's hard to express in terms of static types".
hajile 4y ago
People would benefit more from a stricter subset of JS that has decent performance characteristics and actually sound typing.
- AA-BA-94-2A-56 4y ago
  I agree, but I can't help but think of that meme about there being N+1 standards. The introduction of a stricter subset of JS will make Javascript more complicated, not less. I hate that, because honestly Javascript and the web would benefit form removing a lot of the cruft.
  - sli 4y ago
    > I hate that, because honestly Javascript and the web would benefit form removing a lot of the cruft. This is the primary argument against worrying about N+1 standards. We know it's bad, if we simply do nothing at all, we know it will get worse. We can and should at least try.
    - esprehn 4y ago

ajkjk 4y ago

Can't agree. Typescript already has a better type system than a lot of languages in common usage, but it's not good enough and we run into issues all the time because it's not powerful enough. It can probably stop adding features someday, but IMO that day is at least a few years away, when it is actually solving the problem of type safety in web development fully.

ajkjk 4y ago
In particular, supporting nominal typing, fixing the way index types work, and fixing the story of debugging type failures on giant unions come to mind, but there are countless others. (Don't @ me, my day job is a few versions behind and I can't remember what's in the latest version, but there are plenty of other things if not these.)
- culi 4y ago
  Yeah I think the new `satisfies` operator and improvements to type inferences in the latest version likely resolve a lot of your concerns. TypeScript also supports some really advanced typing I've yet to see in other languages like template literal types (don't @ me, I mostly work with dynamic languages at my current job). I feel like even the TS docs haven't caught up to the full power of TS's full featureset
- svieira 4y ago
  FYI, TypeScript already supports nominal types, but the ways in which you "spell" `nominal` are a little unintuitive: 1. Use an enum 2. Use an intersection with an enum and literally anything else (except a number) 3. Use a private field (only works with classes) 4. Use a `declare const FOO: unique symbol` keyed object intersected with anything else (works with everything including numbers, lots of boilerplate to declare a new nominal type).
  - ajkjk 4y ago
    I'm aware of some of those, but I think they're all suboptimal compared to actual nominal types. In particular iirc you can't use your nominal/branded type as a map key in a type-safe way.

smasher164 4y ago

My favorite language in this category is MLscript. The best part is that type-checking it is decidable! https://github.com/hkust-taco/mlscript https://github.com/hkust-taco/mlscript

no_wizard 4y ago

how is it getting worse, exactly? I know it has features (all of which are optional) that can auto-generate code, but it _doesn't_ require being used. You can, and largely most do, use it just for the syntax for typing. Is there something inherent with TypeScript that is causing issues that you can point to?

thiht 4y ago

That’s not my experience. If anything, I think the Typescript experience improves with each release: typings get more precise, the type system becomes more expressive and allows to simplify the type declarations that used to be more complex, and best of all, what worked before still works. And in most cases, you’re good to go with the basics, you just know that if you need to declare a complicated type, Typescript got your back.

esperent 4y ago
I agree that Typescript improves with each release as I and the people I work closely with use it, because we use the KISS approach to typing so we rarely do use new features, but when we do need them they're useful. But then I find some third party code which seems to use the kitchen sink approach to typing, AKA the "look at how smart we are" approach, and it's a nightmare to understand. A type system is supposed to make code easier to work with, by the time you're spending more time understanding the types than the actual code there's something wrong. In these cases I wish Typescript was more limited and I would gladly give up a lot of the new stuff to enforce simple types across the ecosystem. That said, I don't really have an opinion on who is at fault here - coders for writing overly elaborate types, or Typescript for allowing them.
- citrons 4y ago
  Also agree, with each release I get an "Eureka effect" that now I can solve the type issue I strugled couple months ago trying to create to just make some highly used function safer/easier to use for the developers. Example the new satisfies and some upcomign "as const" features to generics I'm looking forward to
- goto11 4y ago
  > That said, I don't really have an opinion on who is at fault here - coders for writing overly elaborate types, or Typescript for allowing them. Backwards compatibility is to blame. Typescript was designed to support a number of patterns which was already used in JavaScript. For example events are registered in the DOM like `element.addEventListener("click", (ev) => ...)`. The type of the callback will depend on the string passed as the first argument, so the type system need to support literal strings as type discriminators which is a weird feature not necessary in most other languages. If the API had been designed with static typing in mind from the beginning, it would have been designed differently and wouldn't need such a complex type system.

ywei3410 4y ago

Have you heard of ReScript [1]? [1] https://rescript-lang.org/ https://rescript-lang.org/

MuffinFlavored 4y ago

> typescript is already way too complicated and getting worse thanks to its velocity Is it safe to say a non-zero portion of "the community" is headed the direction of: write it in _____ + compile it to WASM + glue DOM stuff to it with some sort of JS bridge?

peatfreak 4y ago
This sounds interesting to me, especially as somebody who was exactly zero interest in learning anything other than regular JS (i.e., no TypeScript, CoffeeScript, or any other JS-extension languages). Is this some kind of pattern, and do you know of any examples that show this?
- giobox 4y ago
  I see a comment like this every time someone mentions WASM and have to eye-roll a little. Yes transpile-to-WASM techniques exist, but as someone like yourself with a self-professed inability to learn TypeScript, I don't think you are going to enjoy living on the edge of webdev with WASM either... The tooling is nowhere near as mature for one, which is always problematic when starting from a position of little knowledge. Just search github.com and you will find countless example repos for many languages, but understanding typescript first is probably a more productive use of most people's time. If you work in web-tech, I consider avoiding JS and TS to be almost negligent to some extent in 2022.
  - deleted 4y ago
    [deleted]

Waterluvian 4y ago

The thing about TypeScript (or any language) is that one needs to recognize that many features aren’t for us normals. They’re for library developers doing all kinds of wild type stuff. I remember my eyes glazing over at the template literal typings and such. But someone on the discord was like, “if it seems overwhelming, you’re probably not the audience. But you’ll end up using it by using a library that leverages it.” Always check ts-essentials for the ideal abstractions built with the wild new features.

kupopuffs 4y ago

Is it honestly more complicated than, say, a browser?

scotty79 4y ago

The funny thing is that TypeScript still has some way to go to be capable of fully expressing JS semantics. This shows that even most complex statically typed languages are way simpler than some dynamic languages.