4 ms·

Why Asana Is Switching to TypeScript

101 points by pspeter3 12y ago

programminggeek 12y ago
I wish TypeScript checked types at runtime.... boo... The only language that I've seen in JS land that is trying to get this right is AtScript from the Angular team. https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit97HnZoKVygDxpWzEYW0U/mobilebasic?viewopt=127 https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit9... Looks interesting so far.
- timothya 12y ago
  Dart can as well. In fact, I think that the whole type spec in AtScript is based on Dart. Edit: Quote from the doc you linked: "This runtime type system is modeled after Dart’s runtime type assertion. Dart users working on large scale applications point out that optional types and runtime type assertions work well in practice."
- pspeter3 12y ago
  Why do you want TypeScript to check types at run time? Integration with other JavaScript code?
  - mjibson 12y ago
    Validation of JSON responses is the big win.
    - pspeter3 12y ago
      Ah that would be cool. We actually code generate interfaces for our responses which is really helpful.
      - recursive 12y ago
        Typelite is good for this.
  - programminggeek 12y ago
    I am a big fan of design by contract. (http://retromocha.com/obvious/ http://retromocha.com/obvious/) I don't trust user input in any form, including the database. So, while a system like TypeScript that checks types in the code is fantastic, it doesn't check types in the input, which is how a lot of problems happen in the first place. Seriously, just import one legacy dataset into your system or have to work with some JSON api, and all of a sudden you can't trust that the data is valid, correctly typed, or even sane. Doing proper validation of types and data integrity at any input point can save you a whole category of sadly common bugs. That includes data coming out of any data source you use, like a database. Runtime type checking is another tool to make validated data a common, sane thing.
- riffraff 12y ago
  why do you want that? The rationale given in the AtScript presentation seemed pretty weak to me.
  - programminggeek 12y ago
    Type checking at runtime allows for runtime data contracts. There are a lot of benefits to that, largely in being able to enforce stronger boundaries in your code. Strong boundaries allow for potentially better code reuse, fewer bugs, and a more confident style. Once you setup a type or validation boundary, you know that you no longer need to check for type errors and so forth elsewhere in the code, if only for the fact that the code will blow up before it even gets there. That means you write less code, have fewer bugs, and can spend more time doing important things, like playing Quake 2.
- klibertp 12y ago
  You can have type checking - or even much stronger validation - on runtime with contracts. Racket and TypedRacked are an example of how well contracts and static typing can work together, providing both compile-time and runtime guarantees. I'm sure something like this will come to "idustrial grade" languages in a decade or so...
- doublerebel 12y ago
  Contracts.js [1] has been actively developed for quite a while. It uses Sweet.js "macros" to provide runtime type-checking. Also usable in CoffeeScript. It doesn't get much hype because it's not new, but that's why I like it. Reliable and stable. [1] http://disnetdev.com/contracts.js/ http://disnetdev.com/contracts.js/ [EDIT: Contracts.js is based off Racket, advantages pointed out by another commenter.]
jbeja 12y ago
Why not purescript?
- pspeter3 12y ago
  Largely because of the difference from vanilla JavaScript syntax. PureScript looks great but would be asking for a lot of change just like Scala.js. We also looked at ClojureScript and LiveScript
alexfreska 12y ago
I may be wrong but didn't they write their own language that compiles to javascript?
- joshuacc 12y ago
  It appears that they did. It was called LunaScript.
- marcog1 12y ago
  We did long ago, but ditched that idea because we get to use the tools of JS and we realised that effectively using a DSL embedded in another language allows the developer to break the rules of the DSL.
  - hackerboos 12y ago
    Surely those points apply to TypeScript.
    - malcolmredhero2 12y ago
      Lunascript was very different from JavaScript, partly because it had automatic support for our reactivity system. As a result it compiled to JavaScript that looked nothing like the original code (even the control flow was different). Reading this code was very difficult.
    - jacklionheart 12y ago
      The IDE support for TypeScript is actually pretty great; building our own tooling support for LunaScript felt like something we didn't really want to have to do.
klibertp 12y ago
"The Surprising Benefits of Static Typing" It's actually "gradual typing", which among many benefits shared with full static typing has one very important of its own: it gets out of your way when you want to ignore the types. The approach itself is old(EDIT: Common Lisp and Dylan), the research and theory behind it is a decade old at this point, this shouldn't be very surprising anymore :)
- steveklabnik 12y ago
  Decade-old PLT is still generally 'zomg super new' for industry languages, though. It's one area of computer science where industry really trends far behind research.
wasd 12y ago
I don't want to keep adding to the comments about why not X so I'll ask a more generalized question, what other options did you consider and why did you abandon them?
- pspeter3 12y ago
  We looked at PureScript, ClojureScript, LiveScript, CoffeeScript, Dart, and compile language X to JS tools. We wanted static typing for run time correctness with respect to accessing data loaded from a server so that ruled out the dynamically typed variants like CoffeeScript. We also did not want to force our developers to learn a new language so that really only left TypeScript. At the time we were investigating, Flow by Facebook and AtScript by Google were not out yet. It seems like TypeScript will play well with Flow which is nice.
wildpeaks 12y ago
About the React post mentioning improvements from types: React wanted to use Typescript (see http://youtu.be/M8x0bc81smU?t=37m57s http://youtu.be/M8x0bc81smU?t=37m57s), but they created Flow instead because Typescript didn't fit them, so the performance improvements the post mentions came from Flow instead.
hippich 12y ago
I came from requirejs code base into new typescript based with rjs used to load modules. I found many small nuances I had to fight about the way typescript generates and uses rjs modules. With browserify-type of modules that should not be a problem tho.

101 points by pspeter3 12y ago

I wish TypeScript checked types at runtime.... boo... The only language that I've seen in JS land that is trying to get this right is AtScript from the Angular team. https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit97HnZoKVygDxpWzEYW0U/mobilebasic?viewopt=127 https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit9... Looks interesting so far.

timothya 12y ago
Dart can as well. In fact, I think that the whole type spec in AtScript is based on Dart. Edit: Quote from the doc you linked: "This runtime type system is modeled after Dart’s runtime type assertion. Dart users working on large scale applications point out that optional types and runtime type assertions work well in practice."
pspeter3 12y ago
Why do you want TypeScript to check types at run time? Integration with other JavaScript code?
- mjibson 12y ago
  Validation of JSON responses is the big win.
  - pspeter3 12y ago
    Ah that would be cool. We actually code generate interfaces for our responses which is really helpful.
    - recursive 12y ago
      Typelite is good for this.
- programminggeek 12y ago
  I am a big fan of design by contract. (http://retromocha.com/obvious/ http://retromocha.com/obvious/) I don't trust user input in any form, including the database. So, while a system like TypeScript that checks types in the code is fantastic, it doesn't check types in the input, which is how a lot of problems happen in the first place. Seriously, just import one legacy dataset into your system or have to work with some JSON api, and all of a sudden you can't trust that the data is valid, correctly typed, or even sane. Doing proper validation of types and data integrity at any input point can save you a whole category of sadly common bugs. That includes data coming out of any data source you use, like a database. Runtime type checking is another tool to make validated data a common, sane thing.
riffraff 12y ago
why do you want that? The rationale given in the AtScript presentation seemed pretty weak to me.
- programminggeek 12y ago
  Type checking at runtime allows for runtime data contracts. There are a lot of benefits to that, largely in being able to enforce stronger boundaries in your code. Strong boundaries allow for potentially better code reuse, fewer bugs, and a more confident style. Once you setup a type or validation boundary, you know that you no longer need to check for type errors and so forth elsewhere in the code, if only for the fact that the code will blow up before it even gets there. That means you write less code, have fewer bugs, and can spend more time doing important things, like playing Quake 2.
klibertp 12y ago
You can have type checking - or even much stronger validation - on runtime with contracts. Racket and TypedRacked are an example of how well contracts and static typing can work together, providing both compile-time and runtime guarantees. I'm sure something like this will come to "idustrial grade" languages in a decade or so...
doublerebel 12y ago
Contracts.js [1] has been actively developed for quite a while. It uses Sweet.js "macros" to provide runtime type-checking. Also usable in CoffeeScript. It doesn't get much hype because it's not new, but that's why I like it. Reliable and stable. [1] http://disnetdev.com/contracts.js/ http://disnetdev.com/contracts.js/ [EDIT: Contracts.js is based off Racket, advantages pointed out by another commenter.]

jbeja 12y ago

Why not purescript?

pspeter3 12y ago
Largely because of the difference from vanilla JavaScript syntax. PureScript looks great but would be asking for a lot of change just like Scala.js. We also looked at ClojureScript and LiveScript

alexfreska 12y ago

I may be wrong but didn't they write their own language that compiles to javascript?

joshuacc 12y ago
It appears that they did. It was called LunaScript.
marcog1 12y ago
We did long ago, but ditched that idea because we get to use the tools of JS and we realised that effectively using a DSL embedded in another language allows the developer to break the rules of the DSL.
- hackerboos 12y ago
  Surely those points apply to TypeScript.
  - malcolmredhero2 12y ago
    Lunascript was very different from JavaScript, partly because it had automatic support for our reactivity system. As a result it compiled to JavaScript that looked nothing like the original code (even the control flow was different). Reading this code was very difficult.
  - jacklionheart 12y ago
    The IDE support for TypeScript is actually pretty great; building our own tooling support for LunaScript felt like something we didn't really want to have to do.

klibertp 12y ago

"The Surprising Benefits of Static Typing" It's actually "gradual typing", which among many benefits shared with full static typing has one very important of its own: it gets out of your way when you want to ignore the types. The approach itself is old(EDIT: Common Lisp and Dylan), the research and theory behind it is a decade old at this point, this shouldn't be very surprising anymore :)

steveklabnik 12y ago
Decade-old PLT is still generally 'zomg super new' for industry languages, though. It's one area of computer science where industry really trends far behind research.

wasd 12y ago

I don't want to keep adding to the comments about why not X so I'll ask a more generalized question, what other options did you consider and why did you abandon them?

pspeter3 12y ago
We looked at PureScript, ClojureScript, LiveScript, CoffeeScript, Dart, and compile language X to JS tools. We wanted static typing for run time correctness with respect to accessing data loaded from a server so that ruled out the dynamically typed variants like CoffeeScript. We also did not want to force our developers to learn a new language so that really only left TypeScript. At the time we were investigating, Flow by Facebook and AtScript by Google were not out yet. It seems like TypeScript will play well with Flow which is nice.

wildpeaks 12y ago

About the React post mentioning improvements from types: React wanted to use Typescript (see http://youtu.be/M8x0bc81smU?t=37m57s http://youtu.be/M8x0bc81smU?t=37m57s), but they created Flow instead because Typescript didn't fit them, so the performance improvements the post mentions came from Flow instead.

hippich 12y ago

I came from requirejs code base into new typescript based with rjs used to load modules. I found many small nuances I had to fight about the way typescript generates and uses rjs modules. With browserify-type of modules that should not be a problem tho.