
Ask HN: Convince me that TypeScript is better than JavaScript - rodneon
I recently started working at a company whose legacy project was built in .NET&#x2F;Angular, so the codebase is largely written in C#&#x2F;Typescript. My first project is built in React, and the other developers are convinced that we should continue developing in Typescript. It just so happens that the combination of tools we&#x27;re using is not too conducive to Typescript code, and I end up spending most of my day wrestling with the tooling rather than building React components. That may be because I&#x27;m new to Typescript, but that&#x27;s not why I&#x27;m posting this question here.<p>I&#x27;ve asked the other devs <i>why</i> they think we should continue using Typescript, and no one has been able to convince me. I&#x27;m not a stubborn person, and I&#x27;d really like to understand the benefits of typed JavaScript enough to be swayed into using it, but I haven&#x27;t heard a single convincing argument as to the benefits of spending time on the cruft that Typescript adds to my code, or the benefits of spending time getting all the tooling to work properly so that I can get some real work done.<p>That&#x27;s where you come in. Convince me.
======
otras
I usually explain TypeScript to others as helping the next person working with
the code, be it me or another developer. I've found that diving in to source
code is made easier when it's in TypeScript, and although it may slow down my
initial development speed, it improves the ease with which I understand
foreign code and get back into my old code (which sometimes may as well be
foreign).

> It just so happens that the combination of tools we're using is not too
> conducive to Typescript code

Maybe the problem is the tools, not the TypeScript. What's the combination of
tools that's giving you trouble?

~~~
rodneon
Mainly create-react-app, styled-components, react-styleguidist (which uses
react-docgen). I'm okay with writing .d.ts files for my React components, but
trying to _develop_ these components in this ecosystem... oof.

------
mimixco
It's not. Strong typing is overrated. Lisp has lived without it for more than
50 years. People are obsessed with typing as though it were the solution to
all dev problems. It's not.

~~~
rodneon
Those have been my thoughts exactly, except I might need to buckle down and
use Typescript because the devs at work favor it. I don't want to _hate_
coding in Typescript, which is why I posted this Ask HN. I still wouldn't use
it on any projects where I have full control. But, if I _need_ to use it, I
might as well try to see the bright side of it.

On the other hand, all this "safety" that Typescript imparts just gets in the
way of productivity. It's a language to show off to your boss, not to get shit
done.

------
d--b
One single reason: refactoring.

When the types of objects being passed to and returned by functions are known,
you can modify the type of an object and know at compile time that you forgot
to update a usage of this type.

If objects have no known type, you may have some code that accesses properties
that do not exist anymore.

~~~
rodneon
This is only a problem when you _remove_ properties from an object. Ok, in
this particular case, I buy your theory... but I'll ask again: is all the
added cruft really worth this small safety? I mean, when you say "when the
types of objects (...) are known"... isn't this the kind of stuff that tests
are supposed to catch? You check to see if the object being passed into a
function has all the properties it needs to have. Right? And if you need that
kind of safety, couldn't you just enforce the use of constructors for
"important" objects, and use instanceof to check for proper usage? All while
using the constructs provided by JavaScript itself?

------
seanwilson
\- You can do very aggressive manual refactoring and be confident you haven't
broken anything.

\- You don't have to write as many tests to get the same coverage.

\- Many potential runtime errors become compile time errors before they get a
chance to happen in production.

\- Machine checked types replace lots of manual documentation.

\- Automated refactoring shortcuts.

I'm sure you've heard of some of these. What don't you find convincing? Coming
from strong functional programming languages, I don't understand why people
like dynamic types at all.

~~~
rodneon
> potential runtime errors (...) before they (...) happen in production

I seriously can't think of an example of this. If all testing is done
properly, from unit testing to integration, etc, the compile time safety for
front end development is just a nuisance. Runtime errors will happen, that's
what tests and error tracking are for.

To put it differently, are all of these reasons that you cited worth turning
this:

// ==========

import React from 'react';

const Welcome = ({ name }) => <h1>Hello, {name}</h1>;

// ==========

into this?

// ==========

import * as React from 'react';

interface WelcomeProps { name: string }

const Welcome: React.SFC<WelcomeProps> = ({ name }) => <h1>Hello, {name}</h1>;

// ==========

In the second example, gone are the years of making Javascript an elegant and
straightforward language, adorned by the intuitive syntactic sugar that is
JSX.

~~~
seanwilson
> I seriously can't think of an example of this. If all testing is done
> properly, from unit testing to integration,

Those tests take time to write, time to maintain and must be updated when you
refactor. They're not free. It's very unlikely you're writing tests to cover
every case of e.g. a variable being undefined or the wrong type either which
happen often.

> In the second example, gone are the years of making Javascript an elegant
> and straightforward language, adorned by the intuitive syntactic sugar that
> is JSX.

You'd be better looking at examples that mix strings, numbers, arrays and
potentially undefined variables.

For the small amount of time annotations would take to write you're getting
all the benefits I mentioned. Those benefits are worth a huge amount on
projects with lots of code and team members. I wouldn't say JavaScript is
elegant and straightforward when simple looking code can be full of subtle
bugs.

------
ausjke
with ES6 and the new JS these days I indeed see no reason for Typescript,
still:

[https://www.educba.com/typescript-vs-es6/](https://www.educba.com/typescript-
vs-es6/)

~~~
wirelessben
The article is email-walled, and it's a terrible, unedited article full of
superfluous sentences, redundant info, punctuation errors, etc. Just bad
English.

------
segmondy
Nope, not going to convince you. Convince yourself or keep using javascript.

