5 ms·

One thing I'm wondering: with all the bells and whistles and insanely complex things TS now supports, why does it still fail to catch seemingly simple mistakes?

One thing I'm wondering: with all the bells and whistles and insanely complex things TS now supports, why does it still fail to catch seemingly simple mistakes? For instance, it's sooo easy to write a React component taking in another component as a prop and some props for that other component, to rendering it. But somehow lose the type safety of the props being passed in. Like, you write some generics and the compiler stops complaining inside your component. But if you go back out and then try to pass some weird props instead, it doesn't care. I feel it's too easy to write code that looks tyoe safe but subtly isn't.

valenterry 5y ago
I'd say it's two things: 1. Typescript has to work with Javascript, which inherently makes things difficult and you have to choose between correctness or ergonomics. TS went for the latter, which probably was a good decision, otherwise no one would use it now. 2. While I have a lot of respect for the creators of TS, the language is not very consistent and uses a lot of "special cases" or "special features" to solve specific problems. But it also means that it becomes hard to ensure that all these features work together well and in the way that users expect. Other languages lack features that TS offer, but they feel more "consistent" or reliable.
- nuerow 5y ago
  > [TypeScript] is not very consistent and uses a lot of "special cases" or "special features" to solve specific problems. That's very interesting. Could you please provide an example that showcases that inconsistency?
  - valenterry 5y ago
    This very post is a good example. Typescript has destructuring and control-flow analysis/refinement. But as you can see from the issues that are fixed by this PR, these two things haven't worked together very well. This comes from trying to fix 1) compiler errors in conditions where the code is safe but the compiler can't understand that and 2) destructuring products/co-products. Even if both features work on their own and help in certain cases, combining them leads to undesired results.
    - bryanrasmussen 5y ago
      >as you can see from the issues that are fixed by this PR, should there be a link to a PR in there somewhere?
      - nextaccountic 5y ago
        The PR is the article submitted in this thread, https://github.com/microsoft/TypeScript/pull/46266 https://github.com/microsoft/TypeScript/pull/46266
        bryanrasmussen 5y ago
        ah ok, thanks. The phrase 'this PR' confused me.
- vesuvianvenus 5y ago
  Just a side note / counter note: >"While I have a lot of respect for the creators of TS," Creators of TypeScript are Microsoft. To any readers unfamiliar with TypeScript and Microsoft's ethics, be sure to research their past corporate ethics to understand whether or not they are trustworthy as a company (or at least those who lead their overarching market strategies. Here is one example, and to me, it describes where TypeScript is going (imho): "The strategy's three phases are: ---> Embrace: Development of software substantially compatible with a competing product, or implementing a public standard. ---> Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the "simple" standard. ---> Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions." https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... For this reason, out of sheer convictions in anti-unethical corporate behavior, I steer clear of TypeScript, and I encourage others to do so as well-- especially those who care about corporate ethics.
  - valenterry 5y ago
    What I meant is, I respect the technical competency of the people who designed TS the programing language. I agree that Microsoft's influence should be observed and considered carefully.
pjmlp 5y ago
Because Typescript only exists on the compiler, while the browser only undestands JavaScript, it is the usual problem of guest languages, the platform leaks.
- capableweb 5y ago
  Well, you could, if people really wanted to, have some sort of runtime type safety, but doesn't seem like that's what people want for various reasons, one thing could be the possible performance impact. Instead, TypeScript only offers type safety at development time. It seems matsemann fundamentally missed the idea of TypeScript, as it's very clear it only offers compile-time checks and nothing for the runtime.
  - pjmlp 5y ago
    Ideally one day TypeScript would take JavaScript's place, but no browser vendor seems keen on the idea. On the other hand, TypeScript success in adoption is based on following another proven attempts, C++ and Objective-C. With such approaches, the warts of the copy-paste compatibility with the underlying platform are both a sin and a curse.
    - capableweb 5y ago
      > Ideally one day TypeScript would take JavaScript's place, but no browser vendor seems keen on the idea. Oh god I hope not. JavaScript is hopefully here to stay, and will remain the runtime of the web together with WASM. TypeScript is a neat idea for enterprise companies where engineering standards tend to not be that great, but that doesn't mean we should lower the possibilities of the current runtime to the lowest common denominator.
      - pjmlp 5y ago
        It would still be possible to write JavaScript like code, that is Typescript selling point vs CoffeeScript and Dart, so I don't see a problem with it.
  - 5y ago
mdip 5y ago
> it's sooo easy to write a React component taking in another component as a prop and some props for that other component ... but somehow lose the type safety of the props being passed in. Previous comments interpreted this, I think, as "why don't I have type safety at runtime." Obviously, it's really little more than a very powerful static analyser on top of a superset of JavaScript. I'm not certain you were asking that; without a little more specifics to what you were trying to do or a code example, I'm not positive I'm understanding the issue you're describing correctly, but I think you're saying that in certain cases, with a React component where another React component is being passed as a parameter, along with other props, you can still reference the root component somewhere else with the wrong parameters and TypeScript doesn't complain. Personally speaking, I have never written React without TypeScript in the last 3 years and have spent about half of my work time in that space. If you haven't taken a recent look and tried the scenario you describe in the latest version of the language, I'd suggest starting there. I remember, early on -- way prior to Hooks and the like -- we were looking at various tooling options around state management (react-redux/mobx/others) to use for a large project and ended up not choosing react-redux due to it being impossible/almost-impossible to get type safety in some cases[0]. Ninety-nine percent of the time when `tsc` fails to produce an error/indicate something useful to you in your IDE of choice like this, it's because implicit typing couldn't figure something important out and the project's configuration was set lax enough to quietly ignore it. One easy fix for me was to go full `strict`; disallow `any`. When typing can't be determined implicitly, you get a shiny error. This leads to the second thing that becomes necessary: providing types explicitly for functions/others -- in certain cases, sometimes because it doesn't work without it, sometimes just to have it clearly defined/obvious. Type aliases help a lot for drying things up and keeping the "type noise" to a minimum. It's also possible that whatever tooling you're using to package/build things is interfering in some way (or publishing the result of the compile regardless of errors/warnings). The strictest settings will bring a lot of new errors, and you'll probably be adding a lot of type info and adjusting code accordingly if you enable these in a project that was more lax, however, I've found it's usually worth it. The issues tend to also bring visibility to a really subtle bug or ... fifteen. Run the latest versions of TS -- improvements around this come constantly. And these days, support for TS on the library side is very solid[1]. Of course, it's still based on a dynamic language and has dynamic elements to it. It's always possible to violate the type system (heck, you can toss a comment in and violate it on a given line if you wish), but the problem you're describing I haven't remembered being a large source of grief, and most of the issues I used to run into from time to time aren't issues in recent versions. If I misread your scenario, let me know; I've been pretty amazed at the kinds of things I can express with their type system and how well its compiler enforces those things[2] so I'm curious about where it really falls down. [0] The specifics elude me, but I recall it had to do with the line that wrapped the component; this was three years ago and I had never re-examined the issue after that. [1] Though I'd not encountered a component/library that I couldn't find a solid alternative to or workaround in some way to get it working in TS. [2] It'd be nice if those extended in a manner that would handle things one encounters with Json data not quite matching up type-wise but a lot of that is because "it doesn't know how the object is going to be used/loaded at runtime" and you can't really expect it to do so.

valenterry 5y ago

I'd say it's two things: 1. Typescript has to work with Javascript, which inherently makes things difficult and you have to choose between correctness or ergonomics. TS went for the latter, which probably was a good decision, otherwise no one would use it now. 2. While I have a lot of respect for the creators of TS, the language is not very consistent and uses a lot of "special cases" or "special features" to solve specific problems. But it also means that it becomes hard to ensure that all these features work together well and in the way that users expect. Other languages lack features that TS offer, but they feel more "consistent" or reliable.

nuerow 5y ago
> [TypeScript] is not very consistent and uses a lot of "special cases" or "special features" to solve specific problems. That's very interesting. Could you please provide an example that showcases that inconsistency?
- valenterry 5y ago
  This very post is a good example. Typescript has destructuring and control-flow analysis/refinement. But as you can see from the issues that are fixed by this PR, these two things haven't worked together very well. This comes from trying to fix 1) compiler errors in conditions where the code is safe but the compiler can't understand that and 2) destructuring products/co-products. Even if both features work on their own and help in certain cases, combining them leads to undesired results.
  - bryanrasmussen 5y ago
    >as you can see from the issues that are fixed by this PR, should there be a link to a PR in there somewhere?
    - nextaccountic 5y ago
      The PR is the article submitted in this thread, https://github.com/microsoft/TypeScript/pull/46266 https://github.com/microsoft/TypeScript/pull/46266
      - bryanrasmussen 5y ago
        ah ok, thanks. The phrase 'this PR' confused me.
vesuvianvenus 5y ago
Just a side note / counter note: >"While I have a lot of respect for the creators of TS," Creators of TypeScript are Microsoft. To any readers unfamiliar with TypeScript and Microsoft's ethics, be sure to research their past corporate ethics to understand whether or not they are trustworthy as a company (or at least those who lead their overarching market strategies. Here is one example, and to me, it describes where TypeScript is going (imho): "The strategy's three phases are: ---> Embrace: Development of software substantially compatible with a competing product, or implementing a public standard. ---> Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the "simple" standard. ---> Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions." https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... For this reason, out of sheer convictions in anti-unethical corporate behavior, I steer clear of TypeScript, and I encourage others to do so as well-- especially those who care about corporate ethics.
- valenterry 5y ago
  What I meant is, I respect the technical competency of the people who designed TS the programing language. I agree that Microsoft's influence should be observed and considered carefully.

pjmlp 5y ago

Because Typescript only exists on the compiler, while the browser only undestands JavaScript, it is the usual problem of guest languages, the platform leaks.

capableweb 5y ago
Well, you could, if people really wanted to, have some sort of runtime type safety, but doesn't seem like that's what people want for various reasons, one thing could be the possible performance impact. Instead, TypeScript only offers type safety at development time. It seems matsemann fundamentally missed the idea of TypeScript, as it's very clear it only offers compile-time checks and nothing for the runtime.
- pjmlp 5y ago
  Ideally one day TypeScript would take JavaScript's place, but no browser vendor seems keen on the idea. On the other hand, TypeScript success in adoption is based on following another proven attempts, C++ and Objective-C. With such approaches, the warts of the copy-paste compatibility with the underlying platform are both a sin and a curse.
  - capableweb 5y ago
    > Ideally one day TypeScript would take JavaScript's place, but no browser vendor seems keen on the idea. Oh god I hope not. JavaScript is hopefully here to stay, and will remain the runtime of the web together with WASM. TypeScript is a neat idea for enterprise companies where engineering standards tend to not be that great, but that doesn't mean we should lower the possibilities of the current runtime to the lowest common denominator.
    - pjmlp 5y ago
      It would still be possible to write JavaScript like code, that is Typescript selling point vs CoffeeScript and Dart, so I don't see a problem with it.
- 5y ago

mdip 5y ago

> it's sooo easy to write a React component taking in another component as a prop and some props for that other component ... but somehow lose the type safety of the props being passed in. Previous comments interpreted this, I think, as "why don't I have type safety at runtime." Obviously, it's really little more than a very powerful static analyser on top of a superset of JavaScript. I'm not certain you were asking that; without a little more specifics to what you were trying to do or a code example, I'm not positive I'm understanding the issue you're describing correctly, but I think you're saying that in certain cases, with a React component where another React component is being passed as a parameter, along with other props, you can still reference the root component somewhere else with the wrong parameters and TypeScript doesn't complain. Personally speaking, I have never written React without TypeScript in the last 3 years and have spent about half of my work time in that space. If you haven't taken a recent look and tried the scenario you describe in the latest version of the language, I'd suggest starting there. I remember, early on -- way prior to Hooks and the like -- we were looking at various tooling options around state management (react-redux/mobx/others) to use for a large project and ended up not choosing react-redux due to it being impossible/almost-impossible to get type safety in some cases[0]. Ninety-nine percent of the time when `tsc` fails to produce an error/indicate something useful to you in your IDE of choice like this, it's because implicit typing couldn't figure something important out and the project's configuration was set lax enough to quietly ignore it. One easy fix for me was to go full `strict`; disallow `any`. When typing can't be determined implicitly, you get a shiny error. This leads to the second thing that becomes necessary: providing types explicitly for functions/others -- in certain cases, sometimes because it doesn't work without it, sometimes just to have it clearly defined/obvious. Type aliases help a lot for drying things up and keeping the "type noise" to a minimum. It's also possible that whatever tooling you're using to package/build things is interfering in some way (or publishing the result of the compile regardless of errors/warnings). The strictest settings will bring a lot of new errors, and you'll probably be adding a lot of type info and adjusting code accordingly if you enable these in a project that was more lax, however, I've found it's usually worth it. The issues tend to also bring visibility to a really subtle bug or ... fifteen. Run the latest versions of TS -- improvements around this come constantly. And these days, support for TS on the library side is very solid[1]. Of course, it's still based on a dynamic language and has dynamic elements to it. It's always possible to violate the type system (heck, you can toss a comment in and violate it on a given line if you wish), but the problem you're describing I haven't remembered being a large source of grief, and most of the issues I used to run into from time to time aren't issues in recent versions. If I misread your scenario, let me know; I've been pretty amazed at the kinds of things I can express with their type system and how well its compiler enforces those things[2] so I'm curious about where it really falls down. [0] The specifics elude me, but I recall it had to do with the line that wrapped the component; this was three years ago and I had never re-examined the issue after that. [1] Though I'd not encountered a component/library that I couldn't find a solid alternative to or workaround in some way to get it working in TS. [2] It'd be nice if those extended in a manner that would handle things one encounters with Json data not quite matching up type-wise but a lot of that is because "it doesn't know how the object is going to be used/loaded at runtime" and you can't really expect it to do so.