Coucou,
Pour faire court, sur le post dédié au tuto sur le HTML/CSS, j'en suis venu à penser qu'un petit tuto sur une introduction « Le Web, comment ça marche? ». Mais j'aurais besoin de savoir si le plan vous semble correct.
Ceci ne contient pour l'instant que le plan!
Merci !
Ca me semble plutôt bien. Juste, pense à mettre un espace avant un signe de ponctuation double (? : ! etc), et après aussi, si le texte continue. Voilà, bonne chance pour la suite !
Merci beaucoup Bat', ces remarques font aussi partie des petits trucs que j'oublie tout le temps 
Ton petit tuto à l'air bien sympa, même si je pense que la partie "l'avenir est dans les frameworks javascript" n'a pas vraiment de valeur éducative: c'est un avis plutôt tranché… Et puis PHP n'a jamais été le seule coté serveur.....
En fait, je m'attendais à cette remarque 
La partie PHP va traiter de l'apparition du dynamisme coté serveur (on ne délivre plus des pages statiques, on les génère en plus). Mais ça n'empêchera pas de parler d'autres technologies, je parle juste de l'apparition de ce concept.
Pour le dernier chapitre, je voudrais aborder la "nouvelle" vague de frameworks web, les framework JS qui s'orientent de plus en plus vers de la réactivité temps réel (Meteor pour ne citer que celui-là). C'est leur principale différence avec les mastodontes du milieu comme Symfony et RubyOnRails.
L'intérêt d'en parler? Le web voit de plus en plus apparaitre le terme "application web", et c'est justement avec ces technologies qu'on peut produire quelque chose qui y ressemble réellement, sans manger une tonne d'ajax bien lourdingue (grace aux websockets)
L'intérêt éducatif est dans le fait d'apprendre que dans le web, une nouvelle étape est en train d'être franchie. Mais bien sûr, j'insisterai sur un point essentiel : leur application est spécifique, et pour beaucoup de choses n'importe quel autre framework fait tout aussi bien l'affaire!
Le dynamisme côté serveur n'a pas été introduit avec PHP mais plutôt avec CGI je crois. À vérifier mais ça me paraît dangereux d'impliquer que PHP est le premier et seul moyen de faire du dynamisme côté serveur.
C'est vrai!
Les titres sont temporaires en fait, mais j'aurais dû mieux les penser de suite…j'ai mis "PHP" vu qu'aujourd'hui c'est le poids lourd super connu du milieu
Mais surtout, n'oubliez pas que je suis absolument ouvert à toutes les propositions et remarques! Vu le sujet, c'est normal!
Si je puis me permettre un conseil, plutôt que de faire un tuto tout seul et de proposer aux autres de faire des remarques dessus, tu devrais adopter la même démarche que nous pour le cours d’intro à la programmation : réunir dans un MP des membres qualifiés sur la question du dev Web (genre, les membres actifs de la section Web du forum et les auteurs de tutos liés au Web), vous mettre d’accord sur les points à aborder, comment les organiser, comment limiter le sujet, etc. et ensuite seulement décider de qui participera à la rédaction proprement dite.
Voyons voyons, qui pourrait être intéressé… Je vais aller chercher qui serait dispo!
Désolé d'être un peu direct mais le plan en l'état est beaucoup trop dogmatique pour être évalué.
Idem dans tes commentaires d'ailleurs, pour avoir bouffé de l'AJAX et des websockets à en vomir (les deux) je ne vois pas en quoi la notion de web-application est liée à l'une ou l'autre des technos. Les deux techniques sont totalement complémentaires. Mettre en place des websockets a un coût non négligeable côté serveur, faire du pub-sub aussi en fonction du modèle de données, utiliser des websockets sous prétexte que c'est neuf et moins "lourdingue" c'est à la fois faux et sans doute une mauvaise idée dans la plupart des cas :\
S'engager en disant que "l'avenir c'est X". C'est très dangereux. Il existe le SSE qui est une bonne alternatives aux websockets dans certains cas, HTTP2 est de plus en plus implémenté et surtout, les APIs REST sont encore et toujours utilisées en tant que fournisseur de service.
"L'avenir c'est Meteor", ouais mais non, c'est trop réducteur pour un cours sur le web.
Je suis pas certain non plus qu'envisager l'aspect dynamique comme ça soit la meilleure approche. Pour moi, un serveur web c'est un serveur qui remplit un tuyau avec du texte quand on le lui demande. En gros, on lui envoie un message, il répond par du texte. Donc par essence, il est dynamique, il envoie du contenu tel qu'il l'a décidé. Après, il s'avère que ce tuyau, il peut le brancher sur le système de fichier qu'il a chez lui, tant mieux, ça permet de gérer l'aspect statique. Enfin, un serveur étant un programme comme un autre, on peut lui dire que pour répondre à une certaine demande, il peut évaluer un script, un programme, un bout de code.
De l'autre côté, je ne vois pas du tout le côté "client". Tu parles de l'évolution d'HTML sans vraiment qu'on sache ce que c'est (jusque là tu as parlé soit de protocole, soit du serveur).
Selon moi, PHP n'est peut-être pas le meilleur exemple pour vraiment comprendre comment fonctionne HTTP. Je me demande si partir depuis nodejs ou du CGI même, bref un truc qui "parle" HTTP directement me semble beaucoup plus instructif. T'as reçu quoi dans le tuyau ? Tu le décortiques, tu réponds par du bête texte, il affiche quoi le navigateur ? Ah, et si maintenant tu expliques au navigateur comment il peut mettre en forme le texte il se passe quoi ? Ah, et si maintenant tu lui dis explicitement comment il doit l'afficher il se passe quoi ? Et si tu lui envoies un code d'erreur ? etc.
Donc à mon sens, sois moins dogmatique, moins orienté, prends du recul sur le pourquoi du comment le web fonctionne pour que ton tutoriel soit concentré sur le fonctionnement du web et pas un état de l'art d'une toute petite portion des technos webs.
Bon courage, c'est un gros morceau mais y'a moyen de faire un très bon cours.
PS : ce que tu appelles "l'avenir", c'est juste une toute petite partie d'un effet de mode. L'effet de mode en question c'est de se détacher des frameworks clef en main pour se rapprocher d'HTTP "brut de décoffrage". Là où RoR, Django ont été en pleine hype à un moment, aujourd'hui c'est node, sinatra, flask, finagle/finatra, etc. Dire que c'est l'avenir ? Rien n'est moins sûr. On aurait pu dire "RoR c'est l'avenir", aujourd'hui certains en reviennent, parce que pour un certain usage ça n'allait pas (alors que pour d'autres c'était excellent). Il faut se méfier des tendances et savoir prendre ce qu'il y a de bon dedans.
Désolé d'être un peu direct
Aucun problème, j'ai (et ça se voit) du mal à généraliser ce que je sais pour écrire ce cours! Je n'ai connu la conception de sites web qu'à travers les prismes HTML/CSS/PHP avec apache, Symfony2, RoR, Node.js et Meteor.
Pour l'AJAX : les websockets permettent quand ils sont bien utilisés un échange "en temps réel", l'ajax avec RoR dans mon ancien travail était plutot plein de latence, surtout dès qu'on commençait à en spammer. Mais je n'ai pas assez poussé ce sujet pour pouvoir en dire plus que ce que j'en ai vu.
J'aime beaucoup ton idée pour l'approche du cours! (généraliser de suite le serveur pour mieux expliquer ensuite les différentes approches inventées au cours des années) 
Je vais revoir le plan.
Par contre, je ne suis pas sûr que descendre jusqu'à l'explication "dans le tuyau" soit vital. Ca nécessiterait une sorte de "TP", non? (tu sais, pourquoi expliquer pas à pas ce qu'il se passe).
( Note à moi-même : revoir de toute façon tous les titres, et virer la moindre mention d'une technologie même si c'est général, pour ne pas me faire assassiner )
(pour ton PS, je pense y avoir répondu dans mon précédent message en fait, je précise que ces frameworks sont plus efficaces pour des applications spécifiques)
Pour l'AJAX : les websockets permettent quand ils sont bien utilisés un échange "en temps réel", l'ajax avec RoR dans mon ancien travail était plutot plein de latence
Il n'y a pas de lien direct entre la techno et la latence.
Une API REST permet de répondre à une requête, une websocket permet de pousser des données, dans un sens ou dans l'autre (typiquement pour faire du pub/sub).
L'AJAX sera intéressant pour un échange de type "transactionnel, sans état", un peu comme un appel de pure fonction dans un langage adapté. Mêmes entrées => même sortie. Exemple type : un login, la création d'une ressource, etc.
La websocket sera intéressante dans le cas d'une "conversation", d'une sorte de ping-pong entre client et serveur du style chat.
Le SSE sera plus adapté à du push à sens unique, dans le cadre d'envoi de notifications par exemple. Il n'y a pas de scénario pré-établi, les données sont "transientes" la plupart du temps, un client connecté à un instant t recevra des données, ce même client connecté à t' en recevra d'autres, contrairement à un appel REST.
La différence est certes technique, mais surtout fonctionnelle. En fonction de ce qu'on veut faire, l'une ou l'autre des technos est mieux adaptée. On confond parfois AJAX et HTTP-polling (d'ailleurs ça transparaît dans ton message : "dès qu'on commençait à en spammer"). Les websockets sont une bonne alternative au polling, mais pas à l'AJAX ou à une API REST.
La latence n'était pas liée à AJAX, mais aux traitements par derrière. Ta comparaison n'a pas vraiment de sens. C'est comme si tu disais : mes mocassins sont intrinsèquement de meilleures chaussures que mes tongs, parce que dehors en hiver avec mes tongs j'ai constaté que j'avais froid aux pieds. Tu compares deux technos adaptés à des usages différents, probablement implémentés sur des stacks techniques différentes, avec des modèles de données différents. Je pourrais te répondre que j'ai déjà constaté une charge beaucoup plus lourdes sur un serveur de websockets en comparaison avec un serveur d'API REST classique, parce que maintenir une liste de clients connectés en IDLE ça lui pompait de la mémoire pour rien => idem, c'est que l'usage est mauvais.
Je n'avais jamais remarqué cette différence fonctionnelle… 
Je te propose alors un plan retravaillé:
Qu'en penses-tu?
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