I learned it in more than five minutes - over the last couple weeks - when I rewrote an open source UI Componenrt library in TS.

What’s scary is the number of bugs in the original implementation! I made the comment on Reactuflux’s #typescript channel that I’m afraid to use code not written in TS now.

Anyway, it’s been interesting coming from the land of Python, and surprisingly quite enjoyable.

The Bulma library I’ve re-written and released on npm is https://www.npmjs.com/package/rbx

I just started a side project with Typescript, and I like a lot of it, but, ironically, type discovery seems _very_ lacking. The JS keywords like `instanceof` are useless because everything is just an object, and Typescript doesn't give you a way to pattern match on types.

For example, in React there is this type that's a union of an array, single object or null. Some kind of catch-all, I guess. So, when you see one of these things, there's no way to know what you have unless you do something ugly like this:

    if ((value as any).length) {
        // it's an array
    } else if (value) {
        // must be a single object, I guess..
    } else {
        // null
    }

The thought of littering my code with these kinds of type checks makes me feel really dirty, unless I'm totally missing something...

For types like those which are outside your control you can use type guards[1]:

    if (value == null) {
        // TS knows value is null, doesn't let you access value .length for example
    } else if (Array.isArray(value)) {
        // TS knows value is an array
    } else {
        // TS knows that it's an object here
    }

However, having types like those in your own code (e.g. things like X[] | Y | null) is probably an antipattern and should be avoided. Using discriminated unions[2] is much better.

[1]: https://www.typescriptlang.org/docs/handbook/advanced-types.... ("Type Guards and Differentiating Types" section) [2]: [1]: https://www.typescriptlang.org/docs/handbook/advanced-types.... ("Discriminated Unions" section)

Deep links:

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

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

What you're "missing", I think, is that Typescript's types only exist at compile-time, so they aren't available through runtime operations like instanceof. It's like a more extensive case of Java generics erasure.

Unless you use metadata reflection. Angular, NestJS, etc use this for dependency injection with great success.

You’re not missing anything ; instanceof can be used to check prototype chain (class inheritance) but there is nothing similar for object interfaces (duck typing). And most Javascript objects are only loosely defined to conform to interfaces.

Good call. I love TypeScript, and wouldn't build a web app of even small scope without a typing solution at least as good as TypeScript, and it's the best.

But, as you say, pattern matching sum types is a weak point in practical use of TypeScript.

Since the types only exist at compile time, maybe there could be a heavier opt-in system that uses something like Symbols to do pattern matching:

  matchable type Shape = Circle | Square | Triangle;
  const myShape: Shape;
  match myShape {
    // uses symbol magic under the hood, eg. if (SymbolShapeCircle in o)
    case (c: Circle) { ... }
    case (other: Triangle | Square) { ... }
  }

It's a far cry from actual pattern matching, but you can always tag your types[1]:

  interface Tagged {
    tag: string;
  }

  interface Circle extends Tagged {
    tag: 'circle'
  }

  // ... Other implementations 

  switch (myShape.tag) {
    case 'circle': {
      // Do circular things
    }
    // etc . . .
  }

You'll occasionally even see this in Scala code, since the @switch annotation optimizes pattern-match statements[2].

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

2. https://www.scala-lang.org/api/2.12.x/scala/annotation/switc...

Misclassifies an empty array as object since zero is falsy.

I really like this kind of introduction; they let you get into what the authors consider the main reason for their products existence straight away - this is what they will spend most time on and other features will exist at these features expense.

It is also the best place to start evaluating how "complete" a solution is; particularly when faced with multiple choices.

It was a tutorial very similar to this one that led me to choose flow over typescript - I did the equivalent of setting the "user" in this example to null, flow would tell me it wouldn't work and typescript just happily compiled away. In short, this kind of quick evaluation led me to deduce typescript is JS with loose types sometimes (but you aren't sure where) so as not to be annoying and flow is JS with restrictive types everywhere (that may not get your indirect but correct logic) so as to provide the most guarantees.

Typescript has flags for turning on more strictness, and I highly recommend using them. For example, strictNullChecks for your example above.

There’s a “strict” flag that you can use to turn on most of the more specific strictness flags all at once.

Genuinely curious. Does anyone use the command line `tsc` to compile typescript in everyday work? Or is it more of just a learning stepping stone?

With the disclaimer that I don't get paid for my Typescript work (I use it for some personal projects, as it saves me a bit of time compared to C++), I have this as the compile scripts entry in my package.json:

    "compile": "tsc -p ./tsconfig.json",

I also have a start script, for running it from the command line:

    "start": "npm run compile && node ./.build/main.js"

tsc has some kind of file-watching mode, that I assume compiles when you save stuff, but I don't use that, because I'm not a monster.

I use tsc -w with a simple Python web server and use <script> tags to include all of my modules. Yeah, I'm a monster. And watch out for the browser cache.

Yeah, we use tsc for node. I typically just use ts-node for development, though, and tsc gets to hang out in CI/CD somewhere. I assume ts-node / webpack / etc all use tsc under the hood, though.

I use cc instead of make, and javac instead of Gradle fairly often for various purposes like debugging or experimenting. Is the js world different?

Yes. ts-node is great for development, but for deployment (in our ci/cd) we run tsc to compile the typescript down to javascript.

For node projects I use ts-node with nodemon watching for filechanges and takes care of restarting the server. And then to build the project for release thats done with tsc.

I use tsc -w, what do you use? I'm not using it on the frontend but for nodejs (i would use webpack on the frontend)

Depends on your IDE. In practice, tsc is a build step in CI/CD, not a dev tool (if you’re using a good IDE).

in a project I worked on, we used tsc with msbuild to build our frontend.

Shouldn't the `Student` class implement `Person` here? Did I miss that in the code sample?

There's a couple of things going on that you might not be familiar with as it's a bit different to most languages:

The public modifier on these constructor parameters is actually introducing them as properties of the Student type:

constructor(public firstName: string, public middleInitial: string, public lastName: string) {}

Since the Student type has 'firstName' and 'lastName' properties, it meets the Person interface requirements. It doesn't need to declare that it is, but could and usually would just for readability and the additional assurance that you haven't forgotten something.

Great question!

No, you don't need to inherit or implement which is one of the great features of TypeScript!

In this example, the `greeter` function accepts any object that has a `firstName` and `lastName` property defined, regardless of what the object/type is called. No need for inheritance.

In fact, the `Person` interface is not even emitted in the JS output because interfaces are only used at compile time, not at run time.

Annoying that the site hijacks your back button history like a porn site. What’s up with that? Sure I want to give Typescript (or the equvilent) a try but this feels desperate if not an error.

TypeScript is one of the fastest-growing technologies in the JS ecosystem right now. It's unlikely the team is using the back button behavior as a way to get membership.

Incidentally, to which porn sites are you referring? Which of your favorite porn sites do you think do the best job with UI/UX?

Article should mention that TypeScript is made by Microsoft.

this seems to be highly downvoted as i suppose people are reading it as a rude aside, but I read it as a feature worth highlighting. Microsoft has an excellent track record with language design, promotion, stability, and tooling.

no, we're downvoting because it's irrelevant and it says it's made by microsoft right in the footer