TypeScript is pretty amazing. In a few weeks, it turned our node project from an unruly mess (with tests) to a well organized and compact codebase with nice interfaces that formalize the various data types that flow around.
We just changed the extensions of all of our files to `ts` and added some type definition files (most from DefinitelyTyped) to our project; then started gradually adding types to the codebase. The compiler complains about type errors, but always generates JS from code that is still valid JS, so the project was fully operational during the migration.
Once that was done, moving code around, renaming things and changing entire interfaces became really easy.
The structural type system (basically formalized duck types) is a great fit for JS, and features such as generics ensure that the typesystem is expressive enough to model common functional code (no higher kinded types though, look into purescript for that).
Its not perfect (all types nullable by default; function arguments are bivariant wrt input/output params and some other weirdness here and there) but its a remarkable improvement over plain JS.
Agreed. We migrated most of the ES6 codebase to Typescript, and it feels great.
We have an angular.js app that makes REST calls. The Java backend has DTOs (data transfer objects) that are mapped by Jackson to json, and after migrating to Typescript, we also run the DTOs through compile-phase that generates corresponding typescript interfaces.
i.e.
in Java:
public class PersonInfo { // the dto for person
public final String name;
public final PersonId id; // we have a class for each id type
public PersonInfo(...) { ... }
}
@RestController
public PersonController {
@RequestMapping("/get-person-info")
public PersonInfo getPersonInfo(@RequestParam int id) {
// dummy example
return new PersonInfo("Peter Jackson", id);
}
}
In the java->typescript generator we add the controllers for which we need the rest API definitions to be generated as typescript interfaces:
" a remarkable improvement over plain JS" - Agreed. Optional types for the win. Types when you want them but just make something <any> when you want to get up to your old js tricks. Dart gives you a first class experience of optional typing with things like checked mode at runtime but I think typescript gets the 80/20 by enhancing js in a very clever way.
TypeScript has been great. With plain JavaScript you have to be outstandingly organized and diligent to maintain any sort of medium to large project. But this part of the process tends to get neglected, and eventually a point is reached where you can either a) break stuff at run-time in unpredictable ways, b) stop refactoring and deal with the consequences, or c) have a proper suite of unit tests. c) requires almost as much discipline as keeping the code clean in the first place, and a) or b) are not great options.
Luckily TypeScript helps out quite a lot and basically for free. Converting an existing JavaScript project to "naive" TypeScript takes hardly any effort, and as the project evolves it is easy to add type annotations and interfaces at any pace. Once a module is properly typed it (almost) stops breaking at run-time, yay! It's also very clear what will be executing in the browser. Using a cross-compiled language that follows the principle of least astonishment is a real treat.
Obviously it can't prevent compile-time errors, generate unit tests, or build a good application for you, but you do get quite a lot of help with the problems it can solve.
Some shameless promotion for a PR I worked on: If you're using the AMD features of TypeScript, support for named AMD modules also made it out in TypeScript 1.4. An example of the syntax can be found in the following file: https://github.com/Microsoft/TypeScript/blob/v1.4/tests/case...
I think the union type thing is cool. As someone who has never worked with something like that before I have to say that I'm not sure I like the conditional inside the function to check the type. I feel like it would be cool if there was some other construct to match on the argument type and then send the arguments to more specifically typed functions.
TypeScript now supports using ‘let’ and ‘const’ in addition
to ‘var’. These currently require the ES6 output mode, but
we’re are investigating relaxing this restriction in future
versions.
Would be quite nice to be able to use 'let', and just use variable renaming to generate ES5 code with unique names in the case where scopes overlap. I guess it might be coming?
Variable hygiene is not sufficient in loops - you have to make IIFE's for that. Then you have to account that the code inside that IIFE might be referring to the arguments object of the outer function, so you have to forward the outer arguments object to the IIFE as well. It's not impossible but the end result is somewhat gnarly.
There's plenty of discussion on this very topic in GitHub issues and PRs. The current "typeof" is inherited from JS and TS compiler doesn't actually do much to change that code. It would be great to see a nice pattern matching syntax, but people will have to figure out what the JS that pattern matching code would look like.
Assuming this source is up to date[1] (and I'm reading it right), then the intersection of chrome ES6 features and Typescript ones is an empty set, while the Typescript ones are a strict subset of Firefox's ES6 features.
"In addition to the type system improvements, one of the main goals for the upcoming TypeScript 2.0 release is to fully support the ECMAScript 6 standard. With TypeScript 1.4, we take another step towards this goal. In this release, we’ve added a new ES6 output mode, support for let and const, and support for ES6 template strings."
There will never be "types" in javascript,at most something like "guards" or runtime assertion checking, but they will never implement typescript type system. It's too late for that.
[+] [-] spion|11 years ago|reply
We just changed the extensions of all of our files to `ts` and added some type definition files (most from DefinitelyTyped) to our project; then started gradually adding types to the codebase. The compiler complains about type errors, but always generates JS from code that is still valid JS, so the project was fully operational during the migration.
Once that was done, moving code around, renaming things and changing entire interfaces became really easy.
The structural type system (basically formalized duck types) is a great fit for JS, and features such as generics ensure that the typesystem is expressive enough to model common functional code (no higher kinded types though, look into purescript for that).
Its not perfect (all types nullable by default; function arguments are bivariant wrt input/output params and some other weirdness here and there) but its a remarkable improvement over plain JS.
[+] [-] mushishi|11 years ago|reply
We have an angular.js app that makes REST calls. The Java backend has DTOs (data transfer objects) that are mapped by Jackson to json, and after migrating to Typescript, we also run the DTOs through compile-phase that generates corresponding typescript interfaces.
i.e.
in Java:
In the java->typescript generator we add the controllers for which we need the rest API definitions to be generated as typescript interfaces: And when the generator is run, a typescript file is generated with following definitions:[+] [-] discreteevent|11 years ago|reply
[+] [-] hammerandtongs|11 years ago|reply
Little oddnesses here and there in DefinitelyTyped d.ts choices.
Overall though typescript feels like first class javascript+a much better future javascript.
[+] [-] guscost|11 years ago|reply
Luckily TypeScript helps out quite a lot and basically for free. Converting an existing JavaScript project to "naive" TypeScript takes hardly any effort, and as the project evolves it is easy to add type annotations and interfaces at any pace. Once a module is properly typed it (almost) stops breaking at run-time, yay! It's also very clear what will be executing in the browser. Using a cross-compiled language that follows the principle of least astonishment is a real treat.
Obviously it can't prevent compile-time errors, generate unit tests, or build a good application for you, but you do get quite a lot of help with the problems it can solve.
[+] [-] gisenberg|11 years ago|reply
[+] [-] dopamean|11 years ago|reply
[+] [-] McP|11 years ago|reply
e.g. instead of
"hello\n" +
"world";
use
`hello
world`;
[+] [-] Pxtl|11 years ago|reply
[+] [-] evv|11 years ago|reply
http://tc39wiki.calculist.org/es6/template-strings/
[+] [-] zodiakzz|11 years ago|reply
[+] [-] zoomerang|11 years ago|reply
[+] [-] BrianHV|11 years ago|reply
* Non-nullable types: https://github.com/Microsoft/TypeScript/issues/185
* Sum types: https://github.com/Microsoft/TypeScript/issues/186
The short story is that there's some interest in both features, but there are challenges that someone needs to propose a solution to.
[+] [-] xxyyzz3d|11 years ago|reply
[+] [-] Arnavion|11 years ago|reply
[+] [-] skrebbel|11 years ago|reply
[+] [-] nine_k|11 years ago|reply
[+] [-] Arnavion|11 years ago|reply
Advanced pattern matching, monads, etc. might be out of scope for TS, since it doesn't want to have major syntactical additions from regular JS.
[+] [-] spion|11 years ago|reply
[+] [-] WorldMaker|11 years ago|reply
[+] [-] hammerandtongs|11 years ago|reply
Ie whats in typescript es6 output that will have issues?
[+] [-] KwanEsq|11 years ago|reply
[1] http://kangax.github.io/compat-table/es6/#typescript
[+] [-] WhitneyLand|11 years ago|reply
[+] [-] forrestthewoods|11 years ago|reply
"In addition to the type system improvements, one of the main goals for the upcoming TypeScript 2.0 release is to fully support the ECMAScript 6 standard. With TypeScript 1.4, we take another step towards this goal. In this release, we’ve added a new ES6 output mode, support for let and const, and support for ES6 template strings."
[+] [-] aikah|11 years ago|reply
[+] [-] tonetheman|11 years ago|reply
[+] [-] nvivo|11 years ago|reply