So we get this news today: "Angular 2: Built on TypeScript"

270 views
Skip to first unread message

Joao Pedrosa

unread,
Mar 5, 2015, 12:26:15 PM3/5/15
to mi...@dartlang.org
Hi,

Someone would post this news sooner or later I guess. You can read about it here:

Looks like "AtScript" is now TypeScript redux. It's good that they could work out a more standard solution. Not too surprising though.

What does it mean for Dart? I think we should get past any jealousy first. :-)

I like it that Dart is getting more optimizations. I also like it that Dart may appeal on the server side.

JavaScript is just inexorable. :-)

Dart is the cathedral. JavaScript is the bazaar. We may need more "bazaar" in Dart. It's good that Dartium will finally be able to work without updates for an entire year, for instance. But as far as design goals went in Dart, I think that requiring an IDE was not the most "bazaar" of the ideas. And yet it was a great idea. :-)

The problem on the client is that manipulating with DOM with more type checking is not exactly more fun than manipulating it without so many type checks in JavaScript. Which means that programming with Dart can be slow and boring on the client. It is only offset by JavaScript currently needing transpilers for ECMAScript 6. But that may be just a bump on the road for JavaScript. For Dart, it may be part of its DNA.

My idea for Dart would be to make it possible to create small widgets that could be packaged up and embedded multiple times in larger and existing applications. Much like Flash animations and Java applets of old, but using HTML and CSS features to get it done. Even if the HTML and CSS had to be converted into JavaScript for easier embedding.

Cheers,
Joao


Justin Fagnani

unread,
Mar 5, 2015, 1:31:08 PM3/5/15
to General Dart Discussion
On Thu, Mar 5, 2015 at 9:26 AM, Joao Pedrosa <joaop...@gmail.com> wrote:
Hi,

Someone would post this news sooner or later I guess. You can read about it here:

Looks like "AtScript" is now TypeScript redux. It's good that they could work out a more standard solution. Not too surprising though.


I think this is a very positive development. TypeScript and AtScript were very similar supersets of JavaScript (well, AtScript adds the possibility that a type system will define a new subset of valid runtime behavior), so it's good that they merge. If you think that rtti and metadata are good, then you should be happy that they appear in more languages.
 
What does it mean for Dart? I think we should get past any jealousy first. :-)

What should it mean? Angular 2.0 was never, ever going to be written only in Dart. They have a massive user base of JavaScript users and right now Dart is not optimized for those who cases where your primary use is as a JavaScript library. That Angular 2.0 chooses one JavaScript superset variant over another probably has no bearing on Dart at all. I'm assuming their internal facade patterns and JS->Dart transpiler still work.
 
I like it that Dart is getting more optimizations. I also like it that Dart may appeal on the server side.

JavaScript is just inexorable. :-)

Dart is the cathedral. JavaScript is the bazaar. We may need more "bazaar" in Dart. It's good that Dartium will finally be able to work without updates for an entire year, for instance. But as far as design goals went in Dart, I think that requiring an IDE was not the most "bazaar" of the ideas. And yet it was a great idea. :-)

Dart doesn't require an IDE. Dart is more toolable than JS, and so you get more out of an IDE than with JavaScript, but just because JavaScript is hard to write tools for doesn't mean that Dart requires those tools any more than JavaScript. The optional runtime type checks and command-line analyzer and compiler work with vim or pico, if you're into that sort of thing.

 
The problem on the client is that manipulating with DOM with more type checking is not exactly more fun than manipulating it without so many type checks in JavaScript. Which means that programming with Dart can be slow and boring on the client. It is only offset by JavaScript currently needing transpilers for ECMAScript 6. But that may be just a bump on the road for JavaScript. For Dart, it may be part of its DNA.

My idea for Dart would be to make it possible to create small widgets that could be packaged up and embedded multiple times in larger and existing applications. Much like Flash animations and Java applets of old, but using HTML and CSS features to get it done. Even if the HTML and CSS had to be converted into JavaScript for easier embedding.

I personally hope that Dart tools can evolve to support the JavaScript library author's use cases even better, maybe offering the ability to trade off certain optimizations like tree-shaking or features noSuchMethod() for the ability to produce plain-ish JavaScript libraries. That would undoubtedly open up a huge user-base that's currently inaccessible.

 

Cheers,
Joao


--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

Cogman

unread,
Mar 5, 2015, 1:51:36 PM3/5/15
to mi...@dartlang.org
To me this highlights a pain point of dart that probably needs to be fixed.  The fact is that the dart-as-a-library story isn't very good right now.  Hopefully it can be made better so that Angular 3.0 uses dart as the backing language.

Don Olmstead

unread,
Mar 5, 2015, 2:03:49 PM3/5/15
to mi...@dartlang.org
Don't think its really been brought up on the list but there is this https://github.com/dart-lang/dev_compiler which will apparently go for a more readable JS.

Benjamin Strauß

unread,
Mar 5, 2015, 5:28:41 PM3/5/15
to mi...@dartlang.org
I think it would have been better if the dart compilation process happened in two stages, first compile to human readable libraries/application structure that can be used with existing javascript codebases (see closure library), then minify/treeshake/optimize everything (see closure compiler).

If the second step would be optional, the angular people could have used dart instead of something like typescript/atscript.....

Greg Lowe

unread,
Mar 6, 2015, 1:48:21 AM3/6/15
to mi...@dartlang.org
This is great news! Now the Angular team's AtScript to Dart compiler is also a Typescript to Dart compiler!

Celerity Abbottt

unread,
Mar 6, 2015, 6:37:47 AM3/6/15
to mi...@dartlang.org
1). Now what does it mean for AngularDart?

2). Is Polymer going to be written in TypeScript?

Celerity Abbottt

unread,
Mar 6, 2015, 6:41:23 AM3/6/15
to mi...@dartlang.org
Has anyone tried TypeScript to Dart?

Why would one want to do it?

Is it perhaps good for porting TypeScript libraries to Dart?

Celerity Abbottt

unread,
Mar 6, 2015, 6:52:26 AM3/6/15
to mi...@dartlang.org
One more comment / question:

Angular people just appear so smart that by not using AtScript but switching to using TypeScript, they have won over at least some portion of TypeScript developers (Who want to use a good and popular UI kit), right?


Kevin Moore

unread,
Mar 6, 2015, 6:54:42 PM3/6/15
to mi...@dartlang.org
What does this mean for AngularDart?

Nothing much. Where Angular1.dart was a separate implementation, Angular2 has a complete implementation for both Dart and JS from Day 1. Angular has a huge JS community they want to support, but they are also delivering a first-class Dart impl as well.

Is Polymer going to be written in TypeScript?

I doubt it, but you'll have to talk to those folks. We're all on different teams – although we try to talk a lot.
Reply all
Reply to author
Forward
0 new messages