Google s'oriente vers TypeScript et voici pourquoi, selon Evan Martin,
Un ingénieur de la firme qui travaille sur le langage

Le , par Michael Guilloux, Chroniqueur Actualités
Si vous utilisez les produits Google, il est probable que vous ayez interagi avec du code TypeScript, et peut-être plus que vous ne l’auriez jamais imaginé. C'est ce que laisse croire Evan Martin, un ingénieur chez le géant de la recherche en ligne, qui travaille sur TypeScript depuis plus de deux ans. Et la raison se trouverait dans la quête éternelle de Google de remplacer JavaScript avec des solutions plus efficaces et qui contournent les limites du standard de facto pour le développement Web.

Google a rapidement adopté les applications Web et donc le langage JavaScript. Gmail par exemple existe depuis de 14 ans, mais quand Google adoptait ce langage, il était loin d'être satisfaisant pour répondre aux besoins de l'entreprise. Au cours des dernières années, Google a donc mis en place de nombreuses infrastructures pour créer de grandes applications JavaScript. Google a également développé de nombreux concepts qui, d'après Evan Martin, sont aujourd'hui familiers aux développeurs Web. Mais la pile JavaScript de Google ayant été développée avant celle utilisée aujourd'hui par les développeurs Web, elle a évolué en parallèle avec cette dernière et est par conséquent conceptuellement similaire, mais (dans la mise en œuvre) totalement différente, avec des processus, des outils et même des noms différents.

« Dans un autre exemple d'évolution parallèle, Google, Facebook et Microsoft ont créé des compilateurs similaires, mais incompatibles, qui ajoutent des contrôles statiques à JavaScript », rappelle Evan Martin. Le compilateur de Google est connu sous le nom de Closure, à ne pas confondre avec le langage Clojure. Mais il faut noter que ClojureScript (un compilateur pour Clojure qui cible JavaScript) utilise le compilateur Closure de Google.

Pour Evan Martin, la pile JavaScript de Google est inégalable. Elle a permis à Google d’écrire et de gérer des applications Web qui ont changé la face d’Internet et elle inclurait même des pièces qui surpassent le meilleur des technologies actuelles. Mais elle a aussi des problèmes. À propos de Closure, l'ingénieur de Google explique par exemple que le compilateur maison a une sémantique imprévisible, qu'il est lent, bogué, entre autres problèmes. « Bien qu'il soit open source, peut-être à cause de ces raisons, il n'est pas largement utilisé dans l'industrie, sauf dans les entreprises qui embauchent des Googlers qui le connaissent », dit-il. « Au sein de Google, je pense que JavaScript a une faible réputation en partie à cause de nos outils complexes, qui combinent la verbosité d’un langage statique avec l’imprévisibilité d’un langage dynamique », a-t-il ajouté.


Si JavaScript a une faible réputation au sein de Google, en dehors de l'entreprise, le langage inventé par Brendan Eich a continué à évoluer et est devenu très populaire au point où la plupart des outils Web sont eux-mêmes écrits en JavaScript. Mais à cause de ses nombreuses technologies maison, Google n'utilise pas ces outils, ce qui fait que même des développeurs expérimentés qui arrivent chez Google peuvent se sentir dépaysés.

En conclusion, Google souffre du fait de faire évoluer des technologies JavaScript maison en parallèle avec des alternatives qui sont largement utilisées en dehors de l'entreprise. C'est un problème que l'entreprise s'efforcerait de résoudre tout en essayant de contourner les problèmes liés à JavaScript qui l'ont poussée à développer ses propres outils. Et plusieurs options s'offrent à elle.

« La première option tentante consiste à simplement abandonner cette planète en ruine et à en installer une nouvelle qui n’implique même pas JavaScript », explique Evan Martin. « Si seulement nous investissions davantage dans GWT (un projet Google compilant Java en JavaScript) ou Dart (un projet Google qui compile un nouveau langage en JavaScript) ou WASM ou [n'importe quel autre langage], nous n'aurions pas besoin de nous soucier de JavaScript », dit-il. Mais adopter un autre langage devrait nécessiter de tout réécrire à partir de zéro.

Evan Martin et sa petite équipe chez Google ont donc poursuivi une autre voie : adopter progressivement des outils externes là où cela se justifie, en déterminant comment les rendre compatibles avec la base de code existante.

La première partie du pont entre la pile JavaScript de Google et le monde extérieur a été d’adopter un vérificateur statique bien pris en charge qui (1) n’est pas développé en interne ; (2) est déjà populaire, tout en étant similaire au code existant ; (3) est conçu pour passer facilement à JavaScript ; et (4) conçu pour soutenir le développement à grande échelle qui a motivé Google à développer des outils personnalisés. « Et cet outil est TypeScript », explique Evan Martin. « La force du compilateur Closure réside dans sa sortie optimisée, tandis que TypeScript possède une interface utilisateur performante et aucune optimisation. Les deux outils sont complémentaires et peuvent être combinés (avec un peu de travail) », dit-il. « Parce que TypeScript fonctionne déjà pour la plupart (c'est en partie la raison de l'adopter), nous obtenons de nombreux avantages en adoptant un langage établi. [...] Le travail qui nous reste à accomplir a été principalement l'intégration : permettre à nos applications de migrer progressivement vers TypeScript sans tout réécriture à partir de zéro. »


Google a donc investi dans l'intégration de ses outils avec TypeScript. Parmi ces investissements, on peut citer un projet (en bêta) pour intégrer le compilateur TypeScript avec Bazel, le système de build qui a été utilisé en interne par Google avant d'être publié en open source. En dehors de cela, Google travaille également sur une intégration de TypeScript dans le système de type/module de Closure, et les résultats semblent déjà concluants. Evan Martin affirme donc si vous utilisez les produits Google, alors il est probable que vous ayez interagi avec du code TypeScript.

Source : Billet d'Evan Martin

Et vous ?

Que pensez-vous des problèmes de développement chez Google qu'a évoqués Evan Martin ?
Croyez-vous que TypeScript est la meilleure solution pour les résoudre ?

Voir aussi :

Babel : la version 7.0 du transpileur JavaScript est disponible avec le support de TypeScript, et bien d'autres nouvelles fonctionnalités
TypeScript 3.0 est disponible en version stable : un aperçu des nouveautés de cette version majeure du surensemble typé de JavaScript
TypeScript 2.9 est disponible et intègre plusieurs nouveautés, le langage continue de compléter son système de typage
TypeScript entre dans le top 20 des langages les plus populaires, d'après le classement Redmonk de juin 2017
Le projet AssemblyScript compile un sous-ensemble de TypeScript en WebAssembly, il est open source et disponible sous licence Apache 2.0


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de micka132 micka132 - Membre expert https://www.developpez.com
le 06/09/2018 à 9:04
Citation Envoyé par Michael Guilloux Voir le message
Et la raison se trouverait dans la quête éternelle de Google de remplacer JavaScript avec des solutions plus efficaces et qui contournent les limites du standard de facto pour le développement Web.
Fallait pas pondre V8 alors...quelque chose me dit que sans ca JS ne serait pas ce qu'il est aujourd'hui.
Pour l'évolution des outils OK, mais quand c'est mieux!
Le nouveau Gmail est une vrai merde. Lent, et 3 fois sur 4 apres avoir lu un mail, il est toujours marqué comme non lu. Avec une telle version gmail n'aurais jamais percé à l'époque...

 
Contacter le responsable de la rubrique Accueil