Ask HN: Convince me that TypeScript is better than JavaScript

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?

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.

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.

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.

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.

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?

- 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.

The refactoring bit is almost convincing enough for me. I'm a front-end developer with a strong background in JavaScript and React. They say Typescript is a superset of JavaScript, but I disagree. I feel like I can't write JavaScript anymore when Typescript is in the mix. React component declaration gets messy and ugly. Just the other day I tried to use "document.something"... nope, can't do that, because there's no explicit interface for "document". It feels like every simple thing takes one or two extra steps with Typescript, and sometimes those steps take me all day to resolve!

> 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.

> 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.

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

https://www.educba.com/typescript-vs-es6/

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

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