5 ms·
> 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 un
by 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.