Est-il possible de se passer de JavaScript sur la toile ?

Est-il possible de se passer de JavaScript sur la toile ?
Après avoir désactivé JavaScript, Klint le réactive pour profiter de ses avantages

JavaScript est un langage qui a été créé en vue de renforcer l’interactivité des pages web. Au fil des années, il a gagné en maturité afin de s’imposer comme outil privilégié sur la toile. De même, sa forte expansion lui a permis de s’assurer une place sur bien d’autres plateformes telles que les systèmes embarqués, le cloud, etc.

Aussi, si ce langage offre de nombreux avantages, il faut reconnaître également que son abus sur la toile a grandement contribué à nuire à l’expérience utilisateur des internautes. Klint Finley qui est au fait de ces inconvénients a voulu améliorer son expérience de navigation en se débarrassant de JavaScript.

Au lieu d’utiliser certains outils comme NoScript ou LibreJS pour filtrer les fonctionnalités JavaScript tournant derrière les pages web, l’internaute a simplement désactivé l’option JavaScript disponible dans son navigateur.

Bien évidemment, cela ne s’est pas fait sans conséquence. Premièrement, l’internaute n’avait plus accès aux outils tels que Google docs pour travailler de manière collaborative sur la toile. Netflix n’était plus accessible. Pareil pour YouTube qui ne fonctionnait pas, du moins sans activer le plugin Flash d’Adobe.

Lorsqu’il a tenté d’ouvrir Facebook, le site l’a dirigé vers une version gratuite de JavaScript destinée aux téléphones mobiles. Et quand il a essayé d’ouvrir la page sur son téléphone, c’est une page blanche qui s’est affichée. Twitter par contre marchait, mais n’affichait plus le décompte des caractères, ce qui faisait qu’il n’était plus possible de savoir si les textes étaient trop longs ou pas.

Il pouvait également parcourir certains sites, mais n’arrivait pas laisser de commentaires, car les options dédiées n’apparaissaient pas. Certaines pages non plus n’arrivaient pas à se charger.

En dehors de ces aléas, tout le reste fonctionnait. Et même fonctionnait mieux, selon l’avis de Klint Finley.

La publicité intempestive qui se déclenchait automatiquement dans les fenêtres popup avait disparu. Klint pouvait désormais parcourir le web avec très peu de distraction. Les fonctionnalités comme le chargement automatique des pages nécessitant un défilement continu pour voir afficher les contenus situés en bas de page n’étaient plus actives non plus.

En revanche, les pages se chargeaient presque instantanément. La batterie de l’ordinateur portable durait plus longtemps avant de se décharger. Et il était moins exposé aux programmes indésirables exécutés avec JavaScript, mais cela n’empêchait pas les sites de collecter les données en utilisant les cookies ou d’autres méthodes.

Cependant, bien que la navigation fut agréable, plus rapide et débarrassée de publicité, Klint n’a pas pu résister à la volonté de revenir en arrière en activant JavaScript après avoir passé la semaine d’expérimentation. Les raisons mises en avant ici sont le fait que Klint désirait comme tout autre navigateur pouvoir utiliser les extensions de Google Chrome qui n’étaient plus fonctionnelles après avoir désactivé JavaScript, pouvoir avoir une interface graphique interactive sur les pages web ou encore pouvoir regarder les vidéos en streaming.

Le désir d’utiliser les fonctionnalités JavaScript a donc eu raison des avantages tirés en désactivant cet outil.

Source : Wired

Et vous ?

:fleche: Que pensez-vous de l’expérience de Klint ?

:fleche: Est-il possible de désactiver JavaScript et avoir par la même occasion une expérience de navigation agréable ?

:fleche: Est-il possible de se passer de JavaScript sur la toile ?

Voir aussi

:fleche: Forum JavaScript

Citation:

---

La publicité intempestive qui se déclenchait automatiquement dans les fenêtres popup avait disparu. Klint pouvait désormais parcourir le web avec très peu de distraction.

---

... vous direz à Klint qu'il y a adblock pour les sites comme ça :aie:

JavaScript est très sollicité par les sites pour être désactivé, parcourir un site sans JS c'est comme boire du cola sans caféine/sucre/bulles. Il ne sera possible de se passer du JS que si des projets comme WebAssembly arrivent à maturité, pour le moment c'est le monopole total.

Javascript fait désormais partie du web, sans lui, on ne peut pas espérer avoir les bienfaits de l'html5 (canvas* and co), ni le responsive permettant d'avoir le même site qui s'adapte à l'écran..

*note pour le canvas, sans javascript le bloc va s'afficher, mais on ne va pas pouvoir dessiner dessus ;)

Citation:

---

Envoyé par Olivier Famien

En dehors de ces aléas, tout le reste fonctionnait. Et même fonctionnait mieux, selon l’avis de Klint Finley.

Cependant, bien que la navigation fut agréable, plus rapide et débarrassée de publicité, Klint n’a pas pu résister à la volonté de revenir en arrière en activant JavaScript après avoir passé la semaine d’expérimentation. Les raisons mises en avant ici sont le fait que Klint désirait comme tout autre navigateur pouvoir utiliser les extensions de Google Chrome qui n’étaient plus fonctionnelles après avoir désactivé JavaScript, pouvoir avoir une interface graphique interactive sur les pages web ou encore pouvoir regarder les vidéos en streaming.

---

Je suis dans le même cas (enfin presque, NoScript au filtrage très strict, autorisation au cas par cas et de manière temporaire).

Le résultat est simple : Firefox ne prend plus 25% cpu sans raison avec quelques (beaucoup) d'onglets ouverts, la conso RAM a baisé (moins de 1Go), et tout est de manière générale plus rapide.
Seul problème, on se retrouve régulièrement face à des pages blanches.

Au final désactiver JS c'est comme activer Adblock : on redécouvre Internet.

Je recommande l'expérience, et pour les devs Web : SVP faites une version de vos sites qui marche sans JS. :)

Citation:

---

Envoyé par Iradrille

Je recommande l'expérience, et pour les devs Web : SVP faites une version de vos sites qui marche sans JS. :)

---

En tant que développeur Web pour du eCommerce, je vais répondre non. En 2015, il est impensable que quelqu'un désactive le JS. Si vous voulez le faire, vous devrez être au courant de ce que vous manquez. Le problème est que développer une version sans JS des sites prend tellement de ressources sur un projet commercial par rapport aux avantages que c'est considéré comme du Scope Creep.

C'est grâce au Javascript que mon site peut avoir des hautes performances. Je mets le cart en cache dans le Local Storage, je profite de l'AJAX pour éviter de faire des connexions inutiles vers mon engine eCommerce lors du chargement des pages (comme pour un Mini-cart). J'utilise aussi de plus en plus des stratégies qui relèvent du Single Page Application pour livrer des pages HTML en coquille vide qui proviennent de l'Output Cache et qui seront remplis de contenu à l'aide de calls REST et de Javascript. Retirer le Javascript, c'est me priver de tout ce qui rend mes sites performants, donc je ne le ferai pas. Désolé.

à part les sites de doc je ne connais pas beaucoup de site sans JS

Citation:

---

:fleche: Que pensez-vous de l’expérience de Klint ?

---

C'est mon quotidien.
Je fonctionne avec NoScript activé en permanence et très peu de sites en liste blanche, ADBlock+ et Ghostery.
Je n'active les scripts qu'au cas par cas et toujours en temporaire. et je suis déjà toujours très méfiant aux scripts qui sont extérieur au site que je visite.
Et il n'est pas rare que, dans le doute, je préfère aller voir ailleurs que d'activer du script aveuglément.

Citation:

---

:fleche: Est-il possible de désactiver JavaScript et avoir par la même occasion une expérience de navigation agréable ?

:fleche: Est-il possible de se passer de JavaScript sur la toile ?

---

Le désactiver et sans passer complètement, non, ce n'est pas possible. Bon nombre de sites ne fonctionnent plus correctement.
Par contre se passer des scripts qui lance des pubs, des popups, traceurs et autres joyeusetés non nécessaire à la consultation du site, oui on peut s'en passer et on se porte que mieux.

Bon nombre de dev web et de régies n'ont absolument rien compris au mouvement ADBlock et utilise désormais JS pour contourner ces bloqueurs et continuer leurs infectes pratiques intrusives. Ils sont en train de provoquer le même rejet de Javascript que celui qu'il y a sur la pub.

Citation:

---

Envoyé par Iradrille

Je recommande l'expérience, et pour les devs Web : SVP faites une version de vos sites qui marche sans JS

---

Autant je suis d'accord avec le reste du message, autant je ne le suis pas avec cette phrase. Moi, je ne demande des sites sans JS, mais des site avec JS utilisé à bon escient. Des sites sans JS qui sert à afficher de la pub ou autres infos non désirées, des sites sans JS qui trace tous nos fait et geste et qui envoie ça à Google, Facebook, Twiter, Amazon, etc.
Du Js pour le fonctionnement même du site, oui, du JS pour nous aliéner encore plus, non.

Des soucis sur les sites Google, Facebook, Twitter et Netflix. Du mieux sur tous les autres. Le constats est donc franchement positif pour le "vrai" web. Logique pour ces autres sites qui imposent un silo aux utilisateurs, raison de plus pour les abandonner.

Je ne comprends pas l'utilité de cette article.
La réponse est déjà sous-entendue.
D'autant plus qu'avec les frameworks one page on ne peut s'en passer.

Il faudrait dire ça aux développeurs de Firefox qui ont supprimé le bouton pour désactiver JavaScript...

C'est dommage de condamner une technologie juste parce que beaucoup font n'importe quoi avec. Comme l'a souligné greto, correctement utilisé le JS permet d'augmenter les performances en sollicitant moins le réseau, en profitant de nouveaux mécanismes de cache et en délocalisant une partie de la logique applicative côté client. C'est aussi le seul moyen d'avoir des sites web consultables hors-ligne, sans demander au client d'utiliser un aspirateur de sites.

Je comprends la frustration des utilisateurs qui vont quotidiennement sur des sites avec 3Mo de JS, des frameworks et libs en tout genre avec du code buggé et pas du tout optimisé. C'est d'autant plus énervant quand on est dev web et qu'on peut constater tous les problèmes d'un site juste avec F12. Ceci dit, en 2015 je ne pourrais pas supporter de naviguer sur la toile avec JS désactivé. Ne serait-ce que pour perdre AJAX et voir des rechargements de page complet à chaque clic sur un lien, non merci.

Les arguments du monsieur n'ont pas de sens. Javascript n'est pas mauvais en tant que tel (surtout d'un point de vue d'un utilisateur de site web) mais c'est l'utilisation qui en fait qui peut-être mauvaise. Sinon on peut reprocher a CSS d'être mauvais car ça permet d'utiliser des couleurs que l'on trouve pas sympa. D'ailleurs comme quelqu'un a mentionné le WebAssembly il est bon de rappeler que pour les problèmes reprochés à Javascript seront les mêmes avec le WebAssembly.

Après pour avoir essayé de navigué avec Javascript désactivé c'est peine perdu. Tellement de site en sont dépendant que le désactivé revient 1 n'avoir que des sites qui ne font pas ce pourquoi ils ont été prévu.

Non de nos jours il est difficilement possible de se passer de JavaScript d'un point de vue utilisateur. Tous les sites l'utilisent à l'instar de Flash il y a quelques années (mais il est maintenant plus dispensable). De plus, les bien-pensants du Web veulent qu'on n'utilise plus que ça pour le Web côté client. À mort les plugins et il ne reste donc plus que JS, au bon endroit au bon moment.

Mais dans un monde parfait les sites devraient pouvoir fonctionner sans JS, quitte à ce qu'ils soient moins performants.

Citation:

---

Envoyé par gretro

En tant que développeur Web pour du eCommerce, je vais répondre non. En 2015, il est impensable que quelqu'un désactive le JS. Si vous voulez le faire, vous devrez être au courant de ce que vous manquez. Le problème est que développer une version sans JS des sites prend tellement de ressources sur un projet commercial par rapport aux avantages que c'est considéré comme du Scope Creep.

C'est grâce au Javascript que mon site peut avoir des hautes performances. Je mets le cart en cache dans le Local Storage, je profite de l'AJAX pour éviter de faire des connexions inutiles vers mon engine eCommerce lors du chargement des pages (comme pour un Mini-cart). J'utilise aussi de plus en plus des stratégies qui relèvent du Single Page Application pour livrer des pages HTML en coquille vide qui proviennent de l'Output Cache et qui seront remplis de contenu à l'aide de calls REST et de Javascript. Retirer le Javascript, c'est me priver de tout ce qui rend mes sites performants, donc je ne le ferai pas. Désolé.

---

Tous ces appels c'est gourmand en bande passante. Bof pour les mobiles et leur Internet mobile pseudo-illimité à quelques Go seulement, quand ce n'est pas moins.

Le panier en cache côté client ? Pas fan. Les données côté clients peuvent être truquées, donc pour la sécurité et la fiabilité du panier il vaut mieux que celui-ci soit géré bien au chaud (en session) côté serveur AMHA. On a ainsi des données nettement plus fiables et on ne doit pas passer son temps à vérifier si celles du client sont bonnes.

Que vaut ta solution niveau SEO ?

Citation:

---

Envoyé par JavaBean

Il faudrait dire ça aux développeurs de Firefox qui ont supprimé le bouton pour désactiver JavaScript...

---

Mozilla, pour un Web meilleur... ;)

Citation:

---

Envoyé par air-dex

Tous ces appels c'est gourmand en bande passante. Bof pour les mobiles et leur Internet mobile pseudo-illimité à quelques Go seulement, quand ce n'est pas moins.

---

Au contraire, c'est moins gourmand. Les SPA évitent de recharger intégralement les pages quant tu navigues, on élimine énormément de overhead HTML. Charger des données en JSON est également plus léger que dans un format déjà sérialisé, typiquement du HTML généré côté serveur. En contre-partie on doit télécharger un peu plus de JS, mais contrairement aux données, le JS peut être mis dans le cache navigateur. Donc globalement, les SPA et le templating côté client permettent d'économiser en bande-passante et rendre la navigation plus rapide.

Citation:

---

Envoyé par air-dex

Le panier en cache côté client ? Pas fan. Les données côté clients peuvent être truquées, donc pour la sécurité et la fiabilité du panier il vaut mieux que celui-ci soit géré bien au chaud (en session) côté serveur AMHA. On a ainsi des données nettement plus fiables et on ne doit pas passer son temps à vérifier si celles du client sont bonnes.

---

Mettre du cache côté client ne sert bien évidemment pas à remplacer les vérifications faites côté serveur, le serveur joue toujours le rôle d'autorité. Cela permet simplement de gagner en réactivité côté client, en faisant de la compensation de latence. C'est aussi nécessaire si on veut ajouter des fonctionnalités offline, comme permettre à l'utilisateur de faire ses achats sous un tunnel et de payer quand il retrouve sa connexion. Le cache côté client c'est un supplément, pas un remplacement.

Citation:

---

Envoyé par air-dex

Que vaut ta solution niveau SEO ?

---

Ce n'est plus un problème depuis la History API de HTML5. Côté URL on ne fait plus la différence entre une SPA et une MPA, et les crawlers savent bien gérer le contenu via AJAX aujourd'hui.

"il faut reconnaître également que son abus sur la toile a grandement contribué à nuire à l’expérience utilisateur des internautes" : Ah bon, il faut ? Je me demande quels sont ces "abus de Javascript" et de quel manière ils "nuisent à l'expérience utilisateur". L'article ne le dit pas et le tient pour acquis, alors que c'est loin d'être le cas.

J'ai recompilé mon browser en retirant les parties qui comprennent l'HTML, curieusement, cela fonctionne moins bien.
Du coup je vais essayer sans écran, si cela n'est pas mieux je désactive TCP/IP.
Non mais, le WEB n'a qu'à fonctionner sans tous ces brols inutiles...

Et pensez-vous aux gens qui ont un handicap visuel et utilise des navigateurs texte, audio, braille. je suis pas sûr qu'ils sont compatible javascript ou en tout cas en partie

@macslan: oui on y pense :) l'accessibilité concerne surtout HTML, mais JS peut aider un peu parfois notamment sur la gestion des focus. J'ai bossé en début d'année sur une SPA avec de fortes contraintes d'accessibilité, et elle a passé les audits. L'idée que les lecteurs d'écran ne supportent pas JavaScript est une vieille idée reçue :
http://webaim.org/projects/screenrea...y4/#javascript
http://a11yproject.com/posts/myth-sc...se-javascript/

Citation:

---

Envoyé par Olivier Famien

:fleche: Que pensez-vous de l’expérience de Klint ?

---

Citation:

---

Envoyé par Olivier Famien

:fleche: Est-il possible de se passer de JavaScript sur la toile ?

---

Elle montre, s'il en était encore besoin, qu'il est compliqué de se passer de Javascript en 2015 sur le Web.

Citation:

---

Envoyé par Olivier Famien

:fleche: Est-il possible de désactiver JavaScript et avoir par la même occasion une expérience de navigation agréable ?

---

J'utilise NoScript et j'active uniquement Javascript de manière permanente ou temporaire lorsque cela m'est nécessaire. J'accepte en contre partie d'avoir une vue dégradée des sites que je visite.
Je ne parlerai donc pas de navigation agréable pas plutôt de navigation choisie.

Je pense que javascript est indispensable - notamment pour déclencher automatiquement des évènements, mais je pense qu'il ne faut l'utiliser que si un langage fonctionnant sur serveur (PHP par exemple) ne peut le remplacer. En effet, toutes les commandes javascript ne fonctionnent pas sur smartphone et tablette bas de gamme (en fonction du wiiewer qui est un navigateur allégé). En revanche, si on code par exemple en PHP5, toutes les commandes PHP5 seront disponibles au niveau du serveur où il n'y a aucune limitation. Donc, à mon avis, il faut utiliser javascript spécifiquement pour certaines parties du programme et vérifier si la fonctionnalité passe bien sur tablette et smartphone.Firefox sur la plupart des smartphones ou tablettes, reconnaît déjà beaucoup plus de fonctions javascript que le wiever de base et même plus que Chrome pour tablette et smartphone, néanmoins Firefox ne reconnaît pas tout javascript non plus. Dans tous les cas, vérifier le résultat de sa programmation sur tablette et smartphone. En revanche, l'avantage d'une programmation entièrement javascript, c'est que l'internaute peut enregistrer un fichier .htm et el lire directement sur son PC hors ligne. Ça se pratique très peu.

bonjour
peut être faudrait il un organisme JsW3C pour Js à l'instar du W3C pour html pour coder proprement
fjp

Notons que le navigateur Midori possède un bouton Marche/Arrêt pour Javascript. Cette option ne fonctionne que si elle a été activée avant le chargement d’une page (si on le passe de "off" à "on" alors qu’on a déjà chargé la page, celle-ci restera sans javascript, et vice versa). Malgré cette limitation (et malgré le manque de maturité relatif de Midori par rapport à Firefox & consorts), j’adore cette fonctionnalité pour sa simplicité (juste un bouton), alors que je ne sais pas configurer NoScript. Je regrette un peu que les "grands" navigateurs, notamment Firefox, n’aient rien de similaire :-(

Je regrette aussi qu’il n’existe pas de bouton Marche/Arrêt pour le XHR.

En dehors de ça, en tant que dev web amateur, JavaScript m’est indispensable pour faire des web apps, mais quand je fais des sites informatifs, soit je n’en mets pas du tout, soit je prends grand soin d’assurer que la version sans javascript offre une bonne expérience utilisateur. Par exemple, sur un site où j’utilise JS pour que, sur mobile, l’élément de navigation soit compacté sous forme d’un menu déroulant « ☰ », je fais attention à ce que le menu développé s’affiche si JS n’est pas dispo.

Ah, et sur l’unique site que j’ai fait qui appelle des scripts externes proprios (genre Analytics), j’ai mis le code de chargement dans une condition comme suit (et tout le monde devrait le faire)*:

Code:

---

1 2 3

if (! (navigator.doNotTrack==="yes")) { // le code de chargement de tout ce qui espionne l’utilisateur }

---

Citation:

---

Envoyé par Bubonik software

En dehors de ça, en tant que dev web amateur, JavaScript m’est indispensable pour faire des web apps, mais quand je fais des sites informatifs, soit je n’en mets pas du tout, soit je prends grand soin d’assurer que la version sans javascript offre une bonne expérience utilisateur. Par exemple, sur un site où j’utilise JS pour que, sur mobile, l’élément de navigation soit compacté sous forme d’un menu déroulant « ☰ », je fais attention à ce que le menu développé s’affiche si JS n’est pas dispo.

---

tu compacte ton menu avec javascript ou tu t'en sert juste pour l'afficher/cacher ?
cas sinon n'oublie pas le

Code:

---

1 2 3

@media screen and (max-width: 640px){ .exemple{width:400px;} }

---

Par exemple un jeu web sans javascript c'est pas terrible je pense...

S'il était fait qu'avec PHP/MySql et HTML/CSS les rechargements de page seraient nombreux dés que les données affichées du joueur doivent changer (la position, les points, etc).
Si je me trompe dites-moi le ;)

On peu citer un type de jeuweb sans javascipt: oGame ;)

Citation:

---

Envoyé par imikado

On peu citer un type de jeuweb sans javascipt: oGame ;)

---

erreur tu fait comment pour les décomptes sans, de plus la dernière interface d'Ogame est pleine de javascript

J'ai commencé le JavaScript en bricolant des userscripts sur OGame. Aujourd'hui c'est mon métier ;)

Citation:

---

Envoyé par TiranusKBX

erreur tu fait comment pour les décomptes sans, de plus la dernière interface d'Ogame est pleine de javascript

---

Les premières versions d'ogame n'etaient pas dependantes de javascript: certains de mes collegues y jouient sur Qtek et autres smartphones de l'époque ;)

Pour la question du compte à rebours: une iframe avec dans la page fille l'utilisation du meta refresh ;)

Citation:

---

Envoyé par imikado

Les premières versions d'ogame n'etaient pas dependantes de javascript: certains de mes collegues y jouient sur Qtek et autres smartphones de l'époque ;)

Pour la question du compte à rebours: une iframe avec dans la page fille l'utilisation du meta refresh ;)

---

c'est la meilleure idée que j'ai entendue pour foutre en l'ai mon navigateur :aie:

Citation:

---

Envoyé par TiranusKBX

c'est la meilleure idée que j'ai entendue pour foutre en l'ai mon navigateur :aie:

---

1. c'est dans l'idée de dire que l'on peut faire des jeux sans javascript: oGame (première génération ) en est l'exemple (même pour le compte à rebours)
2. pour info la balise refresh est mieux géré par les navigateurs qu'un setInterval() en javascript ;)

Mais on reste dans le domaine du POC pour aller au bout de la logique: c'est pas trop recommandé mon post ;)

Citation:

---

2. pour info la balise refresh est mieux géré par les navigateurs qu'un setInterval() en javascript

---

C'est vrai mais on ne peut pas généraliser sur tous les types de jeu, on resterait limité à du Ogame ancien (puisque maintenant javaScript s'est installé chez eux).

Mon post n'est pas une dépo/argument pour faire des sites sans javascript ;)

Juste un POC théorique sur le fait que l'on peut faire un site web sans javascript ;)

Mais oui je suis d'accord que si on veut aujourd'hui faire un jeu en ligne on a trois alternatives : Java applet, Flash ou javascript/css3/html5

Par contre pour html5 and co, il vaut mieux prendre un peu de temps pour apprendre/utiliser une bonne librairie confortable, sinon c'est hardcore

Cf pour info mes journaux pour écrire un bomberman/rts multiplayer :

• RTS: http://jeux.developpez.com/actu/6589...-de-strategie/
• Bomberman: http://jeux.developpez.com/actu/6708...ael-Bertocchi/

Un jeu en ligne sans javascript (mais avec du PHP), ça me paraît possible à condition qu'il n'y ait aucun déclenchement automatique d'une action dans le jeu, donc ça limite. Pas de jeu chronométré qui se déroule dans le temps. Et même pour le PHP, multiplier inconséquemment les accès à la base, ça peut parfois saturer. Du moins, c'est ce que j'ai constaté.

Salut ;)

D'abord pour les taches de temps, il y a CRON ;)

Et concernant ce topic, s'il ne s'agit que de ça :

Citation:

---

Juste un POC théorique sur le fait que l'on peut faire un site web sans javascript

---

Alors c'est la vérité même !


EDIT : (heu...HS) Bonne idée le Bomberman Multi ;)

Je crois que si tu essaies de faire un programme qui prenne la main sur le cron de mon pc sous ubuntu, il ne sera pas bien d'accord :-)

Les développeurs de Firefox ont supprimé le bouton pour désactiver JavaScript... et donc aussi pour le réactiver: je l'avais désactiver et au changement de version m'étant vu bloquer sur certains sites (site de voyages en avion par exemple) je n'ai pas pu le réactiver.

Pour moi, un bon site peut se passer de java-script . Java-script n'est qu'une aide à la navigation et la rend plus rapide sans 'saturer' le réseau:

A ceux qui aime Ajax: Oui ajax permet de n'actualiser qu'une partie de page .
Mais aujourd’hui les réseaux sont (ou devraient) être très rapides et rafraichir une page ou qu'une partie ne devrait pas changer grand chose. Vivement que la France soit entièrement en fibre optique mais cela est une décision politique ... que nul ne veut prendre.

Citation:

---

Envoyé par francisD

Les développeurs de Firefox ont supprimé le bouton pour désactiver JavaScript... et donc aussi pour le réactiver: je l'avais désactiver et au changement de version m'étant vu bloquer sur certains sites (site de voyages en avion par exemple) je n'ai pas pu le réactiver.

Pour moi, un bon site peut se passer de java-script . Java-script n'est qu'une aide à la navigation et la rend plus rapide sans 'saturer' le réseau:

A ceux qui aime Ajax: Oui ajax permet de n'actualiser qu'une partie de page .
Mais aujourd’hui les réseaux sont (ou devraient) être très rapides et rafraichir une page ou qu'une partie ne devrait pas changer grand chose. Vivement que la France soit entièrement en fibre optique mais cela est une décision politique ... que nul ne veut prendre.

---

Il vaux mieux ne rien dire parfois... :roll:

Citation:

---

Envoyé par francisD

Mais aujourd’hui les réseaux sont (ou devraient) être très rapides et rafraichir une page ou qu'une partie ne devrait pas changer grand chose. Vivement que la France soit entièrement en fibre optique mais cela est une décision politique ... que nul ne veut prendre.

---

Ça change énormément en volumétrie de données qui transitent. Si, en france, on est privilégié avec le système des box, bon nombre de pays facturent encore la connexion internet au volume de Mo chargés.
Même en France on a un peu ça sur le mobile avec les forfaits Data. Dans ces situations là, un octet chargé inutilement c'est un octet malgré tout payé

Même sur la rapidité, si ça ne change pas grand chose à ton niveau à toi sur ta connexion internet perso, tu multiplie ça par le milliard d'internautes que nous somme, il y a de quoi saturé les tuyaux.

J'ai récemment eu de longs débats houleux sur des posts anglophones à ce sujet. D'après moi, l'écosystème JavaScript a atteint une technicité et une maturité qui le rendent incontournables aujourd'hui. On peut argumenter que quelques sites simplistes de consultation de contenu peuvent fonctionner sans, et qu'en ajouter de manière incrémentale (progressive enhancement) est la "best-practice" parce que on a toujours fait comme ça on supporte les quelques 1% d'utilisateurs qui ne veulent pas activer JavaScript pour une certaine raison.

Mais "en a-t-on besoin ?" n'est pas la bonne question à se poser. Demandez-vous plutôt: "que peut-on faire pour améliorer le Web aujourd'hui ?".
Et voilà ce que j'ai comme éléments de réponse:

- faire communiquer les serveurs et clients par le biais d'une API REST JSON, ce qui réduit la quantité de données qui transite comparé à du HTML pré-rendu, facilite la découverte de services surtout si on ajoute des liens hypermédia, et permet plus simplement de créer de nouvelles interfaces pour consommer un service (applis natives, interfaces dédiées mobile ou déclinaisons de sites selon le client ciblé).

- mettre en cache persistant tout ce qu'il est possible de mettre en cache côté client, ceci dans le but de réduire drastiquement le trafic Internet. La latence réseau reste le problème numéro 1 de performance, et les SPA reposant sur l'appCache ou les Service Workers ont une réactivité sans pareil.
https://twitter.com/davidwalshblog/s...69103753363456

- stocker les templates et la logique de vue côté client, ce qui permet de ne pas solliciter le serveur quand il n'y en a pas besoin (pour naviguer entre des pages plus ou moins statiques par exemple)

- généraliser la compensation de latence, c'est-à-dire la mise à jour de l'interface immédiate sans attendre la réponse serveur, et en gérant les erreurs de manière rétroactive. Lorsque c'est bien fait, on a l'impression d'utiliser un site web comme une application installée sur son poste: tout est immédiat.

- permettre l'usage de sites web en offline ! Tout le monde a l'air de prendre ça pour un mythe mais c'était déjà possible il y a 3 ans, et aujourd'hui avec les Service Workers le potentiel a été décuplé. On peut continuer à naviguer et interagir avec le site Internet en ayant perdu sa connexion. Les actions de l'utilisateur sont stockées dans une pile et synchronisées avec le serveur au retour de la connexion. C'est aussi incroyablement utile et satisfaisant pour les utilisateurs mobile avec des réseaux défaillants (ceux qui travaillent dans le train sauront de quoi je parle).

- réduire la charge serveur: en déléguant le rendu des pages aux clients, on allège un peu la charge serveur ainsi que le trafic (JSON étant plus léger que le HTML pré-rendu), ce qui se traduit par un gain économique sur l'équipement réseau

- meilleure surveillance et résistance aux pannes serveur; le monitoring est facilité avec une API REST, bien plus facile à tester qu'un panel de pages. Et on peut dire adieu aux pages d'erreur 501 grâce à la résistance aux erreurs serveur (qu'on gère de la même manière côté client qu'un échec de connexion). Si votre serveur est down quelques minutes, il se peut même que les clients ne s'en rendent pas compte avec la compensation de latence la synchronisation en tâche de fond.

Quel est le point commun entre tout ça ? JavaScript, et le rendu côté client. C'est pour ça que je pense (et c'est généralement là que je commence à faire hurler les gens :mrgreen:), que les technos dites de pages serveur (PHP/JSP/ASP...) sont destinées à mourir dans un avenir proche.

On peut aussi parler de l'approche dite "isomorphique" ou "universal JS", qui consiste à faire exécuter le code JavaScript de sa SPA côté serveur et retourner le HTML pré-rendu aux navigateurs ne supportant pas JS. Est-ce une bonne idée ? Oui et non. L'idée est ingénieuse, mais peu réaliste. Penser un service comme pouvant être optionnellement utilisé sans JS aura forcément des conséquences et de fortes contraintes sur l'interface utilisateur. Je ne dis pas que c'est impossible, juste que c'est extrêmement contraignant et que ça pénalise 99% des utilisateurs pour satisfaire les 1% qui ne veulent pas activer JS par peur des XSS et du tracking, quitte à revenir au Web des années 2000.

Toutes ces solutions sont sans doute judicieuses, mais je me demande si elles vont fonctionner sur un smartphone bas de gamme avec le wiever par défaut. En revanche, le PHP, lui, il fonctionnera toujours pareil quel que soit l'appareil et quel que soit le navigateur.