Hacker News Reader

Comment by knocte | Hacker News Reader

I much prefer TypeScript than JavaScript, but TS can still allow shitty code, such as:

* Using the type 'any'.

* Using the immediate value `undefined` (JS is mental in the fact that it has two kinds of null... and with TS there's really no excuse for using this one, however TS compiler doesn't complain).

* Using very ugly, or very easy to be misleading, typeguards (granted, TS doesn't have decent typeguards, see https://github.com/Microsoft/TypeScript/issues/28337 ...).

For these reasons, I applaud JS people moving to TS. But I will not recommend any other people (non-JS) to use TS at all.

View on HN

This hasn’t been accurate for at least 2 years.

- Use the —noImplicitAny flag to prevent implicitly using any (and if you really want — I don’t think you do, but you can — completely ban any with TSLint)

- Use the —strictNullChecks flag to promote null and undefined to explicit types

Or, use —strict to do both of those and more.

Example tsconfig.json: https://github.com/bcherny/json-schema-to-typescript/blob/ma...

Btw, what specifically is indecent about TS’s type guards?

> Use the —noImplicitAny flag

Welcome to reality! When you do this in any decently-sized TS codebase, you want to kill yourself, because the "smart" devs that started the project didn't do it at the beginning, and fixing it now would take you a man month, in order to be able to enforce it moving forward.

> Use the —strictNullChecks flag

My previous reply also applies to this one, plus: you can still compare against undefined when using this flag (we're talking about unreadable code... even if comparing it with undefined wouldn't make any sense in a codebase with structNullChecks enabled, it's not a compiler error).

> Or, use —strict to do both of those and more.

My gripes above would only be solved if these strict modes were the default. Otherwise shitty and unfixable (read again: man months for a normal project) typescript code keeps being written.

> what specifically is indecent about TS’s type guards?

How about you read the link I posted?

You point out issues that are already solved. It's a people problem you have now :) no amount of configuration is going to fix that.

Also strict has been the default for quite a while!

> Also strict has been the default for quite a while!

That would prevent anyone to rename a .js file to .ts and compile successfully. Which I think is not the case today. Prove otherwise please.

https://github.com/Microsoft/TypeScript/commit/d3b7058c2999f... over a year.

Also, the allowJS compiler switch became the preferred approach for in-place migrations over mass renames. It makes it easier to opt in to strict type checking on a file-by-file basis.

https://www.typescriptlang.org/docs/handbook/migrating-from-...

I’ve migrated a pretty big codebase to TS, and then again to noImplictAny. One suggestion is to turn the flag on, migrate a few files, then turn it back off. When you’ve migrated a decent number of files, turn it on everywhere. For a really large codebase, you can do what companies like FB and Google do, and turn the flag on, then codemod every error to suppress it (either with @ts-ignore, or a type assertion). Note that you’ll have to follow a similar workflow for any language-level update- it’s not at all specific to TS.

Re: type guards, Daniel and everyone else in that thread gave a really reasonable response IMO. I think you might just be misunderstanding TS’s design goal of not affecting runtime behavior?

> and if you really want — I don’t think you do, but you can — completely ban any with TSLint

I dunno, on top of the correctness argument: if you successfully write a codebase without any in it, and assuming your data types and algorithms are sane, then the type stability probably would likely result in really good performance.

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

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

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]

Pretty sure you’re missing a typeof check for ‘out’.

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.

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.

Oh, yeah, that feature's existed for years; it's called "user-defined type guards".

https://www.typescriptlang.org/docs/handbook/advanced-types....

Unfortunately, it doesn't work in `checkJs` mode, and I always wish I could do it inline.

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

> But I will not recommend any other people (non-JS) to use TS at all

JavaScript, and increasingly in the Typescript flavor, is the language of the web. What real alternatives are there presently, that additionally gives a developer decent career opportunities?

TS vastly improves on JS in most aspects, while keeping a 100% compatibility with pure JS, i.e. you can just change the extension of a working .js file to .ts and instantly get access to the TS goodies.

You seem to complain about this compatibility, but a serious TS developer will not maintain such compatibility for long (will typically start restricting 'any' type, etc). This compatibility is the effect of the TS onboarding strategy, a crucial one at that.

The typeguards problem you mention is just one of the problems a JS/TS developer deals with as a matter of course, and will usually have solved by creating/using a utility library, something which JS notoriously requires, and something TS doesn't aspire to help you with, for the same above mentioned compatibility reasons.

> JavaScript, and increasingly in the Typescript flavor, is the language of the web. What real alternatives are there presently, that additionally gives a developer decent career opportunities?

As a Scala developer who realised the writing was on the wall for server-side rendering, I spent a good few months trying to use Typescript. It's decent, but the type system was still a huge step down from what I was used to.

A month or so ago I got around to trying Scala.js, and it was... nice, and oh so easy. Facades available for all the big-name javascript libraries. Write ordinary Scala code with the advanced type system and full IDE support that I was used to, and get the same ability to rule out huge classes of errors that I have on the server side.

So, Scala? It's controversial for many but it supports a lot of development styles, uses a runtime that already has a lot of enterprise backing (and will be able to interoperate with your existing libraries if you're a Java shop), and is also used for various bits of exciting newish technology (Kafka, Spark and the like). So it definitely has decent career opportunities.

>> but TS can still allow shitty code

No programming language can stop this. Your issue is with bad devs creating bad code.

>> Using the type 'any'.

Using 'any' is either for prototyping, truly dynamic data, or edge-case scenarios, but Typescript is still far better than having no types at all.

I moved our projects to ts in early 2013. Back then there where no strict null checks (imo main feature of any modern language) and typesystem was in infancy, but still it was totally worth it - our team could reason about code and nothing broke at runtime.

Now ts come long way. If your start any js project - start in on ts. And by god - enable full strict mode.

>* Using the type 'any'.

This is easily enforced in your tsconfig.json

Yeah but a decent tsc configuration is not default, so many people are still writing shitty typescript.

`"strict": true` is turned on by default when you run `tsc --init` and is recommended in every talk by everyone, including the TypeScript team... So I'm afraid the defaults are indeed sane and exactly what you want. I'm not sure much of what you've said in these threads really gels with reality so far.

For anyone confused: `"strict": true` in `tsconfig.json` just blanket enables all type checks, including future ones. You can then opt out of specific ones of your choosing if there's too much pain caused by the original authors, but none of those things are added by default. The TS team wants you to leave strict mode on.

To add to this, flow control analysis requires certain stict features. To be a bit obtuse; you want flow control analysis ergo you want strict :)

You are grasping at straws at this point. TypeScript is not the end all and be all of programming languages. It tweaks Javascript to be a little bit more sane, that's all. The kinds of people that seek out this sort of thing probably know whether or not to enable "any", and did so for their configurations. Either decision paves the way towards a cleaner future; those that started from zero and had "any" disabled on day 1, or those that are cleaning up a large codebase and are slowly making progress cleaning it up. TypeScript lets you be either person and lets you make your own decision.

It is clear to someone with even cursory knowledge of Javascript and TypeScript what options are available in this regard. Whatever the default is, people can probably make the right decision for their application. It's not hard and it's not hidden.

Have a pointer to a sane default tsconfig.json people could build upon?

Here's what I use:

    {
      "compilerOptions": {
        "target": "es6",
        "module": "commonjs",
        "outDir": "../dist",
        "declaration": false,
        "strict": true,
        "resolveJsonModule": true,
        "noImplicitAny": true,
        "noImplicitThis": true,
        "noImplicitReturns": true,
        "noUnusedLocals": true,
        "jsx": "react",
        "lib": [
            "es2017",
            "dom"
        ]
      },
      "compileOnSave": false,
      "buildOnSave": false
    }

Just turning on the --strict flag gets you most of the checks you want in a clean codebase.

https://www.typescriptlang.org/docs/handbook/compiler-option...

I find 'any' useful as a temporary placeholder for third-party data while I figure out what I've got. I wouldn't mind if linters throw errors at it, though.

In what little TS experience I have, third party dependencies that didn't yet have proper typings was the primary motivation for using any - and even then, you can provide a placeholder / temporary type definition for 3rd party libraries yourself. Which is an annoying chore, but you can't expect every JS library to invest time in adding TS / typing support because you would like it.

With that in mind though, a lot of JS libraries did add it, and the people running the @types repository did a lot of work on volunteering to add it even when the maintainers of the library didn't want it.

Reply on news.ycombinator.com