Hacker News Reader

Comment by spriggan3 | Hacker News Reader

    let lowerCased = strs!.map(s => s.toLowerCase());

I'm not a big fan of this, it's really starting to change JS semantics. It's not just type annotations anymore + ES6 . It's starting to look like its own language. Some might like that, I do not.

They should be a bit more cautious before introducing these features. What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? It's like decorators, they are not in the spec, there is no plan yet to officially had them to the spec, yet, Angular2 which is written in Typescript abuse them. What if in 2 years they are introduced in ES2019 with different semantics ? How Typescript is going to handle that too ?

View on HN

This post is full of misplaced FUD.

> It's not just type annotations anymore + ES6

How not?

! is just an inline type coercion.

> What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ?

This seems unlikely because ! is already an operator in JS.

But really, this argument could be made against any operator TS uses. What if ES introduces : as an operator? Or if they introduce some sort of ambiguity with the other myriad type definitions? This is not a new issue, and you shouldn't let null checks drive you away from the language.

In any case, both null checks and decorators are behind flags. The decorators flag is literally called "experimental decorators". So it's not like the TS team is pretending that it's going to be stable forever.

>! is just an inline type coercion.

Are you sure about that? It sounds more like a signal to the compiler to "trust me, I know what I'm doing" and would blow up if you passed undefined anyway. Maybe the author didn't explain it very well. That is, not a type coercion so much as a hint to not bother checking this access.

When would code with ! ever compile differently than code without ! ?

Umm never? That's not the point. It's not changing (coercing) the type of anything, it's just allowing the call without flagging it as an error. The call at run time might still get passed an undefined and fail. It's like choosing an unsafe partial function in Haskell rather than using a total function that forces you to deal with Maybe.

At least that's what it looks like. I've never used typescript or I'd test it right now. I'm on my phone and haven't tried it.

(Edit: my answer didn't quite make sense! It's different since without ! it compiles as an error because, in this case, you can't map over undefined. With !, it just ignores that possibility although it could still happen. The compiler cannot verify all run time possibilities since your sum type says it really can be undefined.)

(Re edit! Verifying the types vs skipping that verification is not the same thing as coercing the types)

It's coercing the type from, e.g. String | undefined to String.

  let lowerCased = (s : string[] | undefined) => s!.map((str : string) => str.toLowerCase());

  console.log(lowerCased(['A','B']));
  console.log(lowerCased(undefined)); //boom!

It doesn't coerce anything. All it does is let the code pass without error. "s!.map" and "s.map" compile to the exact same Javascript code, which means there is no type coercion going on. Are you sure you know what type coercion is? The first log prints out fine and the second blows up, which proves that undefined isn't being coerced to a string[]. If that was the case, the resulting JS would be checking for undefined and probably creating an empty array.

My bad, I meant conversion, not coercion.

TypeScript has dealt with this in the past by adapting to the introduction of `<Foo>` from jsx, which clashed with typescript's casting operator. If this ends up being a problem I'm sure that the TypeScript team will just pick a different syntax.

In my experience, the overhead caused by TypeScript is far outweighed by benefits in tooling and confidence that my code works (mostly) after refactors.

AFAIK, this is actually happening with decorators, which have changed a lot in how they're defined (the latest I can find is the actual spec changes: https://github.com/tc39/proposal-decorators/commit/c32ea1815...)

Even so, I've been pretty impressed with the TypeScript teams ability to manage this kind of change an uncertainty and keep up with and move closer to standard JavaScript where they have been differences.

Specifically regarding the `!` operator* , to convert to standard JavaScript just remove the `!` operator, like you would remove a cast or type annotation. It's still within the TypeScript spirit to me.

* I personally would have rather seen it either be a type of cast (maybe `<!>strs.map(...);`), or add a null-safe property accessor: `strs?.map(...)` which doesn't assert that `strs` is non-null, but makes the expression null-safe, returning null if `strs` is null.

That null-safe property accessor (`?`) is being discussed for ES, and it's reasonable to assume that it will ship eventually. They wouldn't add that and risk having different semantics.

Being realistic, it might take more than a decade to see a standard EcmaScript version with type annotations available in all major browsers. Until then, transpiling is the only choice. So I don't think diverging from the (possible) standard is too bad. We don't know how the state of web development will be at that time, and probably the standar won't ever catch up with TypeScript and transpiling will be required for quite a long time until something like WebAssembly really takes off.

The type definitions in flow are pretty much the same iirc. Also decorators is already an ES proposal, the only concern was the order of application of decorators vs declaration, they've been applied pretty consistently.

As to the additional checks for non-null types, I'd say that async/await would be far more welcome at this point... it's one of the few reasons that those using TS are still running their output through babel after.

Personally, I'm not a fan of TS, but can see why others would like it... I'm pretty good with ES2016 + Stage-1 via Babel...

I don't plan to use that feature. If they remove or change it, my code will still work.

Typescript is a superset of Javascript, but it it's not only Javascript plus types. Some features like async/await could end up being implemented differently in Ecmascript. It seems inevitable that there could be incompatibilities in the future. But the same happens with Babel or other transpilers when they introduce features that are not yet standardized.

Do you have the same complaints about optional parameters too?

    let x = (id: number, name?: string) => { return; };

Is it abuse to use interfaces as well? They are not present in vanilla JS.

How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes?

Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also count as abuse?

I won't even get into generics as that's a whole different can of worms.

Microsoft and the TS team have issued a mandate that TypeScript will always be a superset of EcmaScript and if ES2019 includes decorators that are incompatible with TypeScript's then it will be addressed at that time.

TypeScript was never meant to be just type annotations+ES6, there is Flow[1] for that.

[1] https://flowtype.org/

> let x = (id: number, name?: string) => { return; };

hmm, it would make more sense if it was written like that

> let x = (id: number, name: string?) => { return; };

But I guess it's more or less ok. But I definitely feel inconfortable with the ! .

> How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes?

I don't use React.

> Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also count as abuse?

The probability is higher for ES to implement async/await than the ! operator. The former is a safe bet, the latter isn't, by a long shot.

> Microsoft and the TS team have issued a mandate that TypeScript will always be a superset of EcmaScript and if ES2019 includes decorators that are incompatible with TypeScript's then it will be addressed at that time.

It means that language will break. Not very good if you write large TS codebases today.

> TypeScript was never meant to be just type annotations+ES6, there is Flow[1] for that.

That's your opinion. I'm not interested in Flow.

Ultimately TS is successful because it more or less looks like Action Script 3/ES4/JScript.net and javascript itself. Make it too Alien and the people who refused to use Coffee script because of its semantics will not want to use TS. And FYI I use TS today. I may reconsider that.

> > let x = (id: number, name?: string) => { return; };

> hmm, it would make more sense if it was written like that

> > let x = (id: number, name: string?) => { return; };

> But I guess it's more or less ok. But I definitely feel inconfortable with the ! .

I think the point is that typescript currently supports the shown optional parameter syntax, JS could be extended in a conflicting way to that as well.

In the end, if you are using something that extends JS and you expect that any code you write will continue to work in future versions and that the tool will be altered to stay as close to the standard JS as possible as extended features are incorporated into vanilla JS, you're most likely deluding yourself. Much better to accept that the tool should either try to match vanilla JS, in which case you must accept that you may need to refactor to update occasionally, or that it will eventually diverge, but your code will continue to work, and choose a tool that implements whatever strategy is acceptable to you.

Personally, I'd love to see some of the operators that F# has make it into ES stage-0 proposals...

    |> 
    <| 
    combinedFn = function1 >> function2

etc... Though the last is mostly handled with fat-arrow syntax

> I'm not interested in Flow.

Curious: Why not?

I'm not him, but the Flow compiler not supporting Windows is a dealbreaker for some.

Thanks. The Flow team is planning to announce official Windows support, hopefully in the next few weeks.

Is there a reason to use Flow rather than Typescript now?

It seems to have interprocedural type inference, which is really cool, but I'm not sure that's a feature I'd even want in Typescript, since I feel like it would make code less self documenting.

Overall it seems like there is more community support for Typescript than Flow, which is essentially just group inertia, but it makes me not want to switch.

You're right, it was never meant to just be annotations+ES6. Though when you talk to someone about TypeScript, they'll argue until they're blue in the face that its just "ES6 with types". I guess you can argue semantics here, but don't be too surprise people will argue back that way.

Uhh, yes it is meant to be just annotations + ES6.

https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

The exclamination is a forced cast to another type, just like "x as otherType". So this is still in the same category.

Well it depends how you use it also. To them it really could be ES6 with annotations.

There is no difference between TypeScript's and Flow's design goals. Flow using the same extension as regular JavaScript is just a dirty marketing trick. Microsoft would be lynched for "embrace-extend-extinguish" if they did the same.

But since its Facebook, its completely fine that they're trying to co-opt standards. No problem at all.

Agreed – this may now be my top reason not to use TypeScript (followed by inadequate inference / support for gradual typing, differences from Babel, and a few random features), which I would otherwise very much like to use.

This is a poor reason to not use TS.

If in the unlikely worst case scenario the TS team drops/renames the ! syntax at some point, given that these are compile time checks, you will just manually go through a list of compile time errors and fix the issues one by one.

More likely scenarios:

- They will make the change in a backwards-compatible way

- They will release a jscodeshift script to do the upgrade for you

- Etc.

Okay, fair. Perhaps I overreacted.

I think the general idea of adding syntax outside of declarations really rubs me the wrong way, but perhaps it shouldn't.

I agree, I feel like this is becoming kotlin (not a bad thing) but the syntax is quite a divergence from es5+types less so with es6 but your sentiments are bang on

Reply on news.ycombinator.com