Hacker News Reader

Comment by matsemann | Hacker News Reader

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.

View on HN

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.

> [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?

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.

>as you can see from the issues that are fixed by this PR,

should there be a link to a PR in there somewhere?

The PR is the article submitted in this thread, https://github.com/microsoft/TypeScript/pull/46266

ah ok, thanks. The phrase 'this PR' confused me.

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

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.

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

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.

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.

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

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.

My point is that I can change what I pass in in my code, and the compile time check doesn't catch it. I haven't "fundamentally missed" anything, it's you misreading my post, thanks.

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

FWIW, today we specifically teach and recommend the React-Redux hooks API as the default, and one of the major reasons is that it works _so_ much better with TypeScript than the earlier `connect` API:

https://redux.js.org/tutorials/typescript-quick-start

I think you understood me correctly. Thanks for the various thoughts.

A bit hard to provide an mvc of the issue I'm thinking of. But I often see it happen with HOC kinda stuff. Like I might have a loader component, that I pass three things to: the query to run, a component to render, and some additional props to the component to render. The render component will get the props, plus the result of the query as well.

When adding typing to this, ts will naturally complain. So fix that by adding generics etc. And then everything looks fine according to the ts compiler, so you're happy.

But if you try to change the typing of the inner component, or some type of the props being sent to the outer component, you might find that ts is still happy. Somewhere along the line, it decided to throw its hands up and allow everything. So the typing is just complex noise, not catching subtle bugs.

Of course, people could easily write a correct example handling this. But the problem is that there are so many complex ways to solve stuff in ts, and some of them are wrong even though they look correct.

Some of it might be fixed using a stricter setup as you mention.

Reply on news.ycombinator.com