Let's say there are THREE layers out of there. #1. Source of the truth That is your pure Javascript code. #2. Type Check & Type Generation ESInfer stands here. It will take all the assumptions your code made to see if there are any conflicts. If all pass, you get the type information. #3. Applications You got the information of types. Then the only way to limit yourself to doing something is only the imagination. Examples can be listed, but not limited to: * Communicate with the editor's LSP to give tips on types(this website:ESInfer.com is doing this way) or code suggestions. * Better linting * Annotation generation for or not for typescript/flow * Statical analysis integrated into your git hooks or CI

TL;DR: Typescript is weak on inference, and the type system is not sound. ESInfer is still very early and does NOT have enough features to be used in production. For a more detailed comparison, refer to the discussions repo: https://github.com/ESInfer/discus/discussions/1

Our goal is to support all ES6+ features incrementally. Of course, use frequency is the main factor in deciding which comes first. Currently, it supports nearly all(except a few built-in methods unimplemented, which will do) ES5 features and a select set of ES6+ features, such as Array/Object destructing. If you have any concerns regarding the feature set, please leave a message at the discussion repo on Github.

ESInfer is not a superset of javascript. It analyzes statically without any add-ons to the language or your code. That is to say that you get all benefits from ESInfer at zero cost. On the other hand, it is not a subset of javascript either. It will warn of the potential problem code, such as calling a non-existing method on an object. Stimunously allows, for example, the modification of prototypes dynamically to maximize your development experiences.