I've used both recently, deciding between them. Dart is better.
* Typescript is much more popular, and integrates with other Javascript things better. There are way more libraries available for Typescript.
* Typescript has proper support for non-null types, whereas in Dart everything is nullable (though they are fixing it, as announced here).
* Typescript has pretty nice support for anonymous sum types (i.e. `number | string`).
However:
* Typescript doesn't actually fix any of the insanity of Javascript - it just describes it. So you can still do insane things like using `var` or `==`. In Dart all of that nonsense has been removed.
* Typescript has `interface` and `class` which is needlessly confusing (it has no choice because Javascript).
* It's way too easy to give up on typing in Typescript. It has a setting "no implicit `any`" but it doesn't seem to be comprehensive. You can do still stuff like just omitting the return type of functions and then they instantly lose all type information. In Dart you have to explicitly opt in to `dynamic`.
* Because types are added to Javascript libraries (via DefinitelyTyped), there's nothing that really checks that they are correct and very often they are just wrong. It's pretty annoying to fix when that happens and even harder to know what the correct fix is because obviously the underlying Javascript library has no types! You basically have to ask the authors what they meant.
* A lot of libraries aren't fully typed. For example Vue has very minimal typing - lots of things are just strings. As a concrete example, AngularDart gives you compile errors if the types in your HTML template are incorrect. With Vue they are runtime errors.
* The Dart VSCode extension is literally amazing. It gives you perfect errors and completion and it does it instantly. Nothing else I've used comes close.
When I first started using Typescript I was kind of under the impression that it was a better language built on top of Javascript. That's not really the case - it's still Javascript, it's just a slightly less insane way of using Javascript.
Typescript has `interface` and `class` which is needlessly confusing
Java and C# have had a distinction between `interface` and `class` for decades. It shouldn't be that confusing? One describes a shape or a contract of an object and the other an implementation of a kind of object (which in turn might support multiple interface shapes/contracts). It's not something unusual to OOP languages with type systems. Perhaps the only thing to complain about Typescript interfaces is that they are far more on the shape side of things than the contract side of things, and it is tough to rely on them if you want more of the contract semantics (because the language can't enforce that contract).
It's way too easy to give up on typing in Typescript. It has a setting "no implicit `any`" but it doesn't seem to be comprehensive
Typescript gets as comprehensive as you want it to be. It's set of checks is an onion design to allow for various control needs, especially because projects may need to opt-in to only some of the checks in order to ease migration. If you want all the checks the flag to pass isn't `--noImplicitAny` it is `--strict` (or in tsconfig.json, "strict": true). I recommend that for all greenfield projects and most brownfield projects if they don't mind fixing lots of compile errors (for the betterment of their project).
Because types are added to Javascript libraries (via DefinitelyTyped), there's nothing that really checks that they are correct
Not all type information is from DefinitelyTyped anymore, and in many ways DT is smaller than it was at its peak. More and more libraries on npm themselves are written in Typescript and provide their own type information fresh out of the Typescript compiler itself. Even libraries that aren't written in Typescript are taking maintenance ownership of their Typescript types themselves and sometimes the JS authors are right there critiquing their own types.
There will always be a mismatch between untyped JS and what Typescript types represent of that world, but it is better than it used to be, and better all the time.
Comments
I've used both recently, deciding between them. Dart is better.
* Typescript is much more popular, and integrates with other Javascript things better. There are way more libraries available for Typescript.
* Typescript has proper support for non-null types, whereas in Dart everything is nullable (though they are fixing it, as announced here).
* Typescript has pretty nice support for anonymous sum types (i.e. `number | string`).
However:
* Typescript doesn't actually fix any of the insanity of Javascript - it just describes it. So you can still do insane things like using `var` or `==`. In Dart all of that nonsense has been removed.
* Typescript has `interface` and `class` which is needlessly confusing (it has no choice because Javascript).
* It's way too easy to give up on typing in Typescript. It has a setting "no implicit `any`" but it doesn't seem to be comprehensive. You can do still stuff like just omitting the return type of functions and then they instantly lose all type information. In Dart you have to explicitly opt in to `dynamic`.
* Because types are added to Javascript libraries (via DefinitelyTyped), there's nothing that really checks that they are correct and very often they are just wrong. It's pretty annoying to fix when that happens and even harder to know what the correct fix is because obviously the underlying Javascript library has no types! You basically have to ask the authors what they meant.
* A lot of libraries aren't fully typed. For example Vue has very minimal typing - lots of things are just strings. As a concrete example, AngularDart gives you compile errors if the types in your HTML template are incorrect. With Vue they are runtime errors.
* The Dart VSCode extension is literally amazing. It gives you perfect errors and completion and it does it instantly. Nothing else I've used comes close.
When I first started using Typescript I was kind of under the impression that it was a better language built on top of Javascript. That's not really the case - it's still Javascript, it's just a slightly less insane way of using Javascript.
Dart, on the other hand is a better language.
Java and C# have had a distinction between `interface` and `class` for decades. It shouldn't be that confusing? One describes a shape or a contract of an object and the other an implementation of a kind of object (which in turn might support multiple interface shapes/contracts). It's not something unusual to OOP languages with type systems. Perhaps the only thing to complain about Typescript interfaces is that they are far more on the shape side of things than the contract side of things, and it is tough to rely on them if you want more of the contract semantics (because the language can't enforce that contract).
Typescript gets as comprehensive as you want it to be. It's set of checks is an onion design to allow for various control needs, especially because projects may need to opt-in to only some of the checks in order to ease migration. If you want all the checks the flag to pass isn't `--noImplicitAny` it is `--strict` (or in tsconfig.json, "strict": true). I recommend that for all greenfield projects and most brownfield projects if they don't mind fixing lots of compile errors (for the betterment of their project).
Not all type information is from DefinitelyTyped anymore, and in many ways DT is smaller than it was at its peak. More and more libraries on npm themselves are written in Typescript and provide their own type information fresh out of the Typescript compiler itself. Even libraries that aren't written in Typescript are taking maintenance ownership of their Typescript types themselves and sometimes the JS authors are right there critiquing their own types.
There will always be a mismatch between untyped JS and what Typescript types represent of that world, but it is better than it used to be, and better all the time.
That's not the case: http://www.typescriptlang.org/play/#code/GYVwdgxgLglg9mABFAp...
I stand corrected. Must have been thinking of something else.