IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

JavaScript Discussion :

La spécification WebAssembly Core est désormais un standard web officiel


Sujet :

JavaScript

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre Expert
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Novembre 2009
    Messages
    2 056
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Novembre 2009
    Messages : 2 056
    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...

  2. #2
    Membre éclairé

    Femme Profil pro
    Experte JS / Conseillère en best practices / Chercheuse en programmation
    Inscrit en
    Octobre 2007
    Messages
    741
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Experte JS / Conseillère en best practices / Chercheuse en programmation
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2007
    Messages : 741
    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

  3. #3
    Membre très actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    891
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 : 891
    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.
    ...

  4. #4
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 325
    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 325
    Billets dans le blog
    12
    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

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  5. #5
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    Mars 2012
    Messages
    1 970
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

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

    Informations forums :
    Inscription : Mars 2012
    Messages : 1 970
    Par défaut
    Une tuerie les fleurs de l'arbre qui tombent

  6. #6
    Membre très actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    427
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 427
    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.

  7. #7
    Membre éprouvé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juillet 2009
    Messages : 1 030
    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.

  8. #8
    Membre Expert Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 678
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 678
    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.

  9. #9
    Membre très actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    427
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 427
    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"... ?

  10. #10
    Membre Expert Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 678
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 678
    Par défaut
    Citation Envoyé par pol2095 Voir le message
    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"... ?
    Il n'y a pas de compilateur C++ intégré au navigateur. Le système de fonctionnement sera du type :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    +--------------------+     +---------+     +-------------+
    | Developpeur        |     | Serveur |     |  Navigateur |
    +--------------------+ ==> +---------+ ==> +-------------+
    |C++/Rust/... -> Wasm|     | Wasm    |     |Wasm -> natif|
    +--------------------+     +---------+     +-------------+
    Le Wasm aura accès aux même API que JavaScript, ni plus ni moins.

  11. #11
    Membre très actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    427
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 427
    Par défaut
    D'accord, c'est un langage de bytecode (comme Java) donc moins rapide que du natif, mais plus facile à faire fonctionner sur des systèmes différents.

  12. #12
    Membre très actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    427
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 427
    Par défaut
    j'ai testé la démo sur mon ultrabook, ça saccade par rapport à la vidéo, avec en plus un beau plantage de Firefox. Sur mobile, il ne faut même pas y penser pour le moment.
    De plus le temps de chargement...

  13. #13
    Membre averti
    Profil pro
    Développeur Full Stack
    Inscrit en
    Janvier 2012
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Full Stack

    Informations forums :
    Inscription : Janvier 2012
    Messages : 69
    Par défaut
    D'un cote, c'est la mort lente du client léger qui est à l'origine du web...
    De l'autre cote, ca ouvre la porte du navigateur à d'autres langages, et du coup, ça signe peut etre une periode où on pourra réduire la fragmentation de nos stacks entre back et front autrement qu'en faisant du js cote serveur...

  14. #14
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Billets dans le blog
    9
    Par défaut
    j'ai le sentiment que cela vas finir comme cela ces finis avec les activeX et les applets Java.
    ActivX 1995 : Technologie du futur vous aller pouvoir exécuter du C++ dans le navigateur, c'est finit le client lourd
    Applet Java 1995 : Technologie du futur vous aller pouvoir exécuter du java dans le navigateur, c'est finit le client lourd
    Falsh player 1996 : Technologie du futur vous aller pouvoir faire de la 3D dans le navigateur, c'est finit le client lourd

    10ans plus tard ces technos sont considéré comme un cancer tres dangereuse pour les machines.
    20ans plus tard on est enfin presque arrivé à s'en débarrasser (les activeX sont encore utilisé en Corée du sud)

    2012 HTML5 : technologie du futur il pourra tous faire et sera en plus multiplate-forme et intégré de base dans le navigateur sans pouvoir le désactiver.
    => toutes les 3 semaines les browsers reçoivent des maj de sécurité de la meme manciere qu'avant on faisait les maj de adobe flash player et java
    entre temps on le fait évoluer, HTML5 prend le contrôle de la caméra, du micro, des devices USB, peut créer des fichiers dans le disque dur....
    les pub flash qui bouffait 100% du cpu pentium4 monocœur ont été remplacé par du minage de bitcoin en js qui bouffe 100% du cpu et en plus c'est multicœurs

    mais le js c'est pas assez puissant, on vas créer webassembly, du code C/C++ compilé exécuté dans le navigateur, j’émets de grosse crainte quand on sait que le C est le langage le plus sujet aux failles de sécurité liée à la mémoire (ce qui est logique), Corruption mémoire, Kernel Stack/Heap...

    ne me dites pas que ces technos sont safe et qu'elles ont été conçue des le départ pour être inviolable, soyons sérieux il y'a déjà eu des virus qui se sont installé via du code JS, je vois pas poruquoi il en serait autrement avec webassembly.

  15. #15
    Expert confirmé
    Avatar de Watilin
    Homme Profil pro
    En recherche d'emploi
    Inscrit en
    Juin 2010
    Messages
    3 094
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : En recherche d'emploi

    Informations forums :
    Inscription : Juin 2010
    Messages : 3 094
    Par défaut
    Ça c’est la vision pessimiste.

    Les anglophones ont ce mot, hindsight, qu’on peut traduire plus ou moins adroitement en sagesse rétrospective et qui désigne le fait qu’on apprend de nos erreurs et qu’on produit quelque chose de meilleur à chaque itération.

    Certes, on n’arrêtera jamais de faire des erreurs, mais l’écosystème du Web produit des choses moins maladroites, plus efficaces, plus sûres qu’il y a dix ou vingt ans. Aujourd’hui, les navigateurs demandent l’autorisation à l’utilisateur·trice avant d’exécuter un ActiveX ou un plugin. Les requêtes médias et autres APIs (caméra, micro, géolocalisation, etc.) ont été conçues dès le départ sur ce principe d’autorisation.

    Aujourd’hui les choses sont mieux cloisonnées et il est plus facile d’ajouter des sécurités quand le besoin se fait sentir. Exemple avec la récente décision de Firefox de limiter la méthode toDataURL des canevas, la soumettant à l’autorisation de l’utilisateur·trice, pour prévenir le fingerprinting.

    Le problème du minage de bitcoin est un cas pathologique, on pourrait s’en servir pour accuser n’importe quelle techno. Il y aura toujours des failles, et des pirates pour exploiter ces failles.

    Tes craintes sur les failles de C[++] sont infondées car il est clairement écrit que le WASM est exécuté dans une sandbox sécurisée. Encore une fois, hindsight. Tu sais, je suppose, qu’on peut écrire du code C[++] sécurisé en respectant les bonnes pratiques établies. Considère que le modèle de sécurité des navigateurs oblige à respecter ces bonnes pratiques.

    Tu le dis très bien, aucune techno n’est inviolable, mais est-ce une raison pour fustiger toute tentative de progrès ?
    La FAQ JavaScript – Les cours JavaScript
    Touche F12 = la console → l’outil indispensable pour développer en JavaScript !

  16. #16
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par Watilin Voir le message
    Tu le dis très bien, aucune techno n’est inviolable, mais est-ce une raison pour fustiger toute tentative de progrès ?
    évidemment que non, n'aimant pas le JS c'est d’ailleurs une bonne nouvelle pour moi d'avoir autre chose (je fais pas de web donc je fais partie des plus concernée par ce probleme).

    Considère que le modèle de sécurité des navigateurs oblige à respecter ces bonnes pratiques.
    d'un autre coté de ce que j'ai vue de cette techno, sa sera juste du code ayant les mêmes fonctionnalités que JS mais il sera "pre-compiler" pour que celui-ci soit directement interprété.
    Il ne s'agit donc pas d'étendre les possibilités mais juste d'optimiser le poids et le temps d'exécution en codant en C/C++ au lieu du JS. C/C++ (ou n'importe quels autre langages au passage comme du Go, du python ou du... js )

    Tes craintes sur les failles de C[++] sont infondées car il est clairement écrit que le WASM est exécuté dans une sandbox sécurisée.
    Oui, les implémentations seront vraisemblablement bound checked.

  17. #17
    Membre Expert Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 678
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 678
    Par défaut
    Citation Envoyé par RyzenOC Voir le message
    j'ai le sentiment que cela vas finir comme cela ces finis avec les activeX et les applets Java.
    ActivX 1995 : Technologie du futur vous aller pouvoir exécuter du C++ dans le navigateur, c'est finit le client lourd

    Applet Java 1995 : Technologie du futur vous aller pouvoir exécuter du java dans le navigateur, c'est finit le client lourd
    Falsh player 1996 : Technologie du futur vous aller pouvoir faire de la 3D dans le navigateur, c'est finit le client lourd
    La situation est quand même très différente.
    • Pour Active X le soucis était que c'était une technologie intrinsèquement non portable car totalement centrée sur Windows et dangereuse niveau sécurité. Elle brisait allègrement la frontière entre ce qui est la charge de l'OS et du navigateur.
    • Pour Java, Flash ou (p)NaCl, le soucis et que c'était des technologies qui arrivaient comme une rustine par dessus les spécification du web.et les navigateurs n'avaient aucune maîtrise dessus. Elles étaient sous le contrôle d'une seule société. Enfin leurs API étaient généralement en doublon de celles de HTML et s'intégraient plus ou moins mal avec.

    La principale différence de Wasm avec les technologies précédentes, c'est qu'il aura accès exactement aux mêmes API que le JavaScript, pas plus. Ce qui fait qu'il aura, entre autre une surface d'attaque bien plus faible. Il le fera juste de manière plus performante vu que ce bytecode ne sera pas limité par les spécificités d'un langage de haut niveau.

    Citation Envoyé par RyzenOC Voir le message
    toutes les 3 semaines les browsers reçoivent des maj de sécurité de la meme manciere qu'avant on faisait les maj de adobe flash player et java
    Pour info les navigateurs majeurs reçoivent déjà des mises a jour de sécurité planifiées toutes les 4 semaines (IE, Edge) ou six semaines (Chrome,Firefox), voire moins en cas de faille dangereuse exploitable. Donc wasm ne devrait pas changer pas grand chose au problème.

    Citation Envoyé par RyzenOC Voir le message
    mais le js c'est pas assez puissant, on vas créer webassembly, du code C/C++ compilé exécuté dans le navigateur, j’émets de grosse crainte quand on sait que le C est le langage le plus sujet aux failles de sécurité liée à la mémoire (ce qui est logique), Corruption mémoire, Kernel Stack/Heap...
    Sauf que l'on ne va pas compiler directement le C sur le client et l'executer comme si c'était n'importe quelle application. On passe par l'intermédiaire d'un bytecode qui offre des garanties de sécurité(accès mémoire contrôlé) et bien sur il sera exécuté dans une sandbox avec des accès réduits.

    Citation Envoyé par RyzenOC Voir le message
    ne me dites pas que ces technos sont safe et qu'elles ont été conçue des le départ pour être inviolable, soyons sérieux il y'a déjà eu des virus qui se sont installé via du code JS, je vois pas pourquoi il en serait autrement avec webassembly.
    Le risque zéro n'existe pas, mais ces technologies ont en effet été conçues pour être aussi "safe" que possible à défaut d'être inviolable. Cette technologie n'est ni plus ni moins sure que le JavaScript qui est déjà présent partout dans les navigateurs.

  18. #18
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    9 371
    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 : 9 371
    Par défaut La spécification WebAssembly Core est désormais un standard web officiel
    La spécification WebAssembly Core est désormais un standard web officiel
    après HTML, CSS et JavaScript, WebAssembly devient le quatrième langage pour le Web qui permet au code de s'exécuter dans le navigateur

    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 (ou wasm).

    À la base, WebAssembly est une architecture de jeu d'instructions virtuelle qui permet des applications hautes performances sur le Web et peut être utilisée dans de nombreux autres environnements. Il existe plusieurs implémentations de WebAssembly, notamment des navigateurs et des systèmes autonomes. WebAssembly peut être utilisé pour des applications telles que les codecs vidéo et audio, les graphiques et la 3D, le multimédia et les jeux, les calculs cryptographiques ou les implémentations de langage portables. Soutenu par le W3C, ce projet ambitionne de simuler un processeur virtuel, capable d’exécuter des programmes à une vitesse proche du code natif. Il faut préciser qu’il ne part pas de zéro, puisqu’il reprend les principes d’asm.js, une technologie qui sert à booster la capacité de traitement des applications web.

    Nom : web.png
Affichages : 316876
Taille : 40,4 Ko

    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 ». Toutefois, comme l’a expliqué l’ingénieur Mozilla Lin Clark, 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 ».

    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.

    Parmi les démonstrations fonctionnelles qui ont été apportées, nous pouvons citer celle d'AngryBots,une adaptation d’un jeu Unity. Limin Zhu, le responsable programme Chakra chez Microsoft, avait présenté une démo d’AngryBots sur le navigateur Edge qui se servait alors du support préliminaire de WebAssembly dans le moteur Chakra, il a avancé « qu’en dépit de leur statut précoce, la démo démarre beaucoup plus rapidement qu’en utilisant uniquement asm.js, puisque les binaires WebAssembly ont une taille de fichier réduite et sont parsés plus rapidement que du JavaScript ordinaire ».


    WebAssembly, ce langage bas niveau semblable à l'assembleur, permettant d'atteindre des performances proches des applications natives (par exemple écrites en C/C++) tout en fonctionnant sur le Web, apporte un certain nombre d'options aux développeurs, entre autres :
    • la possibilité de profiter du format compact wasm pour transmettre des fichiers rapidement sur le réseau et les charger en tant que modules JavaScript ;
    • la possibilité d'obtenir des performances quasi natives sans utiliser de plug-in ;
    • la possibilité d'écrire un code à la fois performant et sécurisé, car il s'exécute dans le sandbox de sécurité du navigateur ;
    • un choix de langages en dehors de JavaScript. Il permet par exemple aux développeurs d'écrire du code en C ou C++, puis de compiler directement en wasm, sans devoir compiler le code en JavaScript d'abord. En dehors de C/C++, des langages supplémentaires seront supportés à l'avenir.

    Avec les avantages qu’il présente, il n’a fallu que deux ans à tous les principaux fournisseurs de navigateurs pour prendre en charge le nouveau standard ; depuis 2017, le support de WebAssembly est disponible dans tous les principaux navigateurs notamment Firefox, Chrome, Safari et Microsoft Edge.

    Jeudi 5 décembre 2019, le World Wide Web Consortium (W3C) a annoncé que la spécification WebAssembly Core est désormais une norme Web officielle : « après HTML, CSS et JavaScript, WebAssembly devient le quatrième langage pour le Web qui permet au code de s'exécuter dans le navigateur », note le W3C.

    « L'arrivée de WebAssembly élargit la gamme d'applications qui peuvent être réalisées en utilisant simplement les technologies Open Web Platform. Dans un monde où l'apprentissage automatique et l'intelligence artificielle deviennent de plus en plus courants, il est important d'apporter des applications hautes performances sur le Web, sans compromettre la sécurité des utilisateurs », a déclaré Philippe Le Hégaret, chef de projet W3C.

    Le WebAssembly Working Group et le Community Group travaillent déjà sur une gamme de fonctionnalités pour les futures versions de la norme.

    Source : W3C

    Et vous ?

    Que pensez-vous de WebAssembly ?
    Vous en êtes-vous déjà servi ? Si non, étant donné qu'il est devenu une norme, allez-vous envisager de le faire pour vos développements Web ?

    Voir aussi :

    Mozilla, Fastly, Intel et Red Hat lancent l'Alliance Bytecode, une initiative construite autour de WebAssembly qui propose d'apporter plus de sécurité, d'ubiquité et d'interopérabilité sur le Web
    50 % des sites web utilisent WebAssembly à des fins malveillantes, selon une étude de la Technische Universität Braunschweig
    Mozilla finance un portage de Julia en WebAssembly, afin d'effectuer des calculs lourds au sein du navigateur
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  19. #19
    Inactif  

    Homme Profil pro
    Écrivain public, Économiste et Programmeur Free Pascal
    Inscrit en
    Août 2005
    Messages
    350
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Écrivain public, Économiste et Programmeur Free Pascal
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2005
    Messages : 350
    Billets dans le blog
    40
    Par défaut
    Il faudra vérifier chaque lien et surtout le code source du processeur déclenché derrière. Je préfère me passer d'Intel pour avoir du Atom dans ce cas là.

    Ça m'a affolé qu'on puisse exécuter du Javascript avec un navigateur. Peu d'informaticiens arrivent à déchiffrer l'asm.

    Qu'est-ce que implémentations de langage portables ?

  20. #20
    Membre éprouvé Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2007
    Messages
    1 213
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

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

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 213
    Par défaut
    Citation Envoyé par matthius Voir le message
    Ça m'a affolé qu'on puisse exécuter du Javascript avec un navigateur. Peu d'informaticiens arrivent à déchiffrer l'asm.
    Moi ça m'affole pas plus que ça. J'étais plus affolé par ActiveX où l'on pouvait faire des actions hors du navigateur. JS et Wasm sont cloisonnés à une page de navigateur. Puis aujourd'hui faire un site sans ça c'est compliqué ou fait tout faire à l'ancienne.

    Et je te mets au défit de déchirer ce code JS : https://js1k.com/2019-x/details/4130
    Pas besoin de faire de l'asm pour rendre un code illisible.

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