
Why Angular 2 Switched to TypeScript - Doolwind
https://vsavkin.com/writing-angular-2-in-typescript-1fa77c78d8e8#.xkfxa7yag
======
pixie_
I've been programming for a long time and TypeScript has been a slam dunk for
me. It makes programming large web apps actually considerably more manageable.

Unfortunately I spend a lot of time defending the merits of static typing to
my co-workers. At the same time they're going on about how unit tests are
important, while static typing eliminates entire classes of errors and they
don't get it for some reason. Unit tests while important don't prevent type
errors, and if you tried using them for that you'd have orders of magnitude
more tests to write.

I feel like I'm taking crazy pills having to defend static typing while every
dynamic language I've used for any project of any considerable size has been a
complete nightmare to manage. At this point I feel like a lot of new coders
coming out of school just haven't written anything large enough yet and maybe
that's why they don't see the point.

~~~
bsaul
Don't worry, it's all coming to an end. All the trending languages either are
statically typed ( go, swift, rust), or provide some kind of type hinting
(elixir) to make up for it.

Unit testing is great, but it doesn't provide autocompletion, or help you
analyze your codebase before a refactoring.

------
iLoch
I wanted to use TypeScript with a new React project, but the biggest problem I
had (which eventually lead me away from using it) was that typings were so
hard to get ahold of. Built something in JS? Sorry, you have to provide what
is essentially a source map in order to get it to work with TypeScript. That
should be a non-starter for anyone who is doing more than a hello world app.
Figure out a way for me to use TS without having to create a bunch of extra
type garbage in my app and I'll upgrade my code base immediately.

~~~
cheez
I was under the impression that typescript is a superset of javascript. Is
that not the case?

~~~
dweinus
The title of one of the article sections is literally "TypeScript is a
Superset of JavaScript" ...people do still read before commenting, right?

~~~
cheez
Just wondering why you can't use React directly if that is the case

~~~
iLoch
In order for TypeScript to understand the types it is interfacing with
(especially in the case of libraries) there has to be a type definition
created for each library. Dismissing my complaint because "TypeScript is a
superset of JavaScript" shows a lack of understanding regarding how the system
works.

------
stephen
Question for TypeScript and specifically Angular 2: does Angular 2 being
written in TypeScript mean that webapps based on Angular 2 that are also
written in TypeScript, are basically 100% type-safe (e.g. all app-to-Angular
library calls, or within-app view-to-model/etc. calls, are all type checked)?

I ask because after looking (admittedly very briefly) at writing an Ember app
in TypeScript, it looked like because Ember assumes all of it's webapps will
be JavaScript, there ends up being a lot of dynamic-/string-based idioms, e.g.
model.set("property").

(There is a good SO post about turning this into a typed
model.property.set(...) in TypeScript, but that solves just this one instance,
and not the entire Ember experience.)

So, this left me with the feeling that for a TypeScript webapp to have a truly
great/first-class/typed interaction with it's framework (Angular, Ember,
whatever), that the framework itself would have to: a) be written in
TypeScript, and b) have the founding assumption that most (all?) apps written
for it would also be TypeScript.

So, per this post, Angular 2 is a), it's written in TypeScript. What about b)?

~~~
coltonv
Nothing in Javascript can ever be completely type safe right now. For example,
you compile your TS code and it compiles without error, but you pull a JSON
object from the server and pass it into a function which is expecting the
argument to implement a certain interface. The problem is the interface is
dropped in compilation and there's no type checking at run-time, so there's no
way for Typescript to know that the program will be type safe at run-time.

~~~
k_bx
Not sure about TS, but a good type system would not mean you know the
structure of dynamic JSON. It would just guarantee that before accessing some
field, you would define in some way your code path what to do in case there is
that field and in case there isn't. So, at the end, even if you missed the
structure, you would have a clearly-defined error reporting logic (or whatever
is necessary) at your runtime.

------
Doolwind
If you're looking for Typescript type definitions for a project you're using
check this list -
[https://github.com/DefinitelyTyped/DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped)

~~~
lstamour
Good list, but are they going alphabetically and only made it to 'k'? ;-)

Edit: Thanks, I had a feeling there was a bug... it was just strange to see
files from the top-level folder appear afterward, made it less obvious.

~~~
jjude
You can install typings (npm install -g typings) and then search for type
definitions. For hapijs, it would be `typings search hapi`. Then you can
install using `typings install dt~hapi --global --save`.

------
shadowmint

        There are a lot of options available to frontend devs 
        today: ES5, ES6 (Babel), TypeScript, Dart, PureScript, 
        Elm, etc.. So why TypeScript?'
    

...

    
    
        Elm and PureScript are elegant languages with powerful 
        type systems that can prove a lot more about your program
        than TypeScript can...
    

ouch. Thats got to be a tiny bit awkward for the Dart team to read (so, I
guess Dart isnt in the list of elegant languages then?)

~~~
leshow
Dart isn't even in the same progamming paradigm as Elm and Purescript, so I
don't think it was meant as a slight towards the Dart team.

And really, Dart is more like Java, it's nowhere near the elegance of the
ML/Haskell pedigree of Elm and Purescript

~~~
pjmlp
I think it should already be a pain point that internal Google teams decide to
use languages designed by the competition instead of their own.

------
lomnakkus
It continues to be amazing to me that a new generation of developers is
discovering that, yes, static checking adds a lot of value (for non-trivial-
sized projects). Of course, if you were tasked with delivering web apps --
until recently -- you didn't really have any choice.

The older I get, the more the whole "everything moves in cycles" thing appears
to be true -- almost regardless of what particular subject matter is under
consideration.

~~~
orgomon
Where is the evidence that static typing results in a net benefit? There's
some evidence that points in the opposite direction:

[http://games.greggman.com/game/dynamic-typing-static-
typing/](http://games.greggman.com/game/dynamic-typing-static-typing/)

When a language imposes static types, it also imposes a development cost,
possibly negating all the value it brings.

Typescript is a little in the middle in that static typing is optional, but
then you also don't reap the supposed benefits wherever you don't use it. Any
"tool-based" refactoring is now _less_ reliable than a simple text search.

As for catching type errors, those are usually caught very early. If they
aren't, that points to a lack of test coverage.

As for the "documenting" aspect: The article claims that by static typing, the
documentation need not be consulted, which is rather irresponsible. If you use
a function, you had better read the documentation. I know that's a bit much to
ask from actual developers, but it's true.

~~~
crypto5
> it also imposes a development cost,

Very very small cost.

~~~
dang
> _Very very small cost._

I've gone back and forth a few times in my career (currently preferring
dynamic languages) and would say that the cost is considerable, even with type
inference. The trouble is, we don't notice the costs of approaches we're
habituated to or prefer, so it feels like they're much smaller than they are.
And we don't account for the costs we don't notice, so our cost/benefit
analyses (on both sides of the question) are skewed. We all unconsciously put
a finger on the scale.

This doesn't stop everyone from making grand, confident claims about static
vs. dynamic typing. Such studies as there are don't support these claims, but
the studies are weak in so many ways that it's easy to dismiss the ones you
don't like and stick to your previous opinion, so that's what we all do.

For these reasons, the debate is pure tribalism and cargo cult. We should stop
pretending that our views have any objective support and just talk about them
in terms of taste. That's unsatisfying to the technical mind, though, so none
of us will!

~~~
domlebo70
What is the cost? I mean, you are already working through the types in your
head when writing code in a dynamically typed language. It's not like you get
to just forget what type things are when you program.

~~~
dang
Here's one of many examples: when you're defining types you have to think of
names for them. That's a high-energy mental operation.

~~~
domlebo70
Interesting. Can you give me some more examples?

~~~
dang
Another is that you get a slower interactive development cycle because you
have more things to do before your code can run.

For example, some portion of your program may be half-baked because you
haven't worked out its types yet, or maybe you've changed a type but haven't
yet updated the rest of the program. If you want to play with your program
interactively to find something out about the work in progress, now you can't,
because your program isn't currently 'correct', i.e. it isn't self-consistent.

This adds drag to the development process. First, you have more work to do.
Second, it breaks flow: you must switch your attention to something
extraneous, breaking your concentration on what you were doing. Third, it gets
you in the habit of satisfying the machine rather than thinking about the
problem you're trying to solve.

------
stevehiehn
So far I'm really into typescript (for dev). However i one big problem which
is C.I. It's annoying to have to configure an environment just to run a TS
compile job.

~~~
lomnakkus
I don't understand what you mean by "have to configure an environment just to
run a TS compile job". Didn't you already have some sort of automated CI
testing running on all your JS code?

~~~
stevehiehn
Really I just didn't want to have to install node in the build step because it
was already complex.

~~~
lstamour
Whether it's TS or some other form of minification or listing, I find node on
a build server is unavoidable these days. I just wish it used fewer resources
during npm installs...

