Discussion :

[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

[imikado]

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

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

[progdebutant]

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

[imikado]

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/

[sat99]

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

[progdebutant]

Salut

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

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

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

[sat99]

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

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