Followup: modularity, WebExtensions, and going faster

[David Bruant]

Le 12/10/2016 à 14:41, Gijs Kruitbosch a écrit :
> On 12/10/2016 13:29, David Teller wrote:
>> On 12/10/16 13:33, David Bruant wrote:
>>> Microsoft faced the challenge of writing large JavaScript applications.
>>> They ended up inventing TypeScript for this very purpose. Facebook
>>> followed a couple of years later with Flow. Both have differences, but
>>> in practice the differences are barely noticeable as far as I'm 
>>> concerned.
>>> Note that the Firefox devtools team is already using Flow
>>> https://github.com/devtools-html/debugger.html
>>>
>>> Because of JavaScript limitations and "culture", the type system of
>>> either with never be as expressive as the Rust type system can be.
>>> However, I've never heard of it as an strong argument to move away from
>>> TypeScript or Flow.
>> Fwiw, we are currently trying to come up with a strategy to use either
>> Flow, TypeScript or Google Closure Compiler (which also performs
>> type-checking on JS) on our codebase.
>>
>> Of course, the tools only makes sense if we have clean, well-designed
>> APIs, so the discussion on WebExtensions (or alternatives) is still on.
>>
>> So far, from this discussion, I have parsed the following proposals:
>> - [customized] WebExtensions (which intends to answer the question "how
>> do we present the APIs?");
>> - Rust (which intends to answer the questions "how do we implement the
>> APIs"/"how do we encourage APIs to be well-typed");
>> - don't change anything (which, in my books, doesn't answer any 
>> question);
> Being able to do type checking is orthogonal to using WebExtensions 
> for browser features.
>
> If you could convince people that it's worth annotating all the 
> existing JS in browser/ and toolkit/ with these types, you could do 
> that today.
Annotating all the existing JS is not a requirement to use TypeScript or 
flow (IIRC Google Closure Compiler is a different story).
Interesting blog post from 2013 of someone switching a 100kLOC lib:
http://news.turbulenz.com/post/47457658846/mostly-painlessly-migrating-a-3d-game-engine-to
"The first step I took was to simply rename each of our .js files to .ts 
and create a trivial build step to convert the each of these new .ts 
files to JavaScript [with the typescript compiler].
The advantage of this apparently trivial step was that regular 
development could continue while we gradually expanded the type 
definitions in the same files.  This approach is only really viable 
because TypeScript extends rather than replaces JavaScript, and it’s 
actually very important."
Now, TypeScript has a --allowJs option which makes that you don't even 
need to rename the files anymore. I'm sure it's the same for flow.

Anyway, given TypeScript does type inference, "switching" to TypeScript 
is merely using the compiler to report error and do nothing else 
(--noEmit option) without having to annotate anything.
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.

Now, to fully benefit from the static type checking, annotations are of 
course the way to go, but they can be added gradually over time. From 
experience, it's not a bad exercice and can be seen more as a welcome 
form of documentation. "Documentation" that is run against the code and 
that the compiler invites you to fix when the code changes.

David