
Problems with TypeScript - BarelyLit
https://blog.logrocket.com/is-typescript-worth-it/
======
sethc2
IMO, Yes (usually).

Let me elaborate.

If you are starting a new project, yes use typescript over JS. And configure
it with all strict options.

This doesn't magically give you well architected and well-tested code, it
still takes a good engineer to do that. But what it does allow is for the
engineer to refactor the code to support new functionality with more speed and
confidence, rather than shoehorning it in in fear of breaking something or it
taking too long. Furthermore, as people join your team, it will be a lot
easier for them to figure out where some piece of data is coming from and how
the code flows from one spot to the next.

If you have a massive JS project and you want to convert it to typescript. The
answer _might_ be no. Oftentimes when people port a JS project to TS, they end
up using non strict typescript, and you get the syntactic overhead of writing
TS, without really any benefit because nearly everything is any typed. If your
only concern is a better codebase, and it doesn't matter how long it takes,
then sure it is worth it, but we all know that is never our only concern. It
still might be worth it, but I can almost guarantee you from experience, you
will still end up with TypeErrors in your console at some point, because
people will have just any typed things.

Also if you're writing a tiny node script in a single file, to do some simple
operation, then no it is probably not worth setting up a command to compile it
and a tsconfig to configure it. Unless it is doing multiple things, and/or
someone else in the future will have to use it, then it is probably still
worth it.

~~~
sethc2
Oh one other potential drawback.

Typescripts inferred types, can do some crazy things, and can be very
powerful. This to me is really fun, but has definitely caused me when I first
started using it to get lost in having fun doing crazy things, to ensure my
strings were exactly some set of values depending on what some other value
was, when a simple unit test and a simple "string" type, would've been a lot
quicker and less confusing.

~~~
samhh
If the strings are static you can define a type that's a union of string
literals, create a tuple containing them all, and then a type guard function
that simply checks the argument against the array. If the strings are dynamic
then you're better off looking at a library like newtype-ts, but it's not very
ergonomic compared to the likes of Haskell/PureScript so use sparingly.

~~~
no_wizard
Why not just use an Enum? It will only accept the values of that enum.

[https://www.typescriptlang.org/docs/handbook/enums.html#enum...](https://www.typescriptlang.org/docs/handbook/enums.html#enums)

[https://www.typescriptlang.org/play/index.html?useDefineForC...](https://www.typescriptlang.org/play/index.html?useDefineForClassFields=true&preserveConstEnums=true#code/KYOwrgtgBAsgngZQC4CcCWIDmBnKBvAWACgpSoAxAeUqgF4oAiAIwEMUGAaYsqAIQEEASnUYAzAPbjO3MlUoDh9BhPGt2xAL7FiosCADGSNOJBQTAGzgBRcBH4pMACgBuLcwC5YiVBhwBKfBlSfRNscXNgADpzcScGJAALNFwAdzRzczMQSygkFgBrYCyi8VFchKLCuFxRFHFoeGR0LGwGPwBuIKgQkDCI6NiXNzpaekafFsiFDs1tIgtrW3s4xOSoNIyoJiKWU2AUOvYZ+ezFyGXHceacKaEAgHpHqAAVJNw1kHEkKF2ofcOgA)

~~~
untog
Just my personal preference but using these string union types means that you
don’t have to import the enum. Plus it’s less verbose and translates back to
JS better than an enum does.

Really just a matter of preference though.

------
sli
TypeScript feels worth it until you use something like Elm, then you realize
just how lacking and TypeScript's type system truly is.

I have grown rather weary of type systems that don't require you to be
exhaustive and, for my money, types like `Omit` and `Pick` are nasty hacks
that just let you pretend like you aren't doing dynamic types, something
TypeScript does a lot. The TypeScript pattern of `someFunc<typeof someInput>`
is just dynamic types with extra steps. Using `any` wouldn't really lose you
much of anything, the "type" is just "whatever this input is". That's not a
real type, that's a dolled-up dynamic type. But hey, it typechecks!

TypeScript's major weakness is that it doesn't want to break away from
Javascript. That strict dedication to being a superset means the type system
explodes into ten thousand builtin types the come, seemingly at times, from
nowhere, simply to control for the wildness of Javascript. It feels like a
joke sometimes, and like I need to have encyclopedic knowledge of all these
highly-specialized types that are included in the language and are often being
used in the background.

This leads to nearly impenetrable error messages regarding types, especially
if you have a stack trace involving more than one object/record type (whatever
you want to call it), it will expand all of them and just, no. It's
unreadable. It can be read, but it cannot simply be _grokked._

TypeScript just doesn't impress me. I get far better results from other
languages for a whole lot less work. TypeScript claims to want a balance
between correctness and productivity but the language gives me neither of
those things. My typical experience is that I wrote almost the same amount of
actual code, but now also with types. Elm lets me write _far less total code._
Less code means less bugs and more productivity, and better types and better
correctness is what gives you those things.

~~~
preommr
A big problem is that elm has questionable stability as a project. It's mainly
one person, and not a lot of mainstream usage. The biggest projects mentioning
elm are ones related to the main programmer.

Typescript on the other hand has had massive growth and has been adopted by a
large amount of libraries. Now, web ts/js libraries usually suck but it still
speaks to the overall health of the language in a community. Even then,
typescript still only has a very small percentage of usage.

Elm is basically a rounding error on some of the surveys I've seen.

Long term support, tooling, etc are often much more important for languages
past a threshold. Typescript as a language may not be super exciting.
Typescript as a technology is wonderful.

~~~
salimmadjd
I was an early enthusiast of Elm.

Sadly, Elm was never able to build a true core development team outside of
Evan. Or at lest it didn’t do it fast enough.

Evan is a smart programmer but not a strategic organizer or a communicator.

As a result, one of the most exciting and promising approaches to front end
development was relegated to a nice-toy project status.

If you want to take the risk of building something using Elm’s approach,
you’ll do it with Reason. Maybe not 100% as nice as Elm, but you’ll feel
confident you’re not risking your code base and company on the whims of one
person.

I still think Elm is a nice educational language for getting people (and kids)
into FP.

------
valand
Guaranteed almost 100% type soundness!!! Non TypeScript user will hate this.

Config it to maximum strictness!

Add in runtime type checks Parse, don't validate [https://lexi-
lambda.github.io/blog/2019/11/05/parse-don-t-va...](https://lexi-
lambda.github.io/blog/2019/11/05/parse-don-t-validate/)

Bring type to business logic, e.g.

RegisteredUser { userId: number, email: string }

AnonymousUser { userId: number, email: null }

User = RegisteredUser | AnonymousUser

Handle errors ala Rust,

Return errors/errortype rather than throws

Utilize structure to determine result, e.g.

Failure { error: Error, value: null }

Success<T> { error: null, value: T }

It is worth it. My experience with TypeScript is a whole lot different.

Conspiracy theory inducing facts:

\- LogRocket's main use is monitoring bugs in browser application

\- Airbnb is LogRocket's customer

~~~
dkdbejwi383
I'm interested in the way you describe handling errors here. Do you have any
real world examples you can point me to? Thanks

~~~
valand
I would have gladly shown it to you, but almost all my code is proprietary

Here's a small example:

```

function fetchCurrentWeather(){ return fetch(...) .catch(() => ({ error: new
NetworkError(), value: null}) .then(res => res.json()) .then(maybeWeather =>
Weather.is(maybeWeather) ? { value: maybeWeather, error: null} : { error: new
DecodeError(), value: null}) .catch(() => ({ error: new DecodeError(), value:
null})) }

// And then you use it somewhere in you react app

async initialFetch(){ try { if (this.state.isLoading) return; this.setState({
isLoading: true, weather: null, error: null }); this.setState({ weather: await
fetchCurrentWeather().then(reault => { if (result.error) throw result.error;
return result.value; }) }); } catch (error) { this.setState({ error }) }
finally { this.setState({ isLoading: false }); } }

render(){ return ( <div> {this.state.isLoading && ...} {this.state.weather &&
...} {this.state.error && ...} </div> ) }

```

~~~
pdyck
Why is this better than throwing errors or using Promise.resolve()?

I know it is inefficient because creating a new error with a stack trace each
time is bad for performance. However, you can also throw errors which do not
extend Error to avoid this. Destructuring the output and explicitly checking
for errors every time seems to be quite the hassle.

~~~
JamesSwift
Because the error/success is encoded in the type, you are forced to handle the
error case. If you aren't also wrapping throwable functions in `try/catch`
then you have a lot of unhandled error cases.

If you know that something truly isn't going to error then you can just force
cast it as `foo as Success<T>`. That will still blow up at runtime if its not
a `Success`.

Alternatively, you could introduce a monadic chaining that is able to pipe
`Result<T>` objects through many functions then handle at the end.

------
adrusi
Mentioned as an afterthought at the end: IDE support for typescript, the best
part about using the language.

Not mentioned: type annotations serve as a form of documentation that gets
statically verified. The verification strategy has some cracks, and there's a
(fairly small) chance that the documentation will end up misleading. But API
documentation for javascript projects generally sucks, and typescript helps to
fill a lot of the common gaps.

~~~
nocommentx
i'm tired of devs that claim that TS and GraphQL are "self-documenting" and
don't need to write any documentation. it doesn't fill in the common gaps,
it's just an excuse to not have to think about or talk to users.

~~~
paulcowan1970
I'm the author and the claims that Graphql and typescript replace
documentation is madness

~~~
LaGrange
...good thing that there's pretty much no one making them, then.

There's plenty of people saying that it effectively augments documentation,
and provides a form of it that's quite useful.

------
nikolasburk
While TypeScript isn't perfect, it surely is a major step forward compared to
plain JS! Newer features like conditional types and mapped types open up new
possibilities. My colleague actually recently gave a fantastic talk about
these advanced features at the TS Berlin Meetup, highly recommended watch if
you want to see what it's like pushing the boundaries of TypeScript:
[https://www.youtube.com/watch?v=PJjeHzvi_VQ](https://www.youtube.com/watch?v=PJjeHzvi_VQ)

~~~
vorticalbox
Still compiles Down to js where you lose all type checking.

Have you ever looked at a compiled js file? Things like spreading objects I to
each other

{...a,...b}

End up being a nest object assign which is actually slower than spreading.

~~~
mixedCase
Checks don't need to be in the JS, they just need to be there at compile time.
No differently than a binary generated by Haskell; and you have source maps to
replace debugging symbols too.

And as mentioned by another user, you can choose your compile target to a
specific version of JS which does support object spreading.

~~~
hopia
Actually, Haskell compilation produces more type information available at
runtime than Typescript's compiler does. For example, algebraic data types
turn into tagged unions at runtime on Haskell, allowing pattern matching to
operate on them.

Whereas on Typescript the compilation process erases all this information,
making it impossible to evaluate many such expressions.

There are multiple 3rd party solutions to this, such as:
[https://github.com/pelotom/runtypes](https://github.com/pelotom/runtypes)

~~~
mixedCase
> algebraic data types turn into tagged unions at runtime on Haskell

How does that work? I know next to nothing about the GHC, but in Haskell I
would assume some tag is associated with each constructor (probably an
integer) for the ADT and that the actual pattern matching gets compiled down
to simple comparisons to either that integer or the right function for the
more complex cases (pattern matching strings and other values).

TypeScript essentially does that, except that the tags are not going to be
optimized by the compiler (they will remain strings if the dev uses them), and
the "pattern matching" is just regular conditional checks (if, ternary or
switch) with even the exhaustiveness check being done as a manual hack
introduced by the dev and checked at compile-time (the else or default case
assigning the value to the never type).

As for runtime values, Haskell also needs to validate types when
deserializing, although that will be done by the deserialization libraries
such as Aeson instead of deserializing and _then_ optionally validating like
in TS.

~~~
hopia
Yes, you're right, it should be an integer comparison check ultimately.

> TypeScript essentially does that, except that the tags are not going to be
> optimized by the compiler

What do you mean by this? Typescript erases type information during
compilation. So you would not be able to emulate pattern matching against
types on TS. Or you could if you manually added some common tag to every
single data type like interface.

Or are you talking about just compile-time type checking on TS?

~~~
mixedCase
> Or you could if you manually added some common tag to every single data type
> like interface.

This is how you emulate them, I took it for granted and neglected to
explicitly mention this is a moderately popular convention in TypeScript
(those are the tags I referred to). fp-ts for example uses it all over the
place.

With this the end result is essentially the same with compile-time type-safety
for everything, and compiled down to an untyped binary or an untyped JS blob.

------
Androider
The type of problem that TypeScript solves is not the type of problem that I
have.

In my 15 years of engineering, exceedingly rare is the case where the
underlying cause is due to using wrong types. I could count the number of
times types has been problem on one hand. Instead, almost all issues are due
to logic errors and missing or poorly understood business requirements.

For me, the time spent resolving TypeScript specific issues (missing type
definitions, lack of support in third party libraries, general finickiness
etc.) does not make it a worthwhile investment. I also did Scala for several
years professionally, and while it instils rigor, I feel much the same that
the price you pay isn't remotely worth the benefit you get. Conversely, I
think one of the best investments you can possible make into tooling is to
reduce the edit-compile-view cycle time, and you should aim for seconds at the
most if not instantaneous updates. That speed of iteration will pay dividends.

~~~
Rapzid
It's a charmed life where one hasn't had to spend countless hours helping
other people track down "undefined is not a function" errors :|

~~~
jammygit
I did that a lot at my last job and found that the debugging was pretty quick.
There’s always some race condition from some asynchronous function somebody
called without waiting for the callback. Does TS help with that?

~~~
amatecha
if something can be returned as undefined instead of a function, then yes, you
are forced to either write code to handle the undefined value, or modify your
logic so the returned value can only be a function :)

------
why-oh-why
Instead of focusing on what TS does not, focus on what it does.

TypeScript is not sound; JavaScript isn’t either. The first one will catch
some type errors, the second will catch none.

Syntax highlighting, linting, testing, and now type checking: every step can
make you more confident about the code you ship, before it even hits the
browser.

You can forgo using any help and probably you’ll code faster, but, again, you
lose confidence.

~~~
lucisferre
Tests are the only thing that give me confidence about any code I write,
Javascript or otherwise.

~~~
jsight
And compilers are effectively a rudimentary form of test. They are not
sufficient, nor necessary but they do validate some basic assumptions about
the code.

~~~
thrower123
If for no other reason, I would like Typescript for flagging when you typo
some property - e.g. foo.FooID vs foo.FooId.

I've lost a stupid amount of time in regular JS because of things like this
that make me want to pick up the computer and throw it out the window.

~~~
valand
Decent editor does that now. I'm using atom on daily basis and it's helping me
with that. VScode and intellij does the same

~~~
dragonwriter
Doesn't the functionality for that in most editors leverage typescript
typings, so that it's not really independent of typescript?

~~~
valand
Ah I misread the parent comment. I thought it was more like "I wish typescript
has this anti-typo functionality"

You're right that it's not independent from TS.

------
alkonaut
Doesn't typescript enable things like renaming an identifier and all it's
usages, without doing it as a global text replace, or worrying that you might
have renamed something you shoudldn't? Or is the type checking so "leaky" in a
typical project that that kind of luxury (That would be done every day by Java
or C# developers etc) isn't really available anyway?

Unless it's a massive overhead to use typescript, autocomplete, renaming etc
seems like they would make it worth it on their own.

~~~
scrollaway
I use what you describe on a regular basis in typescript without issues
indeed.

------
gandalfgeek
There has been some research done on how programmers interpret gradual typing
systems, and it turns out that it breaks many expectations and ends up being
confusing.

Explainer video:
[https://www.youtube.com/watch?v=iRf9l3Bz7nA](https://www.youtube.com/watch?v=iRf9l3Bz7nA)

Original paper:
[https://cs.brown.edu/~sk/Publications/Papers/Published/tgpk-...](https://cs.brown.edu/~sk/Publications/Papers/Published/tgpk-
beh-grad-types-user-study/paper.pdf)

~~~
mcbits
Note that the paper is concerned with run-time type checking and glosses over
the fact that most/all of those code samples in the survey would be rejected
at compile time by a static type checker (or at least by TypeScript).

Their conclusion that "erasure" is disliked and unexpected is effectively
saying the underlying dynamic language's behavior is disliked and unexpected.

Of course it's possible to deliberately or accidentally coerce TypeScript into
violating its type constraints and behaving in JavaScript's disliked and
unexpected ways, but the survey questions would have to be substantially
different, and likely the responses as well.

------
proc0
The soundness of the type system is not a valid criticism given that it's
aiming at improving a language that had almost no type system at all. If you
need more from your types then perhaps TS or JS is not the right choice here.

------
no_wizard
My take away from this: If you don't have the discipline on your team to
enforce good structural standards for your code, TypeScript may not help as
much as you think.

In my very much opinionated opinion, all the issues highlighted in this
article, are avoidable with:

1\. Don't use the `any` type (I'm actually pretty shocked this article doesn't
talk about using `unknown` instead of `any`. I have found `unknown` can be
used where `any` tends to be used, most of the time, if not all the time, and
it comes with the benefits of things like assertion control & tsc's type
interference (it acts almost as a marker, in some ways, basically, for the
type that gets fed through. It also forces you to think about validating the
input)

2\. Enforcement of strict options for the compiler

A non-goal to me is using TypeScript to avoid writing tests. This should never
be someone's idea in adopting any typed language. I think this is a smell of a
bigger problem. Types or no types, it does not influence why or how many tests
I write, as testing is about validating your programs ability to handle its
inputs & the correctness of its outputs (your testing algorithms, at the end
of the day), so I do not see how this factors testing at all. Types also do
not negate the fact you need to do validation (beyond perhaps, trivial
validation of arguments at the call site, if your codebase is actually
following good structural patterns)

Is TypeScript perfect? No.

Should you use it? I think you should probably make that decision after a
careful reading of the documentation & discussing it with your team.

Do I personally think this article has a strong case against TypeScript? No,
as its (to me) very trivial to avoid any of these problems.

You know what would likely be more effective with most code bases I've seen
though? Good documentation & comments, with explanations of what things do if
it isn't obvious enough to pick up in a second or less glance. Preferably
following the JSDoc standard.

~~~
frenchyatwork
> Don't use the `any` type

The problem here is two-fold:

1\. Culture and existing code. Popular libraries use any when they should be
using unknown or just not de-serializing stuff and making you explicity parse
it yourself. The reason why these are popular is because culture and because
of #2.

2\. Creating type guards is a pain, especially if you're trying to go from
unknown to something with a complex structure. If types were something you
could reflect on in run time, like most other interpreted languages, this
would be a lot easier.

~~~
no_wizard
To address culture, someone has to start doing it better, no reason it can't
be those who know there is a better way, so I treat that as a red herring
myself. You could always make a strongly typed wrapper around a library, for
instance.

Creating type guards might be a pain, sure. I think assertion functions will
go a long way in this regard

[https://www.typescriptlang.org/docs/handbook/release-
notes/t...](https://www.typescriptlang.org/docs/handbook/release-
notes/typescript-3-7.html#assertion-functions)

I also think that its an overestimated pain. If you are using interfaces to
type your objects (commonly, this seems to be the pain point) then I don't
think its terribly difficult to construct type guards around that.

There is also the reflect-metadata polyfill (that I think TC39 is eventually
going to make a standard) for run time type information. Using decorators
could be valuable combined with `emitDecoratorMetadata` option

[https://rbuckton.github.io/reflect-
metadata/](https://rbuckton.github.io/reflect-metadata/)

------
swyx
the title completely doesnt match the content, this is pure clickbait and
logrocket is so shameless about it. i grit my teeth and click but am
completely unsurprised at yet another low quality list of arguments that have
been rehashed over and over.

here's a less well known, more rigorous study:
[http://earlbarr.com/publications/typestudy.pdf](http://earlbarr.com/publications/typestudy.pdf)
\- To Type or Not to Type: Quantifying Detectable Bugs in JavaScript

~~~
nocommentx
they mention a time tax of 262 seconds median for TS annotations for their set
of 400 bugs. almost 4.5 minutes. so idk, there seems to be some math missing
in this paper about the actual trade offs. so maybe you get a 15% improvement
in "detectable" bugs found, at a 13.3% time cost (60 minutes /4.5 minutes) per
hour of work. worth it...? are your devs expensive? more expensive than QA.

~~~
eyelidlessness
Types are easier to read, reason about and maintain than tests, particularly
if it's QA writing the tests instead of engineers.

------
erokar
Thing is you can now have many of the benefits of TS without using it in your
own code. Most popular libraries come with type definitions now and an editor
like VS Code will take advantage of this and give you the same autocompletions
TS would.

TS introduces some friction for setting things up, it slows you down in
initial development, increases LoC, etc. I do like the type documentation in
function signatures, the autocompletion and the refactor support, but I think
the project needs to be of a certain size for the cost/benefit trade off
favors TS, typically a project that goes on for 6+ months and with 2 team
members or more. Anything smaller than that and I wouldn't choose it myself.

------
_bxg1
> ...there is an argument that states that the adoption of TypeScript would
> not have been as high if a sound type system is 100% guaranteed. This is
> disproved as the dart language is finally gaining popularity as Flutter is
> now widely used.

In my experience TypeScript's unsoundness is a feature, not a bug. You cannot
compare it to languages that were designed from the ground up to be sound.
JavaScript was fundamentally not designed to be used in a 100% sound way, and
trying to do so introduces an _enormous_ developer burden in terms of idioms
and language features that you can't use, and syntactic hoops you have to jump
through. You find yourself constantly fighting against the language.

I know this because at my company we started with Flow, which is (very
proudly) sound. It was impossible to be productive. For a small example, every
reference to document.body had to have a null-check, even though we could
guarantee by where we placed our <script> tags that the body would never ever
be undefined. The experience was rife with situations like this, which created
tons of cruft and made code harder to read.

"any" is nearly always bad. But the other escape hatches, like casting, have
proven essential to building a reasonable codebase that doesn't try to ignore
the reality of JavaScript.

> Runtime type checking would be beneficial when dealing with JSON payloads
> returned from API calls, for example.

This I agree with, but I don't think it belongs in the core TypeScript
project. We used Flow Runtime with Flow ([https://gajus.github.io/flow-
runtime/](https://gajus.github.io/flow-runtime/)) which creates runtime
assertions automatically based on your static types, on a file-by-file basis.
It was wonderful, and is the only thing I miss about Flow, although it was a
third-party project and there's no reason something similar couldn't be made
for TypeScript. I would be giddy to hear that someone was building one.

------
hanneswidrig
These kind of articles seem to be commonplace and I frankly do not think they
provide any productive value. "any" is supposed to be the escape hatch as
TypeScript is designed to be incremental. Anyone with a semblance of
understanding knows that TypeScript transpiles into regular JavaScript, you
don't run TypeScript code in the browser.

~~~
valand
Friendly tips: you can replace any with unknown. Other friendly tips: runtime
type checks are available [https://github.com/gcanti/io-
ts](https://github.com/gcanti/io-ts)
[https://github.com/pelotom/runtypes](https://github.com/pelotom/runtypes)

~~~
sadlion
Can you please provide more detail when it's best to use runtime type checks?
For webapps with strict TS config, I'm failing to see the advantage. Runtime
errors can occur when crossing boundaries from server API to UI but when you
discover the exceptions, you go fix your contract.

~~~
valand
1st it's easier to identify which contract is inaccurate, or even whether the
contract is inaccurate or not in the first place

2nd it's more convenient for both the end-user and the developers that errors
are handled this way

------
lets-surf
This example from the article looks like an argument for immutability to me.

    
    
        interface A {
            x: number;
        }
        
        let a: A = {x: 3}
        let b: {x: number | string} = a; 
        b.x = "unsound";
        let x: number = a.x; // unsound
        
        a.x.toFixed(0); // WTF is it?

~~~
SpaceNugget
Kind of, you can't have your cake and eat it too.

When it comes to typing systems you have to pick 2: Depth, Mutability,
Soundness

------
snek
Whenever that thing about Airbnb comes up I feel compelled to remind that it
was a study of _eight_ bugs, three of which ts would've prevented.

~~~
swyx
8 bugs? are you sure? did you watch the talk?
[https://www.youtube.com/watch?v=P-J9Eg7hJwE](https://www.youtube.com/watch?v=P-J9Eg7hJwE)

------
luord
"Is Typescript worth it?"

No, but not because the tired diatribe on typing, but because JavaScript
nowadays is mostly good enough... As long as we remember what its goal is and
we don't use it for anything more than its intended purpose.

That aside, everything in that post re soundness vs unsoundness was what I
used to know (and was taught in college) as "strong" and "weak" typing, is the
redefinition recent? Was I taught incorrectly? That aside, C is weakly typed
(and there are long, long discussions on it) but I'll say that, if it's good
enough for C, then being for or against it becomes pretty much subjective
(obligatory IMO, my saying that at all is _also_ subjective).

After all, it's a flamewar that's been going on for decades. Typescript
certainly isn't going to solve it.

~~~
archon-99
The definitions are:

Static: Statically checked by a compiler.

Dynamic: Not Statically checked by a compiler

Strong: Types enforced by the runtime

Weak: Types not enforced by the runtime

Of these,

JavaScript: Dynamic, Weak

TypeScript: Static, Weak

C#: Static, Strong

As to if you think TypeScript is worth it, of course its worth it. Whether or
not you're writing JavaScript or TypeScript, you're still thinking in types,
function signatures and data structures. TypeScript allows you to encode that
information so you don't need to hold it in your head (or have other
programmers figure it from usage, as would be the case for JavaScript). But
that aside, TypeScript's tooling alone makes it worth it.

As for this flame war, i strongly suspect that most type system advocates have
mostly likely used BOTH dynamic and static languages (C#, Java programmers
have had to deal with JavaScript for decades), while I expect the majority of
dynamic advocates (say Python, PHP, JavaScript) have primarily stuck with
dynamic.

Those with the wider perspective have the better insight imo.

~~~
luord
I am aware of those definitions. It was "sound" and "unsound" what threw me
off.

> Whether or not you're writing JavaScript or TypeScript, you're still
> thinking in types, function signatures and data structures. TypeScript
> allows you to encode that information so you don't need to hold it in your
> head

Static vs dynamic, a flamewar that's _over sixty years old_ to which I am
_not_ going to contribute.

> But that aside, TypeScript's tooling alone makes it worth it.

JavaScript has pretty good tooling too.

> As for this flame war, i strongly suspect that most type system advocates
> have mostly likely used BOTH dynamic and static languages (C#, Java
> programmers have had to deal with JavaScript for decades), while I expect
> the majority of dynamic advocates (say Python, PHP, JavaScript) have
> primarily stuck with dynamic.

Should we ask LISP developers? How about its derivates like Clojure or Scheme?
There are many of them here in HN (in fact, I've dabbled on Clojure a little
bit myself), though that would probably lead to a different flamewar entirely
(functional vs oo).

In any case, I don't follow what point you were trying to make writing this
suspicion, it was clear that you were going to get counterexamples and you
didn't provide sources that at least gave support to having such a suspicion.
I would appreciate if you elaborated what was your implication.

By the by, I worked in java during 2013 and 2014, and I've been working with
Go exclusively for nearly a year now. I still don't really care about what
type system any given language I've worked on has, there's good and garbage
code everywhere. Though, since all this can _only_ be opinion until someone
conclusively demonstrates a given type system's superiority, I still prefer
writing python code.

> Those with the wider perspective have the better insight imo.

Maybe we should ask Guido van Rossum's perspective.

~~~
archon-99
> JavaScript has pretty good tooling too.

I believe most of the best in class tooling for JavaScript borrows on
leveraging TypeScript compiler for inference. And its still below the bar
offered by TypeScript.

> Should we ask LISP developers? How about its derivates like Clojure or
> Scheme? There are many of them here in HN (in fact, I've dabbled on Clojure
> a little bit myself), though that would probably lead to a different
> flamewar entirely (functional vs oo).

OOP is not at odds with FP. They are different things entirely and can be
leveraged in equal measure within a codebase. Consider C# and LINQ (with LINQ
derived from lazy expressions in Haskell). As for LISP, TypeScript services as
a good test case for layering dynamic languages with type systems, so why not
TypeLISP?

Anyway, the point im trying to make is, irrespective of if the programmer is
working with a type system or not, the programmer is still reasoning about
software with types. The dynamic language programmer is still thinking about
function signatures (arguments, return types), they are still thinking about
'the properties of some object' and they still think about generic
abstractions (as in .map()). I don't understand why JavaScript programmers are
adverse to encoding that information in a type system when it solidifies and
communicates their intent. (both to other programmers as well as the compiler)

JavaScript on its own requires the programmer to infer the original developers
rationale from usage, and assertions of 'correctness' can only truly be
inferred by running a software (by test or otherwise). Obviously, both TS and
JS need tests, but in the TS case, you've removed a whole class of issues
around types and call signatures, where as in JS, one might be compelled to
test both 'types' and 'logic'. A type system can at least narrow huge classes
of problems, allowing a programmer to focus on testing logic, not the
inadequacies of their (or others) brains to hold mountains of implied type
information in their heads.

If you want one practical example..... refactoring. While JavaScript is
dynamic, just change the name of a function, or move functionality
elsewhere...what assertions can JavaScript or its tooling provide that all
dependent code is appropriately updated as a result of that refactor?

Honestly, choosing to leverage of a type system, imo, is an open admission of
the complexities of software, and the fallibilities of the human brain.
Rejecting the benefits of a type system to me demonstrate a dangerous over-
estimation of one own abilities, or a lack of personal introspection with
respect to reasoning. While this debate seems to continue, I don't think my
views on it ever will.

~~~
lispm
> As for LISP, TypeScript services as a good test case for layering dynamic
> languages with type systems, so why not TypeLISP?

Lisp users think that a 'dynamical' and a 'dynamically typed' language are two
different things. Lisp is both. Being 'dynamically typed' supports or
simplifies a lot of dynamical features.

There are a bunch of languages which implement a subset of Lisp features and
which were adding type systems. Historically much of typed FP was developed
out of Lisp tradition.

Common Lisp for example has CLOS definitions like:

    
    
        (defclass person (living-thing)
          ((name :type string)))
    

So the definition makes clear that are a class/type which inherits from the
class/type living-thing. It also defines that contents of the slot name are of
type string.

A CLOS method then is:

    
    
        (defmethod say ((from person) (to person) (m message))
          ...)
    

Which means that an object of class person sends to another object of class
person an object of class message.

Multi-methods in CLOS allow us to define and dispatch on the class of several
arguments.

Common Lisp then also has type declarations:

    
    
        (defun collide (a b)
          (declare (type moving-object a b))
          ...
          )
    

This allows programs to document types, compilers to use types for
optimization purposes and some compilers to do type checking.

What Common Lisp lacks is a more extensive/expressive type system which would
be competitive with what Haskell/or similar would offer.

------
brenden2
I've found TypeScript and React with VSCode to be incredibly productive for
web development. If you're on the fence, give it a shot.

TypeScript is a superset of JavaScript, so it brings a lot of baggage along
with it, but if you're writing frontend code it's a real pleasure to work with
compared to JS.

------
solomonb
Why do these sorts of articles always give vague definitions of Soundness and
act like it exists on a spectrum?

Soundness = Progress & Preservation.

From Pierce's Types And Programming Languages:

"Progress: A well typed term is not stuck (either it is a value or it can take
a step according to the evaluation rules).

Preservation: If a well typed term takes a step of evaluation, then the
resulting term is well typed."

There are not degrees to Soundness and it is a well defined term.

~~~
gjm11
You've shown that _one can give a black-and-white definition of soundness and
have it be useful_.

That doesn't mean that there's no way to give useful meaning to "more sound"
or "less sound".

Consider the following family of languages:

L has a sound type system.

LD (D for "dynamic") is L _plus_ the ability to escape from it, in specially
marked "unsafe" sections of code, into a dynamically typed system. (So
evaluation can produce runtime errors, but they can be handled safely.)

LC (C for "crash") is L _plus_ the ability to escape in "unsafe" sections into
a system like Ld's except that now type errors aren't checked for and caught
at runtime, they just produce memory-stomping and buffer overflows and the
like.

D is just LD's "unsafe" language.

C is just LD's "unsafe" language. (Any resemblance to actual real-world
languages named C, living or dead, is purely coincidental.)

The only one of these languages that is sound is L, of course. But there is
some quality closely related to soundness by which there's an obvious partial
ordering where L > LD > D, L > LC > C, LD > LC, and D > C, and if someone
describes this situation by saying that LD is "sounder" than C then I don't
see any reason why we should stop them.

Similarly: a federal state is either a "perfect union" or not, for any
reasonable definition of "perfect", but it's reasonable for the US
constitution to aim at a "more perfect union". A thing is either "unique" or
not, but despite the cries of pedants it's reasonable to describe a limited-
edition Ferrari of which only two were ever made as "almost unique" and as
"more unique" than a standard-issue Ford Fiesta. A given region of space is
either "vacuum" or not, but most of the things we describe as "vacuum"
actually contain some very rarefied gas and it's common to use terms like
"high vacuum" to quantify how vacuum-like a "vacuum" is.

------
stared
There is quite a lot missing in TypeScript types (e.g. integer or uint types
would help a lot in typical tasks such as accessing an array or iterating a
loop; even if they are stored as floats, I want to make sure someone won't
take 2.5 element of a list to get undefined).

Still, for me, TS is a day and night difference with JavaScript. While it does
not solve everything, at least I know what is code about. E.g. when I see
`volume` in plain JS the first question I ask myself is: is it a number, plain
object, instance of a class, a simple boolean, or what?

It is not only about tests. It is also about readability.

------
crooked-v
Typescript from the ground up is absolutely worth it, starting with how it
gives you full IDE inference for all those "big blob of options" objects that
a lot of JS methods use.

~~~
tantalor
Any IDE could do that for JavaScript; it has nothing to do with TypeScript.

~~~
Rychard
How could this be done for JavaScript without any mechanism for signifying the
_type_ of object that is expected?

~~~
jamil7
If you're using a third party dependency that has type definitions tsserver /
VSCode will pick it up regardless of whether you're writing js or ts.

~~~
Rapzid
I don't believe many understand how much tsserver is doing behind the scenes
in Vscode for JS code bases.. Of course any IDE can do that, because they can
use tsserver via the language server protocol haha.

~~~
jamil7
Yeah I use it with CoC in nvim and find it works as well as VSCode.

------
deckard1
Ignoring the tech side for a minute, my major problem with TypeScript is that
TS proponents assume that the static vs. dynamic debate has been settled. That
the future is static typing, and that people have to be crazy for wanting to
do dynamic typing in a dynamically typed language.

A great many developers have found themselves having to write JavaScript
because that's where they got pigeonholed. Then, because they'd rather be
doing Haskell, Java, or whatever, they bring that crap to JS and enforce it on
developers that possibly liked doing regular JS.

Type inference is older than I am. Yet you would think this is some new
technology. When in reality, we could have had it on Ruby. On Python. On Perl.
And on Lisp. Decades ago. It's not new and it's not special. But it certainly
has a lot of undeserved hype at the moment.

There is no conclusive proof static typing reduces bugs. This is some weird
myth that keeps circulating. The trend pendulum will continue swinging though.
TS won't be immune.

~~~
thawaway1837
I don’t see how you can claim that TS believes the static vs dynamic debate is
settled when TS already includes, and continues to add features that enable
and make it easier to dynamically type stuff (for example, unknown is a fairly
recent addition).

In reality, the reason TS has been so successful, and likely will continue to
be so successful (until they screw up the execution, or forget what made the
language so successful) is thst TS is an entirely pragmatic language. It uses
theory not to decide its roadmap, but rather, uses actual problems and needs
faced by JS developers to decide the roadmap, and then uses type theory and
other CS concepts to solve those problems.

For example, the reason TS uses Types is not because a group in MS decided
that static typing is better than dynamic typing, and what JS really needs is
a layer of types above it (that was coffeescript...). Typescript was created
because MS wanted to make better IDEs and tooling for JS (specifically, they
wanted to bring Intellisense which is a huge VS selling and marketing point,
to JS) and they realised they couldn’t do that without adding type information
to JS.

Hence, a practical need drove the decision to create TS.

~~~
jammygit
IDEs aren’t that necessary if you have strong command line skills. The only
ide feature I really miss is autocomplete because it’s a pain to remember
method names

~~~
addicted
My IDE is Vim/i3/bash.

So the IDE stuff isn’t extremely advantageous for me.

But that’s the reason Typescript was created.

A convenient side effect of that for me is that I can manually use the same
clues an IDE used to understand the code base I’m working on easier, faster
and with more confidence than I would be able to in a vanilla JS project.

------
0xff00ffee
Typescript users: LOVE IT!

Non-typescript users: ANOTHER layer? /sigh/

Cynical, yes, but that's because I haven't had a smooth onramping experience
the times I thought about switching. Would love a recommendation.

~~~
AgloeDreams
Using TS since ~2017.

Moving an existing codebase to it is a giant pain, otherwise it's not bad.

It fits you into better practices, but don't treat it as types are always
true. When debugging issues I'll commonly assume Typescript's types do not
exist or how it would act if they are wrong. This is notably true of consuming
API responses with mixed data types.

Generally, what I really like about typescript is that you normally blend it
with linting, minifying, and strong IDE integrations. These things, when
combined, really help code readability and adherence to TS conventions and
eventually save you from massive bugs that might not have been caught prior.
Obviously, at the end of the day, how you use it really defines how helpful it
is.

All that said, I haven't ever really had major issues with the tools around
TS.

------
leshow
> the adoption of TypeScript would not have been as high if a sound type
> system is 100% guaranteed. This is disproved as the dart language is finally
> gaining popularity as Flutter is now widely used. Soundness is a goal of the
> dart language which is discussed here.

Look, I wish TS type system was sound too, but that's not a "proof", it's just
a data point. TS doesn't have the same goals as Dart, there are lots of
variables which aren't the same, so you can't just take Dart's approach and
say "look I proved it". There are lots of popular languages with unsound type
systems; Java for example.

I don't know how you could have a criticism of TS without mentioning the lack
of sum types. Yes, you can fake it by having an object with the same field
name differentiated by a string constant, it's still not as nice as having
first class support for sum types.

------
chaostheory
Another Typescript fan here. The title didn’t match the post content but I
agree with everything he wrote concerning type “soundness”. From my POV it’s a
downside of typescript but it makes sense since it’s just a superset of
JavaScript

~~~
heisenbit
Yep, it ain't perfect but it is so much better than not having it. Anyone
being concerned about TS adding overhead please take a look at how generics in
Java work - both struggle with erasure of type information at compile time.
Java may be sound but doing anything non trivial with generic types gets
complex quickly. Compared to Java generics doing TS advanced types is almost a
joy.

------
jefflombardjr
Eric Elliot does a great analysis on this:

[https://medium.com/javascript-scene/the-typescript-
tax-132ff...](https://medium.com/javascript-scene/the-typescript-
tax-132ff4cb175b)

~~~
preommr
side note: but what the hell is hashicorp configuration language (HCL)?

It's apparently the second fastest growing language based on whatever metric
the chart is using and I've never heard of it.

~~~
mmorris
It's used with Terraform, amongst other things. So you might not have heard of
it if you're not doing devops/infrastructure work.

------
mattwad
I might get downvoted, but I believe that using "strict" mode is not worth it
precisely for the reasons this article talks about. You get at least 90% of
the benefit of Typescript (IDE support, typos, refactoring, etc) without
--noImplicitAny and other flags that induce a lot of boilerplate and wasted
time. After all, how confident can anyone be that DefinitelyTyped types are
correct? I use types when I find them useful. I also enjoy being able to not
use types when I don't need them, which is why I choose to use Javascript.

------
acemarke
I'd say it's definitely worth it.

I wrote a blog post recently about my experiences learning and using
TypeScript as both an app dev and a library maintainer for Redux:

[https://blog.isquaredsoftware.com/2019/11/blogged-answers-
le...](https://blog.isquaredsoftware.com/2019/11/blogged-answers-learning-and-
using-typescript/)

As part of that, I listed some of the tradeoffs and takeaways. In particular,
I strongly recommend a "pragmatic 80%" approach to tackling TS.

------
dynamite-ready
I won't lie. I read the title, and thought "At last, objectivity". It's like
CoffeeScript all over again.

Except this time, this particular assault on ECMAScript is much better funded.

Don't get me wrong, I think there's a place for strong typing in web based
UIs. But for one, WASM is a better idea for the choices and flexibility it
offers, and more importantly to me, I think the bigger challenges in UI
programming are not solved by strict typing.

------
city41
Most npm modules are written in JavaScript and when it comes to types they are
handwritten (if they exist at all). The very nature of this makes TS unsound,
as you have to count on the types being written correctly. I've encountered
incorrect types many times. Even worse, when the types ship inside the module
and are incorrect, it's difficult to correct them. I prefer JS modules to have
a separate @types module.

------
aecorredor
If you’re writing JS, then adding TS will give you a lot more reassurance when
writing new code or refactoring old one. Even if it’s not perfect, I don’t see
a reason why you’d choose JS over TS today other than maybe you don’t want to
go through the first month of getting used to. Once you’re out of that, you’ll
end up with code that’s much easier to reason about and also debug, in my
humble opinion.

------
jillesvangurp
I've done some programming with typescript. IMHO the reason for around 50% of
the javascript world now using it is that it provides substantial improvements
over javascript that are real. Personally, I insist on typescript on any
node.js or frontend javascript codebase these days.

Yes, it's not perfect. And, yes the inherent problems of javascript still leak
through in many places. But with a little configuration, you can make the
static code analyzer and compiler help you avoid most of that.

IMHO the amount of verbosity it adds is negligible. I actually measured a
slight decrease in LOC when I was converting code. You add some type
annotations (which IMHO also help human code readers) but then you also get
access to syntactic sugar to offset that. It's a fair compromise considering
that most tools trying to help the developer have more to go on and basically
work much better. Ballpark your number of LOC is not going to grow when
switching to typescript.

But IMHO it's just a gateway drug for developers to find their way to more
capable languages. Personally, I'm interested in the direction that Jetbrains
is taking with Kotlin-js, which with the next version will have some nice
tooling around it to leverage typescript type definitions for integrating npms
and hides most of the build tool madness behind gradle. The kotlin compiler
has a much more sound/strict typesystem than typescript and also the language
has quite a few language features that the typescript developers have not
gotten around to supporting yet (they've been making progress catching up with
recent releases though). They are also addressing size of the minified code.
With the recent improvements, hello world is now a lot more reasonable than it
used to be (<80kb instead of ~1MB). It eliminated unused code more
effectively.

If you feel brave, you can get started with this on a modern react project
right away. Most of the dependencies you'd use for that should just work fine
with kotlin-js. But realistically it's probably going to take another few
years to stabilize. IMHO Kotlin is interesting because it is already widely
used by frontend developers on Android and has a lively ecosystem of
frameworks that might also make sense in a browser. Also co-routines are nicer
than async await in typescript.

And of course WASM is opening up this space further to just about any
language. So for people finding themselves a taste for more/better typing,
there will be plenty of alternatives for typescript.

------
tabtab
In general it seems hard to be in-between dynamic typing and static typing
(compiling). As the article implies, one typically has to do more testing if
dynamicness can allow "bad data" in.

The trade-off for dynamicness is more productivity and (potentially) easier-
to-read code because less code is needed on average to express an idea since
type-related code isn't needed as often. But if TypeScript is not type-safe
enough to reduce the need for fine-grained testing, then you get the worse of
both worlds: the verbosity of types and the busy-work of micro-testing.

That being said, I wish JavaScript would add a feature to allow _optional_
parameter checking such as:

function foo(a:intReq, b:datetime, c:datetimeReq, d) {...}

Here, the "Req" ("required") suffix means the field can't be null or white-
space. Parameter "d" has no type indicator. It's still "soft" type checking,
but would catch a lot of problems earlier.

------
typescriptfan1
It's interesting that someone who is primarily using JavaScript in the backend
is criticizing TypeScript's type system. There is a simple reason why
TypeScript's type system is how it is... TypeScript is additive which works
well in practice.

------
ptcampbell
LogRocket deserve some praise for doing the company blog right. Good, self
hosted content (no Medium) and well written pieces on technology from a
practical everyday perspective. I am not a customer, by the way.

------
vemv
I don't think pointing out deliberate design decisions is a valid criticism.
It's like criticising a chair for not being a beachball.

Folks seeking a Haskell-like type system in javascript certainly have options.

------
craftoman
This article is wrong from many aspects. There are things that many developers
can't get with Typescript and it's flexibility...just always keep in mind what
makes Typescript so special compared to any other languages. You can't achieve
both flexibility and typed solid programming in the same place, you must
sacrifice the things you just mentioned and few others. Typescript was
supposed to be flexible and developer friendly, it's not a hardcore language
and never will be.

------
akdor1154
A bunch of the issues here are due to the author actually casting instead of
letting inference do its job.

    
    
       // unsound, val.toFixed(0) compiles
       let val: number = ("string" as string | number)
    

vs.

    
    
       // sound, val.toFixed(0) does not compile
       let val =  ("string" as string | number) // sound
    

In general, it's unnecessary (and as demonstrated, potentially harmful) to
annotate assignments like these.

~~~
TheDong
Their example without `: number` still exhibits the exact same behaviour.

The `: number` isn't a cast either, it's declaring the type of the variable.

You can't help but explicitly name the type of a variable in many cases. What
if they were passing val to a function as an argument? You can't have
'function foo(x)', you have to have 'function foo(x: number)' and name the
type.

So yes, their example is contrived, but no, what you said is not sound. It has
the same problem as the one the author mentions. The typescript compiler
intentionally does not catch their issue.

If I'm misunderstanding what you're trying to demonstrate, please make a
typescript playground of it.

------
trixie_
The author's example is a trivial corner case that can be easily avoided.

It is nowhere close to important enough to fuel the question of 'Is TypeScript
Worth It?'

------
jammygit
I think I’m alone in this, but JavaScript is a neat language that is
incredibly powerful and expressive (minus a few warts). Most of the problems
that arise from it seem to come from undisciplined work habits and a lack of
code review. As long as your team is smart enough to not call all your
function arguments “args” or “data” or “params”, the asynchronous flows are
really nice. IMO at least

------
wildpeaks
It's worth it because it catches a lot of low-hanging bugs at a small cost,
and it's well maintained and has great tools support. Plus you can even use it
like a simple linter if you want to continue writing vanilla Javascript (it
catches less, but still catches a lot).

------
jiofih
I don’t know how these people are using TS, but I’ve been part of a major
project for over a year and we’ve had zero runtime issues, using all kinds of
libraries in both nodejs and the browser. But for our standards, that object
assignment in the example is a big no-no, TS or no TS.

------
dynamite-ready
I've got a tangential question, and I think it's worth asking here.

With the precision ML requires, why aren't data scientists rushing from
Python, to a language with a stronger type system?

~~~
mattnewton
Most machine learning doesn't work the first time and required rapid iteration
outside of your production system in my experience. Then, when you finally get
a model, you can put those weights into your stable production system that has
all the automated testing and is written in a typed language.

------
agumonkey
I had this question since I tried rewriting some big-todo app in TS.

Do people try to write a core in simple (sound) types and then have an outer
shell of IO/frail typechecks around ?

------
techsin101
Change my mind but if you are using VScode you're getting 90% of the benefits
without having to take the cost of writing types.

------
donpark
Worth it at component level. Hassle at application level.

I use TS to write components and JS to write the app using those components.

------
Rapzid
Interesting.. The biggest drawback I've experienced with TypeScript has been
the complaining.

------
vanusa
The main problem with TypeScript is that at the end of the day -- you're still
using JS.

Which outside of its natural realm of application (i.e. the browser) is a
highly questionable value proposition.

"A bandaid over a machine-gun wound" is what we might call it.

------
nocommentx
nope - the loss in velocity is not worth using it unless you're a massive
team. TS is for Java programmers who are mad at Javascript for existing and
don't know how it works well enough to grok overloading etc. plus you get a
lot of the benefits of TS in an IDE like VSCode without actually having to use
types at all. if you're a javascript native, typescript is constricting and
eliminates one of the best parts of javascript - no types!!

~~~
jimbob45
[https://www.tutorialsteacher.com/typescript/function-
overloa...](https://www.tutorialsteacher.com/typescript/function-overloading)

TS/JS don't allow for overloading the way that other languages do - it does
not allow you to differentiate between functions via number of parameters,
only types of parameters. If you try to differentiate based on number of
parameters, it will simply use whichever definition of that function name it
finds first.

~~~
52-6F-62
That's not [entirely] my experience. Here's a quick example:

Declaration file style:

\---

    
    
        // add.d.ts
        export declare function add(a: number, b: number): number;
        export declare function add(a: number, b: number, c: number): number;
        export declare function add(a: number, b: number, c: number, d: number): number;
    

\---

    
    
        // add.js
        function add() {
         switch (arguments.length) {
          case 2:
           return arguments[0] + arguments[1];
          case 3:
           return arguments[0] + arguments[1] + arguments[2];
          case 4:
           return arguments[0] + arguments[1] + arguments[2] + arguments[3];
          default:
           throw new Error("Too few or too many arguments. Number of arguments: " + arguments.length);
         }
        }
        module.exports = { add };
    

\---

    
    
        // adding.ts
        import { add } from "./add";
        
        console.log("4 + 4 =", add(4,4));
        console.log("4 + 4 + 4 =", add(4,4,4));
        console.log("4 + 4 + 4 + 4 =", add(4,4,4,4));
    
    

\---

(Gist: [https://gist.github.com/Robert-
Fairley/98a2da3f0361e524f4e05...](https://gist.github.com/Robert-
Fairley/98a2da3f0361e524f4e056d947a6172a))

It will default to the first function name, but it definitely allows for
overloading the number of parameters.

It's not perfect as you do still have to implement the function as it would
need to be implemented for JS

------
achou
In type systems there's a tension between expressiveness, soundness, and
comprehensibility. A sound type system must exclude _all_ programs that have
runtime issues, and, holding that constant, try its best to maximize
expressiveness and comprehensibility of the programs that can be written.

But what about programs that can run fine but are excluded by the type system?
They are _censored_. This is what's less visible until you actually try to
build something substantial, pushing the boundaries of expression,
performance, or scale. Then you'll find that a sound type system can become
more and more of a straight-jacket. One that forces you to write code in ways
that are limited by what its type designers could envision expressing (or
could prove that was safe to express).

The trouble is that it's hard to know when you might reach the point where the
type system begins to limit you. It might never happen, as you frolick happily
within the walled garden. Or it might happen when you write your first line of
code. In a large system that must deal with external requirements, it's
something that in my experience becomes inevitable. That's not even touching
upon comprehensibility, which becomes an increasing challenge for purely sound
type systems as they attempt to increase expressiveness.

The biggest innovation of TypeScript is JavaScript. That is, TypeScript
started with a huge established corpus of JavaScript that showed what
developers wanted to express and how they wanted to express it. And,
crucially, how popular various kinds of expression actually were in the
developer community. This forced TypeScript to take practical expressiveness
of millions of lines of JS seriously, that ordinarily would have been censored
by type system design before the first line of code was written.

That's why it's entirely unfair to harp on TypeScript's unsoundness, without
also exploring the corresponding gain in expressiveness and comprehensibility
relative to other type systems.

BTW, this line of reasoning is the reason so many "sound" type systems also
have their equivalent of "any": Rust has unsafe[1]. C# has unsafe[2]. Flow has
any[3]. And all practical languages have strings, which are kind of a lowest
common denominator when it comes to dealing with a type system that simply
can't express what you need.

[1]: [https://doc.rust-lang.org/book/ch19-01-unsafe-
rust.html](https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html) [2]:
[https://docs.microsoft.com/en-us/dotnet/csharp/language-
refe...](https://docs.microsoft.com/en-us/dotnet/csharp/language-
reference/keywords/unsafe) [3]:
[https://flow.org/en/docs/types/any/](https://flow.org/en/docs/types/any/)

------
bigodines
yes

~~~
__s
Was working an application written in JS

Converted it to TS. In the process of fixing up types, it found bugs for us.
Value demonstrated

------
VyperCard
I stopped reading after the first sentence.

------
unjte
I don't like TypeScript at all. I used to write c# and javascript all day.
Every time I had to write javascript, it was much more enjoyable than writing
the c#. I would often have to create classes purely because the language
required them. All of these classes all over the place with no methods in them
at all. A whole bunch of typing all over the place that I could tell I was
never even mentally parsing, but still having to type and see on the screen.

Then I started working on my own and decided to use Node a lot in the
situations where I would have to use c# at my previous job. There were no more
bugs, no problems with refactoring, and it was much more enjoyable than
writing c#.

Now this TypeScript is infecting javascript, and all the jobs and so on
require "typescript" instead of javascript. It puts all the things I didn't
like about c# back into javascript. People will make all kinds of ridiculous
claims that it is irresponsible not to use TypeScript, and that it improves
productivity and so on. None of these claims are true and don't get to the
real reason that TypeScript exists.

Most well-structured programs aren't one giant function that is hard to
refactor. They are usually a series of isolated, small functions. There is
even a trend towards "microservices" and function as a service and so on.
These are things that reduce the claimed reasons for TypeScript, rather than
increase it. Many times I see the reason for using TypeScript being "it is
good for large teams". Yet still, I see it used in teams of 3 people all the
time.

The real reason TypeScript is used is because there are a very large number of
programmers now, which means the quality of the average programmers is much
lower than it has ever been. Many people who program often just copy and paste
code from stack overflow. Many of these people were the same people who looked
in fear at JavaScript, and couldn't even understand it because it wasn't the
one language that they knew. TypeScript gives these people more safety,
feedback, and familiarity to be able to do their job.

That is fine, but lets not pretend it is anything else.

