mais oui, mais précisément, voilà ! Il est devenu complètement impossible de se passer de moyens de désactiver sélectivement le javascript dès qu'on a une navigation de quelques dizaines d'onglets : c'est quelque chose qui était complètement impensable il n'y a pas même 5 ans. Et ça c'est pour une raison toute simple : le javascript s'exécute beaucoup plus rapidement et incite donc les dévelopeurs à en abuser. C'est toujours la vieille histoire software becomes slower faster than hardware becomes faster.
Après, dire qu'il faut pas rendre JS plus rapide car JS ça bouffe du CPU, c'est pas très cohérent
Mais si, c'est cohérent : au départ, la lenteur de JS était intentionnelle, c'était un outil limité, destiné à rendre quelques services programmatiques, mais en évitant de rendre les ressources du client intéressantes pour le serveur.
Maintenant, qu'on veuille rendre JS plus efficace, qu'on le JIT, qu'on l'optimise pour qu'il bouffe moins de cycles pour une même tâche, c'est très bien, mais il devrait être limité en vitesse d'exécution par défaut (avec un mécanisme de réglage facile pour les applis exigeantes, voire une api standard pour demander ce genre de permission) et faire des petits usleep(3) des familles pour ne pas rendre ton système rentable à exploiter.
Tout le monde serait gagnant et tu n'aurais pas à faire tout ça manuellement avec ton plugin NoScript qui te casse 98% des sites par défaut - ce qui est quand même un hack incroyable !
[^] # Re: soit dit en passant
Posté par spart . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à -1.
C'est vrai que quand on utilise NoScript
mais oui, mais précisément, voilà ! Il est devenu complètement impossible de se passer de moyens de désactiver sélectivement le javascript dès qu'on a une navigation de quelques dizaines d'onglets : c'est quelque chose qui était complètement impensable il n'y a pas même 5 ans. Et ça c'est pour une raison toute simple : le javascript s'exécute beaucoup plus rapidement et incite donc les dévelopeurs à en abuser. C'est toujours la vieille histoire software becomes slower faster than hardware becomes faster.
Après, dire qu'il faut pas rendre JS plus rapide car JS ça bouffe du CPU, c'est pas très cohérent
Mais si, c'est cohérent : au départ, la lenteur de JS était intentionnelle, c'était un outil limité, destiné à rendre quelques services programmatiques, mais en évitant de rendre les ressources du client intéressantes pour le serveur.
Maintenant, qu'on veuille rendre JS plus efficace, qu'on le JIT, qu'on l'optimise pour qu'il bouffe moins de cycles pour une même tâche, c'est très bien, mais il devrait être limité en vitesse d'exécution par défaut (avec un mécanisme de réglage facile pour les applis exigeantes, voire une api standard pour demander ce genre de permission) et faire des petits usleep(3) des familles pour ne pas rendre ton système rentable à exploiter.
Tout le monde serait gagnant et tu n'aurais pas à faire tout ça manuellement avec ton plugin NoScript qui te casse 98% des sites par défaut - ce qui est quand même un hack incroyable !