
Angular 2: Built on TypeScript - hswolff
http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx
======
WhitneyLand
Angular 2 is having a lot of pushback and challenges, but this may be a
positive.

First, there have been hard feelings over breaking backward compatibility. To
rub salt in the wound the new syntax doesn't seem to buy you much for many
basic scenarios. If you are going to push big breaking changes you need to
show big benefits that are easy to understand at a glance.

Secondly, the Ember community started small but has been kicking ass for a
while now and making many improvements that are compelling to developers. It's
a modern framework, but also easier to understand than some competitors like
react.

I see the Typescript move as a positive because it shows they are at least
trying to do what's right even when using tech from one of the biggest
competitors. How this played internally at Google to overcome executive knee-
jerk/bureaucracy/pettiness I don't know, but it's a good sign.

The community has clearly spoken, and the future of Angular is now riding on
how well they absorb and react to the feedback and advances from competing
teams.

~~~
andrewstuart2
The main mistake, in my opinion, that Angular 2.0 is making is removing two-
way data binding. The whole cornerstone of my love for Angular was the idea
that wherever data was updated (view, model, server, another user's browser,
etc.) it was _trivial_ to make that update appear everywhere else. This is
even more powerful when you add in a technology like WebRTC data channels or
websockets.

I could just bind the data to the view, and if the user changed it, I could
react accordingly. Data changing became an actual event that I could subscribe
to. It abstracted away the onkeydown, onkeyup, onclick, etc. so that it just
became ng-change. _So_ much less mental noise when I'm developing when all I
have to do is react to data having changed.

I hope this gets picked up. ES6 and TypeScript have so much to offer, but
without a data-centric paradigm, I find I'm just not interested anymore.

~~~
sanderjd
I had the same "wow" moment with two-way binding awhile back. Now I think that
the important part is having a source of record that consumers can observe for
changes, and a good way to update that source of record. Two-way binding is
just one way to give you that. In my experience it's far more common to read
data than write it, so making it more explicit where writes are happening is
not burdensome and seems more maintainable and performant.

------
skeeterbug
"Special shout out to Yehuda Katz, who helped us design the
annotation+decorator proposal which helped make this work possible."

How in the world does this man keep up with all these projects? He needs to
write a book on motivation.

~~~
coldtea
> _How in the world does this man keep up with all these projects? He needs to
> write a book on motivation._

By dumping them mid-way and getting to the next shiny one?

Anybody knows how this RoR kickstarter project finally went?

~~~
wycats
Yep. I shipped Tokaido and people use it. It was mentioned on Ruby Weekly last
week.

You can get releases at
[https://github.com/tokaido/tokaidoapp/releases](https://github.com/tokaido/tokaidoapp/releases).
Andres (who now maintains the project) released Tokaido for Ruby 2.1 (with
support for Mavericks) recently and we're working on Ruby 2.2 support as we
speak.

The org is here: [https://github.com/tokaido/](https://github.com/tokaido/)
and there are a number of auxiliary projects (muxr and tokaido-dns are the big
ones) that I developed separately along the way.

~~~
calgaryeng
Big ups for the "bigger man" type response :)

------
skrowl
This isn't really a big jump, as they were using AtScript before which was
really just a forked TypeScript:
[https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit9...](https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit97HnZoKVygDxpWzEYW0U/edit)

They must have convinced Microsoft to accept their patches into mainline
TypeScript.

~~~
aikah
Nope, AtScript was doing runtime type checking (AtScript is basically traceur
with some experimental features) while Typescript DOESNT. To be fair , I don't
care, but that's an important precision.

It means that the Angular team is giving up on traceur or maybe traceur and
typescript will merge somehow in the future.

~~~
lars
I don't see why anyone would want runtime type checking the way AtScript does
it.

With static typing, the compiler can catch type errors early, at the cost of
rejecting some otherwise valid programs.

With dynamic typing, that type checking is delayed until execution time. More
programs are valid, but type errors are caught late.

With AtScript-style late type checking, they took the dynamic type system and
introduced more type errors. This decreases the amount of valid programs, yet
catches no errors at compile time. It does nothing but increase the amount of
bugs.

~~~
nawitus
You want both. Compile-time checking is necessary but not sufficient.
Applications are not monoliths anymore, and web applications especially will
interact with multiple other processes and services. For these you really need
dynamic type checking. You can either try to do it in an ad hoc way in the
application code, or building the check into the language.

~~~
hderms
are you talking about the typing of data received from outside sources?

~~~
nawitus
Exactly. And even when you receive data from your "own" services that you have
type definitions automatically generated for, maybe there's a version mismatch
in a deployment somewhere and so on.

------
aikah
I don't care what people say Angular totally suffers from the second system
effect.

[http://en.wikipedia.org/wiki/Second-
system_effect](http://en.wikipedia.org/wiki/Second-system_effect)

~~~
Firegarden
I have specifically avoided angular because I feel like it's a monster in that
you are so tied to learning and understanding it's proprietary system. I too
have moved directly to react. Can anyone comment on how the skills learned by
learning Angular can be applied any where else?

~~~
AlwaysBCoding
You're 100% right. Once you're in Angular-land you are completely tied to the
framework. You don't think about "how can I make X in my domain happen?" you
think about "how do I make X in Angular happen". This coupled with the
horrific Angular docs make it really tough to justify using from a
productivity standpoint.

I've moved to React as well and feel it's a 10x boost in productivity because
I'm constantly thinking in my domain and not in a framework.

~~~
solomone
It's not like anything you build in React is going to transfer over to another
framework either. In fact, I've been to a lot of React talks and people mostly
ask "how do I do X" in react. The last talk I went to they spent 10 mins
talking about how you might make a spinner when data is loading.

I think that's the nature of any framework.

~~~
AlwaysBCoding
No, it's different.

React is a rendering engine, it's covers the final piece of your web app
(rendering a data structure into DOM). But whatever you do to create the data
structure that gets passed to React is up to you. This keeps most of your
domain logic outside the context of React, you just use React to render
data->DOM. So basically the API you have to learn is just Javascript, which
most people know already and is easy to lookup answers to your questions.

With Angular your domain logic exists in the context of the framework. i.e. if
you ng-repeat something you can't just filter that collection with Javascript
you have to use an ng-filter to do it which is a special Angular construct. So
the API you have to learn to manipulate data isn't just Javascript it's
Angular. And how does ng-filter work? Well, you're tied to the Angular docs to
figure it out. The Angular docs are of particualary poor quality so this
coupling turns into a really serious problem if you're trying to be
productive.

To me React vs. Angular isn't a matter of preference like Ruby vs. Python --
it's more like git vs. FTP where there is a clear right answer if you're
trying to be productive in a team envrionment.

~~~
jhall1468
Sigh... this is such an annoying comparison. If you want to compare, compare
React to Angular Directives since that's a valid argument.

Your entire complaint is that full-stack front-end frameworks are bad and
modular systems are good. It's great that you prefer modularity and the
ability to mix and match tools.

But stop pretending React vs Angular is a thing. It isn't. git vs FTP... just
stop.

------
usingpond
As if we didn't have enough reason to move on from Angular. Now you need to
learn Typescript to contribute or grok the source files?

~~~
BinaryIdiot
This is the main reason why I don't like using languages that transpile into
JavaScript. I don't mind the languages themselves but transpiling into
JavaScript now means you have to be effective in both languages instead of one
to properly debug and you're also subjected to bugs that may or may not be
known in the transpile itself.

Everyone seems to hate on JavaScript but it's really not that bad to use.

~~~
jherdman
Transpiling may actually be the safest way to use JavaScript, especially given
its rate of change. Take, for instance, a number of features trickling down
the ECMA2015 pipe: modules, classes, "let", etc. Using these features without
a transpiler, such as Babel, is simply not possible. A transpiler allows you
to use these features now without any worry.

Not all transpilers may be to your taste, but they have their place.

~~~
BinaryIdiot
> Transpiling may actually be the safest way to use JavaScript, especially
> given its rate of change. [..] A transpiler allows you to use these features
> now without any worry.

I disagree and my original statement applies as much to TypeScript as it does
to an ECMAScript 6 transpiler. If you want to use the new features and you're
transpiling now you need to have a good understanding of the differences
between ECMAScript 5 and 6 and you open yourself up to possible bugs in the
transpiler.

Instead you could just write ECMAScript 5 until 6 is more widely available.
Sure no one likes to wait but it requires the least amount of expertise and
lower chance of bugs from a 3rd party interfering with your application.

~~~
spion
I feel more comfortable writing TypeScript rather than using an ES6
transpiler, really. The compiler is built really well - you can observe the
team's development process on github and I have to say the level is quite
impressive (extensive code reviews and great discussions on the issue
tracker).

~~~
BinaryIdiot
I'm sure the compiler is well built but stability is my main concern.
JavaScript, even with its many flaws, is used by millions of people every day
and is one of the most used programming languages in existence. That's a ton
of testing through real world use. Since transpilers just compile to
JavaScript, they can take advantage of some of the same stability of
JavaScript for its output but the act of transpiling is only used by maybe a
few thousand users. Sure they'll find bugs and fix them but that's nowhere
near the same level as simply writing in native JavaScript (native JavaScript,
is that an oxymoron? lol).

Besides all that everything ever created has bugs; why risk introducing bugs
from a JavaScript engine and from a transpiler when you can risk a single one?

As an aside my first and last time using CoffeeScript I ran into an issue
that, since this was about two years ago, has already been fixed but at the
time it cost me hours of debugging time. It really soured my experience with
any transpiler.

~~~
peferron
You have a very valid point regarding bugs. Transpiler bugs definitely happen.
When I first tried using Babel - still named 6to5 then - instead of Traceur,
it immediately broke my code because of an incorrect TCO implementation in
Babel. Babel's maintainer (sebmck) is insanely responsive and the bug was
fixed almost immediately, but still.

If I used Babel or any other transpiler for critical production code, I would
only enable a whitelist of features that I thoroughly understand: for example,
how a fat arrow is translated into a regular function. This vetting would be
time-consuming, but that's a price I'd be willing to pay because I enjoy
writing ES6 much more than ES5. That's highly subjective though, so I
completely understand how some other people would rather just stick to ES5 and
get stuff done with the lowest possible risk of weird things happening.

~~~
zghst
Babel is a completely different transpirer than all the others. It's goal is
readable, understandable transpiled code and Sebastian (sebmck) is a genius
robot wunderkind. I check the repo everyday and see new updates, bug fixes,
etc. It is heartening to see someone give a project so much dedication.

I have an affinity for Babel unlike any other JS project (except React). They
team works really hard to keep it interesting.

~~~
peferron
Yeah, Babel and the Babel team is great. I got very suspicious of the project
after my first experience with it broke perfectly valid code, but after
reporting the issue and then another and having them fix it almost immediately
they won my confidence back. :)

For production code I'd still stick to a whitelist of features that have been
released for at least a month though. Babel is aggressively pursuing ES6
coverage and new features might not have all edge cases covered when they're
released. Give them one month though and with their responsiveness it's 90%
likely it's going to be fixed.

------
JustSomeNobody
Is javascript really so bad?

Edit: Why did this question get down voted? It was an honest question...

~~~
WalterSear
Not unless you try to make it look like Java.

~~~
possibilistic
It can be a challenge for sizable codebases, especially ones with many
contributors and that undergoes steady refactoring.

That feeling you get when you see code with lots of type checking... A lot of
engineering effort could be recovered with static typing.

~~~
WalterSear
Oh, I have no problems with strong typing. In fact I think it's a good thing
to add to angular. Angular, (And I say this as once upon a time contributor to
Protractor) however, is kind of a step in the wrong direction, and I concluded
this before they started flapping about with all these giant course
corrections.

------
the_gipsy
Yay! I have tested TypeScript in hobby projects with a very positive
experience. I have actually used typescript together with angular once. I was
very disappointed when angular announced that they were going to make some
kind of fork, for the runtime annotations they needed, instead of working
together.

~~~
k_bx
Until they tret null values as a separate type, I'm with Facebook Flow.

~~~
the_gipsy
Although I haven't tried Flow, I have taken a glance at it's Maybe Types. I
don't think that it is possible to work around libraries and browser APIs
returning nulls, and undefined seems to be completely ignored. I think if you
want to get rid of null/undefined then you have to use a complete different
language, something like Elm, but I would welcome being proven wrong.

~~~
k_bx
What do you mean it's not possible to work around libraries and APIs returning
nulls? That's exactly the point I made, Flow solved it.

Yes, they had to write interface for all browser APIs (and it's incomplete,
PRs welcome), and in places where API might return null it states that it may
return it. And your code has to deal with null and non-null cases explicitly
(or at least put an if).

You are right though that this type-system is much weaker than other languages
like Elm or Haskell, and for me, being from a Haskell world, writing JS with
Flow was still a disappointment. It's just that currently there's no better
alternative I know in terms of interop with JS and good level of error-
reporting.

~~~
the_gipsy
> What do you mean it's not possible to work around libraries and APIs
> returning nulls? That's exactly the point I made, Flow solved it.

Sorry, I had the really stupid misconception that Maybe Types could not be
applied to libraries and browser APIs.

So it seems like a good start, but it doesn't seem really useful if they
aren't even in the basic API's descriptions:
[https://github.com/facebook/flow/blob/master/lib/dom.js#L198](https://github.com/facebook/flow/blob/master/lib/dom.js#L198)

~~~
k_bx
If something might return null -- feel free to make a PR with making it a
Maybe type, like here:

[https://github.com/facebook/flow/blob/master/lib/dom.js#L359](https://github.com/facebook/flow/blob/master/lib/dom.js#L359)

------
dchuk
So Angular has gone from being written in plain JS, to Dart, to Atscript, and
now Typescript? Why so much jumping around? Isn't that creating a lot of
technical debt issues?

~~~
lastofus
Constantly trying out the "new hotness" seems to be the norm in front end dev.

~~~
WalterSear
Ditching angular has been the new hotness for a while.

------
boothead
Wow! That's pretty big news!

Very much looking forward to seeing what insights come out of rebuilding
something like angular with types.

 _edit_ actually on second reading, I'm not sure what's been rewritten in
what?

------
digdigdag
Are there any organized efforts to fork the 1.x branch to sustain existing
applications?

~~~
grumblestumble
Not so much to fork, but Angular 1.x is continuing to be developed and Pete
Bacon Darwin has taken over as the technical lead:
[https://plus.google.com/+IgorMinar/posts/2Uo6yh4AV7L](https://plus.google.com/+IgorMinar/posts/2Uo6yh4AV7L)

Angular 1.4 is well underway and there's a lot of good stuff coming out of it,
for example the reworked router module.

~~~
jffry
FYI the new router module
([https://github.com/angular/router](https://github.com/angular/router)) is
going to be a separate project, with semver'ed releases. It'll expose bindings
for both Angular 1.x and Angular 2, but it isn't bound to the Angular release
cycle.

Here's a presentation from ng-conf today about the new router:
[https://www.youtube.com/watch?v=vecg70fPDFw](https://www.youtube.com/watch?v=vecg70fPDFw)

------
tegeek
Looking at the example source code & having experience of AngularJs & TS, I
would say this is a huge development in term of enterprise adoption.

Statically typed, annotations, built-in dependency injection, comprehensive
test support (easy to write testable code), declarative UIs, 100s of already
available libraries & above all support from Google and Microsoft. I can say
this with confidence that even with a complete rewrite & not backward
compatible, AngularJS 2 with TS is going to be a huge success for everyone.

And sooner or later, all other frameworks will adopt ECMA Script 6 because of
standardisation of so many things (modules, classes etc.)

I would also like to add that this is a very exciting time for JavaScript
developers because there are so many things happening & companies of all sizes
will keep investing good amount of money moderating their JS code bases.

~~~
woah
Yea, I'm super excited that the Angular team has given us ES6!

------
arikrak
If Google is promoting TypeScript, can they still promote Dart? How many alt-
javascript's can one company promote?

~~~
shadowmint
They use it internally, but seriously as a platform for other people to use?

Not really, no.

...then again, the 'dart community' has diminished to basically nothing, so I
doubt many will care particularly.

------
Keats
Anyone successfully using typescript with react/flux? I found it a bit
cumbersome to use with most of the flux implementations

~~~
ethagnawl
Have you tried Flow? I would (naively, perhaps) assume it was meant to work
well with the rest of the FB stack.

~~~
Keats
Babel + Flow is the next combination I'm going to try

------
ChicagoDave
My brain just broke. I can't even imagine Google and Microsoft working
together on anything as big as Angular. The Universe just took a 90 degree
turn.

------
pluma
Does that mean they have finally given up on AtScript?

~~~
dmarg
AtScript is now TypeScript is what they said in the opening remarks.

------
cdnsteve
Angular.ts ...

------
thomasfl
"Special shout out to Yehuda Katz, who helped us design the
annotation+decorator proposal which helped make this work possible."

The feverish Yehuda Katz is everywhere! But most importantly he is here on
Hacker News and has close to 6000
[https://news.ycombinator.com/user?id=wycats](https://news.ycombinator.com/user?id=wycats)

------
jugularkill
There's clearly a corporate agenda with 2.0 but who cares. The most important
question is "Is this the best thing for my scenario?" Probably not but it has
a name.

There's too much talk about "typescript" and not enought about what problems
Angular 2 solves compared to "not" having a ready made framework or how many
problems it adds.

------
plurby
Here is a nice introduction video to TypeScript from ng-conf 2015
[https://www.youtube.com/watch?v=U7NYTKgkZgo](https://www.youtube.com/watch?v=U7NYTKgkZgo)

------
electrotype
Why not Dart?

~~~
aberatiu
Yeah. Seriously, why not dart. Any clue, anybody?

~~~
ratbeard
Dart requires loading a dart runtime js file on to the page, as far as I know.
And I think they would claim Typescript is javascript + some extra stuff on
top, whereas dart is a whole new language to learn.

~~~
dubcanada
No Dart compiles to JS. Obviously there is some overhead with transpiling
languages, but it's actually pretty small. They have done a good job with it.

~~~
xrstf
Dart can be run in both modes. Chrome (dunno if enabled by default and/or in
stable) contains a Dart VM, so you "only" need to transpile into JS for non-
Chrome.

The main problem I had with Dart was [a year ago] that using existing JS
libraries like jQuery wasn't as seemless as I would liked. So that would be a
reason against Dart, if Angular wants to make that aspect easier.

Haven't looked at TypeScript's interop with JS. I got frightened by the name
Microsoft and the fact that they only had a huge language spec PDF and not a
single tutorial or something easier to digest.

~~~
danellis
> Dart can be run in both modes.

In production, it's only ever transpiled to JavaScript.

> Chrome (dunno if enabled by default and/or in stable) contains a Dart VM, so
> you "only" need to transpile into JS for non-Chrome.

Not the real Chrome. A version of Chromium that you can use to make the
development cycle smoother. When you deploy, you still transpile to JavaScript
for _all_ browsers.

------
shockzzz
Remember Angular Dart?

~~~
ahoge
Angular 2 is heavily inspired by AngularDart. Angular 2 has a single codebase
for JS and Dart.

~~~
dmak
Sounds like they are trying to move people from Angular to Dart

~~~
shadowmint
The other way around.

(oh! You meant as, in, externally, not internally. I see...)

------
itsbits
One of the reasons, people preferred Angular was its learning curve...now, its
more or less equal to Ember or Knock out...

------
taylorbuley
Can anyone clarify if TypeScript usage is in place of Dart or in addition to
Angular Dart?

~~~
isoos
They write their core in AtScript/TS, and cross-compile it to Dart and JS
(ES5).

~~~
Sammi
AtScript and Typescript have merged.

------
outsidetheparty
My main feeling about this is not so much about typeScript (which, meh, some
syntax sugar I don't care about, and tooltips for an IDE I don't use) -- more
it's that just the mere whiff of Microsoft's involvement will be enough to
snuff out remaining developer interest in Angular 2.

~~~
EugeneOZ
There are not so many devs who hate MS just for being MS. Mostly kids.

~~~
Sammi
Even less in these days of open source glory.

I remember being a MS hater as a kid. Now I hate all the big software
companies. Just some more than others. And MS is heading in the right
direction these days, so I'm optimistic. Hopefully it'll stick.

------
andrewrice
At this point, should a newcomer learn Angular 2 or stick to 1.*?

------
sebastianconcpt
Dude you don't even virtual-dom

------
pbowyer
Is TypeScript the new CoffeeScript?

~~~
iends
No, Coffeescript has always been crap. Typescript is getting better and
better.

------
evbots
wtf

------
yawz
Oh no!

------
tonyedgecombe
Embrace, extend, extinguish.

~~~
xiaq
To extinguish, you introduce incompatibilities to make the life of people
outside your inner ecosystem (compared to the greater, standard-compliant
ecosystem) harder. But since TypeScript compiles to JavaScript and interfaces
with plain JavaScript wells, there is really no "extinguish" part here.

Also, the EEE accusation doesn't really apply to open source projects. EEE is
bad since after the proprietary product supersedes ("extinguishes") an open
product, the community loses control forever. However when an open product
supersedes another, the community always have the choice of forking the
project to take back control.

~~~
aikah
to be fair typescript isnt compatible with es6 right now.

