Discussion :

[Michael Guilloux]

Le projet AssemblyScript compile un sous-ensemble de TypeScript en WebAssembly
il est open source et disponible sous licence Apache 2.0

AssemblyScript est un projet qui vise à créer un pont entre WebAssembly et le surensemble JavaScript typé de Microsoft, TypeScript. WebAssembly est un langage de programmation binaire de bas niveau pour le développement d’applications dans les navigateurs Web. Introduit en 2015, il est actuellement standardisé dans le cadre du W3C. WebAssembly est destiné à dépasser les performances de JavaScript en matière d'exécution d'opérations à forte intensité de calcul dans un navigateur, avec un format de code binaire portable conçu pour rendre les applications Web plus rapides.

D’après la page GitHub du projet, AssemblyScript définit un sous-ensemble de TypeScript qu'il compile en WebAssembly. Il vise à fournir à toute personne avec un background en TypeScript et les API JavaScript standard un moyen confortable de compiler en WebAssembly, éliminant la nécessité de basculer entre les langages ou d'en apprendre d'autres uniquement à cette fin.

Ce que fait AssemblyScript sous le capot, c'est qu'il « relie » l'API du compilateur de TypeScript au backend de Binaryen (un compilateur et toolchain pour WebAssembly, écrit en C ++.) Il faut également noter que le compilateur lui-même est écrit et basé sur TypeScript et aucune dépendance binaire n'est requise pour commencer à l'utiliser. En outre, « chaque programme AssemblyScript est syntaxiquement valide en TypeScript, mais pas nécessairement sémantiquement », est-il précisé sur la page GitHub du projet.

Plutôt que de procéder à une réimplémentation aussi proche que possible de TypeScript au détriment de la performance, AssemblyScript tente, « aussi raisonnable que possible », de supporter ses fonctionnalités, en laissant intentionnellement de côté certaines constructions dynamiques. Il faut noter que :

• tous les types doivent être annotés pour éviter les conversions implicites de type indésirables ;
• les paramètres optionnels de fonction nécessitent une expression d'initialisation ;
• les types d'union (sauf ClassType | null représentant un nullable), any et undefined ne sont pas pris en charge par conception ;
• le résultat des expressions logiques &&/|| est toujours bool.

Le développement d’AssemblyScript est actuellement en phase bêta comme l'indique son développeur principal, Daniel Wirtz. Le projet est disponible sous licence Apache, version 2.0. Vous pouvez également déjà tester AssemblyScript directement dans votre navigateur.

Source : GitHub

Et vous ?

Que pensez-vous de l’utilité de projet ?
L'avez-vous déjà testé ? Qu'en dites-vous ?

[sbeex]

Donc si j'ai bien compris c'est du typescript sans être complètement du typescript ?

J'ai parfois l'impression que dans le monde JS au moindre conflits lors d'une pull request sur github les gars font un "fork" du projet existant, lui trouve un autre nom, changent 2 ou 3 trucs et voilà hop un nouveau truc est sorti mais pas franchement mieux que l'ancien au final...

[Vulcania]

@sbeex :
ça rien à voir, c'est du typescript avec une nouvelle cible de compilation, et c'est un projet très intéressant vu que ça permet de s'échapper complètement du javascript, après ben forcément c'est pas tout à fait du typescript parce tout n'est pas encore implémenté.

[sbeex]

ça rien à voir, c'est du typescript... ça permet de s'échapper complètement du javascript ... forcément c'est pas tout à fait du typescript

J'ai rarement lu autant de contradiction dans une seule phrase

Plus sérieusement je trouve vraiment ridicule de faire un projet a côté de typescript qui utilise du typescript. Ce projet a moins d'être supervisé par une entreprise (comme c'est le cas de typescript par exemple) ne sera jamais en phase avec typescript... Pourquoi ne pas tout simplement proposer au projet typescript d'ajouter ce compilateur et travailler main dans la main ?

Diviser pour mieux régner c'est bien mais diviser pour bâcler c'est moins bien.

PS: lâchez vos moins si ça vous fait zizir c'est pas en forkant à tout va qu'on améliore la vie des devs

[yahiko]

Pour répondre à la question précédente, l'équipe TypeScript ne prévoit pas à court ou moyen terme de supporter le WebAssembly.
D'où l'existence de ces projets "montés dans un garage".
AssemblyScript est l'un de ces projets, prometteurs, auquel je participe même si les difficultés à surmonter pour faire le pont entre le WebAssembly et TypeScript sont assez colossales.

[koyosama]

Enfin un projet coherent. Si il y a moyen de se debarasser de Javascript je suis preneur.
Meme utiliser Typescript, tu dois connaitre un peu Javascript. Et puis le web assembly a ete cree pour sa. J'aimerais bien quelque chose de plus rapide que Javascript avec les syntax et la logique des languages classiques.
J'aimerais bien qu'il le fasse pour Ruby. Non Coffeescript sort du Javascript et tu sens toujours cette syntax Javascript derriere a l'utilisation, je veux un full Ruby to Web Assembly.

[Invité]

Web assembly n'a pas vocation a remplacer le JS coté front end mais à le soulager. En gros tu crées une sorte d'API pilotable par le JS.

Ce genre de projet a beaucoup de potentiel car pour créer un module wasm aujourd'hui tu dois le coder en C/C++, et je serais bien curieux de connaître la proportion de dev. web compétents dans l'un de ces langages.

[Vulcania]

J'ai rarement lu autant de contradiction dans une seule phrase

Plus sérieusement je trouve vraiment ridicule de faire un projet a côté de typescript qui utilise du typescript. Ce projet a moins d'être supervisé par une entreprise (comme c'est le cas de typescript par exemple) ne sera jamais en phase avec typescript... Pourquoi ne pas tout simplement proposer au projet typescript d'ajouter ce compilateur et travailler main dans la main ?

Diviser pour mieux régner c'est bien mais diviser pour bâcler c'est moins bien.

PS: lâchez vos moins si ça vous fait zizir c'est pas en forkant à tout va qu'on améliore la vie des devs

T'es juste complètement à côté de la plaque, il y a pas de fork dans cette histoire, mais une nouvelle implémentation, d'où tes -1.

[koyosama]

Web assembly n'a pas vocation a remplacer le JS coté front end mais à le soulager. En gros tu crées une sorte d'API pilotable par le JS.

Ce genre de projet a beaucoup de potentiel car pour créer un module wasm aujourd'hui tu dois le coder en C/C++, et je serais bien curieux de connaître la proportion de dev. web compétents dans l'un de ces langages.

Pilotable par Js pas sure. Web Assembly vient de l'initiative ASM.js ou tu peux faire du C / C++ et le transformer en JS.
Comme toi, comme tout language c'est complementaire. JS ne pourra disparaitre. Mais je pense qu'il regle deux problemes :

• Le choix du langage cote navigateur. Apres tout on a encore des trucs sous flash, sous Java. Apres on a Dart, Typescript, Coffeescript, ... pour au final se retrouver avec du Javascript.
• La vitesse, je ne connais toujours pas de jeux online via le browser qui existe sans utiliser flash. J'ai essayer par exemple EmpireofCode car je voulais une alternative a Screeps (Non coding game n'est pas le meme concept). Mais que ce soit screeps ou EmpireofCode, sur un vieux ordinateurs, une vielle connexion a 10 mega (qui n'est pas le plus lent), c'est juste la misere.

Je ne veux pas mentionner Javascript car c'est soit complementaire ou soit pas du tout. C'est a votre usage mais le but est de ne pas empecher l'autre.
Et puis Web Assembly ne sera pertinent avant 3-4 ans. Un language met en moyenne cette periode pour devenir stable et un conpcet navigateur en plus. Mais sa va dans la bonne direction.

[Paleo]

auquel je participe

Ah ? Eh bien, bon courage.

Par curiosité, quelle est l'approche ? Réécrire un parseur from scratch (mais sans dépendances wahou) ? Ou bien arrivez-vous à utiliser le compilateur TypeScript pour accéder à l'AST et générer une nouvelle sortie ?

[Paleo]

Web assembly n'a pas vocation a remplacer le JS coté front end mais à le soulager. En gros tu crées une sorte d'API pilotable par le JS.

C'est aussi ce que j'ai compris.

Ce genre de projet a beaucoup de potentiel car pour créer un module wasm aujourd'hui tu dois le coder en C/C++, et je serais bien curieux de connaître la proportion de dev. web compétents dans l'un de ces langages.

D'un autre côté, si les Web Assemblies sont au JavaScript ce que les modules PHP sont au PHP, le langage C++ ne devrait pas empêcher l'écosystème de grandir. Pour PHP aussi les modules sont faits en C++.

[Invité]

Pilotable par Js pas sure. Web Assembly vient de l'initiative ASM.js ou tu peux faire du C / C++ et le transformer en JS.

Je ne sais pas pour ASM.js, mais Web Assembly n'a pas pour objectif de transformer du C++ en JS. Un module wasm c'est un genre de programme exécutable par ton navigateur, et ton navigateur offre une API en javascript pour faire le pont entre ton appli web et ce programme. L'exemple des jeux est bon car on peut imaginer qu'un module existe pour mettre ta carte graphique à profit, ce que tu ne peux pas (à ma connaissance) faire en JS simple.

Mozilla possède une documentation sympa pour web assembly (je met pas le lien car ça à été supprimé par le passé je ne sais pas trop pourquoi, une recherche simple t'y amènera).

D'un autre côté, si les Web Assemblies sont au JavaScript ce que les modules PHP sont au PHP, le langage C++ ne devrait pas empêcher l'écosystème de grandir. Pour PHP aussi les modules sont faits en C++.

Bien vu ! Je ne sais pas trop si ces modules vont être des "simples" drivers qui font le pont entre ton hardware et ton navigateur, ou si ça va être des applications type framework genre le prochain Angular/React, ou carrément l'application complète genre Youtube.

[koyosama]

Je ne sais pas pour ASM.js, mais Web Assembly n'a pas pour objectif de transformer du C++ en JS. Un module wasm c'est un genre de programme exécutable par ton navigateur, et ton navigateur offre une API en javascript pour faire le pont entre ton appli web et ce programme. L'exemple des jeux est bon car on peut imaginer qu'un module existe pour mettre ta carte graphique à profit, ce que tu ne peux pas (à ma connaissance) faire en JS simple.

Je ne vois toujours pas le rapport avec Javascript . Voici le lien qui explique pourquoi WASM a ete cree : Lien
Ces propos que je tiens simplement parce que j'etais la quand les conference sur ASM.js a ete fait en France durant Microsoft Techdays. Et dans le lien donnee, ils disent bien que c'est pour avoir un truc 20x plus rapide que Javascript et que c'est ce n'est une extension et meme ils disent qu'ils veulent remplacer le moteur Javascript.

Javascript n'a rien a voir avec WASM et comme son nom l'indique il va se comporter comme un programme assmbleur au level d'un Browser-Engine. Et si tu es familie avec TIL ou Java JVM, rien de tempeche de creer d'autres languages au dessus et l'interpeter. Aujourd'hui les transcompiler sont extrement limite par Javascript car ils ont pas d'alternative. Maintenant tu as peudo bit-code qui peut etre envoye depuis m'importe quel serveur et qui fait plus que Javascript. Ce pseudo code n'est pas regi par les restrcition de javascript comme le scoping, le hoinsting , ... enfin tous les concepts de Javascript qui empechent les transcompiler d'etre ce qu'ils sont aujourd'hui.

Tu peux voir ici les use-case dans l'esprit des createurs : lien

Ici tu peux voir la definition d'ASM.js. Je me rappelle tres bien comment fonction ASM.js car c'est l'arnque du siecle. Quand HTML5 etait sorti, tout le monde a applaudi pour dire qu'on peut maintenant cree des jeux avec Javascript. En fait ce qu'ils ont oublie de dire c'est que code en dure Javascript c'est tellement pas optimise que t'es bolige d'utiliser ce genre d'outil qui va transformer un code en Javascript et optimiser l'utilisation memoire.

Alors je le redis WASM n'a rien a voir avec Javascript, Javascript peut utiliser WASM mais pas forcement le contraire.