+ Répondre à la discussion Actualité déjà publiée
  1. #61
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 943
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 943
    Points : 8 241
    Points
    8 241

    Par défaut

    il existe un prototype de compilateur pour un langage appelé thinscript
    ça n'a absolument rien d'opérationnel.

    ce qui est intéressant c'est que thinscript n'est que peu ou prou du TypeScript.
    l'un comme l'autre sont des langages qui peuvent sans difficulté être interprété. Mais pour un usage normal on passe par une phase de compilation.
    TypeScript fournis un compilateur écrit en typescript qui produit du js.
    de ce fait le compilateur lui-même s'exécute sur node-js et produit un script JS.

    thinscript est conçu de la même façon. il est écrit en thinscript mais il produit soit du js soit du c soit du wasm
    ainsi le compilateur peut être recompilé avec gcc ou autre et produire un exécutable
    mais une application produite avec thinScript pourra par ce biais être exécuté par node-js ou un navigateur si on a produit du js
    sur une machine si on est passé par une compilation C
    ou sur WebAssembly.

    typescript tout comme thinscript sont des langage très proche de javascript. voire encore plus des dernière génération ecmascript.
    il montre bien que de tels langages peuvent être compilés.
    il est un point qui lui ne peut absolument pas être compilé c'est la génération de code dynamiquement. je ne parle pas d'affecter une fonction à un membre ou ce genre de chose mais bien de définir du code dans une string pour l’exécuter ensuite.
    Mais ce point est facile à résoudre dans WASM moyennant quelques astuces. L'interactivité WASM/JS est prévue et il est possible de faire appel à JS pour évaluer un script. lors de la compilation il faut donc dans ce cas généré un appel à js
    en gros tout le reste peut être compilé.

    Quels intérêts ? j'en vois deux
    permettre au développeur front de continuer à travailler dans leurs langages front.
    produire un exécutable dont le source n'est pas "directement" accessible du client. (au même titre qu'un code C++ peut être désassemblé le code WASM peut être converti en AST lisible par un développeur.)
    ces deux points sont des inquiétude forte de la communauté.

    attention tout comme le projet thinscript il s'agit d'un test qui n'a pas vocation à aboutir.
    j'ai écrit en thinscript un complément pour produire un compilateur thinscript qui s'exécute sur la JVM.
    ce compilateur fonctionne avec eclipse et maven et produit directement depuis un sources thinscript un js un wasm un c
    Mais il montre qu'on peut produire du WASM avec les outils habituels des développeurs.
    Dans le même ordre d'idée en me basant sur http://www.jsweet.org/ j'ai regardé comment produire un WSAM à partir de java
    Il ne s'agit pas d’exécuter une JVM ou du code JAVA sur le navigateur. il s'agit d'utilise la SYNTAXE java pour développer des appli front
    seule la syntaxe est retenue. c'est la même approche que le compilateur java du gnu qui produit un exec pour votre machine.
    il n'embarque pas de JVM seule la syntaxe est retenue. là encore le compilateur JAVA va produire un AST qu'il faut parcourir pour produire le wasm, d ela même façon que Javac parcours l'AST pour produire du ByteCode.

    A+JYT

  2. #62
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 563
    Points : 962
    Points
    962

    Par défaut

    Citation Envoyé par sekaijin Voir le message
    Quels intérêts ? j'en vois deux
    permettre au développeur front de continuer à travailler dans leurs langages front.
    Ah, tu me rassures, mon idée ne semble donc pas si idiote que ça
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

  3. #63
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    2 642
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 2 642
    Points : 55 884
    Points
    55 884

    Par défaut WebAssembly a-t-il pour vocation de remplacer à long terme JavaScript ?

    WebAssembly a-t-il pour vocation de remplacer à long terme JavaScript ?
    Le standard est au centre des discussions des développeurs web

    Au départ, en 1995, JavaScript a été présenté comme un langage léger pour les scripts assez simples. De plus, il a été pensé de telle façon qu’il soit facilement utilisable, même par les développeurs novices, pour des choses relativement simples, comme s’assurer que vous avez rempli un formulaire correctement lorsque vous le soumettez par exemple.

    Plus tard, en 2008, a été lancé ce qui a été désigné comme étant la guerre des performances ; les navigateurs ont commencé à ajouter la compilation à la volée (JIT, une technique visant à améliorer la performance de systèmes bytecode compilés par la traduction de bytecode en code machine natif au moment de l'exécution). Tandis que le JavaScript s’exécutait, le JIT pouvait voir des modèles et faire en sorte que le code s’exécute plus rapidement en fonction de ces modèles. C’est ce qui a contribué à l’amélioration des performances de JavaScript qui a alors commencé à être utilisé pour plus de choses qu’il n’était censé gérer au départ, comme la programmation côté serveur avec Node.js.

    Pourtant, malgré ces améliorations, il arrive que les performances soient imprévisibles. Aussi, pour accélérer les choses, le JIT a ajouté quelques éléments à l'exécution, parmi lesquels :
    • l’optimisation et la désoptimisation ;
    • de la mémoire utilisée pour les informations de compatibilité et de récupération du moniteur pour les cas où des récupérations se produisent ;
    • de la mémoire utilisée pour stocker les versions de base et optimisées d'une fonction.

    Autant d’éléments qui font qu’il arrive que le navigateur ne peut pas exécuter une application aussi rapidement qu’en natif. C’est alors qu’intervient WebAssembly.

    Avec WebAssembly qui a été activé par défaut sur Firefox 52, le premier navigateur à l’embarquer, il serait intéressant de faire le point dessus. Tout d’abord, comme l’explique l’ingénieur Mozilla Lin Clark, « WebAssembly est un moyen de prendre du code écrit dans des langages de programmation autres que JavaScript et d'exécuter ce code dans le navigateur ».

    Il est déjà arrivé sur des forums de discussion que les développeurs se demandent si WebAssembly a vocation de remplacer à long terme le JavaScript étant donné que le standard a été vanté comme étant « plus rapide que JavaScript ». Mais l’ingénieur tient à préciser que ce n’est pas le but ; s’il reconnaît également que WebAssembly s’avère plus rapide que JavaScript dans certains domaines, il précise qu’il ne veut pas sous-entendre que vous aurez à faire un choix entre WebAssembly et JavaScript : « en fait, nous nous attendons à ce que les développeurs utilisent WebAssembly et JavaScript dans la même application ».

    Toutefois, pour bien souligner l’impact potentiel de WebAssembly, il a procédé à des séries d’études comparatives qui ont pour objectif de montrer aux développeurs en quoi WebAssembly est « plus rapide que JavaScript », tout en donnant des exemples concrets où des ingénieurs pourraient opter pour une coexistence de WebAssembly et JavaScript. Il a évoqué le cas de l’équipe React, de Facebook, qui pourrait remplacer le code de leur DOM virtuel par une version WebAssembly : « les gens qui utilisent React n’auront rien à faire ; leurs applications vont fonctionner comme avant et elles vont bénéficier des avantages apportés par WebAssembly ».

    WebAssembly permettra donc aux applications complexes de fonctionner de façon optimale sur navigateur – telles que les jeux vidéo immersifs en 3D, le design informatisé, l’édition d’image et de vidéo et la visualisation scientifique. À ce propos, des démonstrations ont été mises en ligne l'année dernière, désormais il s’agit de passer à une implémentation concrète. Les développeurs pourront utiliser WebAssembly pour accélérer les applications web existantes.

    Au fil du temps, de nombreuses applications de productivité existantes (par exemple les services de messagerie, les réseaux sociaux, les outils de traitement de texte) et des framework JavaScript vont probablement profiter de WebAssembly pour réduire considérablement les temps de chargement et améliorer simultanément les performances tout en fonctionnant. Contrairement à d'autres approches qui ont besoin de plug-ins pour obtenir des performances quasi natives dans le navigateur, WebAssembly fonctionne entièrement dans la plateforme Web. Cela signifie que les développeurs peuvent intégrer des bibliothèques WebAssembly pour des calculs intensifs (par exemple la compression, la détection de visage) dans des applications Web existantes qui utilisent JavaScript pour des travaux moins intensifs.

    Pour avoir une idée du rendu avec WebAssembly, voici une démo proposée de Zen Garden par Epic Games qui allie WebAssembly et WebGL 2 dans Firefox 52.


    « Nous espérons que, comme WebAssembly continue d'évoluer, vous pourrez également l'utiliser avec des langages de programmation souvent utilisés pour les applications mobiles, comme Java, Swift et C# », a déclaré Mozilla.

    Source : introduction à WebAssembly (Mozilla Hack)

  4. #64
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    mars 2016
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2016
    Messages : 24
    Points : 91
    Points
    91

    Par défaut

    Je pense personnellement que WebAssembly a un potentiel absolument spectaculaire, notamment au niveau de la VR et des applications lourdes qui seront encore plus faisables sur navigateur sans avoir besoin de téléchargement conséquent. Mais pour les sites web "classiques" comme on en voit aujourd'hui de partout, aucune raison de passer par autre chose que JS, il fait le travail.

  5. #65
    Membre éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    457
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juillet 2007
    Messages : 457
    Points : 707
    Points
    707

    Par défaut

    Il y a beaucoup de raison de passer a WebAssembly pour tous ou presque.
    1) Pour les gros sites, avoir un site plus efficace (site plus rapide = plus de visiteurs).
    2) Pour les royalties avoir un code encore plus illisible que la simple minification.
    3) Pour les petits site, s'ils utilisent un framework (Jquery) ou un CMS), cela sera transparents... alors refuser des performances en plus.

    Il restera toujours du javascript sur le web de même qu'il existe toujours des sites pur HTML (sans Javascript) pour plusieurs raison:
    - Moins de failles de sécurité.
    - Plus simple à développer / déployer.
    ...
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  6. #66
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 098
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 098
    Points : 2 596
    Points
    2 596
    Billets dans le blog
    10

    Par défaut

    Utiliser WebAssembly ne signifie pas que JavaScript va disparaître, rien n'empêchera de développer en JavaScript pour produire du WebAssembly (lorsque le GC sera opérationnel).
    Nous pouvons faire un parallèle avec le bytecode de la JVM, on peut développer avec le langage que l'on souhaite (Scala, Groovy etc), ce n'est pas pour autant que le langage Java a disparu
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  7. #67
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 059
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 059
    Points : 1 671
    Points
    1 671

    Par défaut

    Une tuerie les fleurs de l'arbre qui tombent
    Si la réponse vous a aidé, pensez à cliquer sur +1

  8. #68
    Membre émérite
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 190
    Points : 2 611
    Points
    2 611

    Par défaut

    Citation Envoyé par Tartare2240 Voir le message
    des applications lourdes qui seront encore plus faisables sur navigateur sans avoir besoin de téléchargement conséquent.
    Tu parles de quels téléchargements conséquents?

  9. #69
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    mars 2016
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2016
    Messages : 24
    Points : 91
    Points
    91

    Par défaut

    Exemple totalement bancal : le jour où on arrivera à faire un outil aussi puissant que GIMP directement avec WebAssembly, on aura plus besoin de télécharger GIMP et, lorsqu'on voudra l'utiliser, on aura toujours la dernière version. Certes le serveur devra envoyer un sacré paquet de données à toutes les personnes voulant l'utiliser mais avec le futur de la connexion web, ce sera pas trop un problème... Enfin je l'espère... Ahem...

    * A été traumatisé par les mises à jour Java *

  10. #70
    Membre émérite
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 190
    Points : 2 611
    Points
    2 611

    Par défaut

    Citation Envoyé par Tartare2240 Voir le message
    Exemple totalement bancal : le jour où on arrivera à faire un outil aussi puissant que GIMP directement avec WebAssembly, on aura plus besoin de télécharger GIMP et, lorsqu'on voudra l'utiliser, on aura toujours la dernière version. Certes le serveur devra envoyer un sacré paquet de données à toutes les personnes voulant l'utiliser mais avec le futur de la connexion web, ce sera pas trop un problème... Enfin je l'espère... Ahem...

    * A été traumatisé par les mises à jour Java *
    Ca ne changera strictement rien au fait que le navigateur doivent télécharger les 100 megas de Gimp.
    Au mieux ca simplifie un peu pour les développeurs qui ne doivent pas se soucier de comment faire parvenir les mise à jour automatiquement vers le client.
    D'un autre coté ca va poser les problèmes à l'utilisateur qui veut faire rapidement une petite modif sur un fichier pour une présentation dans 10 min et qui doit attendre que la mise à jour se termine...pas de bol ce jour là son internet rame à mort . Pour gérer ces cas là finalement il faudra un mécanisme de téléchargement en fond avec rechargement partiel...bref le developpeur y reperdra .
    En vérité WebAssembly c'est comme flash ou les applets java, sauf que les gros du web se sont plus ou moins entendus pour pondre un truc en commun, mais ca n'a absolument rien de révolutionnaire.
    Il y a donc les meme avantages : un developpement simplifié par rapport à JS avec des performances normalement meilleurs, sauf que ca sera non maitrisé par certains dev et comme flash on va se retrouver avec un affichage de texte qui te tue ton navigateur sans raison apparente...

  11. #71
    Membre du Club
    Profil pro
    Inscrit en
    novembre 2007
    Messages
    235
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2007
    Messages : 235
    Points : 68
    Points
    68

    Par défaut

    Je pense que le niveau générale des programmeurs web est très faible, ça n'aura qu'une faible portée.
    Vu la place qu'on pris les apps sur mobile, ça arrive trop tard, de plus par rapport à une app, le navigateur à quand même de grosses restrictions, ne serait-ce que pour l'accès au disque local ?
    Ensuite il y a quand même la surcouche du navigateur, qui fera qu'il sera toujours plus lent qu'une app native.
    Tout est bon quand même pour se débarrasser de la daube javascript, qui n'est pas du tout adapter pour de gros projet (absence de classes...).
    C++ par exemple dépend de la compétence des programmeurs et peut très vite créer des failles importantes sur un système, et peut même s'avérer très lent s'il est mal programmé, et quand on regarde la qualité des bibliothèques javascript c'est inquiétant.

  12. #72
    Membre actif
    Homme Profil pro
    Directeur de projet
    Inscrit en
    novembre 2014
    Messages
    175
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2014
    Messages : 175
    Points : 283
    Points
    283

    Par défaut

    À la vue des spécifications d'ASM on est loin de la mort de JavaScript http://asmjs.org/spec/latest/

    This specification defines asm.js, a strict subset of JavaScript that can be used as a low-level, efficient target language for compilers. This sublanguage effectively describes a sandboxed virtual machine for memory-unsafe languages like C or C++. A combination of static and dynamic validation allows JavaScript engines to employ an ahead-of-time (AOT) optimizing compilation strategy for valid asm.js code.
    Les développeurs C et C++ penseront certainement que la spécification a été écrite par un développeur JavaScript ( for memory-unsafe languages like C or C++ je dirais plutôt developer-unsafe languages )

    Le problème resteras toujours le même tant que les différents paradigmes des langages de programmation ne serons pas clairement distingué pendant les formations des futures développeurs, on apprend généralement cette distinction mais on s'en rend réellement compte que bien après, après des années de POO ou de prototypages voir de programmation fonctionnelle pour les plus originaux, du coup passer de l'un à l'autre demande une gymnastique mentale qui arrive souvent trop tard dans la vie professionnelle.

    Les dev .Net ou Java s'échinerons toujours corps et âme à trouver la librairie Javascript qui permet de faire de la POO quand on leur demandera de migrer leur belle application Desktop en Full Web plutôt que de révisé leur façon de faire (sans jeter la pierre j'ai fait pareil).

    Et les développeurs Javascript, et bien ceux-là ils peuvent pleurer pour ajouter une méthode à un prototype sans passer par une étude approfondie des méthodes d'extension .Net (et encore en lisant les Guideline ils comprendrons que c'est déconseillé).

    La cible première d'ASM est clairement JavaScript. Doit-il disparaître pour autant ... En relisant tous vos messages il semble évident que ceux qui développe du front depuis un peu de temps font rarement du javascript, plutôt du Type Script, du Dart ou autre, avec des grunts,des gulps pour automatiser tout ce qui peut l'être. Donc pourquoi ASM s'appuie sur JavaScript et pas directement sur un de ces langages (qui disposent de tout ce qu'il faut à mon avis pour être directement compilé sans passer par la case JavaScript) ?

  13. #73
    Membre éprouvé Avatar de marsupial
    Homme Profil pro
    DevOp, Tech leader
    Inscrit en
    mars 2014
    Messages
    511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : DevOp, Tech leader

    Informations forums :
    Inscription : mars 2014
    Messages : 511
    Points : 1 111
    Points
    1 111

    Par défaut

    * le navigateur s'affranchit du matériel grâce à l'OS
    * JS comme WebAssembly sont standardisés

    ==> des applications métiers totalement portables et indépendantes de l'environnement système/matériel

    Je ne vois pas son avenir dans les sites web en dehors de quelques retouches par-ci par-là.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  14. #74
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    mars 2016
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2016
    Messages : 24
    Points : 91
    Points
    91

    Par défaut

    Citation Envoyé par micka132 Voir le message
    Ca ne changera strictement rien au fait que le navigateur doivent télécharger les 100 megas de Gimp.
    A ce niveau-là, je suis d'accord, y'aura toujours le téléchargement qui risque de prendre des plombes. Mais de ce coté-là, je pense que ce sera le compilateur en WebAssembly qui peut gérer le système d'update, avec par exemple "Téléchargement de la dernière mise à jour terminée. Veuillez rafraichir votre navigateur pour en profiter pleinement." Et ça, ça me fait rêver

    Un exemple pratique, il m'a été une fois demandé de faire un outil web pour une entreprise car déployer un logiciel sur tous les PC aurait été une véritable misère et aurait pris des semaines et car beaucoup de PC étaient encore sous Windows XP (en 2016). Cela aurait été beaucoup plus simple et plus rapide de créer un soft pour mais à cause de cette problématique, on a demanda une appli web. Avec WebAssembly, cette contrainte n'aurait pas existé

  15. #75
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 563
    Points : 962
    Points
    962

    Par défaut

    Citation Envoyé par Tartare2240 Voir le message
    Exemple totalement bancal : le jour où on arrivera à faire un outil aussi puissant que GIMP directement avec WebAssembly, on aura plus besoin de télécharger GIMP et, lorsqu'on voudra l'utiliser, on aura toujours la dernière version. Certes le serveur devra envoyer un sacré paquet de données à toutes les personnes voulant l'utiliser mais avec le futur de la connexion web, ce sera pas trop un problème...
    Scuce de l'expression... mais t'es un grand malade...

    J'doute pas que certaines boites en arrivent là un jour mais j'trouve ça tellement inconscient, ne serait-ce que pour des raisons de coûts énergétiques/environnementaux
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

  16. #76
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    mars 2016
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2016
    Messages : 24
    Points : 91
    Points
    91

    Par défaut

    Citation Envoyé par Lcf.vs Voir le message
    Scuce de l'expression... mais t'es un grand malade...
    On m'a toujours dit qu'il me manquait un grain quelque part

    En fait je vois tellement de choses qui pourraient être faites par le consortium des navigateurs (mises en cache des ressources téléchargées, versionning...) et les avantages actuels du web (uniformité selon les OS, un seul code source...) que, avec une association de tous les grands noms, ça pourrait littéralement révolutionner le web qu'on voit aujourd'hui et lui rajouter toutes les grosses applications. Du coup, au niveau coût énergétique/environnemental, ce sera pas plus cher qu'un check régulier des versions et d'un téléchargement des nouvelles versions car tout serait stocké chez le client.

  17. #77
    Membre expert

    Homme Profil pro
    Ingénieur Etudes et Développements Junior
    Inscrit en
    juillet 2009
    Messages
    874
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Etudes et Développements Junior
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 874
    Points : 3 520
    Points
    3 520

    Par défaut

    L'inconvénient que j'ai pu remarquer c'est que WebAssembly n'a vraiment un intérêt qu'à partir de technologies d'assez bas niveau comme le C++.

    Le bytecode est un langage proche du langage machine. Donc le langage se doit d'être assez proche pour pouvoir gérer la mémoire, le processeur, de manière précise. Les garbage collector et optimisations "propriétaires" de langages de haut niveau seraient mis à mal, et au final, non seulement on pourrait, dans le cas de Dart (qui génère du javascript optimisé) ou de frameworks comme JQuery, générer un bytecode non optimisé et plus lent que le Javascript, mais également créer des failles de sécurité plus dangereuses (comme avec Java Web Start et les Applets Java) donnant alors un accès bas niveau à des hackers.

    Des tests ont déjà été faits en ce sens, par exemple ici : https://medium.com/dartlang/dart-on-...a70#.wwqoasl55

    C'est pour ça que WebAssembly serait très efficace, mais à partir de technologies pouvant être compilées en bytecode telles quelles, sans transformations préalables. Ce n'est pas la même utilité que le JS. C'est plus dédié à de véritables applications sur le web voire même des jeux vidéo 3D.

  18. #78
    Membre actif
    Inscrit en
    octobre 2005
    Messages
    85
    Détails du profil
    Informations forums :
    Inscription : octobre 2005
    Messages : 85
    Points : 209
    Points
    209

    Par défaut

    Citation Envoyé par Tartare2240 Voir le message
    A ce niveau-là, je suis d'accord, y'aura toujours le téléchargement qui risque de prendre des plombes. Mais de ce coté-là, je pense que ce sera le compilateur en WebAssembly qui peut gérer le système d'update, avec par exemple "Téléchargement de la dernière mise à jour terminée. Veuillez rafraichir votre navigateur pour en profiter pleinement." Et ça, ça me fait rêver
    Je pense plutôt à le coupler avec les service workers, qui est justement la pour faire ce boulot.
    Avoir une version offline et télécharger en arrière plan la maj au besoin, notification via events des que c'est finie. Refresh pour avoir la nouvelle version.

  19. #79
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 472
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 472
    Points : 8 004
    Points
    8 004

    Par défaut

    Citation Envoyé par abriotde Voir le message
    Il y a beaucoup de raison de passer a WebAssembly pour tous ou presque.
    1) Pour les gros sites, avoir un site plus efficace (site plus rapide = plus de visiteurs).
    2) Pour les royalties avoir un code encore plus illisible que la simple minification.
    3) Pour les petits site, s'ils utilisent un framework (Jquery) ou un CMS), cela sera transparents... alors refuser des performances en plus.

    Il restera toujours du javascript sur le web de même qu'il existe toujours des sites pur HTML (sans Javascript) pour plusieurs raison:
    - Moins de failles de sécurité.
    - Plus simple à développer / déployer.
    ...
    A peu près d'accord sauf sur la lisibilité du code. Ça n’arrêtera jamais que les débutants. Et de toute façon si on veut faire du code illisible, il y a des outils qui font plus que de la simple minification tout en restant en JavaScript.

    Pour les failles de sécurité, il n'y a pas de raison a ce qu'il n'y en ait plus en Wasm qu'en JavaScript. Les deux reposent sur les mêmes API et sont compilés en natif en JIT.

    Citation Envoyé par Gugelhupf Voir le message
    Utiliser WebAssembly ne signifie pas que JavaScript va disparaître, rien n'empêchera de développer en JavaScript pour produire du WebAssembly (lorsque le GC sera opérationnel).
    En théorie, on peut déjà le faire maintenant, vu que rien ne t’empêche d'implémenter son propre GC en WASM.
    C'est juste qu'on ne fera probablement pas mieux que ce que font déjà les navigateurs Web.

    Citation Envoyé par champsy_dev Voir le message
    À la vue des spécifications d'ASM on est loin de la mort de JavaScript
    http://asmjs.org/spec/latest/
    ...
    Donc pourquoi ASM s'appuie sur JavaScript et pas directement sur un de ces langages (qui disposent de tout ce qu'il faut à mon avis pour être directement compilé sans passer par la case JavaScript) ?
    Là, il y a un grosse confusion entre "asm.js" et "WebAssembly" : c'est deux technologies différentes, même si elles on des buts en partie communs.
    - asm.js s'appuie sur le JavaScript car c'est la base minimale que gèrent tous les navigateurs web. Ça lui permet de pouvoir être exécutés sur tous les navigateurs, y compris ceux qui ne gèrent pas spécifiquement la technologie.
    - WebAssembly (ou Wasm), au contraire ne se base plus sur JavaScript mais sur un bytecode qui vise à être bien plus efficace en temps de chargement et de compilation. Par contre il ne fonctionnera que sur les navigateurs qui le gèrent spécifiquement.

    Citation Envoyé par Lcf.vs Voir le message
    Scuce de l'expression... mais t'es un grand malade...

    J'doute pas que certaines boites en arrivent là un jour mais j'trouve ça tellement inconscient, ne serait-ce que pour des raisons de coûts énergétiques/environnementaux
    En jouant avec les spécifications récentes du W3C qui permettent de mettre explicitement des ressources en cache, ce n'est pas si idiot que ça en fait.

  20. #80
    Membre du Club
    Profil pro
    Inscrit en
    novembre 2007
    Messages
    235
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2007
    Messages : 235
    Points : 68
    Points
    68

    Par défaut

    Pour la vitesse, ça dépend également du compilateur C++ intégré dans le navigateur.
    Est-ce qu'il y a des limitations, par exemple sous Windows, a-t-on accès aux librairies Windows comme "Winhttp"... ?

Discussions similaires

  1. Réponses: 2
    Dernier message: 12/04/2012, 08h18
  2. Réponses: 1
    Dernier message: 04/11/2011, 17h11
  3. Microsoft propose une version d'évaluation gratuite de Project 2010
    Par Gordon Fowler dans le forum Actualités
    Réponses: 10
    Dernier message: 18/06/2010, 14h47
  4. Réponses: 6
    Dernier message: 09/07/2009, 09h46
  5. Réponses: 0
    Dernier message: 08/07/2009, 13h56

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo