AngularJS : que se passe-t-il si JavaScript est désactivé ?

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour à tous,

Imaginons qu'un site soit conçu de telle sorte que côté serveur, on ne s'occupe que de la communication avec la base de données (instructions du LMD appliquées à des données postées par formulaire ou pour en récupérer depuis la base de données). Cela avec, par exemple, PHP.

Le reste (par exemple l'affichage des données récupérées depuis la BDD par PHP) se ferait avec AngularJS (donc en HTML et JavaScript). Si je ne me trompe pas, c'est ainsi qu'il faut procéder si l'on veut utiliser ce framework.

Eh bien… que se passerait-il si un internaute consultant ce site désactivait JavaScript sur son navigateur ? A priori, rien ne s'afficherait correctement.

Merci d'avance, bonne journée. :)

Université de Bretagne-Sud <3

+0 -0
Staff

En effet sans js angular peut pas faire grand chose. J'imagine qu'ils ont prévu un truc pour te permettre d'afficher un message par défaut le même plus simple reste d'essayer.

+2 -0

AngularJS fait des Single Page Applications, en gros, tout est inclu dans la page index.html, chagrgé en javascript. Si angular ne peut être chargé, il "suffit" de construire d'autres pages en html "classique" si on veut assurer le service ou mettre un message pour dire d'activer JS pour utiliser le site.

Xia, peluche olympienne |Python en s'amusant | Random xkcd

+0 -0
Auteur du sujet

Ainsi, même quand on utilise AngularJS, il ne faut pas se contenter de communiquer avec la BDD côté serveur. On a toujours besoin de gérer les traitements de formulaire en PHP (langage choisi au hasard), ou encore d'afficher des données provenant de la BDD en PHP.

Ou bien, comme vous le dites, on affiche un message obligeant l'internaute à activer le JavaScript et comme ça on n'a pas besoin d'utiliser PHP pour les tâches sus-citées. Au final je pense que c'est cette dernière solution qui est à prendre, sinon il n'y aurait aucun intérêt à utiliser AngularJS : ça ajouterait du travail supplémentaire pour rien (cf. premier paragraphe de ce message) ; pire : le résultat serait totalement contraire à ce pour quoi AJS a été créé (ie éviter de devoir utiliser un langage serveur pour toute autre tâche que la communication avec la BDD)…

Édité par The-Aloha-Protocol

Université de Bretagne-Sud <3

+0 -0

le résultat serait totalement contraire à ce pour quoi AJS a été créé (ie éviter de devoir utiliser un langage serveur pour toute autre tâche que la communication avec la BDD)…

Lern-X

Je me permets juste de réagir là-dessus : AngularJS permet d'avoir une architecture MVW coté client mais ne dispense pas d'utiliser un langage serveur pour accéder à une base de donnée.

Édité par Xia

Xia, peluche olympienne |Python en s'amusant | Random xkcd

+0 -0
Auteur du sujet

le résultat serait totalement contraire à ce pour quoi AJS a été créé (ie éviter de devoir utiliser un langage serveur pour toute autre tâche que la communication avec la BDD)…

Lern-X

Je me permets juste de réagir là-dessus : AngularJS permet d'avoir une architecture MVW coté client mais ne dispense pas d'utiliser un langage serveur pour accéder à une base de donnée.

Xia

Oui c'est bien ce que je dis :)

Université de Bretagne-Sud <3

+0 -0

Ainsi, même quand on utilise AngularJS, il ne faut pas se contenter de communiquer avec la BDD côté serveur. On a toujours besoin de gérer les traitements de formulaire en PHP (langage choisi au hasard), ou encore d'afficher des données provenant de la BDD en PHP.

Vraiment? Perso tous mes projets avec Angular si l'utilisateur n'a pas le JS je l'envoi bouler. C'est comme si dans le dernier jeu a la mode ils avaient fait un second jeu pour permettre au mec qui a pas le bon matos de jouer avec 512mb de ram. A un moment l'utilisateur doit faire la par des choses, navigo a jours, javascript activé etc …

Staff

Ainsi, même quand on utilise AngularJS, il ne faut pas se contenter de communiquer avec la BDD côté serveur. On a toujours besoin de gérer les traitements de formulaire en PHP (langage choisi au hasard), ou encore d'afficher des données provenant de la BDD en PHP.

Vraiment? Perso tous mes projets avec Angular si l'utilisateur n'a pas le JS je l'envoi bouler. C'est comme si dans le dernier jeu a la mode ils avaient fait un second jeu pour permettre au mec qui a pas le bon matos de jouer avec 512mb de ram. A un moment l'utilisateur doit faire la par des choses, navigo a jours, javascript activé etc …

#VK

Mauvais exemple, puisque la plupart des jeux permettent de modifier les réglages graphiques pour s'adapter aux PC moins véloces.

Un site ne devrait jamais reposer uniquement sur du JavaScript. Le référencement du contenu produit par JS est encore très mauvais de même que l'accessibilité (navigation au clavier, personnes mal voyantes). C'est encore pire quand le JS est mal conçu et provoque des erreurs d'affichage (très fréquent sur smartphones).

Chacun est libre de développer comme il l'entend, mais il ne faut pas se plaindre après.

Responsable de la validation - TodoFox - Le JavaScript, c'est bon, mais pas jQuery ! Séries

+3 -0
Auteur du sujet

Ainsi, même quand on utilise AngularJS, il ne faut pas se contenter de communiquer avec la BDD côté serveur. On a toujours besoin de gérer les traitements de formulaire en PHP (langage choisi au hasard), ou encore d'afficher des données provenant de la BDD en PHP.

Vraiment? Perso tous mes projets avec Angular si l'utilisateur n'a pas le JS je l'envoi bouler. C'est comme si dans le dernier jeu a la mode ils avaient fait un second jeu pour permettre au mec qui a pas le bon matos de jouer avec 512mb de ram. A un moment l'utilisateur doit faire la par des choses, navigo a jours, javascript activé etc …

#VK

Mauvais exemple, puisque la plupart des jeux permettent de modifier les réglages graphiques pour s'adapter aux PC moins véloces.

Un site ne devrait jamais reposer uniquement sur du JavaScript. Le référencement du contenu produit par JS est encore très mauvais de même que l'accessibilité (navigation au clavier, personnes mal voyantes). C'est encore pire quand le JS est mal conçu et provoque des erreurs d'affichage (très fréquent sur smartphones).

Chacun est libre de développer comme il l'entend, mais il ne faut pas se plaindre après.

Thunderseb

Dans le cas d'AngularJS, si on ne limite pas l'utilisation du langage côté serveur à de la communication avec la base de données au cas où l'internaute n'activerait pas son JS (au lieu de l'"envoyer bouler" comme dit ci-dessus), je ne vois pas à quoi ça sert d'utiliser AngularJS : ça ne fera que rajouter du travail.

Ce que tu dis me semble donc assez peu adapté dans ce cas précis. En revanche, dans d'autres cas ton raisonnement serait tout à fait valable.

Université de Bretagne-Sud <3

+0 -0
Staff

Ca dépend de ce que tu cherches précisément à faire. Il est clair que si ton but est de faire une appli mono-page pour faire des "choses" en temps réel (un chat, un webmail, une app du genre Word Online..). Avoir un fallback correct en HTML/CSS/Serveur sera quasiment impossible.

Mais si tu dois afficher sur ton blog les derniers articles issus de la base de données, utiliser du JS n'est clairement pas la meilleure idée. Mais encore une fois, ça dépend vraiment de ton objectif.

Responsable de la validation - TodoFox - Le JavaScript, c'est bon, mais pas jQuery ! Séries

+0 -0
Auteur du sujet

Ca dépend de ce que tu cherches précisément à faire. Il est clair que si ton but est de faire une appli mono-page pour faire des "choses" en temps réel (un chat, un webmail, une app du genre Word Online..). Avoir un fallback correct en HTML/CSS/Serveur sera quasiment impossible.

Mais si tu dois afficher sur ton blog les derniers articles issus de la base de données, utiliser du JS n'est clairement pas la meilleure idée. Mais encore une fois, ça dépend vraiment de ton objectif.

Thunderseb

Oui, mais je pense aussi qu'AngularJS permet de faire des choses équivalentes à des langages côté-serveur (affichage de données provenant de la BDD par exemple) de manière plus élégante (ie en rendant le code-source plus lisible) et moins verbeusement.

Après il est certain que ce critère de confort de développement ne doit pas primer sur l'objectif, sur ce qui doit être développé.

Sinon j'ai une autre question concernant AngularJS : étant donné qu'on peut limiter l'utilisation de, disons… PHP, à une communication avec la BDD, est-il vraiment utile d'avoir recours à des frameworks côté-serveur (Symfony, CakePHP…) ?

Université de Bretagne-Sud <3

+0 -0

Sinon j'ai une autre question concernant AngularJS : étant donné qu'on peut limiter l'utilisation de, disons… PHP, à une communication avec la BDD, est-il vraiment utile d'avoir recours à des frameworks côté-serveur (Symfony, CakePHP…) ?

En général si tu as une API rest coté serveur tu vas choisir un framework adapté aux API rest. Du coup tu peux prendre un "gros" framework comme symfony ou cakePHP mais ce n'est pas forcement l'outil adapté (même si maintenant tout les framework doivent être capable de gérer une api rest je penses).

Tu peux aussi utiliser une autre techno que PHP coté serveur : js, ruby, python, ou n'importe quel truc qui peut communiquer avec une base de donnée et une api !

Oui, mais je pense aussi qu'AngularJS permet de faire des choses équivalentes à des langages côté-serveur (affichage de données provenant de la BDD par exemple) de manière plus élégante (ie en rendant le code-source plus lisible) et moins verbeusement.

Personnellement je trouve la logique d'Angular tout à fait pertinente : pourquoi le serveur devrait s'occuper d'autre chose que du traitement des données ? Tout le reste peut être fait coté client (sauf peut être besoin et applications spécifiques), décharger le serveur et donner un rendu fluide et sans rechargements inutiles.

"Il est vraiment regrettable que tous les gens qui savent parfaitement comment diriger un pays soient trop occupés à conduire des taxis et à couper des cheveux"

+0 -0

Personnellement je trouve la logique d'Angular tout à fait pertinente : pourquoi le serveur devrait s'occuper d'autre chose que du traitement des données ? Tout le reste peut être fait coté client (sauf peut être besoin et applications spécifiques), décharger le serveur et donner un rendu fluide et sans rechargements inutiles.

C'est une logique qui a tout son intérêt dans certains cas, et pas dans d'autres.

Je ne comprends pas pourquoi on veut absolument utiliser un truc comme Angular pour faire un blog ou un site à contenu, où l'unité d'organisation reste la page et où les éléments dynamiques sont plutôt rares. C'est pas parce qu'on a un super framework très très bien conçu développé par une société comme Google qu'il est nécessairement pertinent à toutes les sauces. L'erreur, comme dirait cet autre, c'est que quand on a un marteau doré, tout ressemble à un clou.

Angular tout comme les autres frameworks du genre comme Meteor, React, etc. ont été conçus pour les applications à page unique (single page application). AVant de l'utiliser pour un projet, je pense qu'il faudrait se poser les questions suivantes: est-ce que mon projet ressemble plus à une SPA ou à un site web traditionel ? Est-ce que mon application aurait toujours autant d'intérêt si, à la place d'une application web, c'était une application native desktop ou mobile ? est-ce que la notion de hautement dynamique ou de temps réel a une importance capitale ? Est-ce que, à défaut de temps réel ou de aute dynamicité à proprement parler, les notions traditionellement attachées aux apps natives, telles par exemple que les boîtes de dialogue et les interaction dans celles-ci font-elles véritablement sens dans mon cas (et ne sont pas uniquement une question esthétique) ?

Clairement pour un blog, un journal, une encyclopédie ou un shop en ligne, les réponses à ces questions pour moi sont non (n'en déplaise à ceux qui font des apps natives qui sont juste des copies de leur site web). Par contre pour un jeu, un chat, un client mail, un système pour éditer/produire du contenu collaborativement, pour regarder la télé en direct ou pour télécommander un drone, définitivement oui. Pour ces dernières, il n'y a pas de problème à envoyer bouler le client qui n'est pas à jour, parce que de toute façon il n'y a pas vraiment d'alternative. Pour les premières par contre je trouve ça particulièrement dommage.

Décharger le serveur, c'est une fausse excuse. De toute façon le 99% du temps, on le passe à requêter la base de donnée ou des API externes, et faire des vérifications qu'on ne peut de toute façon pas contourner (p.ex. formulaires, droits d'accès). Générer la réponse ça ne coûte rien; qu'on sorte du JSON ou du HTML c'est à peu près pareil. Du coup qu'on fasse une SPA ou un site classique en PHP, je suis à peu près sûr que la différence n'est pas flagrante.

Par exemple, une question symptômatique: quel est l'intérêt d'effacer la majeure partie du contenu pour en recharger un tout autre avec AJAX ? Mème s'il y a un système de template en js qui est super bien foutu et qui essaie de minimiser les modifications du DOM, je ne pige pas trop. Sauf pour les très très gros poissons, c'est pas quelques Ko de plus qui vont tuer le serveur.

Je n'arrive pas à comprendre comment on peut en arriver à ce que, quand je vais sur certains sites de presse (que je ne citerai pas) par exemple, le CPU monte à pas loin de 100%. Juste pour, normalement, du texte et quelques illustrations immobiles. Pour un jeu 3D qui tourne à 60 FPS c'est normal, mais pas pour un article !

Quant à la question de départ, je n'ai jamais vraiment travaillé avec Angular donc je ne sais pas; mais avec Meteor on a droit à une page blanche ou au mieux un message basique. Je suppose que c'est pareil avec Angular.

Édité par QuentinC

Ma plateforme avec 23 jeux de société classiques en 6 langues et 13000 joueurs: http://qcsalon.net/ | Apprenez à faire des sites web accessibles http://www.openweb.eu.org/

+3 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte