Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Microsoft recently unveiled Typescript, a new JavaScript-like programming language. Some time ago, I heard about Dart, a new programming language created by Google to solve problems related to Javascript like performance, scalability, etc..
The purpose of both new languages seem the same to me.. What do you think?
Are the purposes of the languages the same?
What are the real differences about them?
Quoting Bob Nystrom:
TypeScript seems nice if you like JS semantics or have a large JS codebase that you're invested in but you're having maintenance problems at scale. It's path for success is much smoother since it's (mostly?) backwards compatible with JS.
Dart is taking a riskier bet. It's farther from JS in a lot of ways which is, I think, mostly good as a day-to-day Dart programmer, but it makes the barrier of entry higher. But in return for that higher barrier of entry, you get:
- Tree shaking
- Getters and setters (though I presume TypeScript will get those eventually)
- Operator overloading
- Real block scope, no hoisting, no IIFEs
- A native VM
- Sane equality semantics
- No weird implicit conversion craziness
- Lexically bound
thiseverywhere- Mixins
- Annotations
- An import system
- User-defined subscript operators
- Generics, with reification
- Mirrors
- Better collection classes
- A cleaner DOM API
Also, he writes in http://www.reddit.com/r/programming/comments/10rkd9/welcome_to_typescript/c6g37xd :
I'm on Google's Dart team, so I'm naturally looking at it from that angle/bias. Here's some random stuff that caught my eye, mostly comparing it to Dart. I've only spent a few minutes skimming, so don't take any of this too seriously...
No generics
I guess some types are better than no types at all, but it's really rough to lose those. TypeScript does have built-in array types and object types cover some of the "map" type use cases. But not being able to define your own generic types is a drag. The docs say when added, generics will work using type erasure, which is what I'd expect given it's "compile to lightweight JS" style, but that can be a pain too. It's nice to be able to do stuff with your type arguments at runtime sometimes.
All types are nullable
Dart is the same way. Makes me sad in both cases.
The type annotation syntax is nice
Almost every language with optional type annotations (ML, Scala, F#, Kotlin, etc.) goes with "postfix after a :. Dart tries to use C-style type annotations which causes some nasty corner cases. I like what TypeScript has here, especially the syntax for function types:
function takeCallback(callback : (n : number) => number) { ... }Interfaces are structurally typed, classes are nominally typed
Makes sense given that it's JavaScript, but it seems pretty neat. Being able to implicitly implement an interface is nice. But TypeScript doesn't seem to let you go the other way: given a class, you can't make a new type that's compatible with it without concretely extending it because of the brand stuff. In Dart, thanks to implicit interfaces, you can.
Best common type can fail
That means this is a type error:
[1, true]You can overload in interfaces by parameter signature
This is really cool because it gives you a way have more precise type inference flow through a function call that does some dynamic type switching. For example:
interface Doubler { double(s : string) : string; double(n : number) : number; }With this, when the compiler sees a call to double, it can correctly give you a precise return type based on the inferred argument type. What I'm not sure is how to actually implement a class that implements that interface and makes the type checker happy. You can't actually overload concrete methods, and my five minute attempt to make it happy by dynamic type checking didn't seem to work.
There's a dedicated syntax for array types
Makes sense since there's no generics. It's also nice and terse, which is good, but I personally prefer general-purpose generics over one-off special case collections.
There's no implicit downcasting
One of Dart's more unusual type system features is that assignment compatibility is bidirectional: you can downcast without a warning. Aside from the typical special case of assigning to/from any (dynamic in other languages), TypeScript doesn't allow that. You have to type assert. Personally, I like TypeScript's approach here.
Arrow functions and lexical this
This is just motherhood and apple pie. I like it. (Dart has this too, and this is always lexically bound.)
Overall, it looks pretty neat. If you want exactly the same JS semantics (good and bad) but also want a smattering of types, TypeScript seems decent. It's like Closure Compiler but with a better syntax.
If you want something that's a more aggressive step away from JS's syntax and semantics, then it seems like TypeScript isn't that.
While the question was "Are the purposes of the languages the same?", the real question is: "How can we make web programming better from where we are?".
Both projects try to do this considering
programming language (TypeScript makes a small but very clean step, Dart makes the more revolutionary move that is still moving)
interoperability with existing js code (0 transition in TypeScript which compiles to js, complicated in Dart, since 2 VMs talk to each other)
software engineering practices (Dart only, web components and shadow dom)
Over the last 3 days I dived deep into Dart and then into TypeScript. My CoffeeScript codebase went to 2000s lines of code, too much to be handled with lovely but too fluffy CoffeeScript. The problems I faced was that CoffeeScript lacks features that languages designed for medium to large scale programming have: interfaces, modules, type safety. But there was one even much more serious issue with coffee and js: The js "this pointer" weirdness affected my sanity and CoffeeScript does not help anything here.
So here my results after 3 days of eval and usage:
Went thoroughly through the tutorial, reading 1 book, skimming 2nd book and tried the demos. I thought, Dart that is the future. Then I tried to migrate my app to Dart. That was were my enthusiasm went down from 100 to 10. Here is why:
The Dart Editor is the only way to program Dart. While plugins for Sublime Text exist, they do not provide features like intellisense, code completion (correct me if I am wrong). The Dart Editor is however in pre alpha quality. While it does support supercool magic things like updating the web page when you edit the CSS file (! really cool) it hangs or crashes several times a minute. So you type 5 letters and 2 times you have to wait 2 seconds or 15 seconds between typing. And I had a project with some lines of code, so did not want to wait what happens when 1000s lines are in. Moved a file from one folder to the other inside Dart Editor, crash. Debugging with the Dart Editor is at first sight better than all js debugging tools I know (chrome is my choice), but there are still too many things missing: No immediate window (this makes js debugging much better at the moment), no watches.
Politics and Escape Possibilities: Some say that Apple, MS and Firefox will never ever provide Dart VMs. Well, I am not so sure, but at least for Apple this appears at the moment very certain. For the others its more likely than the opposite. So no problem, we can convert Dart to JavaScript. The way this integration works is really great, Dart maintains a js stub that keeps the js code connected to the Dart Editor, so a print() statement still appears in Dart Editor, cool. But here comes the but: the footprint of such converted code is high. 150kB or so (before minification). I did not dig too much into the exact size, so do not nail me down on this.
Language Maturity. Beside the way too serious issues with Dart Editor popping into my face 3 times a minute I also found it unacceptable that every source about Dart code you find uses a different Dart. The language changes every day. You find a post from 5 weeks ago? It is outdated. You try the samples from the Google tutorial? At least 1 sample does not compile since an API changed. Even mundane things, like attaching an event to a DOM element are in good move.
Integration with existing js libraries is a bit involved. 2 VMs need to communicate here, its tricky.
As a conclusion, you cannot seriously use Dart as of today, and diving into it is not too much fun due to 1 and 3. Both points will disappaer over time. About the 2 point, Google published performance benchmarks some days ago demonstrating that their compiled js is better than handwritten js. My compliments, great job. Loading time might still be behind due to the footprint issue as said. However, if the footprint code gets used by many many sites, it might be available cached and voila, disappears as well.
So: I consider Dart a great project, using it at the moment carries a good portion of unforeseeable risk and it will take this year to get it to good stable level.
Evaluating TypeScript is very easy, takes 1 or 2 hours and you know everything. Reading the language spec document and a short book (TypeScript revealed) revealed, I knew everything and started programming. I was then surprised to find that TypeScript's additions to JavaScript just fill every serious need I had to enhance my client programming. Here the highlights:
Interfaces. Encapsulation and interfaces allow me to structure my code easily. Perfect!
Class State.. TypeScript allows to express the state that instances of a class carry explicitly, or better it enforces it. This is a large step better compared to js or coffee.
this call craziness mitigated. Inside arrow functions, TypeScript makes the this pointer like any normally behaving citizen.
Editor, Intellisense. TypeScript comes with 100% top perfect intellisense that reacts in the micro or millisecond range as used from Visual Studio when programming C#. TypeScript headers for all important js libraries exist too. Great great great.
Experience and Risk. Using TypeScript carries zero risk, the language is clearly defined, perfectly stable, it is just js with sugar, nothing unforeseeable.
Actually, these enhancements give me everything I needed. The only thing I would like to see in the future are generic collections. But that is peanuts.
So what about performance? While I consider myself a performance freak, I do not believe that there is any project that would make the technology choice here based on performance. Both are in the js liga.
If you are interested in the future of web programming, both are great efforts, TypeScript is much more pragmatic and usable now, Dart is a very interesting lab project that will be usable once mature editors and debuggers are available and the scope of projects doable with it will depend on politics.
In any case the 3 eval days were mostly fun and I learned a lot, if you find the time, it takes 1 day for Dart and 2 hours for TypeScript to make your own opinion. Try it.
It has been a while and ex post it appears the assumption that Typescript is the safe stable route to go was quite right. I just found a (very) prominent statement about Typescript, Dart and Closure:
I have been interested in the challenge of Web programming in the large for quite some time. I believe that Google Closure is currently still the best option for large-scale JavaScript/Web development, but that it will ultimately be replaced by something that is less verbose. Although Dart shows considerable promise, I am still dismayed by the size of the JavaScript that it generates. By comparision, if TypeScript can be directly translated to JavaScript that can be compiled using the advanced mode of the Closure Compiler, then we can have all the benefits of optimized JavaScript from Closure without the verbosity. What's more, because TypeScript is a superset of JavaScript, I believe that its syntax extensions have a chance of making it into the ECMAScript standard at some point, whereas the chances of Dart being supported natively in all major browsers is pretty low.
http://blog.bolinfest.com/2013/01/generating-google-closure-javascript.html
Michael Bolin is a long time (ex)google (ex)fb front end hero, also involved in google closure (get his book about Closure).
Google's appraoch to live ECMA Script 6 today is its Traceur project: https://github.com/google/traceur-compiler
Compared to Typescript, tooling support is presumably far behind as of today. On the upside however, it is much faster in adopting overly cool future js language ehancements like iterators or comprehensions.
provide similar features as TypeScript.
"One may wonder what’s with these different JavaScript type checking solutions and what to do about it. A good news is that Microsoft, Facebook and Google are collaborating on these, according to Microsoft’s Jonathan Turner:
The TypeScript team is working with both the Flow and AtScript teams to help ensure that resources that have already been created by the JavaScript typing community can be used across these tools. There's a lot these projects can learn from each other, and we're looking forward to working together going forward and creating the best tools we can for the JavaScript community. In the long term, we will also be working to fold the best features of these tools into ECMAScript, the standard behind JavaScript."
this context, as you still have to bind callback functions declared inside methods with the method's this context in order to access class attributes. How is that "fixing" anything?
Quoting Scott Hanselman:
People have compared TypeScript to Dart. That's comparing apples to carburetors. TypeScript builds on JavaScript so there's no JS interop issues. Dart is a native virtual machine written from scratch. Dart interops with JavaScript...but it's not JS. It doesn't even use the JavaScript number type for example.
var x = {}; x.foo = 5; //Doesn't work in typescript and var e = window.event ? window.event : e; //Doesn't work in typescript The example above will fail the TypeScript compiler. Am I missing something? I can't just "drop in" my JavaScript and use types when I feel like it. I have to learn some new syntax and structure everything with types.
var x = {}; x['foo'] = 5; and this does too var y:any = {}; y.foo = 5;, but I was a little surprised to find you're right about this - the perceived type of {} is {} rather than any. Could be a type inference issue. I posted the issue here - we'll see how they respond.
Oct 21, 2013 at 0:27
Had to chime into this discussion with my own finding lately.
1st: TypeScript
MS has taken a nice approach in the fact that you can easily jump in and out of TS and JS. We mainly use AngularJS for our development and have found while not much documentation exist for converting Angular to TypeScript. It has been a nice addition to incorporate TypeScript into our Dev workflow.
2nd: Dart
Dart is a bit of an ironic step for Google. Maybe they don't remember activeX and all of the nightmares around trying to get an application working in anything but the dreaded IE 5 or IE 6 of the day. It has taken MS many years to recover from those days.
Dart as a language "conceptually" seems to try to combine some nice OOP features. Annotations etc are a nice thought for Javascript.
The problem, it is hard to imagine enough bandwidth to create a new editor, new language, new vm's across browsers, plugins for other IDE's, compiler to convert to javascript (without being multiple meg in size), convert or create new dart libraries to replace the thousands of current js libraries, have someone decide polymers or directives, convert the dartlang site to use dart, this is what I can think of off the top of my head.
The concept of trying to use Dart in anything but a trivial app at this time is scary.
On top of all of this ES6 is not far away. ES6 brings many features that Dart is trying to fix that exist in ES5. What will the value proposition be once ES6 hits the streets? At least at this time the only change you have to make in TypeScript once ES6 comes out is to maybe choose a different compile to target.
Just to clear up any though that I am a pro MS person. MS makes some decent products and has made great strides to fix past mistakes with the OSS community. I still vary rarely use anything other than TypeScript from MS.
