Reprise du message précédent :
Tu ne sais pas ce que tu fais, ok on va essayer un truc, dans la plupart des cas ce ne sera probablement pas pire...

Ce qui est bien avec PHP c'est qu'il y avait de la marge de progression, du coup on voit bien les progrès

 
Surtout, tout le monde crache sur PHP et le fait qu'on pouvait faire tout et n'importe quoi avec (et surtout n'importe comment), mais c'est exactement ce qui a permis la démocratisation du web dev à une certaine époque et qui a ouvert tant d'opportunités et de carrières pour tellement de gens.
 
C'est un peu comme parler les langues...`
 
Si d'entrée de jeu tu veux ne faire aucune faute de grammaire, tu ne parles jamais et même si un jour tu finis par parler, tu seras lent, tu ne comprendras même pas certaines erreurs parce que tu n'en auras pas commis suffisamment par le passé.  
Le dev, c'est : I can do it, let's do it now. Et ensuite, l'exp se construit.  
 
C'est aussi pour cela que pour ceux qui veulent démarrer la prog, je leur dis : faites des projets, tout de suite, même et surtout si ça existe déjà. Faites des trucs qui marchouillent, plantez vous, faites de la merde, mais faites le. Suivre 10K tutorials ne vous apprendra pas à programmer.

Totalement d'accord avec toi, HLM C'est en forgeant qu'on devient forgeron.

Oui alors en 30 ans de PHP, même si je me régale aujourd'hui, il y a plein de critiques sur le sujet, en 2025 je vois encore passer des horreurs dignes de 2004...

 
J'imagine.
 
Mais bon, la permissivité du langage a aussi assuré sa popularité et son accessibilité.    
 
Les langages trop stricts auront toujours bcp de mal à percer (enfin sauf ceux qui ont précédé tout le reste) (bon, ce sera peut-être moins vrai avec l'IA maintenant )

Pourtant c'est moins permissif qu'à l'époque...et les frameworks modernes aident à éviter pas mal de choses...

 
AMA les framework sont aussi ce qui empêche les devs de devenir vraiment expérimentés. En fait, un dev senior devrait être en mesure de créer son PROPRE framework (sans jamais l'utiliser pour des besoins pros, bien évidemment ). faire ce genre de projets où tu réinventes la roue constamment est un passage obligé pour devenir suffisamment fort et pour pouvoir réellement comprendre comment fonctionnent les frameworks.
 
N'utiliser qu'un framework et subir la magie des ORMs ou autres trucs du genre sans avoir de vrais skills solides derrière, c'est pas super. Et avec l'IA, ça va pas s'arranger !

 
savoir faire sans c'est essentiel, faire sans de nos jours c'est pas loin d'être suicidaire.

 
Exactement. Tu dois être capable de le faire (coder ton framework), mais ne jamais le faire pour du pro et utiliser les frameworks dûment supportés.

Si tout le monde raisonnait comme ceci, il n'y aurait pas du tout de frameworks. Ou au pire un seul, vu que tout le monde n'utiliserait que le même.
 
Or, tout framework "connu" et "dûment supporté" a commencé dans la tête de quelque'un qui s'est dit "et pourquoi pas ?". Dans la grande sélection naturelle des frameworks, il est donc au contraire parfaitement normal de voir apparaîte (et bien entendu disparaître) de nombreux frameworks "maisons".

 
Quand tu fais un projet pro, ce qui compte, c'est le support, au delà même de la qualité du framework. Je n'irai jamais adopter pour un projet pro un framework juste sorti de l'oeuf, sans support, sans énorme testing etc...  
 
Après, ça ne veut pas dire qu'un projet perso de qualité ne peut jamais devenir pro, tu ne comprends pas ce que je dis.  
 
C'est utiliser un framework perso pour du pro (donc quelque chose que tu fais pour des CLIENTS qui sont en droit d'attendre un projet supportable dans le temps, y compris le jour où tu n'es plus là pour t'en occuper) qui n'est pas raisonnable.

La quantité de projets que j'ai récupéré avec des frameworks pros & supportés... jusqu'à ce qu'ils ne le soient plus Dans le fabuleux monde du javascript par exemple, toutes ces technologies ultra-testées et supportées sont rendues obsolètes à une telle vitesse que je ne suis pas sûr qu'une telle technologie existe vraiment. Y'a tellement de churn que ça devient difficile à suivre.
 
Je comprend ce que tu veux dire, mais ça me paraît très théorique.

 
Donne des exemples... Car pour ma part, tout ce que j'ai fait (moi et mon équipe car je ne code que pour de la recherche) est encore supporté.  
 
par exemple symfony existe toujours, jquery, react itoo etc... et nos vieux projets ont été updatés correctement année après année. On adopte progressivement de nouvelles choses, mais jamais des choses trop récentes ou qui n'ont pas fait leurs preuves. Là, j'ai introduit du rust pour certaines choses, avec python sur des API maisons, on utilise flask surtout avec l'arrivée de l'AI et le support des principales API d'AI qui sont vraiment super python friendly. Nos nouveaux projets n'utilisent plus symfony ni même PHP la plupart du temps, mais quoi qu'il en soit, le support et la stabilité >>>> everything else.

Je rejoins FlorentG sur ce point même si je comprends ton propos. Pour une appli client dont le dév a débuté fin 2003, si j'étais parti sur des frameworks PHP et JS, aujourd'hui (et bien avant ), j'aurais été bien emmerdé
Qq ex : j'ai plus les noms en tête des frameswork PHP de l'époque car j'en ai utilisé aucun (et du reste, plus aucun de cette époque n'existe aujourd'hui) mais pour JS, je peux te citer Prototype.js (ancêtre de JQuery, en tout cas sur la philosophie) et Script.aculo.us (qui aussi a dû donner des idées à JQuery). J'ai dû virer ces 2 libs y'a qq temps car du jour au lendemain, l'une d'elle est rentrée en conflit avec la lib de Google maps. Au final, vu que je me servais de seulement qq fonctions, j'ai viré les 2 libs et recodé juste ce dont j'avais besoin. Du coup, plus de souci.
 
Je précise que mon appli n'est pas exposée sur internet, elle est bien au chaud dans un datacenter interne à mon client, donc le risque de hack me paraît très limité et quand bien même elle se ferait hacker, les conséquences ne seraient pas bien importante vu qu'on a une sauvegarde chaque jour des données.
 
Y'en a qui vont probablement me défoncer, mais à cette époque, le modèle objet de PHP étant encore peu mature et intéressant, j'avais fait le choix de tout coder en procédural et pas objet. Aujourd'hui, je ne regrette pas mon choix car ce qui a le plus évolué depuis PHP4, c'est bien cet aspect. A chaque fois que je suis monté en version de PHP (je suis aujourd'hui en PHP8), les qq soucis que j'ai pu avoir avec du code qui plantait, c'était à cause de code PHP en objet provenant des quelques libs que j'ai été bien obligé d'intégrer à mon projet (genre FPDF, Artishow, PEAR:DB...).
Mais en dehors de ces qq libs, pour passer de PHP4 à PHP8 (pas d'un coup, bien évidemment ), j'ai dû modifier moins de 100 lignes de code sur environ 160 000. Ca va je trouve

 
Bah tu ne peux jamais être sûr à 100% qu'une lib ou un framework ne va pas disparaitre, mais tu as énormément moins de chance que ce soit le cas si la lib est massivement utilisée et supportée VS un truc neuf et/ou totalement inconnu.
Et dans tous les cas, une applie "saine" est une applie qui est mise à jour et qui évolue avec des mises à jour de ses libs.
En tous cas, les choix que j'ai fait il y a 10 ans se sont révélés les bons et c'est pas du au hasard AMA.

register_globals / magic_quotes : ah on était jeunes c'était sympa les \\' dans nos bases de données et sur nos pages
 
mysql_real_escape_string : ça a tué tout le charme si on ne peut même plus mettre <script>alert('toto')</script> dans les champs noms et prénoms, on s'ennuie...*
 
Heureusement qu'on a eu les migrations iso8852-1 vers UTF-8 pour remettre des caractères chelous un peu partout
 
N'empêche, comme dit par d'autres plus haut, PHP reste un langage très sympa parce que tout n'est pas pété au bout de 6 mois.
Le dev mobile je trouve ça insupportable, notamment quand tu passes par des outils pour faire du multiplateforme. Au bout de 6 mois sans avoir touché au code, tu lances tes outils, fait les mises à jour et tu n'as plus rien qui compile et tu as pour 3 jours à modifier ton code, parce que la put**n de brique pour faire un pauvre menu latéral n'est pas native et qu'elle est deprecated, remplacée par une nouvelle qui le sera aussi dans un an mais qui t'oblige à tout recoder de zéro.
Et je ne parle même pas de Google qui t'oblige à monter en version même si tu n'as rien besoin d'updater. Quand tu reçois le mail couperet de Google, tu sais que tu vas morfler pendant une semaine
 
PHP, tu fais ta montée de version majeure, et généralement tu n'as rien à faire. Au pire tu cherches/remplaces les 2 trucs qui sont deprecated (et t'as souvent une ligne prête à remplacer), et c'est reparti pour un an peinard.
 
* Je me souviens d'un de mes profs d'algo (c'était dans une autre vie) qui adorait faire le truc suivant :
"bon vous avez 15 minutes pour me faire un programme (en C) qui demande un premier nombre, ensuite un second, et qui affiche le résultat de la multiplication du premier par le second".
 
Haha, tout fier tu torches le truc en 5 minutes, tu l'appelles pour lui dire que c'est bon, il te dit "ok lance le programme je vais tester".
Hop, premier nombre... et là il tape "toto" et tu regardes tes pieds...

2003, y'avait peu de frameworks et encore moins massivement utilisés Du coup, à la vue des données dont je disposais à l'époque, j'ai estimé que le framework ne m'apporterait pas grand chose comme gain mais pas mal de contraintes, donc plus de négatif que du positif. J'ai fait un pari. 21 ans plus tard, ce pari a été payant. Ma décision était réfléchie, basée sur des faits donc rationnelle, pas prise sur une intuition ou un coup de tête Mais j'aurais pu avoir tord aussi...
 

Mais tellement. J'adore ton ex d'exo. Ca sent le vécu  

Pareil, app de 2005, pseudo framework mvc maison, un truc basique pour passer des vars d'url à mon index et splitter ça dans des fichiers différents et des case différents.
Quelques objets pour les trucs vraiments récurrents, sinon du procédural et des fonctions, et c'est toujours relativement simple à maintenir.
 
J'ai utilisé Smarty pour la partie template... et je suis mitigé. Ca n'apporte pas grand chose à part des contraintes, et quelques difficultés lors des changements de version (mais jusqu'à présent sans difficulté importante). Ca m'a surtout forcé à séparer l'affichage de la logique, chose qui aurait été plus difficile si je n'avais pas utilisé de framework. Je pense que dans plein de cas ça aurait été tellement plus simple de faire tout au même endroit que ça m'aurait amené à faire du code bordélique (enfin plus que ce qu'il n'est déjà)...

 
Oui, si tu remontes à la préhistoire aussi...
 
Moi je parle de maintenant et de quelques années en arrière. Faire son propre framework et le mettre ne production pour du pro ou utiliser un framework qui vient juste d'arriver de nulle part VS utiliser un framework vraiment mur, bien documenté, massivement utilisé et bien supporté, je vois même pas comment tu peux encore discuter. Ça n'a aucun sens.

  Qu'est-ce que tu veux, je conçois des applis qui durent, je suis écologique, moi, monsieur
 
Mais je ne conteste pas ton propos avec des conditions aujourd'hui qui sont radicalement différentes d'à l'époque. Si je devais refaire cette appli aujourd'hui, il est fort à parier que je ferais des choix différents que prendre un framework serait une option tout à fait pertinente.

Tiens vous allez peut-être m'aider :
Je cherche à inclure cette lib et donc je prends l'asset minifié :
https://cdn.sheetjs.com/xlsx-0.20.3 [...] ull.min.js

Quand j'inclus l'asset directement depuis le CDN ça marche.
Quand j'inclus l'asset en local (donc C/C du fichier dans mon appli), ça marche mais les accents des XLS que je parse sont baisés (question d'encodage de la lib manifestement).
Pourtant je save bien la lib en UTF8.. quelle est cette sorcellerie ?

Edit : visiblement résolu en passant par Firefox pour sauver le fichier, pas merci Safari

Idéalement il ne faut pas toucher à ta lib, contente toi de l'enregistrer depuis le site avec un curl (ce que tu as peut-être fait, je préfère préciser).
 
Le problème d'encodage vient probablement de ton serveur qui rend la lib, vérifie via navigateur que les headers HTTP sont bien réglés en UTF-8 sur ce fichier.