Tällä kertaa on mielessä pohdintaa JavaScriptin tyypityksestä. Olen viime aikoina kokeillut TypeScriptiä, joka on Microsoftin kehittämä tyyppilaajennos JavaScriptiin. Se sopii erityisen hyvin yhteen Visual Studio Code -editorin kanssa, joka osaa hyödyntää TypeScriptin ymmärrystä muuttujien ja objektien tyypeistä. Editori näyttää tyyppien perusteella varoituksia ja automaattitäydennyksiä käyttöliittymässään.

Facebook on puolestaan kehittänyt TypeScriptille kilpailijan nimeltä Flow. Se toimii samalla periaatteella, eli osaa varoittaa tyyppivirheistä ja kääntää koodin niinikään tavalliseksi JavaScriptiksi. Se toimii niin Atomissa kuin Visual Studio Codessa, kuten TypeScriptkin.

Pointti näissä molemmissa tyyppijärjestelmissä on se, että tyyppejä tarvitsee määritellä vain sen verran kuin itse parhaaksi katsoo. Kehittämisen voi aloittaa tuttuun tapaan dynaamisesti ilman erillisiä tyyppimerkintöjä. Sitten, kun jokin kohta koodissa alkaa näyttää turhan monimutkaiselta ja vaikeasti hahmotettavalta, siihen voi lisätä tyypityksen.

Yksinkertaisissa web-projekteissa tyypityksestä on oikeastaan eniten iloa silloin, kun käytettävät kirjastot sisältävät valmiit tyyppimääreet. Esimerkiksi AWS SDK -kirjastoa käyttäessä näkee jo editorissa varoituksen, mikäli on unohtanut jonkin parametrin DynamoDB-hausta. Tämä nostaa tuottavuutta aika merkittävästikin silloin, kun virheen muuten huomaisi vasta paljon myöhemmin Lambda-funktiota pilvessä ajaessa.

Oleellista on, että tyyppien käyttöönotto ei tee JavaScript-kehityksestä yhtä jäykkää kuin kokonaan staattisiin tyyppeihin perustuvissa kielissä, kuten Javassa tai vaikkapa Haskellissa. Olin itse aiemmin huolissani tyypityksen "viraalisuudesta", joka pakottaisi lisäämään tyyppimääreet ketjureaktiomaisesti kaikkialle, mutta toistaiseksi on vaikuttanut siltä, että muutaman any-tyypin lisääminen tarvittaessa sinne tänne riittää ainakin TypeScriptissä ja luultavasti Flowssakin. Tämä riippunee kuitenkin paljolti myös käytettyjen kirjastojen tyypityksen tasosta.

Netistä löytyy erilaisia vertailuja TypeScriptin ja Flown eroista enkä osaa vielä itse lähteä ottamaan niihin juurikaan kantaa. Jollain tavalla pitäisi kuitenkin osata päättää, haluaako sitoa oman koodinsa mieluummin Microsoftin vai Facebookin teknologiaan. Toistaiseksi TypeScriptin käyttökokemus on ollut erittäin hyvä, mutta toisaalta koska käytän myös paljon Reactia, Flow houkuttaa tavallaan enemmän.

Eräs TypeScriptin selkeimmistä eduista omassa käytössäni on ollut serverless-plugin-typescript, joka tekee TypeScriptin käyttämisestä Serverless-mikropalveluissa erittäin helppoa. Se kääntää .ts-tiedostot automaattisesti .js-tiedostoiksi ja julkaisee Lambda-funktiot pilveen. TypeScript sisältää myös async/await-tuen, joten mitään lisäkikkailua Babelilla ei tarvita.

Pahoin pelkään, että saman lopputuloksen saaminen aikaan Flowlla vaatisi paljon enemmän erilaisten pluginien asentamista ja konfigurointia, ja se async/await-tukikin pitäisi luultavasti virittää jonnekin erikseen. Luultavasti käytän sen vuoksi itse ainakin tässä vaiheessa enemmän TypeScriptiä, mutta seuraan samalla Flow-työkalujen kehittymistä.

Jossain vaiheessa edessä voi vielä olla vanhojen TypeScript-annotaatioiden vaihtaminen Flow-annotaatioksi. Sitten nähdään kuinka paha rasti sekin on. Toisaalta mikropalveluiden ja Amazon Lambdan ansiosta tällaiset migraatiot ovat nykyään aika pieniä ja ne voi tehdä aina vain yhteen mikropalveluun kerrallaan - ainakin jos on osannut pitää palvelut oikeasti mikrokokoisina.