
Goodbye CoffeeScript, Hello TypeScript - matm
http://blog.heapanalytics.com/goodbye-coffeescript-hello-typescript/
======
hit8run
Is it really that important nowadays to build webapps in pure js or
abstractions of it? We read articles about how many smartphones get superslow
when executing loads of JS code, how broken the development process is and how
framework x tries to solve that broken flow. We make use of super heavy and
complicated toolchains that are outdated half a year from now. I often hear
and read things like: "You still use bower instead of npm?", "You still use
coffee script?! Go with TypeScript.", "BackboneJS? Why not go with Angular?".
Some requirements make it mandatory to do lots of stuff in the frontend. For
example: SoundCloud is supposed to continue playing songs when users navigate
around. Okay they need a pure JS page refresh experience. But the standard
CRUD admin panel you write 90% of the time? There it's not wrong if a browser
does what it is supposed to do. Load a page when a user clicks on a link. Is
this such a bad thing to keep things simple?

~~~
Uehreka
Single Page Applications can enhance the user experience in many ways, even
with more "boring" apps:

* Forums/Comment Threads - If I want to reply to a comment in a thread (like I'm doing right now) I don't want the page to refresh after I submit, causing me to lose my scroll position. Even worse is when discussion sites ( _cough_ HN) whisk you away to a whole 'nother page to submit your comment, then dump you back to the thread afterward.

* Documentation - Let's say you have a long list of topics in a sidebar on the left. If I find a bunch of topics that I want to read and they're in the middle of the scroll, I'll be annoyed if the whole page refreshes when I click on one.

* Forms - If I'm filling out a long form (like enrolling in school or applying for a job) and I enter something wrong, I want to know immediately. I don't want to hit submit, land back on the same page, then find where the error is. Even when sites do this well (by saving the whole state of the form and clearly indicating where the bad field is) it's still annoying. Client-side validation also saves server resources (even though you need to do server-side validation too): every time the client catches a validation error, that's one less postback the server needs to process.

Following the emerging set of best practices (use a CDN, bundle/minify your
code with a tool like browserify/webpack, don't block the critical render
path) is enough to get your code to a point where it should run totally fine
on mobile. The horrible state of mobile web performance more often results
from:

* Fonts - for some reason these seem to take a longer time to load than other assets (or maybe their absence is just more noticable). Using a tool like TypeKit can help to get around issues like "Flash Of Invisible Text".

* Images - People not properly compressing images, using too many images, using PNG where SVG could possibly work are all contributing to slow page loads. Images are usually the largest things on the page (sometimes by an order of magnitude). They are also often demanded by "the business" in the same way that carousels are usually a result of a business compromise and not a deliberate design decision. Tools like grunticon and other gulp/grunt tasks can help mitigate these issues by ensuring that huge hi-res images have a compressed version and don't get sent to phones with tiny screens.

* Ads - Many ad networks either don't run a tight ship or don't police the companies who they allow to run code on their client's sites. The further someone is from actually owning the page where the code runs, the less they often feel compelled to make good optimization decisions.

My point is that a lot of this new-fangled front-end tooling
(browserify/webpack, TypeKit, SVG, grunt/gulp, the <picture> element, etc.)
are geared towards producing a better experience for the user. Many of them
either emerged to deal with mobile web issues or found new importance in light
of the problems developers (and businesses) face on the mobile web.

~~~
wtbob
> If I want to reply to a comment in a thread (like I'm doing right now) I
> don't want the page to refresh after I submit, causing me to lose my scroll
> position.

That's what middle-click to create a new tab is for.

> Even worse is when discussion sites (cough HN) whisk you away to a whole
> 'nother page to submit your comment, then dump you back to the thread
> afterward.

If HN were a single-page app, I wouldn't use HN. Period.

> Let's say you have a long list of topics in a sidebar on the left. If I find
> a bunch of topics that I want to read and they're in the middle of the
> scroll, I'll be annoyed if the whole page refreshes when I click on one.

Again, that's what middle-click is for.

> If I'm filling out a long form (like enrolling in school or applying for a
> job) and I enter something wrong, I want to know immediately.

Sure, that's a nice use for JavaScript. I just don't want to have to expose my
entire system, and all my data, and every system I can connect to, to malware
in return.

~~~
oldmanjay
I have to admit, I'm not really interested in your restrictions on what people
are allowed to use in browsers. You are definitely not the arbiter of the one
true way, no matter how right you feel about your opinions.

~~~
wtbob
Are you interested in security and privacy? Are you interested in
functionality?

I am, of course, the arbiter of what I permit my browser, running on my
computer and accessing my data, to do.

------
unoti

      > It’s reasonable to assume "foo bar and hello world" will compile to either:
      > foo(bar) && hello(world)
      > foo(bar && hello(world))
    

Feel free to sprinkle in additional operators to increase the clarity and
readability of your code. Coffeescript is extreme in what it allows. But even
C code can be made more clear by using more operators than the compiler
actually demands.

I'm not really trying to come to the defense of Coffeescript here, but I think
it's worth noting that adding more operators for clarity is a good thing. I
even go as far as adding additional variables for clarity, because the names
can show what you're thinking as you do the computations involved in a complex
expression.

Although Coffeescript is worse than most, any language will allow you to write
expressions that are hard for humans to parse.

~~~
krisdol
agreed, add a good linter and problem solved. Ruby has been this flexible
since its inception and you don't see people complaining about ambiguity
because they learn how the language works. When there's ambiguity, be
explicit.

~~~
seiji
_When there 's ambiguity, be explicit._

Many (too many) programers seem to take a viewpoint of "only type the minimum
numbers of characters necessary to get something to work." Then they make
their programming goal to be the least characters possible as long as the
compiler accepts their input.

 _complaining about ambiguity because they learn how the language works._

Some programmers also enjoy learning all the ambiguous edge cases then making
sure their code fits them exactly in the way they intend, but not necessarily
the way others will read the code.

That's why we end up with awful things like "if (abc) def; else hij;" or worse
"if (abc) { def; } else hij;", etc. Plus, if your language isn't line-
sensitive, using weak syntax but pretty alignment is just a recipe for future
failures a few steps removed from when you originally introduced the future
inconsistencies.

~~~
vlunkr
Ugh, I used to write coffeescript and I was that way for a while. I left off
parens, brackets, commas, etc. wherever possible. I thought it was great at
the time, but when I came back to the code after writing in other languages it
looked awful, and I wasn't always sure how to read it. Being a little more
verbose will save you a lot of time in the future.

------
jasode
_> Variable initialization and reassignment are the same It’s easy to
accidentally overwrite a variable from a higher scope as a codebase increases
in depth. _

Yep. There was a previous July 2013 article and related reddit thread about
it.[1] The CoffeeScript compiler devs themselves were bitten by their own
strange scoping rules!

As to the other question about why people don't just write raw Javascript,
Eric Lippert explained why plain Javascript is inadequate if you want to do
more than just "make the monkey dance"[3] -- a.k.a. "large complex apps".

[1][https://www.reddit.com/comments/1j1cw7](https://www.reddit.com/comments/1j1cw7)

[2][https://github.com/jashkenas/coffee-
script/commit/7f1088054c...](https://github.com/jashkenas/coffee-
script/commit/7f1088054c91f5ab3bf1ea1098b6ebffaa29a5a9)

[3][http://programmers.stackexchange.com/a/221658](http://programmers.stackexchange.com/a/221658)

------
barrkel
The advantages of CoffeeScript that TypeScript is lacking aren't mentioned. I
wouldn't casually give up lightweight indentation-based syntax and optional
parentheses, despite the confusion both can cause. CoffeeScript makes it easy
to create small DSLs that are fairly readable. Implicit hashes make for easy
keyword-based arguments, only requiring '->' to make a value lazy is a bit
better than () =>, and in particular not needing to end a big block of mixed
code and data in a random mix of ")}]});" is a surprisingly big win,
aesthetically.

~~~
Retozi
I have written a full production application in CS before switching to JS and
then eventually migrated to TS.

I was one of the "you save characters, you gain readability" proponents as
well (I love Python too).

However, it is a terribly flawed argument. Typing characters is incredibly
cheap.

Debugging and refactoring in a dynamic language. However, is very time-
consuming. You might be a tad slower writing Typescript (with autocompletion
and typechecking, I doubt it though). But over the whole lifecycle of a
codebase, Typescript is a lot faster for everything but very small projects.

I have done refactors in Typescript in hours that would have taken me days in
CS... multiple times.

Additionally the human brain can adjust to predictable noise very well
(brackets). After a training period, I find Javascript and Typescript almost
as readable as MY Coffeescript.

However, even when developing 8 hours for multiple months in Coffeescript, I
always had a hard time to grok other people's Coffeescript. There is just too
much freedom.

This does not happen that easy with Javascript/Typescript.

Generally, static typing in a complex user interface is a huge huge win
productivity wise. While you type more characters, you are still faster over
the lifecycle of a project. Hitting keys on your keyboard is literally the
least time-consuming part of programming.

~~~
stn
Static typing doesn't have to require typing substantially more characters
though (ML-family languages are good example, other examples I can think of is
Nim), the syntax choice is quite orthogonal to this but it seems like C-syntax
appears in new languages mostly due to its familiarity.

------
boothead
If you're an analytics shop (presumably) working with streams of events, I'm
going to go out on a limb and say that not picking a functional language
(purescript or elm) is a mistake. It's fits the domain so well, take a look at
the mileage that slamdata are getting out of purescript for example.

 _note_ I'm being deliberately provocative with the above statement to promote
discussion, not argument. :-)

~~~
oatmealsnap
I know zero developers who know purescript or elm. That is a hiring problem,
especially for young companies.

~~~
alanh
I know a few Elm developers. Using a less mainstream language can actually be
a boon to hiring. (Isn’t there a classic PG essay on how ViaWeb benefitted
enormously from using a Lisp when no competitors did?)

> _Had our first hire start today who applied because we use @elmlang in
> production. He rocked it!_

> _PS: still hiring :)_

[https://twitter.com/rtfeldman/status/656238188961226752](https://twitter.com/rtfeldman/status/656238188961226752)

Furthermore, I’ve learned _so many_ languages on the job in my career that I
am unsympathetic to companies who refuse to believe that people who have
learned programming can continue to learn programming!

~~~
smt88
PG isn't God, and he related a single anecdote. I won't believe that argument
unless I see current data that's language-specific.

For example, I could imagine easily being able to hire devs to work on Go, but
it'd probably be really hard to get them to work on Haskell.

~~~
alanh
> PG isn't God

Can you prove that? Absence of evidence isn’t evidence of absence, after all.
You’re being a bit militant in your pg-atheism.

Okay, in all seriousness, you are correct. Ability to hire coders to work in a
particular language is a legitimate concern to have. Still, it’s sad to see
lack of usage drive, well, lack of usage – sometimes it looks to me like an
unexamined assumption, or a self-fulfilling prophecy. To take it back to the
land of religious arguments: it’s a bit cargo-culty.

~~~
smt88
I agree with what you're saying, but "low popularity" is just one mark on one
side of the pros/cons list.

New languages can outweigh low popularity with lots of other important
qualities: syntax, tooling, appropriateness for a certain purpose, abundance
of libraries, etc. If the new language is easy to learn, that pretty much
defeats the issue of low popularity all together!

Unfortunately, a lot of new/amazing languages with great tooling are somewhat
hard to learn. Again, Haskell might be a great language, but it's daunting to
people who only have experience with C-like languages.

Go is one of the exceptions, and I think it did that intentionally. Instead of
having complex syntax, it just has lots of boilerplate. It's easier to read
and easier to learn at the expense of being harder to write and harder to
modify.

~~~
klibertp
> _New languages_ can outweigh low popularity with lots of other important
> qualities [...] _abundance of libraries_ , etc.

How?

> If the new language is easy to learn, that pretty much defeats the issue of
> low popularity all together!

If the language is easy to learn it's probably not worth learning. "Easy to
learn" in most contexts and for most people means "similar" or "familiar".

Of course, there are languages truly easy to learn thanks to their small
surface and internal consistency (like Erlang, PicoLisp, Forth...) but they
are very rarely regarded as such.

> Again, Haskell might be a great language, but it's daunting to people who
> only have experience with C-like languages.

My opinion is that it's their problem, not Haskell's. Instead of "being
daunted" they should go polyglot already and stop whining.

~~~
smt88
> > _New languages can outweigh low popularity with lots of other important
> qualities [...] abundance of libraries, etc._

> _How?_

By "new" I didn't necessarily brand new. I meant something like Rust, Go, or
Julia. They're more than 3 years old and relatively fully-baked, but they're
much younger than the mainstream languages.

I don't know much about Julia, but in the Rust and Go communities, the early
adopters are producing libraries for the not-so-early adopters. A good
question would be, "Why?" I think the answers are: 1) fun, 2) because they
want to get others to use the language, and 3) because their company has
adopted the language in production.

So it does (and has to) happen. In this whole thread, I'm not talking about
the decision-making process of an early adopter. I'm talking more about
someone replacing a mainstream language in a production or business
environment.

> _" Easy to learn" in most contexts and for most people means "similar" or
> "familiar"._

I meant "easy to learn" however you want to define that. Similar/familiar is
fine, as it's definitely contributing to the popularity of Rust and Go. It
really does hurt some excellent languages (e.g. OCaml) that they look so alien
to mainstream, working programmers.

> _My opinion is that it 's their problem, not Haskell's_

That's true. A language should have whatever syntax is most effective and not
make the same mistakes that past languages made.

However, that's not the same thing as readability. A language can be totally
different from C-family languages and still be readable. To mention OCaml
again, I find it ridiculously hard to read because there are tiny, similar-
looking characters that are significant all over the place. To my eye,
significant dots and tildes are very hard to pick out when I'm scanning down a
page.

So assuming Haskell is readable to a complete newbie, it isn't Haskell's
problem that the syntax is new. But it _is_ Haskell's problem if it can't
overcome the catch-22 that people don't use a language if other people don't
use it.

I'm glad we're talking about Haskell, because that community is very
enthusiastic and has made some incredible, accessible Haskell resources to
solve this problem. It may not be their problem, but they're still attacking
it, as every language has to. It seems to me that the Rust community knows
this and is going in the same direction with highly-accessible tutorials.

As for Go, the language is so small that it's "easy to learn" in terms of
syntax, but the patterns and paradigms you use in Go might take longer as a
result.

~~~
klibertp
> It really does hurt some excellent languages (e.g. OCaml) that they look so
> alien to mainstream, working programmers.

How will you explain a relative success of F#, then?

In my opinion "looking alien" is not important at all. To the mainstream real
qualities are much less important than marketing; that's true in many areas
and mainstream programming is not an exception. Given enough marketing, you
can turn "alien syntax" into a perceived advantage relatively easily.

> To mention OCaml again, I find it ridiculously hard to read because there
> are tiny, similar-looking characters that are significant all over the
> place.

Have you seen J? I'll just paste a bit of code in it:

    
    
       join =: 1 : 0
        ((([:{.[:>{.),:[:([:<(>"0))"1[:{:[:1 2 0&|:[:>([:,u"0)#]) (pr y))
       )
    

Is it readable? I'm told that yes, it is. There are people who can read this
mess just fine, no problems at all.

Readability is an artifact of familiarity and, in some cases, tooling. You can
get used to reading (and writing) even the most "unreadable" of syntaxes. Ask
a PERL programmer if she finds her language readable. Will she say "no"?

My point is: until readability is formally defined and we're able to measure
it objectively it's utterly useless to talk about it.

> But it is Haskell's problem if it can't overcome the catch-22 that people
> don't use a language if other people don't use it.

Yes, but this problem _cannot_ be solved with technical qualities alone. Was
it possible we wouldn't use C, Java or JavaScript at all.

It's marketing and "killer use-cases" that matter. You want to use the same
language your OS is written in, for example. Was Windows written in OCaml
you'd use OCaml to write Windows programs. If there's a program you really
like, which is scriptable in Lua, you will use Lua.

~~~
smt88
> _My point is: until readability is formally defined and we 're able to
> measure it objectively it's utterly useless to talk about it._

It's more defined than we, as programmers, pretend it is. There's research in
cognitive psychology, linguistics, and lexicology that tells us that some
things are easier for human brains to process than others.

For example, if you skim through a block of code, it's easier to pick out "&&"
than it is to pick out "and". There are lots of rules like this.

This is partially because of the way humans read words. If yuo spel a bunhc of
words wrng in a sentence in minor ways that don't alter the shapes too much,
it's still very readable.

That's why your example of J is very hard to read (objectively, not
relatively). If someone removed or altered a few of those symbols, no one
would notice upon skimming it. It's ludicrous to argue that it's readable just
because some people say it is (and I think they're just bragging to begin
with).

~~~
klibertp
> There's research in cognitive psychology, linguistics, and lexicology that
> tells us that some things are easier for human brains to process than
> others.

I'm not convinced that such research controls for familiarity effects. Not to
mention, programming languages have much richer syntaxes than natural
languages. I think (suspect), in regard to PLs, what you're talking about (you
mention "skimming" later) is actually legibility - ease of recognizing letters
and words. Not readability, that is ease of understanding the meaning of
what's written.

> For example, if you skim through a block of code, it's easier to pick out
> "&&" than it is to pick out "and".

Why? What if the rest of the line is similarly composed of punctuation? Are
you sure in a line looking like this:

    
    
       >&.@:/"1\and[:    NB. some nonsensical J phrase
    

you'd have an easier time spotting the "and" were it written as "&&":

    
    
       >&.@:/"1\&&[:
    
    

> If someone removed or altered a few of those symbols, no one would notice
> upon skimming it.

Possibly, but we're not talking about "skimmability", but readability.
Removing or altering a few characters in that line would result in an
incorrect, nonsensical sentence and you'd notice it right away.

"Right away" is subjective, of course. I spent nearly an hour trying to read
this damned thing when I attempted it for the first time. Every J phrase was a
challenge then. It's still hard, but it got _much_ easier with practice. The
trick here is exactly the same as in your example:

> yuo spel a bunhc of words wrng

that is, once you learn how the words look like you can recognize them easily,
even if they are a bit mangled.

> (and I think they're just bragging to begin with)

Yeah, I get the same feeling sometimes ;-)

But a human brain is great at pattern recognition. It has to be trained, and
it's possible that some shapes are harder to learn to recognize than others,
but once you learned them... is there really a difference?

Learning different PLs is my hobby, I've looked at ~80 languages to date and
learned quite a chunk of them. Every single time I noticed this effect: once
you internalize shapes of common phrases, you stop having trouble reading the
code. It's much, much harder in some case (J is an abomination here - I'm
trying to really learn it for the second year now and... it's not going that
well) and easier in others (Smalltalk, Lisp, Forth, ...). But I strongly
suspect every language, if studied and used enough, becomes readable.

------
naitsirc
Not trying to sell CoffeeScript here but most reasons of the author for
dropping it looks more like a fault of the developer instead of the tool.

* Ambiguous syntax? Just add a few parenthesis.

* You don't like the existencial operator? Learn some JS, being able to easily differentiate between a truthy value and the existence of a variable with a single character is as sweet as it can get.

* Comparing a language to Babel? Doesn't make sense. Babel translate ES6/2015 to ES5 for compatibility. Comparing ES6/2015 to CoffeeScript makes sense.

* CoffeeScript is the reason you couldn't scale/solve data syncing or redrawable views? JS/CS/TypeScript/etc have nothing to do with that! Maybe he was thinking about Backbone?

Seems like the guy is confusing tools and languages... and making (bad)
decisions because of that.

Personally I'm not going back to writing { }, return and ;'s :-)

~~~
avmich
Language should be natural enough for the person to use and good enough to
apply for the problem at hand. We don't yet know how to have consistently good
solutions for these requirements.

For me, {} are better than spaces - perhaps because of habits, but what will I
get in - non-effortless - changing my habit in this place? "Add a few
parenthesis" advice seems the opposite - don't we want not to have to use
artifacts for clarification, but have simple and natural defaults working?
Etc.

~~~
redka
It's not a choice of this versus that. In CoffeeScript you don't write spaces
instead {} - you write neither. You express this with indentation anyway so
why the extra boilerplate? CoffeeScript removes a lot of the excess work while
TypeScript actually does the opposite.

------
OmarIsmail
Once you go typed JS you don't go back.

We had a large existing pure JS codebase, so Facebook's Flow was a better fit
for us. We still have some portions of our code that don't have type
annotations, and invariably that's where the majority of new bugs are
introduced. Now we have a policy of making sure all the files we touch are
typed, and adding types to a file if it doesn't already have it.

Types + React is a whole new ballgame when it comes to front end dev.

~~~
jaked89
Every JS code is a valid TS, since TS is a superset of JS.

You can benefit immoderately from compiling your existing codebase in TS;
you'll probably discover some bugs, even before adding any annotations.

~~~
DCoder
> _Every JS code is a valid TS, since TS is a superset of JS._

There are still cases where you'll need to sprinkle <any>. For example:

    
    
        var state = { foo: 1 };
        if(something) {
          state.bar = 2;
        }
    

is valid JS, but the TS compiler will complain that `state` does not have a
member named `bar`.

~~~
addicted
The TS compiler will complain but still generate working JS code, so you don't
lose anything.

~~~
DCoder
But the compiler's output will be polluted with these false positives, making
it harder to see actual errors. (Also, there's a compiler flag to prevent
codegen on error, which comes in handy sometimes.)

------
cfontes
I've been playing around with typescript and together with IntelliJ it's just
great... Fast transpiling, easy to config, easy to debug, typed, the list goes
on...

The only thing that toke me a while to understand at the start was the whole
"Definetly Typed" repo, why and how to use it. It is a bit strange to have to
add types as you develop but you can live with it after it sits in.

There is also Angular 2 which mergers very well with it, friendly advice, try
it!

~~~
tigeba
My experience with Typescript is that I have spent the majority of what I
would call 'wasted' time either messing with type definitions, or fumbling
with getting modules to play nicely with code that needs to be used in the
browser and in Node. My impression of the language is fairly positive, however
I'm not currently using it for backend development because the burden of the
type definition files is too great. Having to write a type definition file
yourself for a library where none exists has been fairly painful in my
experience.

~~~
WorldMaker
If you don't have time to write a type definition file, there's always the
fallback to any type. (I tend to start with any-typed things, see any as a
TODO marker, and then fill in definitions as I have time, interest, or need.)

declare var SomeGlobal: any

declare module 'some-node-module' { declare var m: any; export = m }

Also, hopefully more npm package maintainers will start to add typings
directly now that TypeScript searches node_modules.

------
jamra
I've been looking into TypeScript recently, but after having clicked on this
article, I'm thinking that I'll stick with ES6.

Being able to have code completion in javascript is nice, but it's also
something that you can work around by developing a good work regiment using
browser-based debugging tools. The benefit of typescript is substantial, but
circumventable. The drawback, one that I haven't seen anyone mention yet, is
now having to deal with generics inside javascript. Trying to reason about
this code and spending most of my cognitive focus on how the author is dealing
with generics adds an entirely different complexity to reading and
understanding javascript.

On one hand, it's helpful to have types. On the other, adding a very
Microsofty overhead to programming using meta-data on your data and generics
inside javascript makes me want to pass on this.

~~~
smt88
Reasoning about generics in TypeScript isn't bad. I'm not totally sure what
you meant by that. I just rewrote an API in TypeScript for Node, and I didn't
spend most of my time reasoning about meta-anything. TypeScript mostly added
amazing, insightful static analysis, and when I ran my code, it almost always
worked perfectly at runtime. The debugger in VSCode is great, too!

~~~
spion
I think its a common meme that started because of the complexity of C++
templates and continues to be perpetuated by the creators (and moreso, users)
of Go as an excuse to not implement generics.

Unlike C++ templates, generics in TypeScript are really simple - I'd estimate
it would only take a week to get used to them.

~~~
jamra
I have some experience with C++'s templates, but I'm more comfortable with
Generics in C# which I believe are done correctly. I view the code I saw as
closer to C#'s approach to generics so I'm not sure your assumption is correct
in my case.

I just don't want the extra mental overhead of writing and reading generic
parameters whereas I never had to do that with javascript. I really enjoyed
the concept of having types for my javascript objects, but am getting
frightened at the concept of decreased readability due to generics.

~~~
mreiland
C# generics are not the same creature as C++ templates. It isn't a matter of
done correctly or incorrectly, it's apples and oranges.

~~~
jamra
Yes I know. I've done both. Typescript's syntax appears more like C#'s
generics.

My issue is that I would like types for when I get data from the server, but I
don't really want to deal with casting window to "any".

I personally went through the pains of learning javascript and have come out
on the other side comfortable with its dynamic types. I really like the idea
of compile time error checking, but I'm not sure I would stand for adding the
complexity of generics.

The change in my workflow is not very difficult. For example, when I'm using
plain old javascript, I use documentation to find out how to use third party
libraries and DOM manipulations. Though it works out for all of my needs, I
wouldn't mind adding types. Adding types on top of that would reduce casting
and spelling mistakes, but it's not like I can't open up the browser and test
my code with a step through debugger. I would personally prefer opening the
browser and maintaining readability in my code versus having type safety in my
code and giving up readability.

~~~
spion
I almost forgot: generic type variables are used very little outside of
generic libraries. We have a 20KLOC codebase which doesn't use type variables
at all and has only a single in-house written dependency [1] that declares
functions with type variables.

note: This is about declaring generics, not using them. You'll still have to
write Array<string> and Promise<MyType>, thats true. But its hardly any
different from ArrayOfString or PromiseOfMyType in terms of readability.

If I may be so bold, I'd really encourage you to give it a spin. You just
might find that your fears about readability are exaggerated.

[1]: [https://github.com/doxout/promise-
observer](https://github.com/doxout/promise-observer)

~~~
jamra
I didn't catch this at the time, but I will take a look. Thanks.

------
zyxley
After Coffeescript, it's really hard to go back to excess brackets everywhere.
I really wish there was a Coffeetypescript.

~~~
acjohnson55
I used to feel the same way, but now I greatly prefer languages with brackets.
Refactoring and auto-formatting in indentation-sensitive languages can be a
real pain. Semicolons, though, I have no use for. Pity that omitting them in
JS potentially leaves you open to some nasty issues.

~~~
WorldMaker
I've been using semicolon-free Typescript a lot lately (and really liking it
that way) and its transpiler is ASI (automatic semicolon insertion) aware so
it ends up adding the semicolons back into its JS output, which you can use as
a safety net if you are worried that you don't quite have a handle on ASI.

That said, JS ASI is not much different than Python/Coffeescript newline rules
and if you are comfortable programming semicolon free in those languages there
shouldn't be a reason that you should feel uncomfortable going semicolon free
in Typescript and/or JS. The nasty issues are in fact mostly the same as
Python/Coffescript.

------
elwell
This is being portrayed as clear code / a helpful pattern??

    
    
      class GraphQuery extends Query {
        static parse(object: any): Try<GraphQuery> {
          return TimeRange.parse(object.over).flatMap((timeRange: TimeRange) => {
            return Filter.parse(object.where).flatMap((filter: Option<Filter>) => {
              return GroupBy.parse(object.by).flatMap((groupBy: Option<GroupBy>) => {
                return new Success(new GraphQuery(
                  filter,
                  groupBy,
                  timeRange
                ));
              });
            });
          });
        }
      }

------
chimeracoder
The biggest advantage of TypeScript is that the output is unminified
Javascript that closely resembles the input. In fact, you could show someone
the output and convince them that you wrote the Javascript manually (rather
than generating it from the TypeScript).

This makes it really easy to interop with existing Javascript code, but it
also makes it really easy for non-Typescript developers to pick up.

For me, learning Typescript was pretty quick, because valid Javascript is
already valid Typescript. All I had to do was remember the syntax for
(optional) type annotations.

Learning ES6 was actually the bigger hurdle, not Typescript.

------
RomanPushkin

    			  ));
    			}); // I
    		  }); // love
    		}); // TypeScript
    	  }
    	}
    

Actual code from the article above. Just added comments.

~~~
RussianCow
Trailing parents/braces seems like a bad reason to dislike a language. Ever
heard of Lisp? :)

~~~
lazugod
Presumably that's why some people dislike Lisp too.

~~~
soapdog
Is that a valid reason? I know that personal taste plays a strong and
important role but typescript is really cool.

~~~
giancarlostoro
I didn't like Lisp for a long time because of it, I've since given up and
tried Lisp. My friends don't care for Lisp probably because of that as well.

~~~
mdpopescu
I could get over the parentheses but CAR and CDR instead of HEAD / TAIL or
FIRST / REST annoy the crap out of me.

~~~
lgas
I have no idea about the veracity of the claim but this page[0] contends that
Lisp has had first/rest since 1959.

[0]
[https://en.wikipedia.org/wiki/CAR_and_CDR](https://en.wikipedia.org/wiki/CAR_and_CDR)

~~~
empthought
It cited the claim with a source, so presumably you could check the veracity
that way.

------
mreiland
I'll never understand why people don't just use javascript.

~~~
matm
Because it's really hard to build, test and maintain a non-trivial application
in a dynamically-typed language like JavaScript.

I think it's telling that a lot of companies with the most mature products
(Facebook, Dropbox, Asana) eventually resort to optional static typing in
their products, whether that means extending their runtimes (e.g. Hack) or
using a transpiler like TypeScript.

~~~
zurn
The implicit conversions and "we'll just randomly give you undefined to
propagate ondwards" stuff is a much bigger source of bugs in JS than dynamic
typing. Picky dynamically typed languages like Erlang or Python will pretty
reliably produce an error/exception at the scene of the crime. (More so than
C/C++!)

(Also I don't think optional static typing has gotten off the ground in Python
land, or adopted in production at Dropbox?)

~~~
z1mm32m4n
Dropbox Paper is written almost entirely in TypeScript.

------
_pdp_
I typically don't get into these types of conversations but here we go.
CoffeeScript is a lovely language by all means and at my company we use it
extensively because it reduces the amount of boiler plate code by a factor of
10 maybe even 20.

Here is a simple example:

    
    
      some_func = (callback) -> callback new Error 'boom'
      
      some_func (err) ->
        return console.log err if err
        console.log 'everything is fine'
        

The alternative JavaScript version is just too much to read.

This makes huge difference when you write async code and no amount of
TypeScript can really help it.

~~~
mrspeaker
Have you tried diving into ES6 yet? It's much more terse now that they stole
the good bits from coffeescript...

    
    
        let some_func = callback => callback(new Error('boom'));
    
        let some_func = err => console.log(err || 'everything is fine');

~~~
warfangle
I promise I started writing my comment before I saw yours ;)

------
octref
Did you also consider Flow[0] as an alternative? I'm now using ES6 with Babel
to build some small side-projects and it has been a great experience. But as
the codebase grows, I'd appreciate to add some Flow type annotations.
Typescript looks great but it's still not JS. I wonder what will happen to all
those compile-to-JS languages once ES6 becomes supported everywhere.

[0]: [http://flowtype.org/](http://flowtype.org/)

~~~
chimeracoder
> I'd appreciate to add some Flow type annotations. Typescript looks great but
> it's still not JS.

The Flow type annotations are almost identical to Typescript. There's one edge
case around one of them requiring a space before/after the colon and the other
not, but I can't remember what it is. I just tried running one of the Flow
examples through the Typescript playground and it worked fine[0].

The biggest differences between Flow and Typescript are how you run the build
system (`tsc` versus the Flow server) and the file extension you put on the
file.

[0]
[http://www.typescriptlang.org/Playground#src=%0A%2F%2F%20htt...](http://www.typescriptlang.org/Playground#src=%0A%2F%2F%20https%3A%2F%2Fsmellegantcode.wordpress.com%2F2015%2F04%2F02%2Ftypescript-1-5-get-
the-decorators-
in%2F%0Afunction%20foo\(x%3A%20string%2C%20y%3A%20number\)%3A%20string%20%7B%0A%20%20return%20x.length%20*%20y%3B%0A%7D%0Afoo\('Hello'%2C%2042\)%3B)

~~~
samwgoldman
While the type annotation syntax between Flow and Typescript are mostly
identical (this is intentional), there are a bunch of differences between
them:

* TypeScript allows unsound casting, Flow doesn't. These casts are very practical, as you might know more than the analyzer. Flow takes a stricter position here, which is a theme.

* Function are bivariant w.r.t. their parameters (which is unsound) in TypeScript, but contravariant in Flow. Again, this is an intentional, practical choice, but Flow emphasizes soundness.

* TypeScript asks users to add annotations in scenarios where Flow will infer types. TypeScript will infer any (there is a "no implicit any" option).

* Classes in Flow are nominal (interfaces are structural). Classes are structural in TypeScript.

* Flow adds no additional runtime syntax to JavaScript; TypeScript does (enums, for example). Flow does support some ES2016 features (async/await, object spread), but generally holds off on experimental features (stage < 2).

* Flow has a couple interesting features absent in TypeScript, like disjoint unions. I suspect/hope both systems will converge on useful features like this.

* TypeScript treats null as a bottom type, but Flow uses explicit "maybe types."

~~~
jiaweihli
TypeScript supports disjoint unions:
[http://blogs.msdn.com/b/typescript/archive/2015/09/16/announ...](http://blogs.msdn.com/b/typescript/archive/2015/09/16/announcing-
typescript-1-6.aspx)

The two real pain points (among those you mentioned) of TypeScript are
bivariant function parameters and structural classes, since they lead to
potentially unsound code that compiles.

~~~
samwgoldman
The link you provided doesn't seem to show disjoint union support. I'm talking
about this: [http://flowtype.org/blog/2015/07/03/Disjoint-
Unions.html](http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html)

------
vectorpush
I _do_ wish CoffeeScript had stronger type support, however, I don't want to
give up indentation, optional object brackets, optional function parens and
easy loops.

There are a ton of other CoffeeScript features I love like the string
interpolation syntax, comprehensions, implicit return, @ for this, improved
switch syntax, ranges and a ton of other stuff, but I'm going to hang on to
those first four for as long as its practical to do so.

------
kailuowang
From the cons the author listed for typescript, this article is way too
generous with this language. Like CoffeeScript it is just an intermediate
solution to the problems JS has. We are still far away from inventing a good
language for UI logic development. IMO Elm is pointing in the right direction,
Scala.JS is getting some interesting traction and momentum.

~~~
jiaweihli
Personally I'm not a huge fan of mixing language with UI architecture - it
seems like it would slow down development on both fronts. Replacement costs
are also much higher.

That aside, we'll talk about how we built our architecture in our next blog
post! I promise you that I thoroughly pored over the Elm architecture
tutorial[1] before designing any building blocks.

[1] [https://github.com/evancz/elm-architecture-
tutorial/](https://github.com/evancz/elm-architecture-tutorial/)

------
nerdwaller
Kind of feels like they're trying to jump from one popular thing to the next.
The JavaScript world is exhausting.

------
feyn
You can have my CoffeeScript when you pry it from my cold, dead hands.

------
ziahamza
I wonder by Babel was ruled out, in conjunction with Flow. DefinatelyTyped was
a game changer for us, as it already has a large repository for popular
libraries.

But except that, typescript has some catch up to do in terms of typesystem
with Flow.

------
williamcotton
There's no need to choose between TypeScript or Babel!

You can use TypeScript with --target es6 and then use babel as a secondary
transpiler.

~~~
dangoor
Isn't the problem that the TypeScript compiler doesn't support all of the ES6
features that Babel does?

------
hharnisch
Migrating away from CoffeeScript too. I'll be happy to have the ternary
operator back. The existential operator was handy but became a source of land
mines as the project grew. Will miss list comprehensions though.

~~~
tiglionabbit
Seriously? 'You' ? 'like' : 'this'; if 'better' then 'than' else 'this?'

~~~
hharnisch
Ternary operator is more compact and consistent with many other programming
languages.

The bigger issue was the bugs the existential operator led to. Not worth it
when checking for existence wasn't a problem in javascript anyways.

~~~
tiglionabbit
What sort of issues were you having with the existential operator? I've
honestly never had a problem with that, and I often wish I had it in other
programming languages.

------
dreamdu5t
Why not Haskell? If you're going to be transpiling to JS might as well get all
the power of purity and robust typing.

~~~
jonahx
Which haskell to js project do you recommend? The wiki lists a number of them,
but it's to tell which is the best choice.

~~~
dreamdu5t
GHCJS. That said, there's not necessarily a best choice because it depends on
what type of application you're transpiling.

There's an Om-like UI project with bindings to virtual-dom
[https://github.com/boothead/oHm](https://github.com/boothead/oHm) as well as
various react bindings such as [https://github.com/joelburget/react-
haskell](https://github.com/joelburget/react-haskell)

------
hackerboos
Typescript looks great until you realize you need special files that match
types in third-part libraries:

[http://www.typescriptlang.org/Handbook#writing-dts-
files](http://www.typescriptlang.org/Handbook#writing-dts-files)

Will your third-party-lib that doesn't use Typescript keep a dts file? Who
knows...

~~~
radicalbyte
..and for that work, you get a whole class of errors removed from your code..

Luckily most of the big libraries are covered; it's mainly smaller stuff -
think random jQuery plugins - that aren't covered.

These are libraries which are often hacked together, lack tests, clear
documentation and anything approaching support. So things that you shouldn't
really rely on.

------
kyrre
How about using JavaScript with flow?

~~~
jiaweihli
We considered Flow initially as well - but aside from its built-in maybe types
(we use Monapt for this!), it's a subset of TypeScript feature-wise that
doesn't iterate as quickly.

~~~
WorldMaker
Side question: when evaluating/updating Monapt did you take a look at any of
the "Fantasy Land" compliant implementations?
([https://github.com/fantasyland/fantasy-
land](https://github.com/fantasyland/fantasy-land))

~~~
jiaweihli
Ah! I think I saw this awhile back. I didn't refer to it too much when working
on Monapt since it seems to serve a more abstract purpose, and since Monapt's
original purpose was to emulate Scala syntax.

------
seivan
Have they fixed the issue where it was really hard to work with third party
libraries unless they have type definitions?

One problem I saw that it was heard to try out release candidates for React
when they were lacking type definitions.

Apart from that I really like TypeScript.

~~~
pyrophane
Not that I can tell, and it is the one thing keeping me from embracing
TypeScript.

To get the full benefit from TS you really need to have type definitions for
all 3rd-party libraries you use. Libs that aren't written in TS generally
don't provide them, and many of the community definitions maintained by
DefinitelyTyped are badly out of date or incomplete, which in my mind is worse
than having no definition at all.

Without defs you can get the compiler to stop complaining by turning off
implicit any errors and creating definitions for just a few things like node's
require and exports, but this felt like too much of a hack for me to really
feel good about it.

If anyone has found solid solution to this problem please let me know. I love
TypeScript but don't want to spend too much time futzing with definitions.

------
abritinthebay
After using ES2015 patterns for a while now CoffeeScript looks utterly
barbaric in comparison. That said it's really for Ruby programmers (or those
who know/want to know Ruby) who write JavaScript so I guess it will continue
to fill that void.

It adds no utility outside of that niche anymore however.

TypeScript is great but I honestly prefer ES2015/ES6 + Flow comments. It means
I write native JavaScript (ok, for now a transpile step, but _that will go
away in time_ and I'll still have valid JS code) but get all the benefits of
typing like in TypeScript.

However TypeScript is still pretty awesome, though I find the syntax rather
verbose.

~~~
shady_trails
You have an interesting opinion. Coffeescript has, for several years now,
encompassed nearly the entire API surface of ES2015.

    
    
      * Comprehensions (more flexible with Coffeescript).  Wait, that's ES7 now.
      * Template strings
      * For .. Of loops
      * Destructing
      * Classes. ES2015 has an awful implementation of this, without allowing an syntax for binding methods.  Also enforces the somewhat arbitrary requirement of function properties only, as opposed to any type I choose.  Don't forget, mixins with Coffeescript classes is a breeze, but no support with ES2015.
      * Arrow functions.  Unnecessary syntax with ES2015 (the parens even without arguments), not to mention confusing implicit return.
      * Generators with ES2105.  If you find a use for these in front end web dev I'll buy you a beer.
    

ES2015 does succeed in introducing an entire set of confusing ideas: we rolled
for years with var's, but now I get my hand held with const and let, because
figuring out how var works (or just relying on Coffeescript to handle it for
you) is too challenging.

The point here is that it is frustrating to see people jump on the ES2015
bandwagon when Coffeescript has had the same feature set for years. It
suffered adoption because of developers who didn't want to learn `another`
language. I have met a tremendous quantity of developers - myself included -
who initially rebelled against the use of Coffeescript, only to eventually
fall in love with it.

~~~
abritinthebay
> Coffeescript has, for several years now, encompassed nearly the entire API
> surface of ES2015.

Agreed. I didn't say features; I said _looked_. It looks horrible in
comparison.

ES6/7 code is much cleaner, clearer, and more idiomatic, than CoffeeScript.
(in my experience, and I've used/debugged/worked with a LOT of both)

Not going to crap all over the _features_ of CoffeeScript, those were good
(though they produced pretty awful looking JS code as a result). I would say
however it wasn't worth the trade off in debugging pain.

~~~
tallerholler
> ES6/7 code is much cleaner, clearer, and more idiomatic

I'm assuming you're talking about the compiled javascript from coffeescript
and not coffeescript itself? I find coffeescript code much, much nicer to
read, write, and deciper.. but that's just me!

~~~
abritinthebay
Well I could refer to both, but no I wasn't specifically (though it does
apply).

I'm curious: were you a Ruby dev before using CoffeeScript, or at least had a
reasonable amount of experience with it?

That said I find Ruby to be dense and annoying to read sometimes (due to its
sometimes Perl Golf obsession with brevity in language constructs), so it
could be just Ruby idioms annoy me ;)

~~~
tallerholler
I haven't used ruby but ive been writing python for many years and so the
indentation-based syntax definitely something I enjoy. But that said I didn't
even use coffeescript until I was forced to while working at a huge media
company where the big project I worked on had the large client written in
coffeescript... once I got used to working with it I think I enjoyed the clean
code and productivity gains..

I guess your milage may vary though depending on what you're doing etc.

------
geoffwoo
interesting. we use coffeescript at nootrobox.com, but as you noted, it
doesn't have a lot of hand rails. many a time, i've run javascript through a
js2coffee translator to verify. will look into typescript.

------
ilaksh
Embrace, extend, extinguish. TypeScript doesn't implement ES6 fully.

------
ausjke
[http://www.walkercoderanger.com/blog/2014/02/typescript-
isnt...](http://www.walkercoderanger.com/blog/2014/02/typescript-isnt-the-
answer/) so this blog is arguing typescript is not that good either.

Can we have a typescript-alike tool that integrates the "best parts of
javascript" and defaults to 'use strict'? if there is one I'm in.

~~~
aeosynth
Babel + Flow?

------
vorg
> Existential operator accessor (?.) is a leaky abstraction for null

I found this out the hard way when using it in groovy a while back. The
Options abstraction you describe is better, or the one in Java 8, which Groovy
_still_ hasn't brought into its syntax. Groovy's creator James Strachan talked
a lot about how he designed Groovy to avoid the "leaky abstractions" in Java.

~~~
jiaweihli
There is also this gem of a quote by him[1]:

> I can honestly say if someone had shown me the Programming in Scala book by
> by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have
> never created Groovy.

[1] [http://macstrac.blogspot.com/2009/04/scala-as-long-term-
repl...](http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-
for.html)

------
bachmeier
Is Typescript a good language for someone that has done very little in
Javascript? Are resources available for newbies? I've programmed in dozens of
languages over the last 30 years, so I'm not a beginning programmer, but have
simply never messed with Javascript.

How does Typescript compare with Dart? Is Javascript the place to start?

~~~
recursive
I don't think you can expect to use typescript without really understanding
javascript. Not to say you shouldn't learn typescript first. But by the time
you're fluent in typescript, you basically know javascript also.

------
jpochtar
If you want to migrate a coffeescript codebase to typescript, try out
[https://github.com/palantir/coffeescript-to-
typescript](https://github.com/palantir/coffeescript-to-typescript) which
should do it for you automatically

------
arcosdev
I am trying desperately to understand why TS. How does lumping in the baggage
of Java/C# onto a functional language like JS make it better?

 _We have to wait for the previous generation to retire or die before we can
get critical mass on the next idea._ \- Douglas Crockford

------
tkubacki
I heard Wikia gave up on TS - wondering why people are leaving TS ? Too much
friction ?

------
hack_mmmm
Where is the developer community going 2 years from now? I think we can derive
some sort of Moore's law for new languages/frameworks for JS/Web/Mobile.
Objective C and now Swift. Coffee script and now Type script. JS frameworks
and more frameworks. What can be the tighter bound Moore's law alternative for
new frameworks and languages for Web / Mobile/ IOT. It almost always doubles
every two years for sure.

------
LordHumungous
Anyone know if TypeScript will ever be included in ECMAScript standard? If it
is I will love Microsoft forever.

~~~
tracker1
It's not _that_ far off of ActionScript3, or ES4's proposals for strong
typing... I think things are probably headed that way, I would love for the AS
guys to integrate as a Babel plugin for typing (similar to flow), so that it's
just one tool to rule them all... FB already deferred to Babel for JSX
processing.

------
nv-vn
>Non-mainstream syntax seems like this author already knew what they were
looking for from the beginning.

