Les technologies web gagnent du terrain

Bonjour les enfants,

Comme c'est vendredÿ, c'est le moment de s'attaquer au sujet trollifère qui va bien: la progression des technologies web (HTML/XML, CSS et JavaScript notamment) dans des applications jusqu'ici réservées à des langages tels que C, C#, Objective-C, Java, Python... couplés à des bibliothèques d'interface utilisateur.

La première étape a été la création d'applications web/Ajax telles que Gmail, Writely, 280slides, etc. Même s'ils sont jeunes et souvent pas aussi puissants que leurs équivalents desktop, il existe des frameworks pour réaliser ce genre d'application Ajax, par exemple Google Web Toolkit ou Cappuccino.

La deuxième étape, c'est le déplacement de certaines de ces applications hors du navigateur... pour rejoindre le bureau à proprement parler. C'est en partie un tour de passe-passe à coup de simili-navigateur standalone, et pour l'instant ça n'a pas un succès monstrueux malgré une percée de Adobe Air pour quelques applications (certains clients Twitter, les applications de wireframing iPlotz et Balsamiq Mockups...).

La troisième étape, c'est sans doute la percée du JavaScript comme langage à tout faire. Le JavaScript côté serveur est discret pour l'instant, mais pourrait bien faire parler de lui. Le JavaScript comme langage de manipulation d'interfaces (manipuler les contenus, réagir aux évènements...) n'est pas tout nouveau, cf. la plateforme Mozilla par exemple, mais il a le vent en poupe avec le webOS de Palm ou encore Jolicloud.

Je vous fais des poutous partout.
Modifié par Florent V. (12 Jun 2009 - 16:01)

Ah, il y en a qui pense à me nourrir !

Premièrement il ne faut pas oublier que si JavaScript avance c'est parce qu'il y a des gens qui font de la vrai programmation en C/C++ en écrivant des machines virtuelles.

Deuxièmement JavaScript n'est pas LE langage parfait, il a de la concurrence, notamment python.

Troisièmement HTML+CSS+JavaScript ça prend beaucoup de RAM. De plus la facilité de développer quelque chose avec les technologies du web fait qu'il y a énormément de personnes qui se croient développeurs mais qui ne le sont absolument pas. Je le sais bien j'en ai fait parti …

Quatrièmement le web est basé sur un modèle requête-réponse (qui est inhérent à HTTP) inadapté à ce que l'on essaye de construire avec, oui HTML5 essaye de pallier à cela mais ça reste du bricolage. HTTP est adapté à la consultation de documents statiques, il n'a pas été conçu pour construire des applications, que ce soit réseau social, blog, micro-blog ou même forum. Le modèle de requête-réponse ne peut servir à construire un système de notifications efficace, RSS et Atom-HTTP prouvent que ça fonctionne, mais que ce n'est absolument pas optimal.

Cinquièmement le web n'a pas de système universel d'authentification, il n'est donc clairement pas adapté à la construction d'applications.

Sixièmement le web n'a pas de système de librairie et de dépendances, comme il n'a pas été conçu pour des applications personne n'a pensé à le doter d'une chose aussi essentielle. Là encore on revient au problème du système requête-réponse qui fait qu'à chaque fois que l'on va utiliser une application web on va aller demander si une nouvelle version est disponible, je sais que pour un Windowsien ça paraît vachement bien mais sous GNU on a réglé le problème des mises à jour depuis très longtemps avec les gestionnaires de paquets donc les applications qui se mettent à jour toutes seules on n'aime pas trop (enfin ça dépend qui, les pseudo-linuxiens ça ne les dérange pas plus que Flash et Facebook, moi j'ai encore les deux mais ça m'énerve).

Septièmement le web n'est ni anonyme ni sécurisé, je donne mon IP à tous les sites web sur lesquels je vais qui peuvent donc connaître la région dans laquelle je suis, et mes informations sont transmises en clair la plupart du temps. Pour l'IP c'est pas simple parce que le proxy a besoin d'une bonne bande passante mais pour la sécurisation TLS fait bien son boulot. L'avantage des connexions persistantes comme avec XMPP c'est que la sécurisation ne se fait pas 15000 fois …

Enfin y a sûrement d'autres trucs auxquels je n'ai pas pensé …

PS: par contre je viens de me rendre compte que t'es potentiellement en train de tuer une proposition de sujet pour les clavardages organisés …

On ne peut pas nier les faits, mais je plussoie changacco : les technos web, c'est quand même extrêmement lourd.

Il ne faut pas oublier qu'AJAX, tout comme la syndication d'ailleurs, repose sur l'envoie de requêtes plus ou moins fréquentes vérifiant la mise à jour des contenus. Même si on a des machines de plus en plus puissantes et des connexions de plus en plus rapides, c'est un énorme gâchis de ressources inutiles, car une bonne partie des requêtes se soldent par un résultat indiquant qu'il n'y a pas eu de mise à jour depuis la dernière fois.

Pour faire un parralèle qui déplaira sans doute à certains, on a déjà prouvé depuis belle lurette que la programmation évènementielle était beaucoup plus efficace que la programmation purement procédurale en terme de consommation de ressources et de rapidité de diffusion de l'information

A ce dernier propos, rappelez-vous que dans le cas d'AJAX, pour un chat actualisé toutes les 5 secondes, vous voyez au pire les messages arriver avec 5 secondes de retard, ce qui se ressent très rapidement, et qu'une augmentation de la fréquence d'actualisation va de pair avec une augmentation de la consommation de ressources réseau et une augmentation de la probabilité de revenir bredouille de chaque requête, d'où une fausse impression de réactivité accrue, mais une augmentation d'efficacité largement discutable (rapport charge utile / charge totale des paquets échangés)

Donc non, changacco a raison, le modèle requête-réponse de HTTP n'est pas fait pour des applications complexes en modification et en communication constante. Le cas particulier des forums, wikis et blogs constitue une frontière entre la notion de document et la notion d'application, les trois pouvant être consultés à la manière de documents (majorité des cas) et modifiés comme dans des applications.

EDIT : correction d'une faute de frappe très compromettante
Modifié par QuentinC (15 Jun 2009 - 06:58)

On est bien d'accord, sur le fond. Oui, une appli web est très lourde, à mettre en place et en termes de ressources. Encore que les ressources comme la RAM et la puissance processeur, soient, à mon humble avis, un peu le prix à payer pour utiliser des standards, et des langages interprétés, sans lesquels le web n'est rien.

Le hic, c'est que l'histoire n'avance pas par la logique. Les outils disponibles sont ce qu'ils sont, et même si des technologies plus adaptées existent, ben... On les retrouve pas dans des applications suffisamment répandues, les développeurs ne les connaissent pas, etc.

Doucement, hein, on n'en est qu'au début. On commence à peine à sortir du balbutiement, et à commencer à entrevoir un début de commencement de ce que ça va donner à terme.

Par contre, je maintiens que ruby ferait un bien meilleur remplaçant de JS que python.

Lanza a écrit :
Le hic, c'est que l'histoire n'avance pas par la logique.

Oui et non. Le truc, c'est que le choix d'une technologie ne se fait pas uniquement en fonction de ses qualités intrinsèques, mais aussi (surtout?) en prenant en compte un écosystème complet, qui comprend:
- la disponibilité de compétences sur cette technologie sur le marché;
- un capital sympathie chez les décideurs obtenu d'une manière ou d'une autre (le Java de Sun, les technos Microsoft...);
- les questions de portabilité au sens large (qui ne sont pas purement techniques mais doivent prendre en compte les attentes des utilisateurs: peut-on toucher toute notre cible avec telle techno, et à quel cout?);
- etc.

Lanza a écrit :
Par contre, je maintiens que ruby ferait un bien meilleur remplaçant de JS que python.

Ruby n'a pas de références aux sketchs du Flying Circus dans sa documentation, donc automatiquement c'est moins bien. </fin du débat >

Lanza a écrit :
Le hic, c'est que l'histoire n'avance pas par la logique. Les outils disponibles sont ce qu'ils sont, et même si des technologies plus adaptées existent, ben... On les retrouve pas dans des applications suffisamment répandues, les développeurs ne les connaissent pas, etc.

L'alternative la plus crédible aujourd'hui est XMPP, mais elle a encore quelques soucis notamment dûs au fait que c'est un protocole qui a été écrit il y a 10 ans maintenant. Il y a quelques personnes qui réfléchissent à tout ça (dont moi-même), avec des approches différentes, et quand tout ce processus de réflexion sera fini on pourra passer à l'implémentation et là cette alternative s'imposera par elle-même. En attendant HTTP reste un protocole tout à fait honorable, mais il ne faut pas essayer de s'en servir pour faire tout et n'importe quoi.

Changaco a écrit :
En attendant HTTP reste un protocole tout à fait honorable, mais il ne faut pas essayer de s'en servir pour faire tout et n'importe quoi.

À voir. Ce n'est pas parce qu'un usage est problématique techniquement (nécessité de faire des requêtes régulières car absence de push...) que ça n'est pas pertinent dans l'absolu. De plus, si jamais un successeur de XMPP est intégré aux navigateurs web à l'avenir, il y aura sans doute des stratégies de compatibilité où on utilise XMPP pour les navigateurs compatibles, et HTTP pour les autres. Du bon vieux progressive enhancement, quoi.

Florent V. a écrit :
À voir. Ce n'est pas parce qu'un usage est problématique techniquement (nécessité de faire des requêtes régulières car absence de push...) que ça n'est pas pertinent dans l'absolu. De plus, si jamais un successeur de XMPP est intégré aux navigateurs web à l'avenir, il y aura sans doute des stratégies de compatibilité où on utilise XMPP pour les navigateurs compatibles, et HTTP pour les autres. Du bon vieux progressive enhancement, quoi.

Premièrement si XMPP ou une variante de ce dernier devait succéder à HTTP j'ose espérer que les navigateurs ne seraient pas assez bêtes pour reproduire les erreurs du passé et par conséquent bannirait l'HTML étant donné que tout en XMPP doit être en XML.

Deuxièmement il serait bon de réduire le besoin de scripts, notamment en offrant une mise à jour automatique des documents lorsqu'ils changent, confier ça au client plutôt qu'au "document" lui-même. Prévoir des protocoles adaptés pour les forums, blogs et wiki réduirait également fortement le besoin pour du scriptage que ce soit côté serveur ou côté client. Tout ça fait partie de la réflexion en cours bien sûr, il existe même déjà une base de travail que s'appelle PubSub pour XMPP. Le micro-blogging est en préparation aussi dans XMPP.

Changaco a écrit :
j'ose espérer que les navigateurs ne seraient pas assez bêtes pour reproduire les erreurs du passé et par conséquent bannirait l'HTML

Belle ineptie ça.

Benjamin D.C. a écrit :
Belle ineptie ça.

Magnifique argumentation de ton côté …

Je vais préciser parce que c'est vrai que c'était pas clair pour des gens qui ne connaissent pas la problématique en question. HTML est basé sur SGML, langage totalement illogique et pour lequel il n'existe aucun parseur complet, c'est la raison pour laquelle il serait bien de s'en débarrasser une bonne fois pour toute si on devait changer de protocole. XMPP est fait pour transporter du XML, la chose la plus débile à faire serait d'aller mettre du HTML dans un <![CDATA[ … ]]>.

En ce qui concerne HTML5 qui d'après ce que j'ai compris a son propre DOM, ça me paraît être une idée ridicule dont la seule motivation est la rétro-compatibilité, chose qui m'énerve quand on en abuse.

Ce serait l'occasion de faire du XHTML5, vu que le XHTML est compatible XML. (Tous ceux qui ont pensé XHTML2 à la place de XHTML5, levez-vous)

Changaco a écrit :
HTML est basé sur SGML, langage totalement illogique et pour lequel il n'existe aucun parseur complet, c'est la raison pour laquelle il serait bien de s'en débarrasser une bonne fois pour toute si on devait changer de protocole. XMPP est fait pour transporter du XML, la chose la plus débile à faire serait d'aller mettre du HTML dans un <![CDATA[ … ]]>.

Donc HTML c'est mal car basé sur SGML, langage totalement illogique et pour lequel il n'existe aucun parseur complet. À l'inverse, en XMPP on transporte du XML, langage qu'il est bien car... basé SGML, langage totalement illogique et pour lequel il n'existe aucun parseur complet.

Ah mince, j'ai dû louper une info.

Pour rappel:
- HTML est depuis le début inspiré de SGML;
- HTML 4 a été défini comme application de SGML;
- XML est un sous-ensemble (subset) de SGML;
- HTML 5 ne sera pas une application de SGML pour sa version non-XML, il en garde des caractéristiques évidentes mais la conformité SGML est rompue;
- XHTML 5 sera une application de XML, et à ce titre sera conforme SGML.

Changaco a écrit :
En ce qui concerne HTML5 qui d'après ce que j'ai compris a son propre DOM, ça me paraît être une idée ridicule dont la seule motivation est la rétro-compatibilité, chose qui m'énerve quand on en abuse.

Les trois grands axes qui sous-tendent HTML 5 sont 1) la rétro-compatibilité (pas systématique mais généralisée), 2) la rationalisation et la simplification pour s'accorder aux implémentations existantes et aux besoins des éditeurs de contenu (dix ans d'expérience après HTML 4, il faut bien en tenir compte!), et 3) l'ajout de nouvelles fonctionnalités.

Pour le DOM, est-ce que tu peux fournir des détails? Je doute que HTML 5 forke le DOM. Par contre, il peut y avoir des propriétés DOM ou API DOM propres à HTML 5, mais ce n'est pas la même chose que d'avoir un DOM différent...