Partant du principe que tous les navigateurs n'interprètent pas Javascript de la même manière... Qu'est-ce qui se passe si ton javascript plante sur celui d'une de tes cibles?Envoyé par pmithrandir
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Partant du principe que tous les navigateurs n'interprètent pas Javascript de la même manière... Qu'est-ce qui se passe si ton javascript plante sur celui d'une de tes cibles?
Pour moi c'est simple :
Tout langage Turing complet est à bannir des navigateurs pour des raisons de sécurité.
Y'a déjà bien assez de trous de sécurité par ailleurs.
Et d'une manière générale, je pense que tout ce qui dépasse d'une page web simple n'a rien à faire sur le web. (Rien que le nom "application web" me donne des boutons.) L'internet c'est beaucoup plus que du web, alors pourquoi le restreindre au web et essayer de faire rentrer toutes les applications du monde dans un navigateur à coup de pieds de biche ?
Quand je vois webGL, ou des trucs à la con pour faire du P2P entre navigateurs, je me dis qu'on nage en plein délires... On est simplement en train de réinventer dans un navigateur ce qu'un OS sait déjà faire.
Intérêt : 0.
Ma réponse est simple et péremptoire (donc forcément forcément à nuancer dans une certaine mesure) : Si t'as besoin de flash, c'est que tu t'es trompé de technologie, le web n'est pas pour toi.
Bon, après, c'est vrai que les sites à la youtube c'est un peu limite. Mais je pense pas que flash soit la réponse, c'est beaucoup trop lourd pour la tâche gourmande en calcul qu'est la lecture de vidéos. Une meilleure réponse est de laisser l'OS lire la vidéo. Après tout, c'est l'OS qui sait exploiter la carte graphique. Éventuellement, le navigateur peut servir d'intermédiaire...
Ah mais j'y pense, c'est déjà ce qu'on faisait en 2000 avec des plugin.
Et aujourd'hui, HTML5 permet de faire ça de manière bien plus "intégrée" et standard.
J'utilise un framework, jquery pour le nommer, qui me créé une couche d'abstraction.
Donc, peut importe le navigateur.
Pour la question de la validation, je la fait d'abord sur le serveur, et ensuite je la réplique en javascript. Pour mes villes c'est pas une validation, juste un champ autocomplete qui me permet de remplacer un select de 35 000 éléments.
Aux ayatollah du HTML sans javascript... je me demande un peu à quoi ressemble vos site web. et surtout en combien de temps vous les codez.
Parce que d'après ce discours, 90% des sites web, dont les plus interactifs / sympa pour l’utilisateur ne répondent pas au besoin.
Ensuite, pour les différents profiles qui peuvent visiter le site web.
Autant pour l'aveugle, je veux bien entendre le commentaire et j'essaye de faire des choses assez propre... autant le robot de google, il lit bien mon site en l'état. mieux vaut que 15 robots se coltinent du dev en plus pour reconnaitre les sites que tous les dev perdent leur temps selon moi.
Moi qui vient de me remettre, pour ma culture pour l'instant, aux IHM mais sur internet en regardant le php, javascript (Jquery pour être précis) je ne comprends vraiment l'architecture n-tiers majoritaire que maintenant. En fait ma dernière expérience en IHM date de 2001 en client serveur avec Delphi. Et donc en fait je suis d'accord avec toi que les pages html sont des vraies usines à gaz en comparaison de ce que je connaissais avec le client serveur en mode lourd. (Je me suis spécialisé en BI où je ne créés pas de clients, j'en utilise mais ils sont peu interactifs ce sont des rapports. Sinon quand je créés des bases de données je ne suis qu'en back office finalement).
N'empêche que même si sur le plan théorique tu as 100% raison, tes propositions ne sont pas utilisables actuellement car ça voudrait dire qu'il faudrait changer tout les navigateurs. Penses à IE6 qu'on a eut un mal fou à enterrer.
Sinon c'est une idée les web services, d'ailleurs c'est ce qui tend à être fait sur les mobiles si je ne m'abuse.
Je n'ai pas tout de suite compris cette phrase mais en regardant le reste de ton message je comprends mieux. Je me demandais pourquoi tu n'aimais pas le HTML mais je préfère dans un monde intéropérable comme l'est internet un format ouvert que l'espèce de HTML-word que microsoft a essayé de nous refourguer à un moment, ou pire des formats binaires.
Mais en fait ce que tu me dis c'est que tu n'as rien contre le HTML mais qu'il doit rester pour du mode texte. Mais le souci c'est que les pages web actuelles n'ont plus rien à voir avec les années 1990. Je veux dire: comment répondre aux demandes des concepteurs non techniques des pages (les vendeurs, les journalistes, les créateurs de blogs) qui veulent des pages moins austères. Ben pour l'instant on a fait évoluer l'existant puisque l'HTML (et javascript) était le seul disponible.
D'accord avec les web services, mais en revanche je suis plus que dubitatif sur les clients lourds. Si cela a été abandonné c'est à cause des problèmes de déploiements. L'autre souci est qu'ils étaient trop dépendants de la puissance de la machine.
Autant ça peut se résoudre dans le monde de l'entreprise en remettant éventuellement des clients lourds, mais pas facilement pour le déploiement, autant sur la toile je ne vois pas comment on pourrait promouvoir un retour du client lourd. Sans parler des problèmes de sécurité: l'architecture actuelle n-tiers permet l'utilisation d'une machine virtuelle indépendante de l'OS si j'ai bien suivi).
Est-ce que HTML5 répondrait en partie à tes desideratas ? Je ne connais pas du tout ses fonctionnalités.
Tant que c'est un navigateur majeur qui est géré par jQuery, tu veux dire. C'est vrai que tu ne coures pas trop de risques, tant qu'il n'y a que 3 ou 4 moteurs de rendus tous gerés proprement par ton framework.
Donc pas de validation....pour ton site ce n'est sans doute pas grave, mais ça veux dire quand même qu'un utilisateur averti pourrait faire passer n'importe quelle chaîne de characteres pour une valeur de Ville valide. D'ailleurs, j'espere que le framework que tu utilise côté serveur refuse d'interpreter le texte saisit comme du code, sinon injection possible...Pour la question de la validation, je la fait d'abord sur le serveur, et ensuite je la réplique en javascript. Pour mes villes c'est pas une validation, juste un champ autocomplete qui me permet de remplacer un select de 35 000 éléments.
Et ben à vrai dire... C'est ce qu'on me disait il y a 6 ans pour justifier l'utilisation de flash. Genre l'utilisateur ne saura pas installer un logiciel sur son ordinateur (pourtant ils sont suffisamment nombreux à savoir installer e-mule pour tuer l'industrie de la musique, nous dit-on)
Mais de nos jours que fait-on quand on installe une appli sur son ibidule ou sa tapette tactile? Bah... On installe un client lourd! (Qui n'est généralement qu'un navigateur web avec une URL pré-configurée parce que les utilisateurs ne sont pas assez doués pour entrer une URL dans leurs bookmarks)
C'est étrange quand même? Cette capacité qu'à l'utilisateur à devenir soit doué soit débile en fonction de si ça arrange le commercial ou pas.
Par ailleurs, concernant la puissance de la machine... Foutre des animations à deux balles avec un langage interprété, je ne suis pas sûr que ce soit plus performant qu'un client utilisant les éléments natifs d'un OS. :p
Le HTML5 c'est un peu un autre débat. Je serais heureux de te donner mon avis en apparté, mais dans cette conversation ça risque de virer au troll.
Alors, je ne saurais critiquer l'utilisation de jQuery. Je l'utilise moi-même. Mais jQuery ou pas jQuery, si une fonction ou une classe n'est pas disponible dans l'environnement d'exécution, ça ne marchera pas. Si tu n'as pas une couche javascript dégradable, tu devras te passer de nombreuses nouvelles API.
Et à ton avis, est-ce que les dev ne perdraient pas moins de temps si l'on développait des outils pour aider à développer correctement plutôt que des immondices comme YUI ou GWT ? Les devs perdrent énormément de temps car pour coder correctement il leur faut désapprendre parfois des années de mauvaises habitudes et puis aussi parce que tout ce javascript mal fichu rend impossible la mise en place de tests automatisés (dont font partie aussi les 15 robots...)
Oui mais il faut un seul client lourd unifié, ou en tout cas avec protocole unifié. Je vais sur beaucoup plus de sites internet que je n'installe d'application android. Dès que je vais sur un site je ne vais pas installer une appli. En plus y'a un problème de droit sur iOs et android. Qui n'existe pas sur les clients légers.
Ben pourquoi ? Il parait que c'est le futur nirvana ? A t'entendre ce n'est qu'une version mineure de HTML avec quelques ajouts mais qui ne créé pas de nouvelle architecture.
En fait, c'est bien ca.
Si je supporte firefox, Chrome, safari, opera et IE8+, je supporte 80% des utilisateurs mondiaux. Mon site fonctionne aussi normalement sur IE7, mais moins joli.(j ai même pas testé)
C'est simple, si je développe pour autre chose, j'augmente mon cout(et le cout, c'est mes heures perso passé soit a coder soit avec ma copine).
Donc, pour 3-4 pelos qui utilise un navigateur spécifique et qui ont donc les capacités de prendre un truc classique si besoin(je connais personne qui a un de ces navigateur et qui ne sait pas utiliser les autres)... je ne vais pas perdre des heures.
Quand tu fais de l'autocomplete, tu lis une ville, mais mon formulaire récupère un identifiant directement issue de la BDD.
Ensuite, je n'ai qu'a recherché dans cette BDD quel tuple a cet identifiant(en m'occupant des injections, ne t'en fait pas) et à ajouter l'info dans ma table user.
Au final, je ne manipule plus du texte, mon système est naturellement sécurisé et plus facile à utiliser(voir utilisable juste parce qu'un select avec 35 000 valeurs.... je pense qu'on rigolerait)
Ce n'est pas parce qu'à un instant t les technologies sont limitées qu'il faut les hacker pour faire rentrer les besoins dans ces technologies à coup de tournevis, marteau, pied-de-biche et spéculum.
D'autres voies sont possibles et bien plus adaptées aux besoins actuels. Je pense notamment que le modèle smartphone / tablette est une bonne base qui mériterait simplement d'être raffinée.
Tout à fait. Au moins avec le web, on s'assure que tout le monde ait une bête de course pour faire tourner un navigateur.
En plus, un truc bien pensé. C'est qu'à la limite, avant, si tu avais une bête de course, ça ne ramait pas. Maintenant, grâce au "tout par le navigateur". Tu auras beau avoir une bête de course, si le serveur est saturée ou si la page est bourrée d'ajax ou si tu as une connexion lente, ça ramera autant que sur un PC pourri.
C'est beau l'égalité!sniff
Sous Chrome, il y a un plugin très pratique "Quick Javascript Switcher" pour pouvoir débrancher le Javascript sur une page qu'on visite. Ça sert occasionnellement, par exemple dans le cas de lightboxes qui se déclenchent inopportunément à l'ouverture de la page... Et ça a l'avantage de n'être actif que sur l'onglet en cours et de pouvoir se remettre en un clic.
je suis d'accord avec charlycoste,
http n'est pas fait pour ca a l'origine. et un navigateur de devrait pas faire tourner des applications web.
Mais c'est pas vraiment la faute aux developpeur mais plutot aux utilisateurs qui veulent avoir des TOUT en 1 par paraisse de lancer une autre application.
Mais bon firefox a raison si ils veulent avoir plus de part de marcher ca passe par relirer la charge de travail et de securite du niveau utilisateur pour la metre du cote developpeur.
On le sait tout l'utilisateur un une feignasse (sans ironie).
Je suis tombé par hasard sur l'article mais je vois que les conclusions de l'origine de la suppression du blocage du javascript sont érronées.
Je me permet donc d'apporter un correctif.
Cette suppresion n'est en rien lié à la gestion de l'html 5 et du javascript.
En effet, il n'y a aucune remonté indiquant qu'un site n'est plus fonctionnelle suite au déblocage du clique droit ou de la réécriture de de la barre d'état.
En faite, le financement de Firefox est fait en très grande partie par google. Ce partenariat n'est pas gratuit et en echange Mozilla s'engage a inclure du code pour son partenaire: moteur de recherche pas défaut, utilisateur de antiphisign de google, introduction des balises propres à Google etc...
Vu que Google sert en ce moment la vise, il demande plus.
On notera récemment que l autorisation es cookies tierces sont activés par defaut (indispensable pour la publicité de google). Désormais c'est la gestion du javascript que google demande de supprimée.
En effet, vous avez jamais remarqué que la désactivation de la réécriture de la barre d'état fonctionne sur tout les sites sauf sur google.
Ex: l'url suite à une recherche indique en barre d'état "www.exemple.com" alors qu'une fois cliquez dessus vous avez "www.google.com?url=www.exemple.com".
Très utile à google pour identifier les sites sur lequel vous cliquez suite à une recherche.
Voilà, inutile donc de chercher la cause là ou il n'y en a pas. C'est juste une question de politique.
Bonne journée
Salut
Mais quel conte ce récit que tu nous fait, autant certaines personnes ont sortaient de pas bonnes choses, que toi....
Et puis une source de tes propos venant de chez Mozilla aurait pu convaincre quelqu'un... Pas moi, c'est certain.
Le bouton de désactivation globale de JavaScript a été supprimé dans la version 23 pour les raisons suivantes :
http://limi.net/checkboxes-that-kill
Quand à l'utilisation du JavaScript pour Google "recherches", c'est pas utile ! En fait, sans autorisé les scripts, on se retrouve avec la version de base de Google, c'est tout.
Mais dans certaines fonctions de Google (Maps, par exemple. il faut autorisé aussi pour gstatic.com) il n'y à pas le choix, il faut autoriser les scripts, ce qui est entièrement logique.
******************
Google "recherches" fonctionne très bien sans l'autorisation des cookies, donc rien à voir !
Quand à la fonction d'autoriser les cookies tiers par défaut, elle à toujours été comme cela...désactivable bien sur et c'est toujours le cas.
La seule option ajouté (comme je l'ai déjà dis), c'est les autoriser pour les sites visités. Ce qui change pas grand chose à "toujours les autoriser"...
*******************
ça n'a rien à voir.... Javascript activé ou pas pour Google, j'ai toujours et simplement http://www.exemple.com/ dans l'info-bulle.
Un autre exemple de fonctionnalité qui tue un logiciel c'est la petite croix en haut à droite
Sans rire, si les gens pensent savoir ce que désactiver le javascript signifie, qu'ils se lancent dans l'aventure.
Enfin, tant qu'on n'interdit pas l'utilisation de NoScript et autres plugins du genre, ça va
Salut
Pour les personnes (une majorité..)qui n'utilisent que la souris et pas les raccourcis clavier pour fermer une fenêtre (Ctrl + Maj + W ou Alt + F4), en autres, c'est tout de même important !Un autre exemple de fonctionnalité qui tue un logiciel c'est la petite croix en haut à droite
+1Enfin, tant qu'on n'interdit pas l'utilisation de NoScript et autres plugins du genre, ça va
lien google sans javascript :
Lien google avec javascript :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Dans les deux cas google sait où vous cliquez... et on est bien redirigé depuis une url google interne vers le contenu externe.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Tout à fait d'accord.
L’essentiel est surtout de pas ce faire identifier et d'avoir de suivit...(sans un excès d'applications de protection !) Mais bon, ça sort un peu du sujet et c'est une autre histoire.
Vous insinuez que désactiver le javascript n'est pas important ?
Pour les personnes (une majorité..)qui n'utilisent que la souris et pas les raccourcis clavier pour fermer une fenêtre (Ctrl + Maj + W ou Alt + F4), en autres, c'est tout de même important !Mais n'est-ce pas aussi grave d'avoir le javascript activé quand on surf sur le net que de faire l'amour sans préservatif ?
Répondre avec citation
Partager