Why TypeScript for JSCore?

We get asked often why we chose to use TypeScript as our development language for the Patterns and Practices JSCore library. Why not just es6? The simplest answer is scalability. Read the longer answer below the fold.

So seriously, why TypeScript? Yes, TS has static typing but how does that help? When I say scalability I have two interlocking ideas in mind – team size and code size. Let’s look at each point, then we’ll bring it all together at the end.

Team Size

Once a team grows beyond one code needs structure and rules. This is helped by linting (possible in JavaScript as well) but the advantages of types cannot be overstated. Let’s say I write a new module and expose a method that returns an interface. With static typing another developer can quickly see what they should pass to my method as well as what they can expect in return. In JS with dynamic typing this usually involves digging through the actual method to see what comes back. Static typing makes teams more efficient, especially through the ability for IDE’s to perform analysis prior to execution and catch type errors that previously in JS could go undiscovered for months or years.

The same thing applies as teams change members. Much easier to see what is happening with a new library when you can clearly see what information is being passed around. Code simply becomes easier to understand, both to new team members to to folks having to debug years old code.

Code Size

Similar to team size, as code grows it becomes complex and harder to follow without static typing. Static typing allows us to partition blocks of code by saying “I don’t care what happens in that method, but I know I get back a Date”. I’ve encountered a method named “getExpiration”. Likely that returns a date? Nope, a string name of the week like “Tuesday”. We can argue the merits of that particular design decision, but static typing makes this obvious.

As code bases grow we as developers increasingly need to trust the other parts of our own and others libraries to do what we expect. This is solved by the concept of exposing interfaces which create a defined contract between caller and callee. What do we give and what we expect to get back is explicitly defined. TypeScript also makes inheritance explicit and understandable.

The modern programmer’s job is to solve problems and manage complexity. That’s it. Many of the problems we encounter are quite complex and static typing is a great tool in the chest to help us keep things simple. We can also package up that complexity behind interfaces and isolate parts of our application from others.

So Why Then?

As we looked at starting an open source project for the JSCore we needed to manage a team of N developers that is constantly in flux as well as a planned large code base. As outlined above, the advantages of TypeScript helps us with both things. Anyone can fork the library and more quickly understand what is happening. So we decided to bring these advantages to the SharePoint JS client development space. Not accidentally it also aligns with the product group’s decision when they were designing the new SharePoint Framework and allowed us to begin introducing TypeScript and related concepts to the community before the official announcement.

Comments (2)

  1. Nasir says:

    Hi Patrick Rodgers,

    So what is next on Why and Then?

    1. Did you have a specific area you are wondering about? Best way to keep up with what is happening is to join the bi-weekly calls.

Skip to main content