Reprise du message précédent :

Un bon développeur a expérimenté plusieurs technologies et est capable de choisir la plus adaptée pour un projet donné. Mais vu que là il a l'air d'avoir zéro expérience du web, il ferait bien de commencer par HTML/CSS.

Oui, alors ça j'ai fait. Il y a 2 ans pendant l'été j'ai choisi un framework (web2py, comme ça je faisais du python ça me faisait moins peur, et puis c'est un framework réputé pour son intéret pédagogique), j'ai acheté le livre, j'ai fait les tutos et j'ai construit un site.

Sauf que faire les tutos c'est facile, suivre des recettes aussi, mais au final tout ça ça restait de la magie pour moi, je ne comprenais rien à ce que je faisais et dés que je voulais sortir d'un poil de cul de la recette qu'on m'avait filée, tout me pétait à la gueule. Puis je te raconte pas au moment du déploiement la prise de tête, là encore en mode J'ai aucune idée de ce que je fais...

Le problème c'est que pour ccomprendre l'intérêt et la philosophie de tous ces framework, c'est essentiel je pense (et c'est ce que vous m'aviez dit à l'époque quand je m'étais plaint de la complexité de la chose ) de savoir ce qu'on lui fait faire, concrétement, et donc d'être capable le cas échéant de le faire à la main. C'est pour ça que là, pour le moment, je ne prends pas de framework. Je prends les standards modernes mais en termes d'outils je voudrais faire comme en 97.

Tout ce que je connais c'est la programmation locale, de l'assembleur au C++ ça va à peu près, et niveau OS j'ai une petite idée de ce qu'est une connection réseau, un socket, HTTP je pense cerner le truc j'ai déjà codé un client HTTP pour une caméra disposant d'une interface REST.

Là où je suis noyé c'est tout ce qui touche à ce que fait le serveur web (Apache ou IIS), je saisis bien qu'il joue un rôle important mais c'est entièrement magique pour moi.

wok

Tu aurais des ressources pour ça ?

Cimer

Par rapport à la mise en cache de twig, je pense que je comprends l'idée...

Du coup il faut que je choisisse une bibliothèque de mis en cache et que je configure php de façon adéquate ?

Il y a deux buts :
- Apprendre le développement web.
- Créer un site pro pour mon professeur de piano.

Le second objectif serait vraisemblablement atteignable sans grande difficultés avec un CMS quelconque, mais ça ne m'avancerait pas beaucoup pour le premier.

Du coup mon idée c'est :
- Créer un site statique comme en 95 pour comprendre html, css et javascript. <== J'en suis là
- Une fois le site en ligne, ajouter des fonctionnalités dynamiques, typiques d'un CMS mais si ça l'intéresse je pourrais aussi faire des choses un peu plus poussées genre paiement, réservation en ligne, ou planning. À la réflexion, je voudrais pour ça le moins de magie possible donc j'envisage de m'en tenir au php brut dans un premier temps, je pense que l'envergure modeste du projet l'autorisera.

 
Je pense que c'est une excellente idée.

Je pense que t'as raison de vouloir commencer à l'ancienne pour comprendre à quoi servent les frameworks.
 
Très vite tu vas te rendre compte que ca permet au moins (les micro-frameworks en gros):
* faciliter la gestion des vues (navbar, footer, header..etc..) pour eviter les includes ou pire le copier/coller. => View (HTML/JSON)
* faciliter le dispatching des requetes (gestion de l'url et du routing en fonction du type de request GET/POST..etc.. et de la ressource) => Controller (HTTP/WebSocket)
* faciliter la communication avec la BDD => Modele. (SQL ou NoSQL , pas spécifique au web)
 
Note que le MVC n'est pas specifique au web, la plupart des frameworks web sont juste une application du MVC sur les techos web (HTML/HTTP).
 
A ta place, je partirai sur du micro framework, ou bien sur encore plus minimaliste genre juste la librairie HTTP de Node ou de Python.  

Je vais me répéter mais.. commence par faire tes pages avec bootstrap pour tout le static, puis utilise ensuite un framework pedagogique style laravel.

Apres oui les frameworks c'est souvent beaucoup de "magie". Ca sera plus ou moins pareil avec tous les frameworks de n'importe quel langage de toute facon. Tu peux aussi faire sans framework mais y a 99% de chance que tu produises un code dégueulasse et que tu n'apprennes pas grand chose. Plus tard avec l'habitude et en fouillant dans l'API du framework tu finiras par comprendre ce qui se cache derrière. Dans un 1er temps faut se contenter des methodes standards.

 
+1

Sauf que s'il est surtout intéressé par apprendre, et qu'il a le temps pour ça, commencer "à la main", à l'ancienne, pour comprendre par la suite l’intérêt des frameworks qu'il va utiliser peut être pas mal, même si son code initial est immonde.

Oui merci pour les conseils, du coup question dino : on faisait comment en 95 pour faire des templates de sites ?

https://en.wikipedia.org/wiki/Common_Gateway_Interface

Vous auriez pas sous la main une liste d'arguments pour faire comprendre à une société pourquoi c'est mal de rester sous IE9 ?  
Il me semblait avoir vu un site bien branlé pour ca un jour (pas en mode web-dev-rageur mais orienté client)
 
Merci

Bah c'est pas dur, si?
- Plus supporté à partir du 12 janvier.
- Plus supporté par certains sites et bibliothèques JS, donc ça oblige les utilisateurs à avoir un autre navigateur.
- Aucune raison de ne pas utiliser IE11.

Si tu savais le nombre de demandes que j'ai avec compatibilité IE8

Merci, me manquait la date du 12 janvier

Sinon, oui on va pas refaire le débat, mais en gros, chez certain gros client qui ont pas les corones de mettre à jour leurs parcs info (hardware/software), on est bien obligé de faire avec. Mais bon là je pars justement en guerre contre, et j'essaye d'être le plus constructif/objectif/pédagogue possible.

Le plus simple serait qu'ils fassent un audit de sécurité. Il y a de bonnes chances que tout ce qui n'est pas à jour soit remonté.

Tu leur dis que ton taux horaire est multiplié par (12 - version)

Ouais mais non, web2py c'est un truc spécifiquement hyper-magique que personne ne recommande à part les gens qui font que du web2py. Il y a magie et magie, web2py c'est le truc qui va bricoler le runtime et évaluer tes fichiers lui même dans un contexte spécial en auto-injectant des imports parce-que "c'est plus simple"

ah ok je connais pas specifiquement web2py

J'ai jamais trouvé ça si chiant en fait (hors site angular & co)
 
Y a quand même pas mal de polyfill dispo + prefixes + jquery 1 toujours maintenu.
 
Perso je recommande postcss avec autoprefixer (et quelques autres petits plugins), ça fait du css compatible tout en faisant sembler d'ignorer tous les browsers de + de 15 jours

Quand tu vois que certains FW responsives sont totalement HS sur IE8...

Moi je propose une autre pproche :  
client riche , rendu côté client pour les navigateur modernes
client rendu côté serveur pour les autres, dont les 10% de déficients visuel
 
Autre approche : client fonctionnel, mais pas pixel perfect ou même des fonctionnalités manquantes
 
C'ezst dommage aujourd'hui de se passer de flex et rajouter des Mo de polyfill

Perso, le flex j'aime bien, mais pas au point de passer ça en prod avec tous les browsers en utilisation today

Si tu abandonnes IE9 , alors flex est dispo partout (moyennant les prefixes)  

En moyenne, j'ai encore 10-12% de gens sur IE8/IE9 sur la plupart des sites que je gère.
Après, le flex, c'est surtout sur mobile (android/iOS/WP) qu'il faut checker la compat'.

 
complètement d'accord avec ça. Je préfère d'ailleurs le rendu côté "serveur" pour les autres. Je passe moi même parfois bcp de temps en ligne de commande et je déteste arriver sur un site que je peux pas lire avec w3m.

Rendu serveur : je comprends pas, tu files un autres template / autre vue serveur pour ceux-là ? (genre template HTML4 simplifié)

Non.
Rendu client : le serveur envoie un json (ou autre), le client construit le document (le dom).
Rendu serveur : le serveur envoie un DOM déjà construit, tu n'as plus qu'à le mettre là où tu veux.

En gros, c'est ce qu'on faisait il y a 10~15 ans en PHP, avec les toutes premières version des sites dit en "ajax"

Tu as cette solution, qui est un peu à la bite et au couteau ( mais qui fonctionne)
 
Tu as aussi la mode du javascript isomorphique : ton fais un rendu HTML côté serveur, ton FW client se charge et prends le relai avec une navigation côté client . Twitter utilise beaucoup ça.
Comme ça si ton client est pourri, il a quand meme une page html/css

D'ac, merci

 
ça dépend du type de site et de projet.
 
Sur certains projets, tu fais une version HTML simpliste générée par le server sans JS etc... ça fait plus de travail, mais de toutes manières d'un autre côté, cela t'impose de ne jamais oublier de traiter tous les résultats de requêtes côté serveur.
 
Sur pas mal de projet modernes, tu as des sites/applies web qui sont maintenant quasi entièrement côté client avec des appels AJAX au server qui envoie des données "pures" sans aucun HTML. Le gros avantage, c'est de pouvoir à terme transformer l'applie en iPad/Android App sans pratiquement rien changer. Une telle approche exclue IE8/9  
Dans certains cas, IE8/9 restent utlilisés et/ou on veut aussi qu'un mode texte puisse marcher. Dans ce cas, tu fais un site simpliste avec un simple rendu HTML produit par le serveur pour les supports qui ne peuvent pas utiliser la version moderne du site.

C'est un peu ce que je fais, première page, il charge un template HTML avec dom, puis les autres pages sont chargées en async, retour Json, et placement des infos.
Selon le client, le serveur renvoie un json et une version parsée avec DOM au cas où. (enfin, une variable avec l'html parsé dans le tab json de retour, quoi )

j'sais pas si c'est une bonne idée en fait

Tu renvoies systématiquement les deux versions ? Les données en JSON, et formatée ?
C'est super lourd ça ! Tu ne bénéficie d'aucun des avantages de l'une ou de l'autre des deux versions en fait
 
Tu n'as pas la légèreté de la requête et l'économie des ressources serveur que pourrait te procurer le fait de n'envoyer que du json.
Et tu embrouilles ton client plus que nécessaire que s'il ne recevait que la version DOM.

Non, je fais ça que quand le client est suspicieux (IE8/9 détecté), mais rien de fiable puisque basé sur l'user agent

Ok.
Du coup, je vois pas l'intérêt.
Client suspicieux : si tu n'es pas sûr, tu cherches pas, tu envoies en DOM. C'est plus simple pour tout le monde, et surtout, en maintenance, tu sais quel chemin suis ton code.
 
Parce que du coup, tu as un bug sous IE9. En débug, tu fais comment ? Dans un premier temps, il faut que tu devines quel chemin ton code a emprunté (rendu server ou client) !? Non ?

Presque, à chaque retour, j'ai un tab Json avec un truc du genre : (et où output est vide si le client est "normal" )
{
    "response": {
        "vars": [
            {"lol":1, "foo":2}
        ],
        "output" : "<div>lol</div>"
    }
}
Donc je sais quel template est utilisé, je remonte le log de l'appli et je débugge assez rapidement

Il n'empêche, tu ajoutes beaucoup de bruit inutile.
Bande passante, ressources, maintenance, c'est contreproductif.
Envoie, et traite, l'un ou l'autre, pas les deux.

Tout dépend si tu vises la qualité de service ou la performance...
 
Mais vu le coût en face, de plus en plus la qualité de service prime de loin sur la performance.
 
Sans compter que s'il a bien fait son système, il utilise le même template du côté client que serveur (genre Handlebars), donc en réalité, la seule complexité tien sur le JSON, et le micro bout de code qui va choisir entre en rendering client ou l'inclusion serveur.
Autant dire un coût assez minime.

Le template est le même, si j'appelle la même page sans async ou autre, j'ai le même rendu, simplement, ça me permet d'envoyer un autre template pour un client en particulier s'il faut
mais mon appli est loin d'être parfaite, par contre, je peux coder assez vite surtout.

Le client devrait être capable de savoir s'il est capable ou pas.
S'il est capable, JSON. S'il ne l'est pas, DOM.
 
Bien sûr que le choix duquel traiter est "gratuit". Mais :
 
- Le serveur doit générer le JSON ET effectuer le rendu DOM. C'est lui rajouter une charge supplémentaire dont il pourrait bien se passer. Sur des milliers de requêtes, ça peut faire une différence.
- Les données sont envoyées en double sur le réseau : en JSON et en DOM. C'est doublé, quoi qu'il arrive. C'est redondant, consommateur de BP. Sur des milliers de requêtes une fois de plus, surtout si les données sont importantes.
- L'ensemble du JSON doit être chargé dans la mémoire du client, puis parser / traité quoi qu'il arrive, pour finalement n'en utiliser que la moitié par le micro bout de code qui va choisir le rendering ou l'inclusion. Sur des documents avec une grande quantité de données, ça peut faire une sacré différence, surtout sur des config pas très à jour.
 
A un moment donné, il est capable de faire un choix entre rendering et inclusion. De faire ce choix après la requête plutôt qu'avant, c'est juste l'inverse d'optimiser, quel que soit le contexte. Alors que finalement, techniquement, il n'y a aucune difficulté à différencier correctement les deux.

Le serveur génère du JSON dans tous les cas, et dans 10% des cas (IE8/9), effectue un rendu DOM
Sinon c'est le client qui fait son rendu.

Que le serveur génère du JSON dans tous les cas, et effectue parfois un rendu DOM, ok. C'est le seul truc que je trouve à peu près excusable (et encore ).
Mais tout renvoyer vers le client, ça reste à mon sens une erreur (NB: oui, je sais, il ne renvoie tout qu'à certains client, mais ça ne change pas mon propos : ces clients qui reçoivent tout sont justement ceux qui devraient en recevoir le moins possible ).

et un truc tout con ou tu detectes les possibilité du client au chargement du template?
tu lances une requete $.getJSON que tu tentes de decorer et d'inclure puis tu check le rendu.
 
si ca colle pas tu sais que tu es en mode merdique et ta factory te retourne un mode DOM, genre au lieu de $.getSON() ca te fera des $.load() avec les urls qui vont bien.