6 ms·

I very rarely see TypeScript developers actually use `any` (usually to reflect something like something parsed from arbitrary JSON that needs to be interrogated

I very rarely see TypeScript developers actually use `any` (usually to reflect something like something parsed from arbitrary JSON that needs to be interrogated rather than just type-asserted) and in my experience it's a rare shop that doesn't use `strict` for everything to at least force it to be called out and checked in code review. `undefined` and `null` seem conventionally used to mean different things amongst the TypeScript developers I know. `null` is typically used to denote something that is consciously known to be nonexistent; `undefined` is not rarely, in my experience, used at all except as a check against something coming in from untyped modules. I'm sure there are people who honor this more in the breach than the observance, but this is pretty consistent in my experience. Personally, I've moved to TypeScript for most of my personal projects, away from both Ruby and C#, and it's fantastic. (Some things remain more appropriate for the JVM, typically Kotlin, but that's OK, too.)

knocte 8y ago
> I very rarely see TypeScript developers actually use `any` whoaboy, I guess you only work with people convinced about the value of TS (or types in general), but if your colleagues are a bunch of javascript fanboys, the only thing they will do is rename their .js files to .ts files and be done... "tada!!!" (this is not a fucking joke, TS allows this madness, just rename and compiles!)
- nrb 8y ago
  What's madness about this? TypeScript is a superset of Javascript, meaning any valid Javascript is automatically valid TypeScript. If you want to force type declarations, enable strict mode.
- ovao 8y ago
  The ability to incrementally adopt strict static type checks is a feature of TypeScript, without which TypeScript wouldn’t have seen much adoption. Without adoption, you’d not see library typings and TS-native projects, rendering it fairly useless.
  - knocte 8y ago
    It's funny, I think the features it has that allow "incremental adoption" are the ones that make decent developers stay away from it.
    - ascorbic 8y ago
      Then enable strict mode. What's the problem? My general rule is strict mode for new projects, but not for old ones that are being migrated. When they're fully migrated you can enable strict mode.
    - knocte 8y ago
      Re @ascorbic, dude that works for me, but not for the vast majority of devs out there. strict should be default! I don't want to come to a team and start evangelising or fixing their fucking compiler errors which could take me ages.
      - manigandham 8y ago
        So again, you have a people problem and not a tech problem.
      - 59nadir 8y ago
        `"strict": true` is default on `tsc --init`.
      - heisenbit 8y ago
        This is understandable, however there are many projects you can join that got to the point where they can afford paying you by taking a few shortcuts. We are all standing on the shoulders of giants and these giants have been standing there for a while - they are anything but clean but they are standing tall.
    - scrollaway 8y ago
      Your issue is with the developers, not the language. Stop working with bad devs. And honestly you should revise your own attitude as well, it's a poor worksman who blames his tools. What you keep complaining about in TS is the rigid backwards compatibility which, should it not be there, you'd probably be the first one to post angry comments about. Your assertion that decent devs stay away from typescript is incorrect. If you think staying away from it makes you personally a decent dev, yikes.
- eropple 8y ago
  Yes, I do tend to work with people who have a sober understanding of their tools. I've also incrementally ported codebases from JS to TS and have used `any` as a stopgap myself. As we made changes, we firmed up our type definitions. It is profoundly not a big deal, and it is not "madness"--it's how you get large projects onto the goddamned rails.
- Jach 8y ago
  What got the devs to behave that way, just renaming? I'd wager one likely possibility is an architect made a decision on high for "and so now all will be TS, because TS is Good" without much internal support but enough political power to make it so, at least on paper. Of course things aren't going to go well in that case. Incrementalism isn't a benefit when there's not a broad desire to change to the new thing, it just adds to the mess. Such projects would be better served sticking with pure JS and making that better.
dvlsg 8y ago
> I very rarely see TypeScript developers actually use `any` (usually to reflect something like something parsed from arbitrary JSON that needs to be interrogated rather than just type-asserted) Even that example usage of `any` should be less common, now. I think `unknown` (which is fairly new) is better there.
- Zarel 8y ago
  Is it? My impression is that `unknown` type doesn't solve that specific problem. const out: unknown = JSON.parse("{a: 1}"); if (out && typeof out.a === 'number') console.log(out.a); gives the error: [ts] Object is of type 'unknown'. [2571]
  - charrondev 8y ago
    Pretty sure you’re missing a typeof check for ‘out’.
    - Zarel 8y ago
      I'm pretty sure I'm not. const out: unknown = JSON.parse("{a: 1}"); if (typeof out === 'object' && out && typeof out.a === 'number') { console.log(out.a); } gives the error: [ts] Property 'a' does not exist on type 'object'. [2339] It's a completely unnecessary check, anyway: `out &&` is sufficient to exclude `null` and `undefined`, which is all that's needed to ensure that `out.a` won't crash. I challenge you to give a single input to `JSON.parse` that would crash my code without the `typeof` check.
      - charrondev 8y ago
        I see what you mean. I guess unknown just doesn't work that well with inline type checks for objects, although in that case you probably want a function anyways. Using the `in` return type you can do something like this: const out: unknown = JSON.parse("{a: 1}"); interface MyStructure { a: number; } function isMyStructure(toCheck: unknown): toCheck is MyStructure { return toCheck instanceof Object && 'a' in toCheck; } if (isMyStructure(out)) { console.log(out.a); } This will give you no type errors, and gives you the benefit of having a re-usable function for this validation. I just discovered this today. I seem to have missed it in a recent release note.
bpicolo 8y ago
> I very rarely see TypeScript developers actually use `any` I mostly use it to cheat when instantiating / using HoCs. Across various packages, they are rarely entirely correctly typed.

knocte 8y ago

> I very rarely see TypeScript developers actually use `any` whoaboy, I guess you only work with people convinced about the value of TS (or types in general), but if your colleagues are a bunch of javascript fanboys, the only thing they will do is rename their .js files to .ts files and be done... "tada!!!" (this is not a fucking joke, TS allows this madness, just rename and compiles!)

nrb 8y ago
What's madness about this? TypeScript is a superset of Javascript, meaning any valid Javascript is automatically valid TypeScript. If you want to force type declarations, enable strict mode.
ovao 8y ago
The ability to incrementally adopt strict static type checks is a feature of TypeScript, without which TypeScript wouldn’t have seen much adoption. Without adoption, you’d not see library typings and TS-native projects, rendering it fairly useless.
- knocte 8y ago
  It's funny, I think the features it has that allow "incremental adoption" are the ones that make decent developers stay away from it.
  - ascorbic 8y ago
    Then enable strict mode. What's the problem? My general rule is strict mode for new projects, but not for old ones that are being migrated. When they're fully migrated you can enable strict mode.
  - knocte 8y ago
    Re @ascorbic, dude that works for me, but not for the vast majority of devs out there. strict should be default! I don't want to come to a team and start evangelising or fixing their fucking compiler errors which could take me ages.
    - manigandham 8y ago
      So again, you have a people problem and not a tech problem.
    - 59nadir 8y ago
      `"strict": true` is default on `tsc --init`.
    - heisenbit 8y ago
      This is understandable, however there are many projects you can join that got to the point where they can afford paying you by taking a few shortcuts. We are all standing on the shoulders of giants and these giants have been standing there for a while - they are anything but clean but they are standing tall.
  - scrollaway 8y ago
    Your issue is with the developers, not the language. Stop working with bad devs. And honestly you should revise your own attitude as well, it's a poor worksman who blames his tools. What you keep complaining about in TS is the rigid backwards compatibility which, should it not be there, you'd probably be the first one to post angry comments about. Your assertion that decent devs stay away from typescript is incorrect. If you think staying away from it makes you personally a decent dev, yikes.
eropple 8y ago
Yes, I do tend to work with people who have a sober understanding of their tools. I've also incrementally ported codebases from JS to TS and have used `any` as a stopgap myself. As we made changes, we firmed up our type definitions. It is profoundly not a big deal, and it is not "madness"--it's how you get large projects onto the goddamned rails.
Jach 8y ago
What got the devs to behave that way, just renaming? I'd wager one likely possibility is an architect made a decision on high for "and so now all will be TS, because TS is Good" without much internal support but enough political power to make it so, at least on paper. Of course things aren't going to go well in that case. Incrementalism isn't a benefit when there's not a broad desire to change to the new thing, it just adds to the mess. Such projects would be better served sticking with pure JS and making that better.

dvlsg 8y ago

> I very rarely see TypeScript developers actually use `any` (usually to reflect something like something parsed from arbitrary JSON that needs to be interrogated rather than just type-asserted) Even that example usage of `any` should be less common, now. I think `unknown` (which is fairly new) is better there.

Zarel 8y ago
Is it? My impression is that `unknown` type doesn't solve that specific problem. const out: unknown = JSON.parse("{a: 1}"); if (out && typeof out.a === 'number') console.log(out.a); gives the error: [ts] Object is of type 'unknown'. [2571]
- charrondev 8y ago
  Pretty sure you’re missing a typeof check for ‘out’.
  - Zarel 8y ago
    I'm pretty sure I'm not. const out: unknown = JSON.parse("{a: 1}"); if (typeof out === 'object' && out && typeof out.a === 'number') { console.log(out.a); } gives the error: [ts] Property 'a' does not exist on type 'object'. [2339] It's a completely unnecessary check, anyway: `out &&` is sufficient to exclude `null` and `undefined`, which is all that's needed to ensure that `out.a` won't crash. I challenge you to give a single input to `JSON.parse` that would crash my code without the `typeof` check.
    - charrondev 8y ago
      I see what you mean. I guess unknown just doesn't work that well with inline type checks for objects, although in that case you probably want a function anyways. Using the `in` return type you can do something like this: const out: unknown = JSON.parse("{a: 1}"); interface MyStructure { a: number; } function isMyStructure(toCheck: unknown): toCheck is MyStructure { return toCheck instanceof Object && 'a' in toCheck; } if (isMyStructure(out)) { console.log(out.a); } This will give you no type errors, and gives you the benefit of having a re-usable function for this validation. I just discovered this today. I seem to have missed it in a recent release note.

bpicolo 8y ago

> I very rarely see TypeScript developers actually use `any` I mostly use it to cheat when instantiating / using HoCs. Across various packages, they are rarely entirely correctly typed.