
Every new web app at PayPal starts with TypeScript - munchor
https://medium.com/paypal-engineering/why-every-new-web-app-at-paypal-starts-with-typescript-9d1acc07c839
======
rococode
Here's my strongest argument in favor of type safety: if you're building a
project that is intended to have a long life and be seen by many people, type
safety _may_ be a hassle for you but it'll be a blessing for the hundreds of
people who will have to eventually figure out your code.

~~~
maxyme
My team has recently focused on adding JSDoc to most of our codebase and I've
been thinking, JSDoc provides essentially all the benefits (and more) of
typescript from a maintainability aspect and contains none of the headaches
(outdated definitely typed definitions, fighting with types...). As long as
you use something to validate the JSDoc comments (like the JSDoc eslint
plugin) they are extremely helpful in ways very similar to typescript.
Language Servers like that in VSCode (tsserver) will inherit types from JSDoc
comments and provide useful annotations with both the types and descriptions.
They can even be used to show code examples or statically generated into
webpages.

If your only argument is to use typescript for maintainability reasons doesn't
using JSDoc extensively both solve and improve upon that goal?

~~~
alangpierce
I guess depends on exactly how you use JSDoc, but it sounds like you're
talking about relatively informal documentation with some best-effort machine
validation. My experience is that you don't get anywhere close to the
confidence that you get with a real typechecker. Docs can be overlooked, docs
can be misinterpreted, docs can get out of date, docs can be wrong by mistake.
And, inevitably, if you have many people working with the same code over the
course of years, these issues will be common. Having an actual typechecker
avoids all of these problems, at least for documentation of data formats.

If you do mean annotating all types with the thoroughness that you'd annotate
TypeScript code, then really you're just writing TypeScript in JS, and
TypeScript is a much more concise language than JSDoc for that.

------
alangpierce
Note that it's possible to use both TSLint and ESLint in the same project, and
that's what I've been doing for nontrivial projects. ESLint has a big
community and a lot of nice rules, but there are a few things that ESLint
can't (yet) do and that aren't implemented by TS itself:

* The TSLint no-unbound-method rule is really helpful for avoiding the React bug of passing `this.handleClick` at render time without it being a bound method. This is one of the "needs type info" rules that uses the type analysis from the TS compiler, and generally these sorts of rules are much more powerful than what you can normally get in ESLint.

* The TSLint ordered-imports rule with autofixing is a much nicer way to force import ordering than anything I've seen in ESLint. (ESLint sort-imports won't reorder your imports, for example.)

But as mentioned, the TS team has said that they want ESLint to be the future
for TypeScript linting, so hopefully ESLint will get all of that soon enough.

~~~
conover
We use both at Twitch, on a codebase approaching 7-digit lines of non-
generated code. It’s worked out well for us.

------
starefossen
My biggest grape with staticly typed languages like TypeScript is that many
developers considers type safety a replacement for test - it is not. It is
completely at best.

~~~
aportnoy
Heh, did you mean gripe?

~~~
cozuya
I read his post as less of a critique of the linked article and more of a
wine.

------
keymone
Static typing doesn’t reduce bug density, this is no news, just a risk
compensation principle at work.

But there’s another factor: static typing creates a nice puzzle for you to
solve instead of solving the actual problem. You solve the puzzle and feel
nice, you show the solution to management later and they feel nice to because
it’s all neat and hierarchical. Then you write majority of the code that
doesn’t neatly fit the puzzle’s constrains, then new feature
requests/requirements come in and after a time the puzzle needs to be solved
again. And so the wheel turns.

What people usually mean when they talk about static typing is a language to
specify promises and requirements. To my knowledge that language has not yet
been successfully reduced to mostly static and rigid annotations that are
useful in dealing with changes to the software itself.

~~~
zbentley
I've heard that argument before, but I've never seen that sort of behavior in
practice. If anything, statically typed (or heavily annotated) codebases I've
worked on have been much _more_ amenable to change when it comes to adapting
to "code that doesn’t neatly fit the puzzle’s constraints" as you say. The
refactoring tooling and assurances provided by the type system tended to make
people more willing to start rethinking their "puzzle" (type design) earlier
in the process, rather than doubling down on a flawed model.

I've seen people do similarly great work in highly dynamic languages, too, so
this isn't a "static > dynamic types" statement; just an anecdote in contrary
to your claim.

~~~
keymone
The puzzle is not some inherent problem within the one you’re actually
solving, it only arises because of limitations of any type system you choose
to work with.

~~~
zbentley
I don't think that's true. But even if I did, it doesn't address my point
above that, in return for having to solve the "puzzle", programmers in more
strongly-typed languages gain numerous other advantages.

~~~
keymone
> in return for having to solve the "puzzle", programmers in more strongly-
> typed languages gain numerous other advantages

advantages and disadvantages. and solution to the puzzle is almost always
wrong or becomes outdated and requires major rethinkings often.

------
russellbeattie
This thread is going to quickly devolve into the pro-type safety vs. the pro-
flexibility camps. Look, if you looooove declaring types and somehow thinks
this reduces bugs, great. If you just want to focus on the logic of your app
and don't feel like managing the minutia of how the computer stores a number
or string, great.

But if you want to declare one is fundamentally or empirically better, then
you need to get a grip. We can all like different things, it's allowed.

The one core thing I'd like to stress, however, is that TS is not JS. If you
use TypeScript, you are not using JavaScript. They are cousins, sure, or maybe
uncle and niece, but they are not the same.

~~~
jchw
>Look, if you looooove declaring types and somehow thinks this reduces bugs,
great.

I'm speechless. Do you believe type checking doesn't catch bugs? Because
that's what it sounds like you're implying.

>But if you want to declare one is fundamentally or empirically better, then
you need to get a grip. We can all like different things, it's allowed.

This is a ridiculous argument. People make such declarations because they
believe them to be true. You're basically saying, "You're insane if you
disagree with me that one is not fundamentally better than the other."

>The one core thing I'd like to stress, however, is that TS is not JS. If you
use TypeScript, you are not using JavaScript. They are cousins, sure, or maybe
uncle and niece, but they are not the same.

I don't see why this would stop anyone from using TypeScript. Why should we
care?

(Also: When people say 'TypeScript is just JavaScript,' it's not because
they're crazy. It is just saying something else. TypeScript _is_ a strict
superset of JavaScript that is compatible and compiles down trivially, which
is in contrast to CoffeeScript for example, which was previously popular.
Nobody was ever claiming that TypeScript triple equals JavaScript.)

...

You start off by implying that type-checking is ineffective (' _[somehow
think]_ this reduces bugs') then call for people to not engage in flame
wars... what did you expect to happen?!

------
herbst
The title alone makes a good reason to further ignore typescript. If i should
name a single major product that has the most horrible UI/UX it would be
PayPal.

~~~
femiagbabiaka
What does UI or UX have to do with language choice?

~~~
0xFACEFEED
Good UIs usually undergo rapid and extreme changes over very short periods of
time. The choice of language could make it difficult or time consuming.

~~~
danielhlockard
It doesn't in this case.

~~~
0xFACEFEED
Sure it does. We often have designers jumping in and programming UI code
themselves. Teaching them all about type systems would be very time consuming.

~~~
chess_buster
As consumers of a library? Quick, what kind of object can I use this function
with?

function computeAge(birthday: Date): int;

------
jondubois
>> What took took me so long?

It took a while for all of Microsoft's marketing to kick in and for the
mindless hypewagon to reach full speed.

I have decades of experience with Typed ECMAScript (first with ActionScript 3
from 2006 and then TypeScript). It's not worth it. Productivity will drop
enormously and bug density will not change at all.

~~~
simion314
My personal experience is that AS3 was a better experience over JS and Flex4
was a pleasure to work over the JS frameworks and CSS mess.

~~~
Matthias247
Overall AS3 with Flex felt great, and I used it for one of the funnest
projects I've ever worked on (prototyping for a new GUI system).

The inbuilt widgets functionalities were great, with things like skinning
functionality and the ability to place shaders on widgets right on your
fingertip. States were easy to model. I think it took Javascript years to
catch up, and while now some of the modern frameworks (React, Angular, Vue)
might be ahead in lots of regards, they might still be behind in others.

Actionscript itself had a pretty weak type system compared to what Typescript
can do now (or could do years ago). E.g. there were no generics, apart from
the some kind of semimagical vector. So this one is the smaller loss.

~~~
simion314
I agree, my point was not that AS3 > TS , my point was that AS3 > JS still and
AS3 is old and it had no improvements in years. The GUI part is still behind
though, you still can't CSS the scrollbars and you need a JS library, you
can't CSS the select options and you need a library to create a better
dropdown, you have no built-in or a standard set of Widgets simlar to the
DataGrid or AdvancedDataGrid, working on some old projects CSS drives me crazy

