4 ms·

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

- 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 8y ago
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!
rodneon 8y ago
> 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 8y ago
  > 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.

rodneon 8y ago

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!

rodneon 8y ago

> 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 8y ago
> 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.