Followup: modularity, WebExtensions, and going faster

[Richard Newman]

>
> 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.
>

For a few reasons:

   - JS build systems are already hairy. Are you going to Babel then
   TypeScript, then webpack, then…?
   - Optional types mean an easy on-ramp, but the cost-benefit exchange
   starts off negative.

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

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).

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.

(Apologies for dragging out a sidenote!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161012/35b0adb7/attachment.html>