PC & Mobile

Réactiver le Web avec WebAssembly – Yordan Yordanov

Réactiver le Web avec WebAssembly - Yordan Yordanov


La vidéo a tué la star de la radio. N'est-ce pas?

Photo de Tracy Thomas sur Unsplash

Retour dans les années 50 et 60, les émissions de télévision deviennent plus populaires que celles à la radio. C'est devenu la nouvelle chose.

Un mot circule sur le fait qu’une nouveauté dans le monde du développement Web est là pour mettre fin au monopole de JavaScript sur la programmation côté client. Nous allons essayer de démystifier cette rumeur à un très haut niveau. Nous allons commencer par les questions naturelles qui se posent lorsque vous rencontrez un nouveau type d’animal, tel que "Whaaaat?", "Comment?", Etc. Nous verrons pourquoi nous en avons besoin et quelles en sont les implications. Pour répondre à toutes ces questions, nous devrons ouvrir quelques livres d’histoire et parler un peu des compilateurs. Mais voyons d’abord ce que WebAssembly est réellement.

WebAssembly est un format binaire exécutable par les navigateurs Web qui le prennent en charge et par la plupart des navigateurs Web modernes. À l'instar de tout autre langage d'assemblage, il s'agit essentiellement d'un ensemble de règles permettant d'interpréter les octets, qui consistent en gros en des opérations et des données. Il s’agit d’une machine reposant sur une pile, ce qui signifie que les opérations peuvent pousser et / ou extraire des données sur une pile.

Voyons un exemple - un programme très simple qui additionne 1 et 1 puis l’envoie en sortie à une méthode magique appelée $ print . Le programme est affiché dans un format mnémonique, de sorte qu'il puisse être lu par des personnes

1 i32.const 1
2 i32.const 1
3 i32.add
4 call $ print

Nous commençons par mettre une valeur entière constante 32 bits de 1, puis une autre par dessus. le ajouter l'opération supprime 2 éléments et demande à l'ALU de faire un ajout. Une fois le calcul terminé, le résultat est renvoyé dans la pile. Enfin, la méthode magique ferait ressortir la valeur et ferait des choses magiques avec. Part de gâteau.

Lorsqu'il traite avec WebAssembly, le client Web commence par décoder ces instructions en instructions équivalentes à la machine, puis à les exécuter comme indiqué ci-dessus. La phase de décodage est très rapide, car elle est déjà très proche du langage machine. La phase d'exécution pourrait être assez performante (plus tard). Tout cela se fait dans un environnement de type "boîte à sable", ce qui signifie que vous n’avez pas à vous soucier des problèmes de sécurité (exploits de la mémoire, etc.). WebAssembly dispose également de liaisons JavaScript, ce qui lui permet de communiquer entre elles, ce qui est particulièrement utile lorsque vous souhaitez modifier le DOM depuis votre programme.

Sauf si vous êtes un programmeur d'assemblage expérimenté, écrire quelque chose de plus utile que d'ajouter 1 et 1 pourrait s'avérer une tâche très ardue, comme le montre l'exemple. Vous préférerez probablement opter pour une langue de niveau supérieur.

WebAssembly pourrait être généré à l'aide des chaînes d'outils LLVM. Ils sont conçus pour permettre et accélérer le processus de compilation des fichiers binaires pour plusieurs architectures, en effectuant certaines pré-optimisations de la source en la transformant en une représentation dite intermédiaire (IR). Il s’agit essentiellement d’un code machine abstrait. C’est encore peu compréhensible pour la machine, mais elle est beaucoup plus proche de sa contrepartie que sa contrepartie source originale et, en tant que telle, elle peut être transformée beaucoup plus facilement en une architecture spécifique. Les chaînes d'outils que vous pouvez utiliser aujourd'hui pour compiler WebAssembly sont Emscripten et PNaCl.

Dans un scénario traditionnel, le code source est d’abord transformé en un IR. Cette étape est appelée phase d'optimisation, conçue pour déduire les opérations de bas niveau nécessaires pour exécuter les instructions de haut niveau de la source. Comme nous l'avons déjà dit, ces instructions de bas niveau ne sont pas encore assez basses. Par conséquent, à l'étape suivante - la compilation, elles sont transformées en de nombreux binaires spécifiques à l'architecture et liées aux bibliothèques statiques requises. Le résultat est un exécutable qui ne peut être exécuté que sur cette architecture spécifique

Dans le cas de WebAssembly, l'IR est compilé selon la spécification WASM dans un fichier .wasm, que vous pouvez expédier avec votre application. La chaîne d’outils générera également un fichier .js contenant les liaisons nécessaires pour communiquer avec votre programme WASM. Un navigateur Web ayant reçu ceux-ci procédera comme expliqué dans la section précédente.

Il y a quelques alternatives à cela. Turboscript est un langage semblable à TypeScript qui se compile dans WebAssembly. Et il y a beaucoup plus de langues dans le pipeline à venir.

Alors, pourquoi devrions-nous nous préoccuper de tout cela, étant donné que JavaScript est pris en charge par les navigateurs depuis des décennies et fournit un paradigme de haut niveau agréable et facile à utiliser? Pour répondre à cette question, nous devons examiner la tendance générale des applications Web au fil des ans et savoir si JavaScript est en mesure de le suivre.

L'histoire derrière…
Le Web a commencé avec le premier site Web de Tim Berners Lee au début des années 90. Son objectif était de créer un réseau d’informations dans lequel vous pouvez cliquer sur certains éléments du texte, ce qui vous mènerait à d’autres pages (avec probablement plus d’informations sur ce que vous venez de cliquer). À ce stade, les pages ont été créées en écrivant manuellement du code HTML et le contenu était entièrement statique. Les gens ont commencé à prendre conscience de la puissance du Web, et progressivement les pages sont devenues plus interactives avec l’ajout de JavaScript, et un peu plus tard, tous les frameworks JS que nous connaissons et utilisons aujourd’hui. Du côté du serveur, les choses ont également commencé à changer: passer de fichiers statiques html et JS à appeler des scripts côté serveur (par exemple via CGI) pour créer des pages HTML générées dynamiquement. Tout cela crée une tendance importante: rapprocher les applications Web de l’expérience native, et nous la suivons depuis.

La légende raconte que JavaScript a été créé en quelques jours par Brendan Eich dans les années 90 pendant son séjour à Netscape. Ils venaient de s'associer à Sun Microsystems pour s'attaquer à MS Internet Explorer. Au départ, Eich souhaitait que le langage Scheme fonctionne dans son navigateur, mais sous l’influence de Sun et la popularité croissante de Java à l’époque, il finit par créer un langage de type Java appelé Mocha, qui, après plusieurs renommages, fut appelé Javascript. Il a été conçu pour faire des scripts rapides et compliqués pour accompagner le code HTML, sans faire de gros travail.

C'était censé être un compagnon pour Java, qui était également utilisé dans le navigateur pour le calcul de choses lourdes. Le développement d'applications Java était relativement plus difficile que le script, elles étaient lourdes, nécessitaient beaucoup de bande passante à télécharger et s'exécutaient dans une fenêtre de la page sans accès au DOM. JavaScript avait exactement l'intention inverse: être capable de manipuler le DOM de manière dynamique assez facilement.

Au cours des dix prochaines années environ, JavaScript devenait de plus en plus populaire et largement adopté. Java s'est finalement éteint côté client, tandis que des technologies comme AJAX et des infrastructures telles que jQuery ont poussé les capacités de JavaScript à écrire de meilleures interfaces utilisateur. Cependant, sa performance est restée à peu près la même, jusqu’aux environs de 2008.

Les éditeurs de navigateurs Web se sont battus pour fournir des performances JavaScript optimisées. Pour la première fois depuis la création du Web, les utilisateurs ont pu constater des améliorations dans ce domaine. Des cadres de haut niveau (tels que React et des milliers d’autres) ont été créés, ce qui permet de créer facilement et sans douleur des éléments très réactifs dans la page. Il a également amené JavaScript hors du navigateur Web dans certains territoires inattendus, tels que la programmation côté serveur avec Node.js et le développement d'applications mobiles avec React Native. La clé pour y parvenir consistait à faire passer JavaScript d’un langage purement interprété à un langage compilé juste à temps.

La mécanique
La possibilité de compiler des morceaux de code critiques dans un langage plus machine signifie que vous pouvez l'exécuter plus rapidement. Différents moteurs JavaScript ont adopté des approches légèrement différentes quant à la manière dont ils le font, mais l'idée générale est la même.

Lorsque le moteur obtient du code, il le transforme en code octet. Ce code d'octet pourrait ensuite être pré-optimisé en fonction des connaissances générales de ce moteur. Il irait ensuite de l'avant et procéderait à l'exécution. Le moniteur de moteur vérifierait le déroulement de l'exécution et s'il remarquait qu'un certain morceau de code était exécuté plusieurs fois de la même manière, il continuerait et serait optimisé.

Et nous n'aurions pas de problème si JavaScript n'était pas un langage typé dynamiquement. S'il s'avère que ce morceau de code a maintenant été appelé avec un type de données différent, le moniteur signale à l'exécuteur testateur qu'il ne peut plus exécuter ce code et qu'il doit revenir à une version antérieure du code.

Il est important de noter que la surveillance et la compilation prennent un peu de temps CPU. Si elles sont effectuées de temps en temps, elles peuvent accélérer les choses, le cas échéant, car leur temps de calcul serait comparativement plus court que le temps d'exécution total. Toutefois, si votre code se trouve dans l’embarras entre optimisation et dé-optimisation, vous rencontrez un problème réel, car l’effet inverse peut se produire: le temps d’exécution risque d’être plus lent que le scénario d’interprétation à la volée.

En outre, comme mentionné précédemment, différents moteurs JavaScript ont des implémentations différentes sur la compilation juste à temps, ce qui signifie que votre logiciel peut se comporter différemment sur différents navigateurs Web. Bien que cela convienne parfaitement pour des cas courants tels que le traitement d'interfaces utilisateur, il se peut que cela ne soit pas aussi parfait pour les scénarios dans lesquels vous souhaitez fournir une expérience fluide (par exemple, un rendu graphique).

Et voici où WebAssembly intervient à la rescousse: il fournit un code déjà proche de la machine, où rien de tout cela ne pourrait arriver. De plus, comme la majeure partie du travail est effectuée à l'avance, le décodage et la compilation de WASM prennent beaucoup moins de temps que l'analyse et l'optimisation de JavaScript.

À ce stade, vous penserez peut-être: «Génial, compilons tout le code JavaScript de WASM et en avons fini!». Ce serait bien si cela fonctionnait, mais voici le problème. Nous devons nous rappeler que WebAssembly évolue dans un monde de très bas niveau - il ne sait pas comment gérer la mémoire ni aucun type de données de haut niveau (du moins pour le moment). Il existe deux approches pour y remédier.

Dans une approche naïve, vous compileriez un interpréteur JavaScript complet dans WASM, juste pour atténuer cela. Ainsi, vous réinventerez l’eau chaude, car le navigateur en a déjà un, et il y a de fortes chances pour que ce soit meilleur que le vôtre.

Une autre approche consiste à introduire le typage et la gestion de la mémoire dans votre source JavaScript, en le portant sur TypeScript ou quelque chose de similaire. Bien que cela puisse être une option viable, vous devez peser très attentivement les travaux d’ingénierie requis pour le faire et les gains potentiels que vous pourriez avoir. Le plus souvent, il peut être préférable de transformer vos parties du code gourmandes en ressources processeur en WebAssembly à l'aide de l'outil de votre choix, tout en laissant le reste de votre code JavaScript tel quel.

La radio est-elle toujours en vie?
Oui, ça l'est. Peut-être sous une forme différente de celle d’il ya un moment, mais en 2019, elle est toujours là. Les personnes écoutent toujours de la musique à la radio, le cas échéant, tout comme elles utiliseront JavaScript pour créer des interfaces utilisateur pour le Web. Et tout comme la vidéo et la radio sont différentes, JavaScript et WebAssembly sont deux outils différents qui peuvent être utilisés ensemble pour créer des solutions permettant de résoudre le problème que nous avons posé précédemment: créer davantage d'applications de type natif pour le Web.

Vous pouvez considérer le JavaScript comme un couteau suisse, un outil toujours pratique et efficace, tandis que WebAssembly peut être considéré comme un outil chirurgical (un scalpel, par exemple) et peut être utilisé partout où vous avez besoin de cette précision. WebAssembly est loin de tuer JavaScript et ne vise pas à le faire. Son objectif est de combler le fossé entre les applications Web et la puissance de calcul disponible sur la plupart des appareils actuels. Mais oui, cela met fin au monopole de JavaScript car il introduit maintenant toute une variété de langages pouvant être utilisés pour écrire du côté client.

Afficher plus

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Articles similaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Bouton retour en haut de la page
Fermer