Ask HN: Convince me that TypeScript is better than JavaScript
I recently started working at a company whose legacy project was built in .NET/Angular, so the codebase is largely written in C#/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'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'm new to Typescript, but that's not why I'm posting this question here.
I've asked the other devs why they think we should continue using Typescript, and no one has been able to convince me. I'm not a stubborn person, and I'd really like to understand the benefits of typed JavaScript enough to be swayed into using it, but I haven'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.
That's where you come in. Convince me.
15 comments
[ 3.3 ms ] story [ 43.3 ms ] threadhttps://www.educba.com/typescript-vs-es6/
> 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?
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.
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.
- 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.
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.
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.