Discussion :

[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.

[Golgotha]

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...

[sevyc64]

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.

[SylvainPV]

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 ), 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.

[sat99]

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.

[SylvainPV]

@sat99: Ce n'est pas un sujet réservé au JS. Un vieux navigateur peut aussi mal supporter un élément HTML5 ou une propriété CSS.

Mais on sait comment améliorer le support des vieux navigateurs: avec des polyfills !
Un exemple que j'ai écrit hier pour l'élément HTML standard <details> :
https://gist.github.com/sylvainpolle...cb88081969605c
http://caniuse.com/#feat=details

Cela permet de faire fonctionner cet élément sur Firefox et IE, à condition que JavaScript soit activé. Car ces polyfills sont écrits en JavaScript. CQFD

[ABCIWEB]

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.

Je me suis acheté un smartphone android entrée de gamme à 60 € il y a deux ans justement pour tester mon petit CMS de présentation dont tu peux voir une utilisation ici. Il utilise jquery et également un setTimeout pour pouvoir faire défiler automatiquement le diaporama disponible quand on clique sur une image.

Au pire le fondu enchainé peut être légèrement heurté quand le smartphone fait en même temps des grosses mises à jours (car je ne m'en sert pas souvent), mais rien de rédhibitoire et toutes les fonctionnalités de navigation sont ok. Pourtant au départ j'ai développé le CMS y compris le module de diaporama uniquement sur et pour desktop. J'ai donc été agréablement surpris, l'implémentation de javascript sur les principaux navigateurs android (chrome ou firefox) est correcte et la puissance des petits smartphones la plupart du temps suffisante

[fjp]

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

[Bubonik software]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[TiranusKBX]

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 CSS :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[progdebutant]

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

[imikado]

On peu citer un type de jeuweb sans javascipt: oGame

[TiranusKBX]

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

[SylvainPV]

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

[imikado]

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

[TiranusKBX]

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

[stb007]

J'adore comme vous crachez à le gueule des sites qui vous "polluent" avec de la pub... Et j'imagine que vous pensez que les gens qui rédigent des articles, font des tests, hébergent sur des gros serveurs afin d'avoir des temps de réponse potables bossent gratos ? Vous bosseriez gratos vous ?

[SylvainPV]

@stb007: ici tu es sur un site de bénévoles: rédacteurs d'articles, de news, modérateurs, relecteurs, on bosse tous gratos. Le petit encart de pub en haut à droite sert uniquement aux frais généraux comme l'hébergement du site.

[stb007]

@stb007: ici tu es sur un site de bénévoles: rédacteurs d'articles, de news, modérateurs, relecteurs, on bosse tous gratos. Le petit encart de pub en haut à droite sert uniquement aux frais généraux comme l'hébergement du site.

Grand bien vous fasse, mais ce n'est pas le cas de tout le monde, on a le droit d'être rémunéré pour un travail, et à chacun de définir sa stratégie.

[Golgotha]

J'adore comme vous crachez à le gueule des sites qui vous "polluent" avec de la pub... Et j'imagine que vous pensez que les gens qui rédigent des articles, font des tests, hébergent sur des gros serveurs afin d'avoir des temps de réponse potables bossent gratos ? Vous bosseriez gratos vous ?

il existe d'autre forme de rémunération, comme les comptes premium.