Using TypeScript with React

What unreleased APIs are you needing to warrant this? We've used any a couple times, but usually just as a placeholder until the data model is locked down.

>- Development time is slower than writing in regular JS/React. This started to become a major issue due to the nature of our project being a prototype (fast iterations on ideas and features).

Again, I can't say I've had this experience. Development time is _initially_ a tiny bit slower, but once you've setup types, the time saved from fixing type related issues adds up very very fast. Also, autocomplete / autoimporting has actually sped up my development time hugely. Not having to worry about figuring out relative paths or imports and just being able to type a component to import it is magic.

>- Lots of frustration when a package doesn't have types (although most major ones do have them).

This is true, but I've found that 95% of the packages we use do have types. The few that don't, tend to be very small indie packages that don't do a lot, so the lack of types isn't a huge issue.

What I've found is that there tends to be a happy medium between making everything 'any' at the start and never using 'any' at all that roughly corresponds to how defined our implementation is. When we're designing the implementation as we go, there tends to be lots of 'any', but when we spent time defining the interfaces, there's not as much need for using 'any', because instead there's a specific type. The type itself usually doesn't remain static, but where it's used does.

So for example, when we're adding a rest endpoint, when we know the required and optional arguments/response, we can make a type and validator function and then there's not really a need for 'any' after the validation function, but if we don't know what the arguments/response will be (or the design is still at the 'make every argument optional' stage), then any sort of prototype will be littered with 'any' or '{[key: string]: any}' types.

TypeScript is a superset of JavaScript, which means any JS dev already knows most of TypeScript. They're effectively just learning the type system and best practices on implementing it.

The syntax of Elm is extremely different, which would effectively require developers to learn an entirely new language. It's also a completely different proposition. It's a whole framework, which means complete buy-in on a project. I know there are some interop packages, but you would normally use it instead of React/Vue/Angular etc. This means it's only suitable for new projects.

It's a very nice framework (imo) but it's not a true comparison.

- I don't know what unreleased API's you're referring to, but I generally haven't seen the need to use them - if they're unreleased, I try to avoid them.

- Especially for projects with fast iterations, TypeScript has been massively useful. Changing the API around, which I do often at the start of a project, is just so much easier when you've got TypeScript to make most of the required changes, or to tell you where you have to make changes.

- Type availability might be a problem, but I also generally stick to major packages for which it's not. But yes, I have learned to contribute to DefinitelyTyped - which luckily is a relatively smooth process.