
Love for TypeScript - svieira
https://github.com/Microsoft/TypeScript/issues/10011
======
Retozi
TypeScript is the one technology I would discard last of the entire web stack.

Using TypeScript instead of JavaScript is such a productivity boost for a team
developing a sizeable single page application, any other technical decision
(which Framework, tooling decisions) is almost irrelevant relative to this
major improvement.

TypeScript has ALL the properties that should make adoption a no-brainer:

1) Increases developer productivity, especially over long term maintenance
timeframes. (My non-scientific, ymmv estimate is at least 30%)

2) Reduces production exception rate significantly

3) Can be adopted gradually

4) Full JavaScript ecosystem still at disposal

People seem to massively underestimate the benefit of a typed language in a
frontend codebase. At gunpoint, I would rather have the backend in a
dynamically typed language and keep TypeScript for the frontend. Chances are
that the distance between your database and the API is not far, so static
typing is not that useful.

However, if you have decided for a client side rendered application, your app
is stateful, dynamic and probably quite big. Static typing really helps to
avoid mistakes and increases the ability to refactor quickly and correctly by
order of magnitude.

There are too many hardly ever visited code branches, and tests are very
costly to write for an application where users can click a lot of things.

~~~
wangchow
Although, dynamic languages force extra incentive to unit-test the shit out of
the codebase. Compilers certainly catch a lot of syntax mistakes and whatnot,
but it also relaxes the requirement to add extra code coverage. The onus is
more on the developer with dynamic typing but I'd take more-accurate code
coverage over static types any day!

EDIT:

If you have static-typing _and_ good unit-test coverage it's the best of both
worlds I suppose. I tend to prefer duck-typing though which is sort of wedged
in-between dynamic and static-typing in a sense. This however then becomes not
a question of static vs. dynamic typing but of the language implementation of
the type system.

In C++ for instance, the over-object-orientation is a pet peeve of mine when
people define so many types and interfaces for this-and-that. I tend to prefer
the "looseness" of template functions since you can pass whatever type in
there so long as it contains the appropriate methods on the passed-in object.
Such _is_ static typing though so I'm digging myself into a hole from my
original post :)

Now, a good static-analysis tool could catch issues on a dynamically-typed
language in the same sense. Then I suppose the dynamic language becomes a
pseudo-static language since a static-analysis algorithm is executed on the
codebase. Since most build systems are set up to do: compile codebase; run
static analysis to detect issues; run unit tests; run integration tests, it
could theoretically be redundant step at compile-time doing static analysis
when it's also done by an external tool. Just some stream-of-consciousness
thoughts :)

~~~
lubonay
The only tests you have to discard when using a statically typed language are
some of the tests validating your input data. I don't see how static typing
leads to less test coverage...

~~~
catnaroek
> The only tests you have to discard (...) are some of the tests validating
> your input data.

That's not true. You can safely discard anything that tests something you've
proven. A good type system doesn't only prove things for you - it also makes
it easier to manually prove what the type system can't prove.

~~~
shados
A good type system, yes. Something like TypeScript though? Only checks that
variable types match. We're a far cry from ML/Elm/Scala/Haskell here.

So the only thing it helps is get rid of bad tests (eg: tests that check a
function return any string...tests you shouldn't write even in a purely
dynamic language).

~~~
catnaroek
> Something like TypeScript though? Only checks that variable types match.

TypeScript's type system is unsound, so you can't rely on the type checker
alone to prove anything useful. However, manually proving things about
TypeScript programs is still easier than doing so with JavaScript programs.

I don't believe it's practical to rely on type checkers to prove absolutely
everything. There are mathematically proven upper bounds on how much you can
automate reasoning. For instance, global type inference only works with first-
order type languages. Higher-order anything flies out of the window, yet
higher-order properties of programs need to be proven!

What we ought to do is find the optimal division of labor between automated
and manual proving, always keeping in mind that the optimal case isn't being
able to prove something. The optimal case is not having to prove it because
it's obviously true. How do we design a programming language so that more
interesting things are obviously true?

------
johnfn
TypeScript is straight up one of the best technologies I work with, rivaled
only possibly by giants like Postgres. It takes one of the worst parts of my
day - refactoring Javascript code - and makes it straightforward and
enjoyable.

TypeScript 2.0 goes beyond that and begins to push the envelope on what type
systems can do. Recently I've been loving the combination of discriminated
union types and nullable types. It means that you can have code like this:

    
    
        function myFunction(x: number | null) {
            if (x === null) { 
                return;
            }
    
            console.log(x + 1); // x is now a number
        }
    

The argument to the function is x, which is either number or null (that's what
number | null means). But the if statement ensures it's not null by exiting
the function, so by the time you get to the log TypeScript has (correctly) set
the type of x to be just number!

The types match up exactly with how you'd write the Javascript code. It's
awesome and it just works.

~~~
paradite
I have not used TypeScript, so can anyone explain to me what is the difference
between the above the normal JavaScript code like this:

    
    
        function myFunction(x) {
            if (x === null) { 
                return;
            }
    
            console.log(x + 1); // x is now a number
        }
    

Edit: Or is this example being used to show that TypeScript now support
multiple types including null in the parameter?

I assumed that such feature would be available by default.

~~~
ycitm
You could call your js function with a string, and rather than a compile time
error you'd get broken behaviour at runtime.

~~~
Too
Inside the function you also have to continue using x as a number, like you
wouldnt be able to accidentally pass it into a function accepting only string
as argument etc.

------
scotty79
Wait? Same guy built Turbo Pascal, Delphi, C# and now Type Script? First three
is the list of languages that make me feel at home when I'm doing desktop
development. Yet another reason to seriosly try TypeScript with default
tooling if it's comming from this guy. His work is beacon of sanity in tangled
world of software development.

~~~
mercer
Yeah, for me one reason to give TypeScript a serious go was that I grew up on
Turbo Pascal and Delphi, and a bit of C# experience. Haven't been
disappointed.

------
isoos
It is interesting for me to follow how the community mindset develops around
TypeScript/JS/... over the years. Many in the JavaScript community frowned
upon GWT, Closure Compiler, Dart and other typed compile-to-JS tools, most of
which predate TypeScript, and provided state-of-the-art tooling at the time.
"Types are overrated, everything that is non-JS must go away" was a common
mentality.

Now some of these people started to see some value in tool-based refactoring,
and suddenly realize that types are not always bad. TypeScript undeniably
improves the situation over JavaScript, with the caveat that it won't stop you
shooting in the foot with the bad parts of JS. So now, types are good,
nevertheless JS must stay.

I wonder how many years it will take for people to lobby for a clear break of
JS backwards-compatibility, to use something that is not ad-hoc, has good
tooling and a great base API, etc. Something where sorting number doesn't need
additional extra care.

These usually start to matter when the team size is beyond 10 person working
on the same part of the codebase. It will be interesting to see how this spans
over the years. I bet the earliest "clear break of bad JS" will happen around
2019, with mostly linters and data flow analysis improving but hitting the
eventual limits.

Uninteresting times, in a certain sense. I'm glad we have other tools to
compete with.

~~~
spion
GWT came with a language that has a poor type system for JavaScript's needs.

Closure Compiler types are/were too verbose. It didn't support most module
systems until this year.

Dart didn't provide an easy interface to existing JS libraries. Everything
goes through a very cumbersome FFI. Also the only "tooling" was Eclipse.

TypeScript comes with a structural type system (with generics) designed
_exactly_ to fit existing JavaScript code perfectly, as well as a type
definition scheme for existing code, as well as support for all current JS
module systems (ES6, CommonJS, AMD). The tooling also comes in the form of an
embeddable language service.

It succeeded because its a type system for JS, and not a compile-to-JS
language for another ecosystem.

~~~
magicalist
> _Closure Compiler types are /were too verbose._

The difference is about the length of an additional "/ __@type _/ " and the
fact that the annotation is in a comment, not in code. That had the benefit
that that all code for closure was valid JavaScript, which was key in the days
before basically all production JavaScript went through a transpilation step.

> _It didn't support most module systems until this year.*

ES6 modules maybe, but it's supported CommonJS and AMD modules since 2011[1]
and its own module format before that.

The real reasons I think it didn't catch on are that it came out too early for
much of the JS world, the closure library is written verbosely/awkwardly
(though there's no reason to touch it when using the compiler, they're
associated by name), and many thought you to annotate all existing code to use
it instead of adding annotations incrementally.

[1] [http://www.nonblocking.io/2011/12/experimental-support-
for-c...](http://www.nonblocking.io/2011/12/experimental-support-for-common-
js-and.html)

~~~
spion
1\. Its unclear how you can declare new generic types using @type

Here is an example type of a map function in TypeScript:

declare var map: <T, U>(f: (t:T) => U, t:T[]) => U[]

I cannot figure out the equivalent @type annotation in Closure using these
docs: [https://developers.google.com/closure/compiler/docs/js-
for-c...](https://developers.google.com/closure/compiler/docs/js-for-
compiler#declaring-a-generic-type)

------
SomeCallMeTim
TypeScript is, in fact, awesome. 2.0 adds still more awesomeness, and 2.1 has
async/await compiled down to ES3/ES5, which I will be very happy to see.

The only thing that I don't understand is why TypeScript isn't just considered
a required client (or Node) Best Practice at this point.

There are other languages that I prefer for specific domains, of course. But
if you're writing code that needs to run on a web client and/or that needs to
run in Node, TypeScript is the only way to go.

~~~
michaelchisari
For me, I've simply decided to just focus on javascript. I have to use it, and
while I had quite a bit of enthusiasm for Coffeescript, the move towards ES6
has made me realize that I need to just buckle in.

Maybe it's a little bit of fatigue setting in, but at this point, my next
foray into a new language will be something properly compiled like Rust or
Swift, not a transpiled language.

This is not to detract from Typescript or Purescript or anything else like it.
There's some amazing work going on, but for now, I'd rather learn the ins and
outs of javascript instead, warts and all.

~~~
cel1ne
Give Kotlin a try. It's a JVM-language and 100% java-compatible, but it can
also compile to Javascript (not sure if that backend is production-ready yet
though)

[https://kotlinlang.org/](https://kotlinlang.org/)

It's also backed by JetBrains the IDE-maker.

~~~
jbverschoor
Kotlin is a JVM clone of swift.

~~~
nostrademons
They're actually quite different - a good chunk of my current project is in
Kotlin, and all of my last project was in Swift.

Things Swift has that Kotlin doesn't: associated types, file-based access
control (changing in Swift 3.0), pervasive use of keyword arguments, trailing
closures, full pattern matching (Kotlin can only destructure component1...N
sequences), reference counting.

Things Kotlin has that Swift doesn't: smart casts, declaring properties
directly in the constructor, declaring constructors directly in the class
statement, auto-delegation, data classes, singleton objects, implicit
parameterizable 'this' (handy for builders & DSLs), garbage collection.

Things they both have: null chaining & defaulting, class extensions, somewhat
clumsy first-class method syntax, concise lambda syntax, lambda anaphora ('it'
in Kotlin, $0 and $1 in Swift), concise range operators, property descriptors,
operator overloading.

Kotlin generally has the feel of a much more pragmatic, industrial language.
It's Java without the warts, where the designers took note of the common Java
patterns they wrote and provided a lot of syntactic sugar to dramatically
improve brevity. Swift feels more academic; its type system is more modern and
less ad-hoc, it has polished implementations of many features that academic
languages have been trying to get right for years. Both are heavily influenced
by their ecosystems; Swift feels like a better Objective-C, and Kotlin feels
like a better Java.

~~~
cel1ne
Kotlin does have trailing closures:
[https://kotlinlang.org/docs/reference/lambdas.html#higher-
or...](https://kotlinlang.org/docs/reference/lambdas.html#higher-order-
functions)

And some form of pattern matching via the "when" keyword:
[https://kotlinlang.org/docs/reference/control-
flow.html#when...](https://kotlinlang.org/docs/reference/control-
flow.html#when-expression)

~~~
nostrademons
It's a bit different in Swift. Kotlin lets you omit the parentheses if the
closure is the _only_ argument to the function. Swift lefts you place the
lambda outside of the parentheses if the closure is the _last_ argument to the
function. That lets you construct a much larger variety of control-structure-
like HOFs. Event handlers, for example, often take a functional argument plus
a bunch of other data.

~~~
cel1ne
No, it's the same in Kotlin, from the docs:

"There is a convention that if the last parameter to a function is a function,
that parameter can be specified outside of the parentheses."

So you can have normal arguments and specify the last parameter outside like.

    
    
        val col = "A"
        val row = 3
        table.update(col, row) {
           it * 5
        }
    

You may have confused that with SAM-conversions (?), which are for java-
interop: [https://kotlinlang.org/docs/reference/java-
interop.html#sam-...](https://kotlinlang.org/docs/reference/java-
interop.html#sam-conversions)

~~~
nostrademons
Cool. Learn something new every day. (I was confused because all the examples
except for lock() are single-arg, and IntelliJ usually autocompletes with
parentheses because there's often a non-functional overload.)

------
deevus
I too, love TypeScript.

The client side JS where I work was becoming a bit of a horrible beast so I
started using TypeScript here and there when I worked on new things. It has
really helped rein in some un-maintainable messes.

It's got to the point now where TypeScript is my default go-to language
because it's so powerful.

Someone mentioned how great it is for strongly typing API's and libraries, and
I have to second this. When there aren't typings available it forces me to
RTFM instead of just prodding around in intellisense, so in some cases it
actually helps me learn libraries better.

Just today I created a boilerplate project for webpack/typescript 2 [0]. It's
not finished yet, but it's usable if you wanted to jump right into TypeScript
with no run-time dependencies. As a bonus I modified the same boilerplate but
for HTML [1]

[0]: [https://github.com/deevus/webpack-
typescript2-boilerplate](https://github.com/deevus/webpack-
typescript2-boilerplate)

[1]: [https://github.com/deevus/webpack-typescript2-html-
boilerpla...](https://github.com/deevus/webpack-typescript2-html-boilerplate)

------
saosebastiao
I cant believe how much more accessible typescript is than javascript. Type
signatures are helpful. Refactoring is so much less stressful. Even things as
simple as catching misspelled imports have saved me tons of time.

At one point in time, a 'this' bug ate up half of my day. Ever since moving to
typescript, I haven't had a single 'this' bug make it past the compiler. I
still don't fucking understand 'this'...all I know is that Typescript knows
what it is and can tell me to fix something before I send it off to the
browser.

Typescript will never be my favorite language...not even close. But since we
can't actually get rid of javascript, I'm pretty happy we have typescript
around to make it not suck so much.

~~~
ridiculous_fish
TypeScript catches a lot, but "this" bugs are still one of the most common
things it misses. For example, when factoring a method into a free function,
I'll often miss a this:

    
    
        function hypot(x:number, y:number) {
            return Math.sqrt(this.x * this.x + this.y * this.y)
        }
    

TypeScript does not warn about this case.

~~~
farnsworth
Check out the option "noImplicitThis" in TS2, for this exact case. It will ban
using `this` when it's implicitly `any`. I agree that it was much needed!

~~~
ridiculous_fish
Great addition! Thanks for pointing it out.

------
einrealist
We introduced Typescript into our architecture. We start to love it, too.

One thing though: the engineers started to write classes for everything. I had
to catch that and forced them to stay as functional as possible. Does that
happen to other teams, too?

And I really like to see WebAssembly to become part of our browsers and
Typescript generating it instantly.

~~~
kevingadd
TypeScript will never generate WebAssembly for you. WA is used for hosting
your own sandboxed native code environments, it doesn't offer any of the
tooling you'd need to run TypeScript-based libraries/applications.

~~~
ZenoArrow
I don't understand this line of reasoning. WebAssembly isn't 'sandboxed native
code', it's a compressed AST, and even if it was native code there's nothing
stopping someone creating a native compiler for TypeScript.

That said, Typescript is most likely to support WebAssembly when WebAssembly
offers a GC implementation for it to use (the WebAssembly GC is planned in the
medium to long term IIRC).

------
mark_l_watson
I like TypeScript for what is probably a different reason than most people. I
have started using TypeScript as a great languge for book examples. The
language is so easy to read and understand, and it is so quick to install the
compiler and runtime. Right now I am using it for many of the examples for a
book Introduction to Cognitive Science that I am writing. TypeScript is a
great universal language for thinking about code and algorithms.

~~~
Noseshine
Ahem... TypeScript is 100% Javascript, they only add _optional_ type
annotations. The "to-ES5" compilation serves a different issue - that's just a
different version of Javascript.

~~~
mark_l_watson
But I use the surface TypeScript syntax for the book examples. It is a clear
and concise notation, which is why I like it for this use case.

~~~
Noseshine
I have no idea what you mean by

    
    
        > surface TypeScript syntax
    

TypeScript syntax is... Javascript (ES 2015 or above) - plus the optional type
annotations and some few minor additions like "enum" or decorators. Things
like "interface" don't compile to actual code, they only serve the compile-
time type checks.

------
gaoshan
I will say that I'm my experience developers with a background in C# seem to
love Typescript while developers with a background in Javascript seem to be
slower to warm up (a lot slower).

In our office it seems like the JS folks are sensing that they should "get on
board" with the clear enthusiasm from the C# folks but there is resistance
(mostly muttered quietly to each other to avoid looking like they don't get
something that seems so obvious to others).

------
a-saleh
Did any of you have good experience using typescript on node.js project?

I remember trying out typescript with few tutorials, but so far mostly on the
browser side (i.e angular 2 is in typescript) and when I poked around I
couldn't really figure out how to hook up to the npm ecosystem.

Was that just a lack of decent google-fu that particular day?

~~~
d357r0y3r
Yes, wouldn't even consider using node without TypeScript, personally.

Really, the main pieces that could seems a little mysterious are type
definitions and compiler options. tsconfig.json exists in the root of the
project for compiler options. Type definitions can be managed by a library
called 'typings', or for TypeScript 2.0, type definitions can be managed with
npm.

~~~
mercer
The biggest problems I had with TypeScript involved type definitions, combined
with the module system. Now, the latter is not TS' fault and a bit clusterfuck
at the moment for everyone, but it's a bit more complicated if you add TS to
the mix.

It's improved immensely though in the past months/year.

------
awalGarg
This would be a little offtopic for this thread, but anyone knows if there is
an example of using TypeScript with Node only as a typechecker (like flow)?
Recently it was in news that TypeScript can understand JSDoc annotations - so
I was wondering if I could use TypeScript as a typechecker for my code which
is all 100% pure JS with JSDoc style type annotations.

I tried flow, but flow's comment syntax for type annotations is not compatible
with JSDoc, and flow really needs a lot of work still. I am hopeful it will
improve, but I feel presently it isn't ready for primetime for large codebases
on the server side. (I guess it works great for React though).

Pretty new to TS but I like TS a lot as well!

~~~
wwwigham
The TS compiler is usually configured to disregard most type errors in JS
(even if it does infer a bunch types from JSDoc comments); if this would be
super super useful for you, you should consider making an issue or upvoting an
existing issue for it on the TS repo!

------
agentgt
Did anyone else chuckle at the bug labels (I often find weird things funny)?

------
qwertyuiop924
Wow. I feel like the only person who doesn't especially like static typing,
traditional OO, and typescript.

~~~
GFischer
Many people like myself like static typing and don't particularly care for
"traditional OO". I wouldn't put them all in the same bag.

Heljsberg himself (the creator of TypeScript) likes functional programming a
lot and brings the best features to his languages.

I haven't tried TypeScript yet, but I look forward to it :)

[http://www.itwriting.com/blog/2443-anders-hejlsberg-on-
funct...](http://www.itwriting.com/blog/2443-anders-hejlsberg-on-functional-
programming-programming-futures.html)

~~~
qwertyuiop924
I put it in because TS added 'class' to the language

------
zumu
What are some reasons to switch from flow to ts?

I see a lot if ts hype, but flow has been getting the job done for me. When
non-nullable types come to ts via 2.0, I could see myself switching if there
are viable reasons.

~~~
shados
basically, on paper flow is better. However, lack of Windows support and poor
tooling, plus the fact that it was second to market, slowed down its adoption.
Now you have the issue where TypeScript has thousands of type definition for a
lot of libraries, and Flow only has a few. Facebook keeps underestimating
Windows (eg: there was a survey out for a while asking people if they should
just stop working on Windows support for Jest and depend on Windows 10's linux
userland support instead).

That, coupled with Flow being harder to get up and running, makes TypeScript
much more popular for the average developers. I still prefer Flow though :(

------
q1t
How is Dart doing comparing to TypeScript? I mean what are significant
differences?

------
andrewclunn
Sorry, but unless browsers srart interpreting typescript directly, I won't be
using it. I'm done with flavor of the month preprocessors. I'll code in the
base language and focus on developing my skills there.

~~~
pmoleri
I totally get your point and I would think the same if all browsers supported
ES6. But right now I would transpile just to use ES6, and TS adds a lot of
goodies on top of that. Also, TS is pretty stable and proved its value, it
isn't a flavor of the month transpiler.

------
bricss
Maybe it could be better to just learn JavaScript?

~~~
d357r0y3r
TypeScript doesn't let you avoid learning JavaScript fundamentals. The same
basic rules still apply.

The difference is having a compiler and a type system that tells you when
you've broken things. Most people that have actually used TypeScript for any
length of time understand the type system to be invaluable.

~~~
bricss
FYI -> [https://medium.com/javascript-scene/the-shocking-secret-
abou...](https://medium.com/javascript-scene/the-shocking-secret-about-static-
types-514d39bf30a3#.sh9gk2gsf)

~~~
sotojuan
Using Eric Elliott articles as a source is never a good idea. The guy is way
too dogmatic and even crazy/harmful.

