
TypeScript at Google - wslh
http://neugierig.org/software/blog/2018/09/typescript-at-google.html
======
Nitramp
> The first tempting option is to just abandon this ruined planet and settle a
> new one that doesn't even involve JavaScript. If only we invested more in
> GWT (a Google project that compiles Java to JavaScript) or Dart (a Google
> project that compiles a new language to JavaScript) or WASM or [insert your
> favorite language here — Clojure? Haxe? Elm?] we wouldn't need to worry
> about JavaScript at all!

I thought about this for quite a while when we started on TypeScript at Google
(I work on this with Evan). I've convinced myself that using a different
language cannot solve the problem that we're looking at.

The argument goes like this: if you use a different language than JavaScript
for front end development, you're (hopefully) doing it for a reason. That is,
you (a) want the other languages semantics (e.g. bounds checks on array
accesses, runtime types, method dispatch, you name it), or you (b) might want
the programming languages ecosystem - editors, IDEs, etc; but most importantly
libraries and frameworks. Most likely, you're looking for a combination of (a)
and (b).

The problem with (a) is that the more different the runtime semantics of your
programming language are, the more emulation code you need. Emulation code is
costly in code size, performance, interop with JS, and often understandability
(at some point you will need to debug the output, believe me).

The problem with (b) is that you typically opt into a large ecosystem that was
originally written for a very different environment. This was a big issue with
GWT: people would pull Java libraries, but those libraries, amazing as many
are, were not written for the web or with code size in mind. This meant using
a common library like Guava required a lot of engineering effort to keep code
size in check. This also applies to WASM, possibly even more so.

These mechanisms work together to make it very hard to hit the sweet spot
between performance, developer experience, and interoperability. And
ironically, the better you get at the goals you're aiming for (different
semantics, different ecosystem), the farther you get away from a working
solution.

I don't think it's impossible to achieve a transpile-to-JS language that works
really well with enough investment, but keeping in mind the other reasons Evan
lists (mind share, existing code base), incrementally improving JavaScript
where needed is IMHO the much more promising approach.

~~~
sanderjd
This is a super interesting perspective. It seems to me that another way to
strike this very tricky balance is to design a language with it in mind - so
that you can choose semantics with the emulation trade-off explicitly taken
into account - and invest very heavily in its ecosystem - so that you can
catch up on the library, framework, and IDE front. Arguably both Dart and
TypeScript (among others) are doing the first part of that, but only
TypeScript is doing the second part. I guess there's a third important part
too: choosing a really good set of semantics based on that trade-off. I think
TypeScript has really nailed that one. I like Dart and Elm too, but TS is
definitely in the sweet spot for me.

~~~
evmar
Unfortunately, to take this approach you generally need it to be a _new_
language, so it doesn't have existing ecosystem baggage to carry along, which
means it is less likely to win on another axis you often care about: developer
familiarity.

This is why the candidates in this space are only the upcoming ones like Dart,
Elm, and maybe Kotlin. The other "compile to web" approaches that use more
established languages (like emscripten for C++ or GWT for Java) tend to
produce larger binaries due to carrying along their ecosystem.

This is restating GP's point, but to say it again, this tradeoff is kind of
inevitable -- half the reason to want to transpile is to reuse knowledge and
libraries, but then by reusing those libraries you kill your binary size.

(This dynamic reminds me of all the people who hoped they'd be able to reuse
their existing web apps on mobile but ended up with bad mobile apps. I think
it's possible to make a good web-based app work on mobile but it's often a
rewrite from an existing web site, at which point you're often rewriting
anyway and might as well use a mobile-native language.)

------
mattferderer
I'm hesitant to work in any JavaScript code base that isn't using TypeScript
at this point. Two years ago, it was painful to use as any early release is
but the benefits were obvious.

My biggest wish for TypeScript is that it was easier to use experimental
flavors that supported JS features currently being considered, such as the
pipeline operator proposal.

~~~
MBCook
Have you spent any real time with Flow?

As I’m starting to get into the modern front end world… I do want the safety
of a stronger type system but it doesn’t look like the React ecosystem has
really decided which way to go.

TypeScript is popular. But flow was developed by Facebook and so it’s
obviously heavily used by some of the top people.

I’ve only been reading about them, I haven’t chosen to use one yet. But I’ve
been leaning on flow since it’s developed by the React team at Facebook.

~~~
Vinnl
Although it's clear that Facebook's libraries, among which React, favour Flow,
there's strong community demand for TypeScript even around React. Thus, the
type definitions that are available for React are excellent, Redux even
includes its type definitions natively, and most of the large tools in the
React ecosystem work pretty well with TypeScript.

The main large project you're likely to use that does not really play well
with TypeScript yet is create-react-app. There's a TypeScript fork [1] which
works reasonably well, but "reasonable" is not really what you'd hope.

That said, the strong community push means that they're at least considering
it. [2]

[1] [https://github.com/wmonk/create-react-app-
typescript](https://github.com/wmonk/create-react-app-typescript) [2]
[https://github.com/facebook/create-react-
app/pull/2815](https://github.com/facebook/create-react-app/pull/2815)

~~~
acemarke
We're actually looking at removing the type definitions from the Redux core
and punting them over to DefinitelyTyped, because neither of us primary
maintainers use TS ourselves and we don't have the experience to maintain the
type definitions.

Also, the CRA-TS fork runs, but the one time I played with it was when I tried
to help another team set up their project, and that's when I found out it has
_ridiculously_ restrictive default linting rules. Every lint error is a
compile error, and it flags things like using arrow functions in render
methods, which is absurd (see discussion at [https://github.com/wmonk/create-
react-app-typescript/issues/...](https://github.com/wmonk/create-react-app-
typescript/issues/333) ).

~~~
joshtynjala
The first thing I do in a new CRA-TS project is make the tslint.json rules
default to warnings instead. Or just disable them completely. After that, it's
great! I'm actually surprised that they still haven't loosened the rules after
Dan called it out a month or two ago. Seems like an easy enough fix to at
least make them warnings until they choose better defaults.

------
munificent
_> If only we invested more in GWT (a Google project that compiles Java to
JavaScript) or Dart (a Google project that compiles a new language to
JavaScript) or WASM or [insert your favorite language here — Clojure? Haxe?
Elm?] we wouldn't need to worry about JavaScript at all!_

I'm on the Dart team. I don't know if the author intended this, but you could
read this as saying that Google isn't investing much in Dart, which isn't
true.

Flutter and Fuchsia are the high profile projects that use Dart. AdWords is
also built in Dart. The Dart team itself is as large as its ever been and
growing. (I'd give more precise numbers, but Google generally shies away from
publicly stating personnel details.) We have a ton of internal and external
code written in Dart, and it's growing at a nice clip.

Different projects have different needs. If you have a large existing JS
corpus that's providing a lot of value for you, then an incremental migration
to TypeScript makes sense.

If you're looking to rewrite a lot of code and pay off technical debt anyway,
then moving to a new language that doesn't have all of JavaScript's baggage
can be a smarter choice. Dart has a cleaner object model and fewer warts like
"===", etc. Making a bigger break from JS means that Dart's type system can be
simpler than TypeScript's and is sound. That in turn means the compiler can
rely on types for optimization and minification.

~~~
jadbox
I mostly know Typescript, but I'd like to learn more about Dart...
particularly where the type system differs in theory. Do you have a good
recommended article on that?

The other question is the community one: if Dart requires type bindings (like
TS .d.ts files) to the large community of JS projects, how does it plan to
solve the kickstart problem. It's taken TS community many years to over just
the popular js libraries out there. Imho, I'd make a utility to
convert/translate TS definitions into Dart wrappers... but that would require
to support TS primitives almost 1:1.

None of this is meant to sound critical, I'm just genuinely curious on the
process of language development.

~~~
munificent
_> Do you have a good recommended article on that?_

I don't, but I agree it would be useful. We're not where I wish we were in
terms of docs right now.

 _> if Dart requires type bindings (like TS .d.ts files) to the large
community of JS projects, how does it plan to solve the kickstart problem._

We actually have a tool that will generate the proper Dart interop bindings
given a TypeScript .d.ts file:

[https://github.com/dart-lang/js_facade_gen](https://github.com/dart-
lang/js_facade_gen)

 _> It's taken TS community many years to over just the popular js libraries
out there._

Dart is different from TypeScript in that we are deliberately a more
batteries-included system. We wrote and maintain a full set of core libraries
(collections, async, etc.) and Google has a well-funded team to ship and
maintain a full-featured web framework (AngularDart).

So we aren't _as_ stuck needing to rely on the JS ecosystem as TypeScript is.
There is still tons of useful functionality that's available in JS and not yet
Dart, which is why interop is important, but we have a lot of customers that
can get by without needing much or any JS interop.

------
TheAceOfHearts
Google has enough resources for someone to write a transpiler that can take
annotated JS and convert most of it to TypeScript. It's certainly much more
pleasant than having to type random comments everywhere, which kinda makes
syntax highlighting way less useful. Oh, and last I checked there were no
editor plugins for linting Closure Compiler annotated code.

Another option would be to add TypeScript support to Closure Compiler,
although it doesn't seem likely since there's no spec to guarantee
compatibility.

I'd love to see Facebook, Google, and Microsoft team up in this space, instead
of creating 3 separate but very highly similar tools.

Also, while we're talking about Closure, let's take a moment to appreciate its
amazing UI toolkit [0]. I'd still consider many of their widgets to be the
gold standard. It's written with desktop clients in mind and is incredibly
feature-complete. I believe it also has pretty good accessibility, although I
haven't personally tried that out. Oh, and don't forget the i18n as well! The
closure library definitely has a lot of quirky aspects to it, but it's still
quite amazing if you consider its age and how much stuff it supports. It's
worth taking a few minutes to browse through their docs [1].

[0] [https://google.github.io/closure-
library/source/closure/goog...](https://google.github.io/closure-
library/source/closure/goog/demos/index.html)

[1] [https://google.github.io/closure-
library/api/](https://google.github.io/closure-library/api/)

~~~
bazza451
[http://www.syntaxsuccess.com/viewarticle/closure-compiler-
vs...](http://www.syntaxsuccess.com/viewarticle/closure-compiler-vs-rollup-vs-
webpack) \- interesting article about how closure enables smaller bundle
sizes.

I agree, it would be cool for someone to do the same thing for Typescript, I
seem to remember a repo a while back on Github that said someone was
experimenting with it - cant for the life of me remember where though!

~~~
bazza451
didn't read the other comment on this -
[https://github.com/angular/tsickle](https://github.com/angular/tsickle) was
the repo

------
shadowmint
I feel like this sort of organic growth (for typescript) is a very healthy
sign for a project.

ES6 (or whatever we’re supposed to refer to it as now) is good enough for many
things, but when you see it used heavily with, for example, proptype hints...
you get the feeling that there really is a trend these days towards flavoring
static type checking and the error checking that offers.

I think its an interesting shift, with python and javascript both being poster
child dynamic languages, but people who use them seriously going... ‘yeah,
type checking is actually pretty handy...’.

~~~
EE84M3i
Sorry if this is a well known term but what is a "proptype hint" in this
context? I can't seem to find any references for '"proptype hint"
"javascript"' or any variations that come to mind on Google.

Edit - changed previous sentence to "proptype hint". I originally erroneously
read the parent as saying "prototype hint" which I couldn't find results for,
but even after correcting my reading error my question still stands.

~~~
shadowmint
github.com/facebook/prop-types is the 2nd google search result for this term,
and is what I was referring to, although the first result
(devhints.io/react#property-validation) is arguably a better summary.

Ie. ‘lite’ type checking, used in react.

(did you perhaps see the results for ‘javascript prop type hint’ as a google
autocorrect suggestion or something? This _is_ a well known term, but I’m
pretty amazed two seconds of google didn’t discover what it was...)

~~~
rounce
I read it and thought you were referring to something related to some proptype
based code completion. The use of 'hinting' threw me off completely,
especially when you're talking about _checking_ & _validating_.

------
nathan_f77
I wonder if it's worth migrating from Flow to TypeScript?

Flow has been great, but I've just tried to update to the latest version and
I'm dealing with a flood of indecipherable errors, especially from the react-
dnd library. Looks like no-one is really maintaining the flow types so I'm on
my own, and I don't even know where to start.

I also haven't been able to track down some errors, like "Cannot read property
'foo' of undefined". Flow thinks that this variable can never be undefined,
and I have no idea how it's happening. It might even be a bug in Immutable.js,
but I have no idea.

So if TypeScript is more popular and has a bigger community, then maybe it's
worth migrating just so I can get more help with these issues. And maybe
TypeScript will catch more cases as well.

~~~
AriaMinaei
That's what I did. I switched to TypeScript after two years of being both
heavily invested in Flow and advocating it.

The reason I initially chose Flow was the fact that their goals were more
ambitious (trying to build a sound type system for example). And there were
features that Flow had and TypeScript didn't (tagged unions for example).

The reason I ultimately switched to TypeScript was that after a couple of
years, it had simply caught up and surpassed in the one area it was behind
Flow (i.e. expressiveness of the type system and type-level programming), and
that it had widened the lead in the areas that it was always better at, like
much better tooling, bigger community, core team being more engaged with the
community, releasing RCs to smooth out the rough edges, etc.

So yes, I switched to TypeScript, and I see that I'm spending less time
working around the type system's quirks and more time getting things done. I'm
also very much enjoying the fact that I can express types in TS that I never
could in Flow. So my codebase has much better type coverage in TypeScript than
it did with Flow.

[0] [https://www.typescriptlang.org/docs/handbook/advanced-
types....](https://www.typescriptlang.org/docs/handbook/advanced-types.html)

~~~
davnicwil
> much better tooling

If you have the time, would you mind commenting specifically on this?

I'm using Flow, rather than TS, for a bunch of reasons you are probably
familiar with, but over time I'm just wondering more and more if switching to
TS might be worth it just for the tooling.

With Flow in VS Code (via the flow-for-vscode plugin), whilst things have
slowly and steadily improved over the last 2 years it is still quite a way
from 'just works'. I get the _impression_ that the story for TS with VS Code
is a lot different, and everything would just work out the box (intellisense,
auto import, meaningful error messages tied to line numbers, etc) though I
simply haven't yet found the justification to invest the time in migrating
just to check this. If I'm wrong and it's the same or only very slightly
better, it would obviously have been a time sink for not really much benefit.

Do you have any insights or advice on this? Even if you're not a VS Code user,
what tools _do_ you use that _are_ better with TS than Flow?

~~~
AriaMinaei
Well, we had a 50K sloc codebase written in Flow. We had invested heavily in
the type system for quality control, so we had types everywhere. This made it
riskier for us to switch to another type system, which is why we stuck with
Flow for longer than we should have.

The way I finally did it was that I tried out TS on a side-project that I
wrote from scratch. I did expect better tooling with TS, but I was still
surprised by how better the experience was.

Auto import just worked. Same with code navigation. And they made me work much
faster. Intellisense was also much better. And the error messages more
readable. (And they've gotten even better since)

All of these things work to some extent in flow+vscode, but the experience
with TS was incomparably better.

I was still hesitant to switch the larger project to TS though, mainly because
we were using some of Flow's more advanced features to type-check a function
like `wrap()` in this code:

    
    
      const obj = {foo: true, bar: {baz: 2}}
      const wrappedObj = wrap(obj)
      wrappedObj.get('foo') // returns true
      wrappedObj.get('bar').set('baz', 'some string') // type error. baz must be a number
    

This was almost possible to do in Flow using `$ElementType<>` and `$Call<>`,
but TS had no counterpart for `$Call<>`. Luckily though, TS soon came up with
conditional types, which turned out to be a much more reliable way to handle
these cases.

That's when I decided to switch the codebase to TS. It took about 5 days. It
wasn't straightforward, but in the end, it gave us a much smoother developer
experience.

------
markn951
We’re going through a similar process at my company - how do we refactor the
decade old startup-style JS without 1) spending a year rewriting everything
from scratch generating little business value and potentially introducing
regressions in the process 2) continuing to build stuff on that shaky house of
cards. It looks like the solution we’ve kind of settled on has also been
TypeScript. At this point it’s probably sub-5% of our prod code that’s TS
source, and it’s daunting given how much we have to change and how many years
it will take at our current pace, but it is the middle ground moderate way and
probably the right way to approach things like this.

~~~
martin_drapeau
In my experience old JS code suffers from lack of structure and discipline
much more than type safety. Can you provide an example where that isn't the
case in your codebase?

~~~
markn951
Nope, that’s absolutely the issue. But we figure we can do both at the same
time, and type safety hasn’t hurt anything.

------
theprotocol
I haven't used it in a while. Does it play nice with plain-JavaScript
libraries from npm yet?

I quit using it a few years back because it was a _nightmare_ having to write
d.ts files for everything or be unable to use noImplictAny for your own files.
`AllowJs` wasn't even a thing when I started using it, but even after its
addition, this problem continued to be absolutely disastrous for my project. I
remember being very disillusioned with it because all of their materials
(website, docs) kept hammering on how effortless and incremental it was to use
with JavaScript, yet `AllowJS` wasn't even a thing for the longest time...

I also had very severe issues with its importing of npm modules, even ones
that supported TypeScript. Sometimes it would double-parse bundled d.ts files
resulting in a huge error output. Other times it would just completely fail to
resolve import paths no matter what I tried.

I remember various workarounds like having to define empty modules for each
plain-JS import, or using `///` imports for certain files, and it was a
nightmare (and I found many similar issues on StackOverflow that were
unsolved). The maintainers at the time considered these terrible workarounds
as valid solutions, and thus would almost not even entertain reports regarding
these problems.

~~~
Vinnl
It's got to the point where, for me, TypeScript support is an important
feature of a library that influences my decision whether to pick that library
over another. Luckily, most of them these days either ship with their own
definitions, or have them available.

Bottom line: I never write my own definitions for other projects.

------
bazza451
Real big fan of TS, like anything though you just have to be disciplined when
using it. Type absolutely everything and set the transpiler to the most
aggressive checks possible... If you’re being lazy and putting : any
everywhere and then complaining about how good it is...you’re doing it wrong

In our project I’ve found we make a lot less mistakes than with pure JS and
there’s a lot less pointless type check unit tests due to the guarantee’s it
gives us. io-ts ([https://github.com/gcanti/io-
ts](https://github.com/gcanti/io-ts)) around rest endpoints checking json
input as well has been a godsend.

~~~
adwhit
I always use it with

> "compilerOptions": { "strict": true }

But given the huge number of other options I worry that like GCC's '-Wall',
that doesn't actually give you the strongest possible type checking. Anyone
know about that? My aim with Typescript is to turn JS into OCaml.

~~~
PinkMilkshake
You might like
[https://bucklescript.github.io/](https://bucklescript.github.io/) Facebook
use it in Messenger.

------
modernerd
The author says they contemplated an “abandon this ruined planet” option,
mentioning Haxe/Clojure/Elm as alternatives. I'd love to read their follow-up
post to learn what kept them on planet JavaScript/TypeScript.

The alternatives to TypeScript seem increasingly compelling to me.

It was good to see Haxe mentioned even in passing; I really enjoy using it and
— as others have noted[1] — it feels like a “better” TypeScript.

Haxe has great features both at the language-level (pattern matching,
algebraic data types, array comprehensions, and more[2]) and tooling-level
(cross-compilation to JavaScript, native code and dynamic languages, a fast
compilation server[3], good VS Code support in Haxe 4, and a bunch of cross-
platform game frameworks[4]). I wish more people would try it!
[https://haxe.org/](https://haxe.org/)

Reason is also compelling; it will be better still once Bucklescript's Belt
library is out of beta and some warts in Reason/OCaml are smoothed out — lack
of ad-hoc polymorphism[5] and lack of unicode support without BuckleScript
string literals being two examples.

[1]:
[https://news.ycombinator.com/item?id=10009290](https://news.ycombinator.com/item?id=10009290)

[2]: [https://haxe.org/documentation/introduction/language-
feature...](https://haxe.org/documentation/introduction/language-
features.html)

[3]: [https://haxe.org/blog/nicolas-about-haxe-
episode-1/](https://haxe.org/blog/nicolas-about-haxe-episode-1/)

[4]: [https://haxe.org/use-cases/games/](https://haxe.org/use-cases/games/)

[5]:
[http://ocamllabs.io/doc/implicits.html](http://ocamllabs.io/doc/implicits.html)

~~~
evmar
The mastermind behind our TypeScript project commented on this topic here:

[https://news.ycombinator.com/item?id=17896925](https://news.ycombinator.com/item?id=17896925)

I used to tinker a lot with OCaml around 13 years(!) ago. It's neat to see
people are still working on fixing some of its problems. It would be fun to
find a reason to use it again.

------
fogetti
[Irony on] It's somehow reassuring that Google engineers also " _check
StackOverflow for answers_ ". Helps me to raise my low self-esteem. :D I
thought all what Google engineers do is writing code from scratch in brainfuck
all day long.[Irony off]

Of course I am just joking. Well, the author faced the same dilemma that we
all face when instead of joining the next-to-be-unicorn startup we join an
established company which has been operating for more than one decade. Namely
legacy code.

They should pick up a copy of 'Working effectively with legacy code'. They
might extrapolate some of those advices and apply to their situation.

------
galfarragem
Isn't Reason/Ocaml a better direction than Typescript? I believe that TS is a
step forward but I'm afraid that we are still in _a muddy path_.

~~~
vvpan
I hear ya, but the author of the article needed something that could be
adopted _incrementally_. JS is a subset of TS. Throwing some typing onto a JS
file is often trivial. Reason would be a whole different story. Learning curve
alone...

------
s4vi0r
As somebody migrating a React codebase from JS to TS, I can't believe how
popular TS is.

It seems like something that only exists due to the popularity of Angular,
where I can only assume the experience is significantly better than with
React.

The type system is frankly disappointing, and the errors the compiler spits
out at you (besides the most obvious ones) are almost always useless or
gibberish and at times even more harmful than helpful.

It's better than nothing I guess, but I can't help but feel extremely
underwhelmed with it given how many people use it. Are all of the people in
this thread Angular developers or something?

~~~
FlorianRappl
I can believe how popular TS is and it is super useful. I would not write a
React application of any noticeable size without TS (and just FYI I would
never willingly write an Angular app). The reason that I get far superior code
completion and meaningful warnings / errors is sufficient to add a few
annotations here and there.

Many people are doing TS wrong. They add types everywhere. Honestly, you
should write as many types as necessary, but not more. Use type inference
which works remarkably well.

~~~
h1d
At least add them on function return types and annotate types on common
objects so that you don't have objects lingering with wrong property name/type
or redundant properties that would be confusing to review.

It helps to create a type reference for your database schema, so you don't try
to insert something weird or insert with missing columns.

------
leetbulb
> But that's what we engineers do: we make interesting compromises that
> attempt to balance different concerns.

I like this :)

------
Tade0
After a few years with both TS and JS my verdict is that TypeScript definitely
_helps_ , but mostly with type-related bugs - with proper testing you don't
get many of those.

What I would like to have in TS is a more expressive type system - the current
is somewhat basic(e.g. you can't have a Symbol as a dictionary key -
interesting given that it's possible in JS. Also you can't mix dictionary
fields with regular ones in one class/interface).

EDIT: typo.

~~~
jeremyjh
The point of type checking isn't so much to prevent bugs in production, but to
speed up your development loop by catching many errors before you've even
saved your file. Its much faster to see a red squiggly right after you've
written a line of code, and fix it, rather than figure out whats gone wrong 10
minutes later looking at a stack trace in your test suite.

~~~
askmike
Doesn't this 100% on your personal develop workflow? I for one have been
forced to use typescript in the past, and am personally very happy that I
don't have to anymore.

------
suzzer99
Google Maps definitely made JavaScript cool at a time when it was not much in
favor - people still thought Java Applets or Flash were going to rule the web.

------
chrisco255
I wish they would make a JS/TS-based version of the Closure compiler. I
suspect a lot of apps would benefit from the compilation and we'd see much
smaller bundle sizes. But the Java dependency is a burden to bear.

~~~
zdragnar
Isn't there already one? I seem to recall that it mostly works, just much more
slowly than the java version

Edit: here you go: [https://www.npmjs.com/package/google-closure-
compiler](https://www.npmjs.com/package/google-closure-compiler)

~~~
chrisco255
Nice! Didn't realize this was a thing. I suspect they could make even more
aggressive optimizations if they made a TS version.

~~~
evmar
This idea is probably worth a post of its own. I believe that because
TypeScript's type system is effectively advisory rather than guaranteed
('unsound'), you cannot rely on it for optimization unless you're willing to
unpredictably break programs.

~~~
bcherny
Hey, that’s an interesting thought!

If you go all the way and make it sound with variance annotations, banning
asserts & under specified types, etc. then you end up with a language that
sucks to use in practice.

If you go to the other extreme, you don’t have static types at all.

If different parts of your code are typed to varying degrees, or you use a lot
of unsound types/inferences, maybe there’s a way to assign a confidence score
to every type to indicate how accurate you think it is. Maybe there’s a clever
way to statically compute that score, or you can instrument some % of prod
traffic at runtime to observe types with lower confidence (Node has this, or
see MonkeyType or Reticulated Python). Then take that info and feed it into
Closure compiler.

~~~
wwwigham
> If you go all the way and make it sound with variance annotations

Variance annotations aren't quite what would make the language (in strict
mode) sound. Specifically, what makes it unsound is the `any` type (generally)
and the lack of enforced variance on methods, non-function properties, and
index signatures. It doesn't need annotations to determine variance - type
parameter variance can be inferred from where in a type a type parameter is
used. It already does so for functions (that's the strict flag's
strictFunctionTypes subflag). The real issue is that far, far too many people
rely on, eg, unsound array assignments (array aughta be invariant over what it
contains but it's often treated covariantly), for it to be reasonable to be a
default. However it could always be changed (or added) in the future - that's
what the strictness flags are for, ideally; providing ways to ratchet up the
safety such that it won't permanently break longtime users of the language.

~~~
evmar
As far as I understand it, every sound language eventually has to fall back to
runtime checks to maintain soundness in tricky cases. For array covariance I
know that Java/Dart eventually use runtime checks on array accesses to verify
the types work out.

However, it's kind of against the spirit of TypeScript to insert runtime
checks. For example because the type system models 'undefined', to model out
of bounds array accesses you'd either need to make every array access have
type T|undefined or insert bounds checks that throw. (I believe Dart does the
latter.)

------
Karupan
I love typescript as a JavaScript developer, but having used go for personal
projects, I find the type system complex (maybe necessarily so). Having said
that, I cannot thank TS enough for how it’s made life easier when working on
and refactoring large codebases.

~~~
smt88
I don't know what you find complex about the type system, but I actually find
it slightly limiting. They keep improving it, so it can express about 95% of
what I want, but I still hit situations where I can't tell the compiler
everything.

~~~
bcherny
What sorts of things do you have trouble expressing with the type system?

~~~
smt88
I can't think of something off the top of my head, but it's usually related to
generics. I'll type something that makes sense, but the compiler doesn't like
it.

Another issue is that handling of string literals as types can be wonky when
they're being compared against the type "string", which they should always
satisfy but sometimes don't.

~~~
bcherny
I’d love to see examples for those, maybe drop a comment when you run across a
specific issue.

------
jpswade
I think the most fascinating thing here is that Google are turning to a
language developed and maintained by Microsoft.

~~~
h1d
It's come to a time that discriminating MS was an old thing.

~~~
jpswade
Or maybe it's about Microsoft's continued influence, especially in the Open
Source community.

------
neop1x
Web shouldn't end up this way. Web was designed for sharing documents. Webs
and webapps now are sluggish and take soooo much RAM. I have a pretty fast
computer with 16GB RAM but running all these webapps with Megabytes of
javascript is bringing back -5years experience and can fill up my RAM. I know
it is still improving but webapp developers are also quick with abusing every
performance gain often for unwanted and unneded functionality. For example CSS
animations for every mouse over, material clicking highlights are terrible,
terrible design decisions which occassionally even spin up my laptop fan.

------
cribbles
> Gmail engineers had to worry so much about Internet Explorer's poor garbage
> collection algorithm that they'd need to manually hoist string literals out
> of for loops to avoid GC pauses.

What does this mean in practice? I know about variable hoisting and function
scoping, but not about old JS GC algos.

~~~
MBCook
My read was that Internet Explorer couldn’t realize that a string variable
could be reused over and over so each iteration of the loop it was allocating
a new one, using it, and then garbage collecting it. Basically tons of
unnecessary overhead.

Having the programmer define a variable before the loop and then reuse it each
iteration meant that all that allocation and garbage collection wasn’t
necessary during the passes of the loop.

~~~
evmar
That is exactly right.

------
aggre
I switched from Flow to TypeScript. Flow has some type-declared libraries, but
it's fewer than TypeScript type-declared libraries. The excellence of VSCode
also helps me.

------
willy8
> it's likely if you use Google products you've interacted with some
> TypeScript code

Transpiled Typescript code I expect, so?

------
martzcodes
So... I love Typescript, but...

"Because TypeScript already mostly works — that's part of the reason to adopt
it"... c'mon

------
lexy0202
I'm still reluctant to use TypeScript given that it has a serious type
narrowing bug that is two years old! You'd think Microsoft could have sorted
this out by now.

[https://github.com/Microsoft/TypeScript/issues/9998](https://github.com/Microsoft/TypeScript/issues/9998)

------
sheeshkebab
What js in browser is missing is something that golang provided on the server
- fast, simple (and more standard) way of writing and executing code,
including large code bases.

Typesafety is a small part of it and I’m not sure whether switching or
choosing entire dev tooling based on just that is worth it. Just structure
your code better and use react prop types and most of type issues go away, in
react code bases.

~~~
KeitIG
Prop-types is for runtime, TS does static type checking. Prop-types are
terribly verbose and only work with React (what about utils files, external
libraries, etc?).

------
eksemplar
I always wonder why people think typescript is a fix for bad code.

We primarily do JavaScript, and I see no issues with it when you set up
governance in how to use it.

I don’t think building your own libraries is really a bad thing either, in
fact I think you should do so often instead of relying on 3rd party packages
of quality you typically judge on how many times they’ve been downloaded if
you’re being honest.

I think typescript is silly. It works with legacy code, sure, but if you’re
refactoring you might as well rewrite your JS or if you’re compiling to JS you
might as well chose Dart which is vastly superior to typescript.

I don’t really see type safety as an issue. I can’t remember when it was a
problem for us, and we operate millions of lines of code, but they are all
written with governance. Want a number? Then call your argument numWhatever
and check your input. It’s really as easy as that.

I mean, sure type checks will prevent shitty code from compiling, but really,
just don’t write shitty code. I know that sounds silly to some people, but 95%
of what you write is about shifting data around through simple mechanics, it
really shouldn’t be so hard to do it right.

You won’t see an engineer go “oops that support beam in your building wasn’t
right, my bad” and programmers really shouldn’t get that luxury either. If
they write shitty code then figure out why, maybe they need more time, maybe
they need training, maybe they need governance or maybe they need to be
replaced.

But hey, feel free to fix your shitty code with code that’s only less shitty
because your compiler protects you. Just know that typescript comes with a
different set of risks, once you need your JS codebase to move forward in a
way that isn’t supported by JS.

~~~
ketralnis
> fix your shitty code with code that’s only less shitty because your compiler
> protects you

I mean... Yes? That's exactly what it's for. That's all it's for. That's all I
want out of it, and that's what it does. I'm not really sure what you're
railing against here.

~~~
eksemplar
My point is that I don’t think it fixes your shitty code.

Especially not if you’re not converting your entire project to typescript, and
if you’re converting the entirety of it, then why not use a better language?

I think typescript is popular because it’s very java/c# like and I think it’s
dangerous because it allows you to write bits of your program with the safety
it provides and other bits without it.

So you’ll have programmers thinking they are safe, when they are really not.

~~~
smt88
TypeScript has structural (not nominal) typing, which makes it very different
from Java/C# in practice.

Also, it doesn't fix shitty code. It just lets the compiler warn you when
you're either making a mistake or misunderstanding some other part of your
code base.

You should really try it before you say it doesn't help.

