
Why We Chose Typescript - darwhy
https://redditblog.com/2017/06/30/why-we-chose-typescript/
======
TheAceOfHearts
If you want runtime assertions with flow you can use flow-runtime [0].

Babylon merged TypeScript support yesterday [1]. This means that in the future
it should be easier to setup Babel with TypeScript.

I agree with the decision to go with TypeScript. It has drastically better
community support. Most third-party components won't have flow annotations.
Flow would've been a lot more successful from the start if it had started out
with DefinitelyTyped support. Heck, even now I'm still wondering why they
don't do that.

[0] [https://codemix.github.io/flow-
runtime/#/](https://codemix.github.io/flow-runtime/#/)

[1]
[https://github.com/babel/babylon/pull/523#issuecomment-31172...](https://github.com/babel/babylon/pull/523#issuecomment-311720960)

~~~
octref
Sorry but what is the use case for Babel + TS? I thought you use either Babel
or TS but not both together.

~~~
mercer
One case I ran into: using css-loader/style-loader for my css. TS doesn't
understand importing css files, so that's where Babel comes in.

In the end i decided to stick to 'old-fashioned' SCSS with an npm script; the
downsides of adding Babel to my stack weren't worth the upsides of css
modules. Difficult decision to make though.

I guess what I'm saying is that while there is a use case, so far it's been
worth it to just stick to TS without Babel, much as I wish it'd be different.

~~~
ksjogo
You could use the webpack (which you might be using already) css loader and
declare the css file as any.

------
tqkxzugoaupvwqr
> Using a typed language in our frontend has already paid dividends: our code
> has fewer type-related bugs, we are more confident making large refactors,
> and our inline documentation is focused around concepts instead of object
> shapes and function parameters.

Sounds like they learned from their mistake of using Python on the server-
side. Dynamically typed languages for large code bases are terrible.

~~~
TekMol

        Dynamically typed languages for
        large code bases are terrible
    

The success of Wikipedia, Wordpress, Facebook, Youtube, GitHub etc etc etc and
last but not least Reddit seem to prove otherwise.

~~~
minitech
> seem to prove otherwise

Prove how? They could have succeeded in spite of dynamic typing, not because
of it. Facebook defined a new programming language to add static typing to
HHVM. The process of plugging into WordPress is infamous in its
disorganization.

There’s a lack of good statically-typed languages, so it’s natural for many
popular things to be built in dynamically-typed ones, but that doesn’t make
the dynamic typing approach better.

~~~
TekMol

        Prove how?
    

By means of natural selection.

    
    
        They could have succeeded in spite of
        dynamic typing, not because of it.
    

You think the otherwise smart and successfull founders of these projects all
made the wrong choice when it came to selecting the right tool for the job?

    
    
        Facebook defined a new programming language
    

No, they wrote a faster runtime.

    
    
        to add static typing to HHVM
    

No, they added type annotations.

    
    
        There’s a lack of good statically-typed languages
    

No, in the past statically typed languages were the norm. C, C++, Java...

It's just that dynamic languages outcompeted them.

~~~
dom0
> It's just that dynamic languages outcompeted them.

All "trending" languages are statically typed (Rust, Go, Swift, Kotlin, ...)
and all the popular JavaScrip-improved-languages are statically typed as well.
Even further, many dynamically typed languages have pushed in recent years to
add type annotations or even static typing (e.g. mypy).

Dynamic typing is the brainchild of the 90s for rapid _initial_ development.
Sustainability has been a big issue from the outset.

~~~
kazinator
Dynamic typing is from 1958 Lisp. Your history is off a bit there, by some
forty years.

~~~
vorg
The 90's also saw much commercial experimentation with visual environments
(e.g. Visual Basic, Delphi, JBuilder) with round-trip conversion between the
layout form and underlying code. They were promoted for R.A.D. (rapid
_application_ development -- remember that acronym?) but, like dynamically
typed languages, they also had sustainability issues.

Of course, like dynamic typing and Lisp, visual environments also had
Smalltalk from way back, but they were before big business became infatuated
with the ideas.

~~~
TimJYoung
How do products like Delphi have sustainability (maintainability ?) issues ?
Delphi/Object Pascal is statically-typed, so you can't even build an
application that has issues with the code-behind for a form.

You _can_ see errors at run-time from mismatches between the code-behind and
the forms, but this has nothing to do with the language. It's just the way
that certain products like Delphi decided to handle such mismatches. You'll
see these types of issues with _any_ code that performs run-time
serialization/deserialization of class instances. Our product, Elevate Web
Builder, uses a similar architecture with its WYSIWYG form designer/forms
(they use JSON instead of a custom key-value format), but it simply _ignores_
properties in forms that don't exist in the actual code.

------
martin_drapeau
Is Typescript necessary for front-end Javascript?

In the many years I've done front-end with Javascript, type-related bugs were
very, very rare. Textbook logic as why to use strong types make absolute
sense. Yet in the real world, I've had to fight with logic, DOM, UX, framework
incomprehension and other types of bugs - not types. Type issues were
anomalies among bugs. When they came up, they were the easiest to fix.

Am I alone here? Anyone in the community have concrete examples of type-
related bugs that took so much time to required using something like
Typescript? Can anyone quantify that?

~~~
epidemian
> In the many years I've done front-end with Javascript, type-related bugs
> were very, very rare.

Wow, really? My experience has been the complete opposite.

Most of the bugs that slip into production have been dumb type errors. Things
like accessing a property on an null/undefined value, or on an object that
doesn't have that property and unfortunately JS just returns `undefined`
instead of complaining (these silent ones can live longer before being
spotted).

It's because of these kind of bugs that i've found many JS codebases tend to
become brittle to the slightest change, and very difficult to refactor into a
good shape. And why i'm seeking statically typed languages like TypeScript on
that front at the moment.

~~~
jmull
But that's really a symptom of a "big ball of mud" design (non-design,
really), where everything has dependencies scattered all over the system, and
to change anything you have to consider everything.

Type checking can help you with a few kinds of problems you'll have trying to
make changes in those kinds of systems, but you still have piles of problems
and it doesn't do anything to help improve the underlying issue.

Static types can help you with some small problems, but that doesn't mean much
when the problems you have are big.

~~~
epidemian
> But that's really a symptom of a "big ball of mud" design (non-design,
> really)

Yep, that's exactly the problem :)

The thing is that, without ease of refactoring, it's very difficult to change
that big ball of mud into something prettier. In fact, i'd say that without
ease of refactoring it's kind of inevitable to fall into that big ball of mud
"design" in the long run.

(Note: static type systems are not the only tools to help with refactoring.
Good test coverage, style guidelines, a well documented / simple architecture,
are of course very helpful too.)

~~~
davidjnelson
Exactly. Static types ( I've used flow not typescript, but similar ) and good
unit tests allow ridiculously easy and merciless refactoring of enormous
swaths of code in an extremely short period of time with incredibly high
confidence.

Integration tests ( not to be confused with functional tests / i.e.: selenium
) that test multiple classes in concert via input / expected output give the
most bang for the buck, because you know your code works as a whole.

------
peruvian
It's hard to take these kind of posts seriously when Reddit mobile site is one
of the worst performing SPAs I've ever used.

~~~
founder_advice
What are your specific criticisms?

~~~
andrewguenther
Personally, I find the entire experience to be incredibly slow. Loading the
front page takes multiple seconds, there is a noticeable delay between tapping
a link and any form of response, and back navigations are often unexpectedly
slow.

Non-SPA related, I also think that many of the touch targets are too small, or
work in unexpected ways. Tapping a username collapses a comment, even though
there's an arrow next to it. Tapping an image associated with a link doesn't
follow the link, it expands the image (even if it is an article link). Tapping
the title takes you to the comments, not the article. The only way to get to
the content is to click the itty bitty domain title beneath the title. All of
these behaviors are different than how the desktop view behaves. For a site
that calls itself the front page of the internet, it's getting harder and
harder to get to actual content.

~~~
alanbernstein
That's funny. Reddit took over my [desktop] web surfing precisely because of
how much faster/cleaner it is than any other comparable website. Beaten only
by HN.

~~~
kronos29296
HN is usability and speed taken to the extreme. I mean it the personification
of Unix philosophy 'do one thing and do it right'. So no bloats.

------
jondubois
I've worked with TypeScript on and off for a couple of years now. I don't like
it.

The compilation step is a major pain. Even after using it for several months
straight, I feel like I'm in a constant battle with the compiler. It's slow
and difficult/annoying configuration problems keep coming up from time to
time. It slows down my debug cycle and the compilation delay makes me lose my
train of thought. I used to love using console.log() to quickly test an
assumption in JavaScript; you cannot do this with TypeScript (it's not
practical given the 5 to 20 seconds compile time); you have to use the
debugger every time and step through stuff (even when you have a very good
idea about which specific variable you want to check) - It's extremely
cumbersome.

I have gone back and forth from dynamically typed languages to statically
typed languages many times for years and I've spoken with engineers who used
to be Java developers for many years, then switched to Javascript, then
TypeScript and they shared the same thoughts as I did. TypeScript is slow and
restrictive in a way that is unnecessary. It's got Microsoft all over it.

Also it forces all developers to use bulky commercial IDEs like WebStorm
because you rely more on code completion to help you figure out the right
types. You can say goodbye to Atom, Sublime and the rest... Atom's TypeScript
plugin is not good enough unfortunately.

At my previous work, even developers who said that they liked TypeScript
secretly didn't like it because they used the 'any' type Everywhere.

I wonder if the people who are making this decision have actually tried
TypeScript themselves for any decent amount of time on a decent sized project.
I don't think they know what they're getting into.

I decided not to renew a lucrative contract at a finance firm as a front-end
developer in part because I did not enjoy using TypeScript every day.

~~~
octref
> It's slow and difficult/annoying configuration problems keep coming up from
> time to time. It slows down my debug cycle and the compilation delay makes
> me lose my train of thought. I used to love using console.log() to quickly
> test an assumption in JavaScript; you cannot do this with TypeScript (it's
> not practical given the 5 to 20 seconds compile time);

Have you ever used `tsc --watch`? First build can take long but modification
and rebuild takes < 1s.

> you have to use the debugger every time and step through stuff (even when
> you have a very good idea about which specific variable you want to check) -
> It's extremely cumbersome.

You don't "have to" use the debugger if you prefer `console.log` all the way.
However in the debugger there is a "watch" tab for inspecting specific
variables.

> Also it forces all developers to use bulky commercial IDEs like WebStorm
> because you rely more on code completion to help you figure out the right
> types. You can say goodbye to Atom, Sublime and the rest... Atom's
> TypeScript plugin is not good enough unfortunately.

VSCode? [https://code.visualstudio.com/](https://code.visualstudio.com/)

~~~
jondubois
Using console.log is not practical with TS because I only get one chance per
debug cycle to log the value of the variable which I think is of interest. If
that doesn't give me any insight, I have to log another variable. This is fine
with JavaScript because it takes me about 2 seconds to add a console.log and
check it. With TypeScript, the cycle takes about 10 to 15 seconds, so it's not
efficient to do that, so yes, I end up having to fiddle with the debugger, add
watchers and hover over individual variables... I kind of have to deal with
the debugger's clunky UI every time which is slower. If source maps don't work
correctly (as was the case for a lot of projects), then the debugger is even
more of a pain.

I've worked on TS on large existing projects as part of large teams. In my
last project, we did have some sort of file system watcher but it still took >
10 seconds on average to compile. Launching the project from scratch took
longer than 1 minute. From time to time, I did have to relaunch the whole app;
usually for a different reason every time.

------
opvasger
I'm coming at this from the Elm-camp, and my first impression (and largely why
I think languages like Elm is promising) is how languages that are implemented
as supersets of other languages have the potential to be as bad as their
subsets.

The example that I was given was C++ and C, but I think TypeScript with it's
gradual-typing approach is forced to remain potentially as bad as JavaScript
itself - that is, if you're feeling weak and want to "get shit done", you can
bypass all the goodness that TypeScript undeniably offers you.

For a language like Elm, the type-system is invariably gonna have your back -
a value-proposition I think means a lot more in practice than some self-
proclaimed pragmatists realize :)

~~~
Gaelan
tsc --noImplicitAny solves that.

~~~
DanRosenwasser
Or to go all-in - we have a `--strict` flag that gives you `noImplicitAny`,
`strictNullChecks`, `noImplicitThis`, and a mode that always puts you in `"use
strict"` mode.

~~~
zumu
I don't understand why `strictNullChecks` is not the default behavior. It
being a special compiler option makes me somewhat dubious of TypeScript in
general.

~~~
Gaelan
Backwards compatibility.

------
tkubacki
Wondering why Dart was not considered. Large apps are written in it (Ad sense
UI, Ad Words UI, Google CRM). Has good tooling (IntelliJ plugin, Webstorm).
It's fairly easy to pick up - Java/C# like syntax. It's harder to shot
yourself on your own foot (it's not JS superset). It has strong mode. It has
superb tooling and package manager ( dartanalyzer, pub)

~~~
JeremyBanks
Dart is for Google, by Google, and external engagement has been as neglected
as for all of Google's front end efforts. Google ceded the thought leader
position in this area years ago and everybody knows better than to trust any
of their new efforts.

~~~
noway421
There's still polymer which is developed by chrome team and angular2 by ads
department and those seem to be quite industry proven. E.g. angular2 is one of
the main adopter of typescript.

~~~
JeremyBanks
Don't forget that Google's first instinct for Angular 2 was to create an
incompatible fork of TypeScript.

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

~~~
TomMarius
That was because TypeScript didn't support decorators back then - the "at"
comes from the at sign.

~~~
JeremyBanks
Yes, and what kind of reasoning is that? You do not fork a language to make
your framework a little more convenient. It's inane. That's how you end up
with both a dead language, and a dead framework.

Microsoft saved them from themselves. (I expect they could have arranged to
have the feature added without first publicly declaring their intention to
fork the language, but that's above their community engagement skill level.)

Google's Closure Compiler was the best version of compiled JavaScript for five
years. It should have been the winner, but Google did nothing to make it
palatable to the open-source community (docs are a disaster, the code is full
of unexplained Google-specific workarounds, it integrates with nothing), got
trampled, and now they're forced to adopt someone else's tech to remain
relevant. Google is _so_ bad at this.

------
bjterry
I recently moved to a company using Flow from one using TypeScript, and it
seems like the tooling ecosystem for TypeScript is way better than flow. The
emacs plugin for flow in particular is practically nonexistent, and doesn't
even provide proper syntax highlighting. TypeScript's by contrast is amazing.

------
maxxxxx
I recently had to do some Node.js scripting. My JavaScript experience was
minimal and having worked almost exclusively with typed languages I considered
Typescript. I decided against it eventually because I figured you need to know
JavaScript first to understand the JavaScript ecosystem even if you are
writing your own code in TypeScript.

Does this make sense or is it feasible to skip learning JavaScript and jump
directly to TypeScript?

~~~
livingparadox
TypeScript is, strictly, a superset of javascript. You probably could "jump
directly to TypeScript" but you would not be able to "skip learning
JavaScript" as TypeScript is based off the concepts in JS.

That being said, I don't see why you couldn't learn them concurrently; you can
learn the basics of TypeScript and then simply rewrite any relevant JS example
code into TypeScript to learn JS code in a TS context.

Edit: I should also point out that integrating with any JS libraries may
require you to install the '@types/' package alongside it to maintain type-
safety. For example, if you're using jQuery, you can install the
'@types/jquery' package which will expose all the type information for the
jquery package.

~~~
mercer
The downside of going straight for TS is that it's a bit more work to figure
out how to build and debug (with sourcemaps) if you're not too familiar with
front-end development.

On the other hand the upside, and a very big one, is that if you set up the
relatively simple TS build process, you automatically get all the ES2015+
stuff for free, even without needing to figure out Webpack and Babel and the
like (with some caveats front-end-wise, primarily Promises and Fetch).

------
spiderfarmer
Reddit should stop promoting their app on every freaking action you do on
their website. I refuse to install because of it. Just build a better website.

------
flavio81
Javascript is a _weakly_ typed language and no superset like Typescript or
Flow will solve this problem, just mitigate it.

However, on the other hand, I think that a _good_ , experienced developer has
no problem with that. The bugs that the experienced developer "fears" have
nothing to do with type errors, which at the end are rather easy to solve...

~~~
vog
_> The bugs that the experienced developer "fears" have nothing to do with
type errors, which at the end are rather easy to solve_

Not sure how you define "experienced developer", but I think you got it
backwards.

A good type system enables you to structure your code in a way that most
sublte bugs are "converted" to type errors. That's the magic of types!

Your type definitions aren't just some syntactic sugar so that the type
checker finds some typos.

Your type definitions are a vital part of the code base that you design to
protect it from changes that introduce subtle bugs - the kind of kind you can
easily foresee when you wrote a particular module, but which others (or
yourself after 6 months) won't be aware of. This is especially important on
refactoring, but also super helpful for non-trivial extensions.

In that sense the types are like unit tests. Although they are less flexible
than unit tests (so they are no substitute), they make most of your unit tests
unnecessary and are shorter and easier to write and to maintain than those
unit tests. Most importantly, however, they "test" all cases, statically at
compile time, not just the specific cases of your unit tests.

~~~
flavio81
Good reply, but the benefits you described are already realized by _strong_
typing, which is not the same as _static_ typing.

A language with strong typing (which additionally can be a dynamically typed
language, something that many people are not aware of) will catch any of such
type errors, without having to bother adding type specifications/signatures
everywhere in your code. Thus, those are bugs that are trivial to solve.

And this, to paraphrase your post, protects your code from changes that
introduce subtle bugs.

You can also have a language that is statically typed but that has weak
typing! Which language? C. And i think everybody knows the extra effort needed
to keep a C program bug free. And this not only due to lack of automatic
memory management!

I have been programming for most of my life, that is about 23 years of
programming on where 20 of those years were using statically typed languages,
including many years programming on large, business-core systems on Java and
C#. I since have gone to dynamically typed languages and never looked back.
You just need strong typing, that's enough.

~~~
mavelikara
A compiler verifying against a static strong type system proves certain
properties about your program which provides some assurances about what your
program can and cannot do.

You might be able to prove more assuring properties about your program with a
test suite.

When the GP said:

> A good type system enables you to structure your code in a way that most
> sublte bugs are "converted" to type errors. That's the magic of types!

I am almost certain that s/he meant type errors uncovered without actually
executing the program. In a dynamic strongly typed language, you will need to
execute the program and force it into these errors - presumably using a test
suite.

> A language with strong typing (which additionally can be a dynamically typed
> language, something that many people are not aware of) will catch any of
> such type errors, without having to bother adding type
> specifications/signatures everywhere in your code.

A static type system does not need type specifications/signatures "everywhere"
in your code. In Java and C#, it does. But many modern languages, TS included,
can infer static types to a large extent.

~~~
vog
_> I am almost certain that s/he meant type errors uncovered without actually
executing the program. In a dynamic strongly typed language, you will need to
execute the program and force it into these errors - presumably using a test
suite._

Yes, this is exactly what I meant. Well, I was really arguing for both, static
_and_ strong typing, although my argument concentrated more on the "static"
part, as that gives you safety and correctness guarantees that cannot be
achieved with assertions and unit testing at all.

 _> A static type system does not need type specifications/signatures
"everywhere" in your code. In Java and C#, it does. But many modern languages,
TS included, can infer static types to a large extent._

I relied on type inference a lot when writing OCaml code. However, I noticed
that on some places I still want explicit types. (I just don't want to be
forced to type them on every variable.) For example, on most function
definitions an explicit type helps a lot. Otherwise, the compiler can only
tell you that your function call doesn't match your function - but can't tell
you whether your function is wrong, or the code using it. With an explicit
typing of the function, you know exactly which side is wrong. Also, in case it
is the function, you'll note this when writing the function, not later on when
trying to use it.

------
dom96
As much as I am disappointed that Nim wasn't chosen, I am impressed that it
was mentioned at all. Nim's JS backend is still rather young, and tooling is
definitely lacking. But you can make some pretty cool things with it[1].

1 - [https://picheta.me/snake/](https://picheta.me/snake/)

~~~
girvo
Yeah, I did a double take when I saw it on the list. We use Nim at my new work
extensively for some back end stuff (mainly homomorphic encryption
experiments, but a full implementation of Paillier is also in it!) and I've
just started getting the team to leverage it for the front-end too :)

~~~
dom96
That's awesome. Can we expect a blog post from you about Nim in the near
future? :)

~~~
girvo
Yep, especially because IBM just gave me a 20-core (8 hardware threads per
core) POWER8 server with 256GB of RAM to run this stuff on, so I'm going to
have a lot of fun getting Nim up and running on it!

~~~
dom96
Awesome! If you want it posted on nim-lang.org then just create a PR on the
website[1] repo :)

1 - [https://github.com/nim-lang/website](https://github.com/nim-lang/website)

------
erokar
The intellisense you get with TS is quite nice, as is improved refactoring. I
also think typing in function signatures is a good thing and increases
comprehension.

But the type-safety you get with these kinds of static languages only catches
a few trivial bugs. There are also some situations where TS complains where it
shouldn't, for instance it doesn't handle JS' built in reduce function very
well.

In the end, it's a trade-off between the benefits and added costs. It is in no
way a given that adding static typing to your JS project will be beneficial
when all factors are considered.

~~~
jstimpfle
By contrast, does anybody think that having "stronger" dynamic typing (don't
convert strings to numbers as implicitly, etc.) like Python's would not be a
huge benefit?

~~~
mercer
That's actually one reason why I often opt for TS. While the 'stronger dynamic
typing' isn't the most sexy benefit, it has saved my ass quite often.

There are so many situations where my input is strings (JSON through various
API's) that _should_ get turned into just integers, floats or (string)
constants shortly after being consumed. Using TS types from this point onward
promotes discipline to do so on my part, removes any ambiguity going forward,
and alerts me if I treat these values as strings or any other wrong type
(which commonly happens to me, at least, when using vanilla js).

~~~
jstimpfle
I agree - one thing is noticing bugs, which is easier with stronger dynamic
types.

And as you say it's also important to setup some boundaries so that bad values
can't travel to the other end of the program before you notice, which is a
pain to debug.

I like to make value checks on module boundaries, but do much fewer checks
inside modules. I typically do this using assertions. Optional types can be a
way to do it with less noise. But they still can't replace asserting arbitrary
invariants, like invariants involving multiple values.

------
paulborza
TypeScript is an excellent language.

~~~
tkubacki
No it's not. It has all JS flaws - it's just better than js and it's easy to
use it with js. Otherwise Dart would win.

~~~
bcherny
Like what? TypeScript is careful to avoid a lot of JS's footguns (implicits,
undefineds, etc.)

~~~
legulere
== versus === and all the other weak typing wats, undefined type still exists
in typescript, no integer type, UTF16 strings are the ones coming to my mind
and I don't even program in JS/TS

~~~
johnfn
I'm pretty sure all weak typing warts basically stem from equality checks with
==/===. If you use === all the time you'll never run into them.

TS has optionals so undefined is not an issue.

The rest is valid.

~~~
legulere
There are also some JavaScript functions like isNaN that also do type coercion
and of course +. How is this handled in typescript?

~~~
nycdotnet
In a word, "correctly". The result of an expression with + or isNaN() will be
of whatever type the JS spec says it should be. This is one of the less
frequently touted, but more useful aspects of TypeScript - the lib.d.ts file
acts as a partner to explain to you how the built-in JS type system actually
works without you having to memorize or look up everything in docs.

------
bayesian_horse
Can someone please _prove_ that types make development somehow safer and more
productive?

I for example believe that readability matters, and typescript is not that,
compared to Python or even coffeescript.

And I really don't like how all the cool new languages lack significant
whitespace.

You can probably tell I'm a Pythonista. A Pythonista always pays his technical
debt.

~~~
fpgaminer
> And I really don't like how all the cool new languages lack significant
> whitespace.

Significant whitespace is redundant in the face of auto formatters. The latter
are becoming more popular, and rightfully so.

~~~
bayesian_horse
Auto formatters still make you look at the braces... and typescript needs a
lot of those. It's not just about formatting...

------
tycho01
I tried typing functional programming library Ramda using TS, and got
frustrated it still had some limitations (e.g. needing overload codegen in
lieu of variadic support).

I tried finding what TS can do now, and figured out type-level tuple
iteration, among a few others. The current roadblock seems to be getting
function return types. Progress, for anyone interested:
[https://github.com/Microsoft/TypeScript/issues/16392](https://github.com/Microsoft/TypeScript/issues/16392)

At this point I'm amazed how close we are to typing anything, despite having
only 5 (!) type-level operators, with their respective warts.

------
mdip
Gotta comment ... I dove into TypeScript about a year ago and dropped it. I
saw the value but because of a large number of libraries and custom components
of my own, switching purely to TypeScript wasn't easy and I was in a hurry.

Fast forward several months and I picked it up again. I've now been writing
_everything_ that I would have done in JS in TypeScript and have built several
applications using both Angular and React entirely in TypeScript. I've also
sold my teammates on switching to the language.

When I was (stuck) writing JavaScript, the frustration factor was high for me.
I'd get nebulous errors[0], hunt around the line it referenced, swear a
little, and trace the code back to the cause. I would wildly estimate that one
out of ten attempts at blindly running my code would succeed[1]. Even on unit
tests, which had a higher degree of success since they were testing much less,
still had a _much_ higher fall-over[2] rate than I get in typed languages that
I enjoy. The addition of types, which adds a little overhead, flipped that
over. I am _still surprised_ every time I refresh a page that uses code I'm
modifying and _it loads_. The reduction in time spent debugging (and swearing)
makes me enjoy the language more every day that I use it. It's even left me
longing when I am writing code in other languages (mostly Java/C# these days)
and features I have come to really enjoy (union types, intersection types and
to a lesser extent the duck-typing nature of the language[3]).

Since crapping on _any_ language, or feature/lack of feature of a language
tends to become a religious war fought with verbal violence, allow me to admit
a few points: Traditionally, I avoided JavaScript and jobs related to it.
Personally, I hate the language. This means I've spent considerably less time
researching all of the best practices/techniques for surviving those cases
where I _have_ to write JavaScript. I started in C and Pascal and prior to a
few months ago spent 99% of my time in typed languages. I am an advocate for
unit testing[4], but I find test-driven development requires me to work
backward and it's less productive for me. I'd imagine that if I went _all in_
with TDD, I might see fewer of these problems, but many of the best practices
for JS development are best practices in the languages I am more proficient in
and despite following these practices, JS design led to these practices being
less effective at reducing bug frequency. Yes, I could just be a yelling 'get
off my lawn' because I'm unwilling to change[5]. But I've also worked closely
with highly-skilled JS developers who could rapidly produce incredible things
as a result of its flexible, dynamic typing. Incredibly, though, one of those
'huge JavaScript advocates' was the one who told me to give TypeScript a
chance late last year. Though he would always fight me on the "dynamic vs.
static" thing, his argument was that TypeScript's type system was light-weight
enough to keep out of his way while strict enough to lower the frequency of
self-inflicted foot bullet-holes (paraphrased). Really, though, ... two nulls,
asinine boolean implicit conversions necessitating code like double-bang and
=== / !== operators[6] should be enough.

[0] Often depending on whatever framework I was using, but I've rarely found
one that returns an error that results in a really _obvious_ 'oh, I know what
I did to cause that'

[1] I like to check that a component renders visually appropriately and often
do a quick check before I've written all of the required unit/integration
tests to make sure it's rendering accurately (right data/right result).

[2] As in, something fails badly enough to stop execution rather than just
failing on an assert for an incorrect result.

[3] It's a love-hate thing for me -- the result is being able to reduce
boilerplate making mostly-compatible types interact, but the down-side is that
the compiler giving a pass to "A=B" when "A" has at the properties of "B"
results in some subtle bugs that have already bitten me more than once.

[4] Though I don't buy into TDD (either before writing the code or after)
solves most of the issues of dynamic typing. I've had more than a few tests
fail because of a type-related issue...in the test.

[5] Except that I _love_ learning new languages and 'keeping up' and have
found that as I've aged, I can pick up new languages far more quickly than I
could in my early 20s... [plug]RUST![/plug] I'm also not terribly old, nor
terribly sensitive about being called an oldster.

[6] I don't recall who, but someone was once reading code out-loud and said
"if action _fuckin ' equals_ 'ADD' and payload.Length _doesn 't fuckin' equal_
zero". Adding in the _fuckin '_ every time he encountered the "really, really
[not] equals" operator. So that is how I mentally read those. I'll never
forgive him (sorry for the swears ... and doubly sorry if you end up reading
code like this as a result).

------
z3t4
upvote should be a global with capital letters. but writing it like that might
be a leaky abstraction of the underlaying database storage. should the web dev
really have to know that some variable is represented by a tinyint later
converted to a float, then "optimized" to a 32 bit int !? why make it into a
failure point when there is so little gain in performance and make little
sence in a high level, lose typed language such as javascript. stop writing
javascript like its java!

------
coldtea
> _Should work on both the client and the server. SEO is very important to
> Reddit, so lack of universal rendering is a deal breaker._

This sounds like a total non-sequitur.

------
vog
From the article:

 _> Typescript also came with a lot of “social proof” and better assurances
about its longevity There are several large projects using Typescript
(examples include VSCode, Rxjs, Angular, and Typescript itself),_

While I agree with the sentiment, I don't understand why they include
"Typescript itself" in this list. Isn't that a circular argument?

~~~
nycdotnet
Not really. It's direct proof that the language is good/fast enough that the
people creating it chose it for themselves. The flow team, for example, wrote
their language in ocaml.

------
dcgudeman
I would like to know if they are moving towards a SPA architecture and, if so,
what framework they will be using.

~~~
underwater
The mobile experience is a single page app. It's not very good.

~~~
KingMob
If you land on the desktop site, it consistently pushes you to download the
app, and buries the mobile link.

~~~
h_r
It is an incredibly ham-handed way to try to push people into the app.
Extremely irritating.

------
slimsag
> Should work on both the client and the server. SEO is very important to
> Reddit, so lack of universal rendering is a deal breaker.

Are client-side only JavaScript applications not handled well by the likes of
Google et. al. today? I was under the impression that they run a full JS
interpreter.

~~~
mrdmnd
[https://www.stephanboyer.com/post/122/does-google-execute-
ja...](https://www.stephanboyer.com/post/122/does-google-execute-javascript)

------
macmac
I would have more confidence in the list if they spelled ClojureScript
correctly.

~~~
taspeotis
I suppose I'll piggy-back this off your comment, since mine doesn't really
deserve to stand at the top level, but I am also surprised this blog post
can't stylise TypeScript correctly...

------
noway421
The screenshot in the header is strange. Why would they reimplement
arrayToDict function instead of using lodash's _.indexBy

------
emilsedgh
I personally skipped Coffescript, Javascript Generators and Angular.

And none of them passed the test of time.

So I think I made the right call by not adopting them super early.

I think I'm going to do the same with Typescript. Hopefully static typing will
be adopted by ES.Next and then I'll port my programs to it.

~~~
johnfn
Er, JS generators definitely did pass the test of time and are now part of
modern JS.

~~~
18nleung
With async/await there's not much of a case for their use anymore, though

~~~
AgentME
The regular generator use (return a lazily-evaluated iterator) still exists.

------
iamleppert
From what I know of the Reddit community and their feedback on anything any of
these "new devs" have done, it's not going to matter how pretty, well-typed or
"scalable" (whatever that means) the code is.

All the new product is just awful. I feel sorry for them.

------
rmuratov
Anyone know existing open source projects written in Flow?

~~~
gaastonsr
There are quite a few. I know some Facebook projects are.

From the top of my mind [https://github.com/styled-components/styled-
components](https://github.com/styled-components/styled-components).

------
amagumori
ok. i get why you chose typescript.

however, why did you choose this weird cursive-ish monospace font? and...where
can i get it?

~~~
zuzun
Operator Mono

[https://www.typography.com/fonts/operator/](https://www.typography.com/fonts/operator/)

------
sushisource
Lord that font in the header image is disgusting. Who would want a faux-
cursive programming font?

~~~
LeoNatan25
Anyone knows what that font is?

~~~
_ar7
Operator mono I think. It costs a lot.

~~~
LeoNatan25
Thank you!

------
lapsock
Buy _why_ are you redesigning the site? It looks fine as it is. Let me guess
some designer told you to redesign it in order to justify his paycheck.

------
revelation
"We picked Typescript because this is what we feel everyone else is using and
wow are we late to this party"

Take nothing away from TS but the mobile Reddit is all the proof in the world
that no matter the language, the paradigm or the ecosystem, someone can still
use it to turn out a horrible product.

~~~
SquareWheel
Using quotation marks with false quotes is a pet peeve of mine. It misleads
the reader, and is essentially admitting to setting up a strawman.

