<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><span style="background-color: rgba(255, 255, 255, 0);">That is why we have the websites <a href="http://definitelytyped.org">definitelytyped.org</a> and <a href="https://github.com/flowtype/flow-typed">https://github.com/flowtype/flow-typed</a>. Sure they don’t have type definitions for all libraries, but more are being added all the time and developers can provide their own definitions to fill in the gaps. Being able to use types, even when some libraries do not have type definitions is still far better than not using types at all.</span><br><br><div id="AppleMailSignature">---<div>R. Mark Volkmann<div>Object Computing, Inc.</div></div></div><div><br>On Jan 13, 2018, at 9:49 PM, Ranando King <<a href="mailto:kingmph@gmail.com">kingmph@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Stripping the types does solve the runtime problem, but only at the cost of creating another. Suppose a website imported a remote library with types in it. There's no way that, with the types stripped at runtime, the remote library and the local code could validate that each other were satisfying their type requirements. That is a major issue. The simple process of modularization reduces the usefulness of types that are stripped at runtime to only validating the self-consistency of each individual module. Good unit testing can already do that.</div>
</div></blockquote></body></html>