Trolloscope Who is the best ? - Page 89

Ah, ça c'est une bonne nouvelle ! On va enfin pouvoir arrêter de se traîner le boulet du JS et utiliser d'autres langages mieux conçus.

Ahahah... non. En tout cas pas avant un booooon moment.
Le support de vieux navigateurs, en particulier les IE6-9, obligera à continuer d'utiliser des fallbacks JS jusqu'à ce qu'ils représentent une part négligeable d'utilisation, et on a encore du temps avant que cela n'arrive malheureusement.
Mais on peut toujours tabler sur des technos tierces pour convertir ces codes en JS en guise de fallback.

En réalité rien ne l'empêche dès maintenant.

Vu que le but est de faire un bytecode js, on pourra toujours faire interpréter ce bytecode par du pur js équivalent, qui lui même est optimisable par le moteur JS du navigateur. c'est le role de asm.js (asmjs.org)

Meowcate (./2642) :
Ahahah... non. En tout cas pas avant un booooon moment.
Le support de vieux navigateurs, en particulier les IE6-9, obligera à continuer d'utiliser des fallbacks JS jusqu'à ce qu'ils représentent une part négligeable d'utilisation, et on a encore du temps avant que cela n'arrive malheureusement.Mais on peut toujours tabler sur des technos tierces pour convertir ces codes en JS en guise de fallback.

Tu peux déjà oublier tout ce qui est antérieur à IE8
De plus, le renouvellement est de plus en plus rapide vu que les différents navigateurs sont mis à jour de façon de plus en plus automatique.

C'était pourtant pas mal, PNaCl... mais c'est resté single-vendor, alors que WebAssembly est omni-vendor.
Comme PNaCl, et pour de bonnes raisons, la toolchain standard WebAssembly est basée sur les technos LLVM.

À priori cette techno essayé de capitaliser sur les retour d'expérience de asm.js et pNaCl. Le bytecode, en plus de la légèreté, vise à être stable et rapide à traiter ce qui était un défaut du LLVM-IR qui n'était pas prévu pour ce type d'usage.
Il évite également de passer par une infrastructure de plugin specifique (PPAPI). Il y aura uniquement accès aux API Web.

Ils auraient pu utiliser EM

Je connais pas EM et je trouve rien dessus, c'est quoi?

Un bytecode, utilisé par une toolchain assez ancienne mais toujours vivante, qui fonctionne un peu de la meme maniere que LLVM, et EM qui est bytecode intermediaire, est executable par une VM:

http://tack.sourceforge.net/olddocs/em.pdf

Certain point du Amsterdam Compiler Kit peuvent faire un peu vieillot (il a été désigné en 1984) mais compte tenu de quand ce projet a commencé, il est très intéressant a étudier et propose pas mal de choses novatrice pour l'epoque

flAnker (./2644) :
Tu peux déjà oublier tout ce qui est antérieur à IE8 smile

Très sincèrement, j'aimerai bien. Mais je dis cela parce que je me le tape encore. Notre plus gros client qui nous appelle parce que plusieurs des utilisateurs de son appli ont des soucis de fonctionnement du fait d'exceptions propres à IE7.

flAnker (./2644) :
De plus, le renouvellement est de plus en plus rapide vu que les différents navigateurs sont mis à jour de façon de plus en plus automatique.

Justement, quand je parle des IE6-9, je parle d'une part non négligeable ne navigateur qui ne se préoccupent pas de la MAJ auto, où on était dans une optique "ça viendra avec l'achat du nouveau Windows".

squalyl (./2643) :
Vu que le but est de faire un bytecode js, on pourra toujours faire interpréter ce bytecode par du pur js équivalent, qui lui même est optimisable par le moteur JS du navigateur. c'est le role de asm.js (asmjs.org)

Cela ne risque pas de faire bobo aux performances pour les vieux navigateurs ? on accélère les récents et on ralentit les anciens.

Les perfs ne semblent pas être une préoccupation de la plupart des développeurs Web. Sérieusement, essaie de consulter les sites actuels avec une vieille machine et/ou un vieux navigateur (sans bloqueur de pub, tant qu'à faire). Et pleure.

Le développement d'Adblock Edge s'arrête (merci à The_Cure pour l'info).

Le remplaçant recommandé est µBlock, dont il existe deux variantes : µBlock "tout court" et µBlock Origin, ce dernier étant un fork de µBlock par l'auteur original de ce dernier (c'est bon, vous suivez toujours ? ).
Apparemment, il vaudrait mieux choisir le fork : http://ohax.fr/oubliez-pachydermique-adblock-plus-ublock-origin-est-arrive
Les deux versions sont censées êtres moins consommatrices de RAM qu'Adblock Plus/Edge.

Au passage, j'ai découvert un nouveau moyen de pistage :
https://developer.mozilla.org/fr/docs/Web/API/Navigator/sendBeacon
Super...

Cette fonction semble surtout être un moyen équivalent mais plus light aux "pixels", c'est à dire ajouter un pixel invisible (via une balise <img>) qui n'a pour but que de déclencher un appel vers une URL arbitraire. J'ai l'impression que ça ne permet rien de plus, mais qu'au moins l'impact sur le navigateur est plus léger (pas de création d'un élément inutile dans le DOM, et requête asynchrone).

D'après la description, c'est surtout censé servir à renvoyer des infos quand on ferme une page :

This method addresses the needs of analytics and diagnostics code that typically attempt to send data to a web server prior to the unloading of the document. Sending the data any sooner may result in a missed opportunity to gather data. However, ensuring that the data has been sent during the unloading of a document is something that has traditionally been difficult for developers.

Pourquoi pas, mais ce genre de trucs ne devrait pas être activé par défaut, ou au minimum configurable. Or il semble que ça ne soit pas le cas : http://www.wilderssecurity.com/threads/hyperlink-auditing-aka-a-ping-and-beacon-aka-navigator-sendbeacon.364904/
(mais ça a peut-être évolué depuis)

Au final ça ne change pas grand chose vu que ce genre de traçage est déjà faisable avec un XHR. C'est juste une manière plus simple de le faire.

La feature n'aurait absolument aucun intérêt si elle n'était pas activée par défaut... désactivable pourquoi pas, désactivée par défaut n'incitera jamais personne à la supporter.

Pour revenir à l'esprit du trolloscope originel, testez votre navigateur pour ECMAScript 6 (la dernière monture Javascript) : https://ruanyf.github.io/es-checker/

Actuellement, j'obtiens un 69% sur mon Firefox Dev 41.02a dernières MAJ, 11% sur mon vieux Chromium 34.0 (même pas idée de la dernière maj de celui-ci)

(ils sont pas à 40 pour chromium ?)

64% sur firefox 39

28% après deux crashs sur firefox 21

vince (./2658) :
(ils sont pas à 40 pour chromium ?)

J'ai dit "vieux" Chromium c'est celui des dépôts de mon Linux Mint, alors que mon Firefox Dev a été installé manuellement.

Tiens j'ai 50% la avec le chrome de je sais pas quand qu'il date (43.0.2357.130 m)

La dernière stable de Chrome est 43.0.2357.132, autant dire que tu es à jour à une goutte d'eau près.
Pour la dev, 45.0.2439.3

Mmm ? Perso je suis en 45.0.2450.0

Je me demande quand ce *** c'est MaJ

C'est la magie de Chrome. Il se met a jour tout seul, discrètement, sans demander ton avis, et c'est pas désactivable.

(nah mais j'ai chromium, je viens de le télécharger suite à la demande de test d'un collègue)

Faites trèès gaffe a flash, la fuite de Hacking Team a révélé un zeroday "packagé pro", donc facile a déployer et a exploiter, et qui n'est donc pas encore patché par adobe dans sa dernière version.

Attention donc aussi a Chrome dans lequel on ne peut apparemment pas facilement désactiver flash.

safari est à la rue (19.

je me souviens d'un article récent expliquant que ça devenait le nouvel IE, l'auteur n'avait pas tort ^^

(C'est juste pour quelques outils, mais merci pour la mise en garde — d'ailleurs c'est sans doute pour ça que Firefox a désactivé le flash player un peu partout)