Reprise du message précédent :

 
r'fo C'était la blague

Je suis un peu dans le cas de rufo, single dev d'une appli php/mysql construite il y a fort longtemps, et je suis toujours surpris de la facilité avec laquelle ça passe le test du temps. Passée en PHP 8.3 cette semaine justement, et c'est une librairie associée qui a couiné, sinon zéro souci.
PHP 8.2 c'était un peu plus galère avec pas mal de fonctions qui n'acceptent plus les valeurs nulles en entrée, mais pas trop compliqué à gérer une fois que tu as compris le problème.
Et côté code, j'ai du procédural et de l'objet, un pseudo MVC maison, des objets juste pour les trucs vraiment réutilisés partout / procédural pour ce qui ne servira de toute évidence qu'à un seul endroit.
Surtout j'évite autant que possible les trucs tordus de code sur-optimisé ou trop conceptuels : le délire des objets "véhicule" avec ensuite la classe "voiture" dont la méthode get_roues() surcharge celle de véhicule je trouve ça joli dans les bouquins, mais souvent en pratique c'est aussi le bon moyen de se paumer et s'arracher les cheveux pendant des heures quand tu débugges et que tu ne cherches pas au bon endroit.
En terme de ressources justement, quand tu as une case avec une variable GET et que tu n’exécutes que la partie qui va bien (tests, update bdd, select qui va bien...) c'est juste ultra efficace. A l'opposé quand le moindre appel à la moindre page te charge la moitié de ta bdd en ram via l'appel à 500 fichiers imbriqués (ok j’exagère, mais c'est un peu l'impression que Wordpress me laisse par exemple) forcément c'est plus la même chose. Sur un serveur type kimsufi premier prix, tu peux faire tourner plein de trucs en PHP... mais un site Wordpress est totalement à la ramasse pour le moindre affichage de page qui n'est pas en cache.
 
A côté de ça j'ai dev une app mobile pour Android, vu que je suis une bille sur le sujet j'étais passé par un truc permettant la cross compatibilité ios/Android + coder principalement en JS... ben ça a été une merde sans nom à maintenir, et désormais c'est tombé en désuétude.
J'ai tout refait dans un autre langage équivalent (react-native) car c'est vraiment une app riquiqui, et quel bordel, pour faire la moindre chose tu es "obligé" d'importer des composants tiers, genre pour faire un bouton, un side-panel, ... tout dépend très vite de trucs extérieurs. J'imagine qu'on pourrait tout faire soi-même, mais comme évoqué plus haut, on évite en général de réinventer la roue s'il y a quelqu'un qui a déjà fait ça très bien, qui est probablement nettement plus compétent que moi et qui a fait face à la majorité des bugs et problèmes.
Bref, au bout de 6 mois ça ne compilait plus à cause de dépendances, de librairies abandonnées, de trucs remplacés, ... j'en ai chié... pour une app de 3 écrans / 2 boutons.
 
Donc pour revenir au développement web, j'ai tendance à limiter moi aussi autant que possible l'utilisation de frameworks et librairies tierces... mais pour les trucs vraiment relous (mails, gestion de calendriers avec évènements récursifs, génération de pdf...) difficile de faire sans.
Mais même en prenant les libs les plus populaires du moment, ça arrive quand même régulièrement que le projet soit abandonné.
J'utilisais WAmailer à une époque, et de souvenir ça a merdé et j'ai du passer sur PHPMailer, je crois que c'était justement l'absence de suivi suite à une mise à jour majeure de PHP.
Il y a aussi le moteur de template smarty, avec lequel j'ai commencé directement (en 2004 ou 2005 je crois ?) parce que c'était la base pour séparer code de présentation, ça ne s'est pas toujours bien passé, mais c'est difficile de faire autrement désormais sans tout recoder l'appli. Étrangement après une période difficile (versions de PHP encore, probablement le passage à PHP 7) ça a l'air totalement ok aujourd'hui, et les versions actuelles passent sans souci en PHP 8.3 sans avoir à tout recoder... même si cette couche est totalement dispensable et qu'avec le recul j'aurai dû faire sans.
 
En fait le pire c'est pas forcément la lib dont le suivi s'est arrêté mais plutôt les nouvelles versions non rétrocompatibles. Genre le dev à totalement revu la manière d'intéragir avec sa lib, et là c'est très chiant. Genre tu as besoin de la nouvelle version sinon tu as whatmille erreurs dans ton nouveau PHP X.Y, mais si tu mets la nouvelle version de la lib il n'y a plus rien qui fonctionne et il faut tout refaire l’interaction avec elle.
 
Bordel, j'ai encore fait un pavé, désolé

Un peu pareil que Rufo et Depart, mes classes ne sont souvent que des boites à outils dans lequel je vais piocher des fonctions dont j'ai besoin un peu partout (DB.obj.php, File.obj.php, I18n.obj.php, etc.).
Sinon je fais le plus souvent du procédural.
Pour le problème des mises à jour des libs tierce je passe toujours par un objet intermédiaire "à moi" pour centraliser les appels et donc limiter la casse en cas d'abandon ou de changement.
Par exemple j'ai un singleton Mail:: qui est une surcouche à phpMailer avec toutes les configs spécifiques au client chargé lors de l'initialisation de l'objet.
 
Un jour faudrait faire payer le vrai cout écologique aux services web, entre un site "onepage"de 10Mo avec on ne sait combien de requête à la base de donnée d'un Wordpress "vitrine" (sans actualités ni réel besoinde dynamisme, des fois y'a un formulaire de contact ^^) et l'équivalent 100% html statique avec js et ccs minifié le rapport de ressource gaspillé doit être de 10 ou 100...

Ah ben pareil, pour PHPMailer, j'ai fait une petite surcouche qui m'a permis de pas trop galérer quand j'ai changé de lib pour envoyer des mails

mechkurt : bonne idée l'objet intermédiaire. Je l'avais fait pour smarty, mais en pratique si je voulais passer sur autre chose je suis quasi sûr que ça deviendrait une usine à gaz parce que quand on construit l'intermédiaire on se base sur les besoins de la lib qu'on utilise et si ça se trouve la nouvelle aura besoin d'autre chose et faire un parfait match 1:1 va nécessiter la mise en place d'une usine à gaz.
 
Pour le mail par contre c'est pas bête. J'aurai dû le faire. A la place je me suis fait un truc genre smtp_prepare() qui prend l'objet phpmailer en entrée et le retourne configuré avec tout ce qu'il faut, mais ta solution aurait été meilleure.
 
Le site statique, j'y pense de plus en plus pour les prestas que je fais pour des petites boîtes.
Vu le bordel de Wordpress, les mises à jour, les extensions qui pètent le site lors d'une mise à jour... et en face le client qui ne touche en pratique à strictement rien et qui t'appelle pour faire une modif, c'est tentant de regarder du côté de Hugo par exemple.
Mais en même temps on peut désormais honnêtement facturer une presta de maintenance/sauvegarde mensuelle
 
Et du côté de Hugo (et équivalents), pour l'instant je n'ai pas trouvé beaucoup de contenus sympa (justement des thèmes et plugins qui font la richesse de Wordpress).
Ca manque aussi de GUI (enfin la dernière fois que j'avais testé). Se taper l'ajout de pages ou la compilation via des lignes de shell c'est un peu 90's. C'est bien que ça existe, mais ça serait sympa d'avoir un Hugo éditor avec la lourdeur d'un Wordpress si on veut, et ensuite que ça génère le joli HTML tout seul et le publie en prod à chaque fois qu'on clique sur un bouton "publier".

Ben non l'interet de l'objet c'est la boite noire qui ne te fait qu'exprimer un besoin au niveau de ton code, besoin qui légitimement ne changera jamais.
Affiché une image optimisé & recadré, envoyer un mail, afficher un pdf, etc.
Si tu dois changer de lib il faudra que le job continue à être fait, donc trouver une autre manière de faire.
A un moment donné le plus grosse refactor que j'ai eu à faire sur un changement de lib ca a été de passer de tcpdf à html2pdf (pacque le client avait besoin de bcps de latitude sur la mise en forme de son contenu administrable et il y'a fallut bien verrouiller son tinymce).

La plupart du temps le client se fout un peu de la technologie, et a partir du moment ou il paye il préfère sous traiter la modif a son prestataire.
Je penses que bien amené (sécurité, écologie, économie), le site statique pourrait encore bien se vendre.
Quand je dit statique, je penses surtout au coté léger au niveau du serveur, ça n’empêche pas une certaine richesse (graphisme, animation) au niveau du client...
J'en suis un peu revenu du "ça vas plus vite de poser un WP", ce n'est pas si rapide au final, ça implique des couts de maintenance supérieur et le bilan écologique est vraiment mauvais.

Tout dépend du besoin du client, s'il veut un backoffice facile à prendre en main, ou qu'il a l'habitude de Gutenberg sur WP, alors perso, ça va plus vite de poser un WP, de faire rapidos un template sur mesure, et si fonctions personnalisées très précises, alors j'ajoute un plugin MVC maison via un adapter WP que j'ai également fait de toutes pièces.
Ce qui me permet de rester dans le même environnement de développement (MVC) tout en restant compatible avec un WP.
Et si jamais le client veut virer WP pour passer sur Drupal, j'ai rien à redévelopper puisque j'ai fait l'adapter Drupal aussi.
Même chose si Synfony ou autre...
C'est pas le plus "écologique", mais ça répond à la demande et c'est compatible en temps et en budget pour le client, enfin ça me permet de pas passer trop de temps et de réinventer la roue partout.

This ×1000.
 
J'ai aussi un micro-framework MVC. Je viens de faire un module pour WordPress, le cœur de l'app est complètement agnostique. Tout est planqué derrière des interfaces, ce qui me permet de changer ce qu'il y a en-dessous, voire de l'adapter pour autre chose. Seule la partie admin est 100% spécifique (y'a du WooCommerce aussi, ça va être difficile de s'en abstraire), sinon tout le frontend ne sais même pas qu'il est sous WP.
 
Et comme mechkurt, je planque systématiquement les libs sous-jacentes. Je dois faire de l'export PDF, j'ai donc une couche intermédiaire entre l'app & MPDF. Ainsi je peux changer l'implémentation sans modifier au-dessus. Pareil pour les mails, la DB, etc.

Évidemment je parlais de se passer de WP au profit de site statique dans les cas (relativement nombreux dans mon cas ^^) ou y'a pas de mise à jour coté client (et encore moins de vente en ligne ^^).
Et encore, on pourrait envisager un bout de backoffice qui modifie une page html, mais bon c'est un autre problème.
 
On peut aussi faire un site dynamique sans charger 1Go de fichier php en mémoire et 10 requêtes à la base de donnée, c'était le propos à la base...

Début des années 2000, en stage chez un traiteur, je lui avais codé en Delphi un logiciel de gestion de ses prestations (du devis jusqu'à la facturation, avec la gestion de son catalogue produits). Il avait un site web (statique), bien tout pourri que je lui ai refait. Ben j'ai ajouté une fonction dans mon soft qui regénère les pages concernant les produits de son catalogue quand il faisait des MAJ.