<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As a side note, it still surprises me that most JS projects (front-end or Node) don't use the Typescript (or flow) compiler. It just takes running it on normal JS code to have errors reported for free with no consequence; errors that are not reported by any other tool.<br></blockquote><div><br></div><div>For a few reasons:</div><div><ul><li>JS build systems are already hairy. Are you going to Babel then TypeScript, then webpack, then…?</li><li>Optional types mean an easy on-ramp, but the cost-benefit exchange starts off negative.</li></ul></div><div>We tried Flow for Tofino. At the time it didn't support Windows, so it was an optional build step… and so it mostly turned into a "make the compiler happy" game of chasing some error that someone else introduced a few days before. We caught one or two small bugs, in exchange for a bunch of irritation. At the time, particularly for Tofino's front-end React code (which already did prop type checking etc.), we decided the juice wasn't worth the squeeze. I hope to revisit that decision at some point<br></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">nalexander and I have been using the Google Closure Compiler by way of ClojureScript on Datomish, and it works fine for its purpose, but it isn't much use for type checking (particularly with CLJS on top).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Much of the architectural benefit of types comes from using a sophisticated type system well, so that broad classes of errors or modeling problems are simply impossible to express. It takes a big investment in Flow or TypeScript to start to see the benefits you see from day one with a language like Swift.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">(Apologies for dragging out a sidenote!)</div></div>