Discussion :

[HeadCoder]

Opinion : les framework web sont-ils synonymes du mal ?


J'ai récemment remarqué que personne n'a pris de recul sur les frameworks dédiés au langage PHP. Ils sont utilisés partout, ils sont devenus critères numéro un dans les recrutements de projets, ils sont l'équivalent d'une mode, etc. Bref, le framework est devenu le crucifix du développeur web.

Mais un framework, est-ce vraiment que du bien?
Non. En rassemblant une certaine quantité d'information trouvée sur quelques débats à propos de ceux-ci, j'ai décidé d'exprimer mon opinion sur l'utilisation d'un framework. Je trouve qu'un framework peut s'avérer être au sens propre le synonyme du mal.

Avons-nous des statistiques sur l'utilisation des frameworks ? Y a-t-ils autant de gens qui en utilisent que ceux qui n'en utilisent pas?

Il serait bien de connaître quelques statistiques sur les frameworks (leur utilisation comparativement à ceux qui n'en utilisent pas, les plus utilisés, etc), ce qui attire le plus dans cette mode, etc.

Bref, je vous fais part d'un lien vers un article qui traite de l'utilisation des frameworks en PHP : le voici.

Son auteur, un fervent opposant à l'utilisation des frameworks web en PHP, explique les raisons ayant motivé cette prise de position.


Et vous ?

Partagez-vous cet avis ? Expliquez nous pourquoi ?

[Joker-eph]

Pour moi un "framework" a beaucoup plus d'avantages que d'inconvénients, il faut surtout savoir bien l'utiliser !

Mais c'est un moyen très simple de profiter de fonctionnalités toutes faites et bien intégrées, qui donne un ensemble cohérent quand on développe une appli web un tant soit peu complexe.

Souvent le reproche qu'on peut lui faire repose sur la lourdeur de l'ensemble, après dans une appli web "complexe", il y a de toute façon des traitements lourds à faire et un framework peut apporter beaucoup avec des gestions facile de mise en cache par exemple, ou encore de serveurs "d'assets".

J'ai vu le plus souvent des benchs de "hello worlds" qui indiquait qu'ils sont lent, ça ne me semble absolument pas significatif de ce qu'on attend d'un framework. Si c'est pour faire du hello world, effectivement ça n'est pas le bon outil...

[HeadCoder]

Pour moi un "framework" a beaucoup plus d'avantages que d'inconvénients, il faut surtout savoir bien l'utiliser !

Certes au niveau technique il peut nous faire développer beaucoup plus, mais niveau cognitif, c'est la régression assurée.

Le framework exerce une sorte d'unification et uniformisation de la pensée sur le développeur. Un code, c'est comme un texte. Alors pourquoi écrire un code si c'est pour reprendre les idées des autres?

Personne va réellement se soucier de la manière dont le problème est résolu. Y a-t-il vraiment des algorithmes implémentés dans les frameworks? Et même s'il y en avait, les gens se comporteront comme des script kiddles et se soucieront pas un instant de la solution apportée par le framework. J'appelle ça de la paresse.

"Lourdeur" et autres points souvent technologiques, se sont des points de second degré. Ce n'est pas le pas le plus important. Les vrais problèmes se situent surtout au niveau cognitif, au niveau de la façon de penser. Si un projet est pensé de dix milles façons, cela réduit sa stabilité. C'est un autre point parmi tant d'autres où le framework nuit aux projets.

La majorité de ces points sont soulignés dans l'article (avec plus de détails). Peut-être devrais-tu le lire? Ne serait-ce que pour comprendre le point de vue et l'idéologie des autres?

[werss]

J'appelle ça de la paresse.

et d'autres appellent ça de la rentabilité
un chef d'entreprise a pour but de faire rentrer de la monnaie sur le compte en banque de l'entreprise donc s'il existe un moyen d'accélérer le résultat fourni par ses employés (en les évitant de devoir trop réfléchir par exemple) il choisira forcement ce moyen.

[HeadCoder]

et d'autres appellent ça de la rentabilité

Et comme je l'ai dit plus haut, la finance n'a pas à se mêler de ce qui ne la regarde pas. Non?
Je trouve qu'elle devrait avoir pour objectif d'assurer la sécurité des autres. D'ailleurs, c'est le principe de l'argent, assurer une certaine sécurité... M'enfin, là on s'égare.

[dourouc05]

Le framework exerce une sorte d'unification et uniformisation de la pensée sur le développeur. Un code, c'est comme un texte. Alors pourquoi écrire un code si c'est pour reprendre les idées des autres?

C'est bien, ça a juste un arrière-goût assez prononcé de copier-coller... Partages-tu réellement l'opinion du rédacteur ou bien te limites-tu à dire ce qu'il dit, etc. ? Ce n'est pas là le plus important.

Très personnellement, je suis passé du PHP pur avec une architecture faite assez barbarement à la main à un framework, symfony pour ne pas le citer. Ça n'a pas changé ma manière de coder. Ça l'a accélérée (vive l'admin generator !). J'avais fait un infâme MVC (en fait, plutôt M-VC), je suis passé à du plus vrai MVC. Un peu d'organisation dans la pensée, voici l'effet du framework. Et je ne respecte pas toujours sa philosophie, loin de là (étant donné que, quand ça fonctionne, il faut s'arrêter). Mais ça permet qu'un pauvre hère qui passe par là puisse reprendre mon code. Avant, je me perdais moi-même dans les méandres de ce que j'avais écrit... Là, je commence à m'y retrouver.

Unification de la pensée ?
Loin de là.
Milliards de lieues de là.
Simplification du travail en commun surtout.
Tente de communiquer avec quelqu'un qui ne parle pas du tout la même langue que toi, qui n'a pas la même gestuelle : il utilisera le même corps, les mêmes sons (approximativement), ce que l'on pourrait comparer au langage - ici, PHP, cela est cependant généralisable. Mais vous ne vous comprendrez pas. Unification de la pensée ? On peut enfin se comprendre.

Unification de la pensée ? Unicité du moule ?
Loin de là.
Combien de framework ? Wikipédia en recense un beau nombre : http://fr.wikipedia.org/wiki/Liste_de_frameworks_PHP. Si vraiment les frameworks unifiaient la pensée, il y en aurait un, dénommé TheUnique.

Un code, c'ets du texte, mais formaté d'une telle manière, avec une telle syntaxe... qu'il devient autant unifiant qu'un framework. Tu peux réinventer le PHP, si tu veux, pour avoir une autre philosophie. Au lieu de reprendre tous les mots du dictionnaire pour refaire un texte, tu réinventes un dictionnaire. Tolkien l'a fait, on connaît le succès ; beaucoup d'autres ont tenté, peu ont réussi. Mais pourquoi donc...

Personne va réellement se soucier de la manière dont le problème est résolu.

Entièrement vrai. Et pour cause. Tu vas au garage, tu demandes à ton garagiste (sic) de réinventer la roue ? De t'expliquer comment, pourquoi, par qui, à cause de quoi, en quel but ça fonctionne ? Tu t'en fous royalement, ça fonctionne, c'est très bien comme ça. Pour la roue, passe encore. Pour le moteur, passe encore. À l'aéroport, on change de décor mais aussi de complexité. Une fusée, c'est encore pire. Quand tu vois une fusée, tu veux qu'on t'explique tout ce qui fait que ça décolle ? Restons sur terre (sans majuscule), c'est impossible. Si tu veux utiliser du HTTPS, tu ne vas pas tenter de réinventer un processeur pour le faire. Tu ne vas pas réinventer un OS pour faire fonctionner le truc. Tu ne vas pas réinventer un interpréteur pour faire fonctionner ton biduloïde. Tu ne vas pas réinventer un équivalent au RSA ou le réimplémenter. Tout ça, c'ets déjà fait. Et c'est pas anodin, évidemment, c'est pour unifier, que tout le monde se comprenne, qu'on ne perde pas de temps sur ces futilités. Si, à chaque navigateur, on devait réimplémenter ces trivialités, on aurait deux ou trois navigos, un libre peut-être, les autres avec des gens surpayés derrière. Mais non. On a OpenSSL et on est très contents avec. Tout le monde se fout du fonctionnement de RSA, ça fonctionne, c'est secure, tout le monde le sait, c'est très bien comme ça.

Tu ne pensais pas aller jusque là ? C'est bien dommage, nuance alors un peu. Là, on pourrait dire que tu veux tout foutre dehors et recommencer à 0... L'Homme évolue depuis des milliers d'années, ce n'est pas pour que chaque génération reparte à 0.

Y a-t-il vraiment des algorithmes implémentés dans les frameworks?

Forcément. Peut-être pas des algos comme tu les conçois mais il doit y en avoir. Ils résolvent des problèmes en utilisant des algos. Notamment pour une requête symfony, il faut commencer par parser l'URL (tient, un algo symfony, des algos en C derrière...), puis on recherche le module qui va bien et on l'exécute (mais on ne sait pas où est stocké tout ce qu'on cherche, on sait qu'on cherche une classe ModuleActions quelque part, on y va à coups de piolet et d'algos).

J'appelle ça de la paresse.

J'appelle ça du gain de temps. C'est fou ce que ça prend comme temps de réinventer la roue, le MVC. Alors, quand tout est fait et que tu veux te dépêcher de finir ton appli, tu réfléchis trois secondes au pire (un projet se commençant le matin, on n'est pas vraiment réveillé...). Que ce soit en tant que salarié ou en bénévole. Surtout en bénévole d'ailleurs. Surtout en salarié d'ailleurs.

Les vrais problèmes se situent surtout au niveau cognitif, au niveau de la façon de penser. Si un projet est pensé de dix milles façons, cela réduit sa stabilité. C'est un autre point parmi tant d'autres où le framework nuit aux projets.

J'aurais tendance à dire : zéro pointé.

Les frameworks ne sont pas décousus comme ça... C'est peut-être ton expérience de PHP qui te fait parler comme ça (et le PHP seul, c'est pas très digeste, sauf la doc à la main, l'API part un peu dans tous les sens AMHA). Un framework est pensé par des personnes, beaucoup de personnes, dans une seule direction. Sinon, divergences d'avis, plusieurs frameworks. Comment faire coïncider des opinions diverses sur le MVC, par exemple ? (Oui, j'aime cet exemple, je sais, je fais des tartes de MVC demain après-midi, si vous en voulez ). Non, ils doivent s'orienter, se concerter, pondre difficilement quelque chose qui convient à tout le monde. D'où une certaine stabilité au final.

Maintenant, oublie les frameworks. Ils n'existent pas. Certains en rêvent, d'autres ne voient que ça en cauchemar. Tu veux faire une appli. Tu dois d'abord rassembler tout le monde et, après des jours de débat, accoucher d'une architecture, possiblement à adapter en fonction de l'évolution. Maintenant, remets les frameworks au milieu de la table. Simplifions l'énoncé, n'en considérons qu'un, un seul langage existant. L'architecture est déjà faite, il suffit de découper le projet dans cette architecture. Tout est "prépensé", une certaine stabilité dans l'édifice pourra exister. Si tu remets plusieurs frameworks et langages, il suffit de choisir la bonne combinaison qui convient aux divergences de vue des concepteurs.

Ne serait-ce que pour comprendre le point de vue et l'idéologie des autres?

J'ajouterais même :

La meilleure manière de démolir l'opinion des autres est de l'inventer

Le problème ici, c'est qu'on n'a pas vraiment ton opinion détaillée, il faut alors extrapoler, donc faire mentir ton discours. Viens répondre à la suite, histoire qu'on élimine certains doutes.

[HeadCoder]

C'est bien, ça a juste un arrière-goût assez prononcé de copier-coller... Partages-tu réellement l'opinion du rédacteur ou bien te limites-tu à dire ce qu'il dit, etc. ? Ce n'est pas là le plus important.

C'est moi qui a écrit l'article. Alors tu sais déjà mon opinion.

Très personnellement, je suis passé du PHP pur avec une architecture faite assez barbarement à la main à un framework, symfony pour ne pas le citer. Ça n'a pas changé ma manière de coder. Ça l'a accélérée (vive l'admin generator !). J'avais fait un infâme MVC (en fait, plutôt M-VC), je suis passé à du plus vrai MVC. Un peu d'organisation dans la pensée, voici l'effet du framework. Et je ne respecte pas toujours sa philosophie, loin de là (étant donné que, quand ça fonctionne, il faut s'arrêter). Mais ça permet qu'un pauvre hère qui passe par là puisse reprendre mon code. Avant, je me perdais moi-même dans les méandres de ce que j'avais écrit... Là, je commence à m'y retrouver.

On dirait que tu mélanges tes termes. MVC n'est pas un framework hein. C'est rien qu'une méthode de conception. Ce n'est pas un framework.
T'as besoin d'un framework pour que les gens puissent passer derrière toi? Et à l'école, tu fais comment? Un code est un texte, c'est complètement idiot d'utiliser un framework pour une question de propreté. Les commentaires ne sont pas fait pour les chiens hein.

Unification de la pensée ?
Loin de là.
Milliards de lieues de là.
Simplification du travail en commun surtout.
Tente de communiquer avec quelqu'un qui ne parle pas du tout la même langue que toi, qui n'a pas la même gestuelle : il utilisera le même corps, les mêmes sons (approximativement), ce que l'on pourrait comparer au langage - ici, PHP, cela est cependant généralisable. Mais vous ne vous comprendrez pas. Unification de la pensée ? On peut enfin se comprendre.

Tu n'as pas compris. Le framework qui fait l'unification de la pensée, c'est comme si il t'imposait une façon de penser. Tu n'as pas le droit de penser autre chose autrement, tu te dois de rester dans le sentier (bref c'est comme la dictature si tu veux un exemple au pif). À quoi bon écrire un code si c'est pour réécrire les idées des autres?
Si tu dois parler à quelqu'un qui y connait que dalle en informatique, à toi te faire sortir ta pédagogie et lui expliquer le plus clairement possible. C'est à celui qui connaît les termes de s'abaisser au niveau des autres.

Unification de la pensée ? Unicité du moule ?
Loin de là.
Combien de framework ? Wikipédia en recense un beau nombre : http://fr.wikipedia.org/wiki/Liste_de_frameworks_PHP. Si vraiment les frameworks unifiaient la pensée, il y en aurait un, dénommé TheUnique.

Étrangement, j'ai comme la sensation que plus de la moitié font la même chose. Ils sont toujours en quête de la même chose... Si c'est pas la quête d'avoir le plus de développeurs à ses pieds, je me demande ce que c'est.
Peux-tu développer sur le fait qu'il n'y a pas d'unification de la pensée et du moule? Car un "Loin de là" ne règle pas la chose.

Entièrement vrai. Et pour cause. Tu vas au garage, tu demandes à ton garagiste (sic) de réinventer la roue ? De t'expliquer comment, pourquoi, par qui, à cause de quoi, en quel but ça fonctionne ? Tu t'en fous royalement, ça fonctionne, c'est très bien comme ça. Pour la roue, passe encore. Pour le moteur, passe encore. À l'aéroport, on change de décor mais aussi de complexité. Une fusée, c'est encore pire. Quand tu vois une fusée, tu veux qu'on t'explique tout ce qui fait que ça décolle ? Restons sur terre (sans majuscule), c'est impossible. Si tu veux utiliser du HTTPS, tu ne vas pas tenter de réinventer un processeur pour le faire. Tu ne vas pas réinventer un OS pour faire fonctionner le truc. Tu ne vas pas réinventer un interpréteur pour faire fonctionner ton biduloïde. Tu ne vas pas réinventer un équivalent au RSA ou le réimplémenter. Tout ça, c'ets déjà fait. Et c'est pas anodin, évidemment, c'est pour unifier, que tout le monde se comprenne, qu'on ne perde pas de temps sur ces futilités. Si, à chaque navigateur, on devait réimplémenter ces trivialités, on aurait deux ou trois navigos, un libre peut-être, les autres avec des gens surpayés derrière. Mais non. On a OpenSSL et on est très contents avec. Tout le monde se fout du fonctionnement de RSA, ça fonctionne, c'est secure, tout le monde le sait, c'est très bien comme ça.

Tes exemples sont bidons. Disproportionnés et complètement sans rapports. Un framework est abstrait. Une voiture ne l'est pas. Mais bon, si on prenait cet exemple, alors:
-Je suis le garagiste, c'est à moi de me préoccuper si je réinvente la roue ou non.

J'appelle ça du gain de temps. C'est fou ce que ça prend comme temps de réinventer la roue, le MVC. Alors, quand tout est fait et que tu veux te dépêcher de finir ton appli, tu réfléchis trois secondes au pire (un projet se commençant le matin, on n'est pas vraiment réveillé...). Que ce soit en tant que salarié ou en bénévole. Surtout en bénévole d'ailleurs. Surtout en salarié d'ailleurs.

Encore un autre exemple bidon. Le rapport entre ces faits est nul. On ne compare pas le temps de création et d'utilisation. Compare le temps d'utilisation d'un framework créé de A à Z et un framework créé par un autre. Sinon compare le temps de création des deux.

As-tu lu l'article? Viens donc émettre ton opinion dans un commentaire sur celui-ci! Il y a pas mal de gens qui ont de très bonnes opinions (qu'ils soient pour ou contre).

[grunk]

As tu déjà eu à travailler en équipe et pas seulement dans ton coin ? Combien d'année d'expérience à tu en php en milieu pro ?

Soyons honnête , les Framework ont des inconvénients c'est certains , mais ils ont aussi une masses d'avantage que l'on ne peut oublier.

Sans framework (quelqu'il soit) travailler à 4 ou 5 développeurs est une horreur. Chacun à sa manière de faire et même si on fixe des "règles" de développement on n'arrive pas à la même qualité de code qu'avec un framework.

J'appelle ça de la paresse

Ca te plait tant que ça de refaire , encore et encore les même chose alors qu'elles peuvent être faites avec un appel à une méthode ?
Quand dans un nouveau projet tu dois refaire la même chose que ton projet précédent , tu recodes tout ? ou tu fais un copier coller de ton projet précédent ?

Honnêtement les framework ne sont là que pour simplifier les truc chiants du quoitidien. La vraie complexité d'une application n'est pas de générer un formulaire , de faire une requête sur un serveur ou de générer un fichier xml (je suis volontairement réducteur sur les possibilité d'un framework).
Le framework permet au contraire de se détacher de ses taches répétitives et sans grand intérêt pour se concentrer sur la vrai partie applicative.

Et comme je l'ai dit plus haut, la finance n'a pas à se mêler de ce qui ne la regarde pas. Non?

C'est dans le monde des bisounours , ou le patron ne se mèle pas de se que font ses employés sous pretexte qui ne sais pas le faire ...
Framework = gain de temps = gain d'argent : CQFD

Après effectivement en phase d'apprentissage du langage , il est plus que déconseiller de commencer avec un framework.

[dourouc05]

C'est moi qui a écrit l'article. Alors tu sais déjà mon opinion.

Merci de le préciser !

On dirait que tu mélanges tes termes. MVC n'est pas un framework hein. C'est rien qu'une méthode de conception. Ce n'est pas un framework.

Je n'ai jamais prétendu le contraire. Ma prose était peut-être ambiguë, mon opinion sur le sujet ne l'a jamais été. Et le "rien qu'une méthode de conception" me fait penser que tu n'as pas encore vu l'utilité des design patterns (je ne me présente pas comme un fervent utilisateur, juste comme un piqueur de bonnes idées quand c'est utile). Surtout que les frameworks sans MVC sont assez rares...

T'as besoin d'un framework pour que les gens puissent passer derrière toi? Et à l'école, tu fais comment? Un code est un texte, c'est complètement idiot d'utiliser un framework pour une question de propreté. Les commentaires ne sont pas fait pour les chiens hein.

Là, tu te poses à un autre niveau. Quelqu'un doit pouvoir comprendre l'organisation de mon code sans jamais ouvrir un seul fichier. Qu'il soit propre ou pas, qu'il soit en Python ou en Java, ça ne change rien, tout le monde doit pouvoir en comprendre l'architecture (à condition que connaître les problèmes résolus et d'avoir un certain background technique il s'entend). Commentaire ou pas, ça ne changera rien à ce niveau. Et l'utilisation d'un framework permet de standardiser tout ça : quelqu'un qui connaît symfony pourra voir comment c'est organisé, pourra retrouver ses jeunes assez vite ; s'il ne connaît pas le framework, il trouvera sans problème des tutos (extrêmement bien faits, d'ailleurs) lui expliquant l'architecture générale des projets symfony. Pas besoin d'ouvrir des fichiers. Bon, pour savoir précisément ce que fait un tel module, rien ne vaut un petit coup d'oeil ; tu sauras néanmoins à son emplacement que c'est un module, à son nom son périmètre d'action. Et ça, aucun commentaire ne le permet aussi facilement.

Tu n'as pas compris. Le framework qui fait l'unification de la pensée, c'est comme si il t'imposait une façon de penser. Tu n'as pas le droit de penser autre chose autrement, tu te dois de rester dans le sentier (bref c'est comme la dictature si tu veux un exemple au pif). À quoi bon écrire un code si c'est pour réécrire les idées des autres?
Si tu dois parler à quelqu'un qui y connait que dalle en informatique, à toi te faire sortir ta pédagogie et lui expliquer le plus clairement possible. C'est à celui qui connaît les termes de s'abaisser au niveau des autres.

Soit je n'ai effectivement rien compris. Soit je n'ai rien compris. Comment faire le lien entre l'unification de la pensée (menant à Hitler en poussant le bouchon très loin) et réécrire les idées des autres ? Le framework te montre une voie à suivre ; maintenant, tu la suis pour les avantages mis au-dessus. Ou tu ne la suis pas et tu n'utilises pas ce framework, te tournant vers un plus light à ce niveau (ZF, par exemple, me semble-t-il, se laisse utiliser comme une vulgaire lib). On utilise alors les idées des autres. On construit sur ce qu'ils font. Comme la croissance de l'humain : il ne peut se construire que sur les autres. De là à considérer une app comme un bébé, il n'y a qu'un pas !

Tes exemples sont bidons. Disproportionnés et complètement sans rapports. Un framework est abstrait. Une voiture ne l'est pas. Mais bon, si on prenait cet exemple, alors:
-Je suis le garagiste, c'est à moi de me préoccuper si je réinvente la roue ou non.

Si tu n'arrives pas à comprendre ma pensée sur un raisonnement concret, seras-tu capable de la comprendre sur un raisonnement concret ? Platon pensait exactement le contraire quand il a fini sa caverne. Je ne pense pas être suffisamment avancé dans ma compréhension de l'univers pour aller à son encontre.

Étrangement, j'ai comme la sensation que plus de la moitié font la même chose. Ils sont toujours en quête de la même chose... Si c'est pas la quête d'avoir le plus de développeurs à ses pieds, je me demande ce que c'est.
Peux-tu développer sur le fait qu'il n'y a pas d'unification de la pensée et du moule? Car un "Loin de là" ne règle pas la chose.

symfony a bien évidemment été créé pour avoir contrôle sur tout l'univers. C'est bien connu. Voyons. Ce framework a été développé à l'origine pour simplifier les devs de Sensio Labs. Puis ils l'ont ouvert. Et voilà. Un grand framework (avis personnel). Dont le seul objectif est bien de contrôler plus de territoire que les Romains et la Russie réunis. C'est très logique.

Autre analogie. Dans ta cuisines, tu utilises des moules pour faire des gâteaux. Certes, ils ont tous la même forme ; tu peux varier la farine, le sucre... même changer la recette et les quantités. La forme restera là, le contenu sera très différent... et la forme ne sera pas toujours complète.

Ici, tu as déjà une variété de langages. Puis de frameworks. Chacun a son propre mode de pensée, sa logique propre. Si celle d'un framework ne te convient pas, tu changes soit de framework, soit de boîte. C'est ton droit. Rien ne t'oblige à t'enfermer dans une seule et unique combinaison. Si tu trouves qu'un framework unifie trop ta pensée, va voir ailleurs, tu la désunifieras un peu. Pour la réunifier, selon ton discours. Auquel cas tu iras respirer ailleurs. Tu peux le faire, profites-en. Ils font tous la même chose ? Oh, c'est bizarre, tous les humains vivent... C'est normal, ils sont tous prévus pour faire la même chose. Comment veux-tu qu'en voulant faire la même chose ils fassent des choses différentes ? Si tu trouves la solution, petite boite noire, direction le centre de recherche pour la boîte et l'asile pour celui qui l'a rempli.

Encore un autre exemple bidon. Le rapport entre ces faits est nul. On ne compare pas le temps de création et d'utilisation. Compare le temps d'utilisation d'un framework créé de A à Z et un framework créé par un autre. Sinon compare le temps de création des deux.

Euh... Si du temps est passé à la création d'un framework, c'est pour éviter de repasser ce temps dans l'utilisation de PHP, de gagner du temps dans l'utilisation de PHP conjointement avec le framework... Ou je ne te suis pas...

As-tu lu l'article? Viens donc émettre ton opinion dans un commentaire sur celui-ci! Il y a pas mal de gens qui ont de très bonnes opinions (qu'ils soient pour ou contre).

Le débat est très bien ici, je ne vais pas m'amuser à le suivre sur deux endroits différents... Si tu souhaites alimenter celui-ci, tu peux reprendre des commentaires de là-bas, citant l'auteur, qu'on puisse en débattre ici. Sinon, j'ai survolé l'article, pas lu en détail. Suffisamment pour avoir une idée globale.

[HeadCoder]

As tu déjà eu à travailler en équipe et pas seulement dans ton coin ? Combien d'année d'expérience à tu en php en milieu pro ?

Oui j'ai déjà travaillé sur pas mal de projets en équipe. Et sans frameworks, on s'y est très bien débrouillé.

Sans framework (quelqu'il soit) travailler à 4 ou 5 développeurs est une horreur. Chacun à sa manière de faire et même si on fixe des "règles" de développement on n'arrive pas à la même qualité de code qu'avec un framework.

Dans ce cas faut s'arranger. Imposez un cadre de travail ou un "esprit de travail". Une façon de penser unique propre à vous (et non à celle des autres, cf frameworks).

Ca te plait tant que ça de refaire , encore et encore les même chose alors qu'elles peuvent être faites avec un appel à une méthode ?
Quand dans un nouveau projet tu dois refaire la même chose que ton projet précédent , tu recodes tout ? ou tu fais un copier coller de ton projet précédent ?

C'est pour cela qu'il faut savoir y aller avec modération. Utilise un CMS pour des sites web tous cons. Utilisez un framework lorsque qu'il le faut vraiment. Et n'en utilisez pas lorsque vous voulez une totale autonomie, ou bien pour être adapté à 100% au projet et ne pas avoir besoin à se fier à une base qui peut dérouter du jour au lendemain.

Honnêtement les framework ne sont là que pour simplifier les truc chiants du quoitidien. La vraie complexité d'une application n'est pas de générer un formulaire , de faire une requête sur un serveur ou de générer un fichier xml (je suis volontairement réducteur sur les possibilité d'un framework).
Le framework permet au contraire de se détacher de ses taches répétitives et sans grand intérêt pour se concentrer sur la vrai partie applicative.

Il n'y a pas que les tâches répétitives et chiantes comme tu dis. Il y a aussi tout ce qui est cognitif chez un framework. Laissez tomber tout le côté technique. La théorie, ça personne n'y pense. Et pourtant...

C'est dans le monde des bisounours , ou le patron ne se mèle pas de se que font ses employés sous pretexte qui ne sais pas le faire ...
Framework = gain de temps = gain d'argent : CQFD

Voilà pourquoi j'ai l'impression que les gens qui utilisent un framework n'ont pas quitté leurs habitudes des bancs d'écoles (c'est un exemple, une comparaison avec les écoliers), toujours vouloir en faire le moins possible car gros poil dans la main... Et puis, ça démontre tout l'intérêt que vous portez au client et à votre projet. Aucun.
Il s'agit de faire les choses soit au complet, soit à moitié et l'autre moitié sera faite par quelqu'un d'autre (très beau sens de l'exploitation à doubles sens).

Après effectivement en phase d'apprentissage du langage , il est plus que déconseiller de commencer avec un framework.

Étrangement on voit rarement cela en application.

Je n'ai jamais prétendu le contraire. Ma prose était peut-être ambiguë, mon opinion sur le sujet ne l'a jamais été. Et le "rien qu'une méthode de conception" me fait penser que tu n'as pas encore vu l'utilité des design patterns (je ne me présente pas comme un fervent utilisateur, juste comme un piqueur de bonnes idées quand c'est utile). Surtout que les frameworks sans MVC sont assez rares...

Je sais très bien leur utilité. Mais justement, est-ce que les gens savent ce qu'ils font? S'y prennent-ils de la bonne manière pour choisir leur design pattern? Quand je vois le sigle "MVC" partout, je me pose de sérieuses questions.

Là, tu te poses à un autre niveau. Quelqu'un doit pouvoir comprendre l'organisation de mon code sans jamais ouvrir un seul fichier. Qu'il soit propre ou pas, qu'il soit en Python ou en Java, ça ne change rien, tout le monde doit pouvoir en comprendre l'architecture (à condition que connaître les problèmes résolus et d'avoir un certain background technique il s'entend). Commentaire ou pas, ça ne changera rien à ce niveau. Et l'utilisation d'un framework permet de standardiser tout ça : quelqu'un qui connaît symfony pourra voir comment c'est organisé, pourra retrouver ses jeunes assez vite ; s'il ne connaît pas le framework, il trouvera sans problème des tutos (extrêmement bien faits, d'ailleurs) lui expliquant l'architecture générale des projets symfony. Pas besoin d'ouvrir des fichiers. Bon, pour savoir précisément ce que fait un tel module, rien ne vaut un petit coup d'oeil ; tu sauras néanmoins à son emplacement que c'est un module, à son nom son périmètre d'action. Et ça, aucun commentaire ne le permet aussi facilement.

Bah justement, avant d'utiliser un framework pour ces raisons, il faudrait savoir le faire sans. Ce n'est pas normal d'avoir besoin d'un outil à ce point juste pour une question de propreté. Cela remet en doutes les connaissances, l'expérience et les méthodes de travail de la personne. Bref, c'est une excuse bidon non crédible.

Soit je n'ai effectivement rien compris. Soit je n'ai rien compris. Comment faire le lien entre l'unification de la pensée (menant à Hitler en poussant le bouchon très loin) et réécrire les idées des autres ? Le framework te montre une voie à suivre ; maintenant, tu la suis pour les avantages mis au-dessus. Ou tu ne la suis pas et tu n'utilises pas ce framework, te tournant vers un plus light à ce niveau (ZF, par exemple, me semble-t-il, se laisse utiliser comme une vulgaire lib). On utilise alors les idées des autres. On construit sur ce qu'ils font. Comme la croissance de l'humain : il ne peut se construire que sur les autres. De là à considérer une app comme un bébé, il n'y a qu'un pas !

Je n'ai jamais insinué Hitler. Oui un framework unifie la pensée des gens. Tout le monde aura la manière de penser et d'agir de Symfony ou un autre. Et après? Comment on évolue dans la technologie? Pourquoi donc se fermer et se centrer sur une seule méthode? Ça détruit l'unicité et l'originalité d'un code.

Si tu n'arrives pas à comprendre ma pensée sur un raisonnement concret, seras-tu capable de la comprendre sur un raisonnement concret ? Platon pensait exactement le contraire quand il a fini sa caverne. Je ne pense pas être suffisamment avancé dans ma compréhension de l'univers pour aller à son encontre.

Pas facile de comprendre la façon dont tu t'y prends pour mêler concret et abstrait. Tant que tu n'es pas dans l'un ou dans l'autre dépendamment du sujet, l'exemple sera mauvais.

symfony a bien évidemment été créé pour avoir contrôle sur tout l'univers. C'est bien connu. Voyons. Ce framework a été développé à l'origine pour simplifier les devs de Sensio Labs. Puis ils l'ont ouvert. Et voilà. Un grand framework (avis personnel). Dont le seul objectif est bien de contrôler plus de territoire que les Romains et la Russie réunis. C'est très logique.

Les gens qui créent les frameworks sont des gens qui veulent controler la façon de faire des autres. J'appelle ça de l'égo et des manipulateurs.

Ici, tu as déjà une variété de langages. Puis de frameworks. Chacun a son propre mode de pensée, sa logique propre. Si celle d'un framework ne te convient pas, tu changes soit de framework, soit de boîte. C'est ton droit. Rien ne t'oblige à t'enfermer dans une seule et unique combinaison. Si tu trouves qu'un framework unifie trop ta pensée, va voir ailleurs, tu la désunifieras un peu. Pour la réunifier, selon ton discours. Auquel cas tu iras respirer ailleurs. Tu peux le faire, profites-en. Ils font tous la même chose ? Oh, c'est bizarre, tous les humains vivent... C'est normal, ils sont tous prévus pour faire la même chose. Comment veux-tu qu'en voulant faire la même chose ils fassent des choses différentes ? Si tu trouves la solution, petite boite noire, direction le centre de recherche pour la boîte et l'asile pour celui qui l'a rempli.

Le problème, c'est que de plus en plus de gens ne sont pas capables de se débrouiller sans. On va rapidement finir comme les clients pour qui nous réalisons les projets: toujours vouloir faire plus simple, toujours accumuler de la paresse, toujours vouloir de la facilité. Le développeur deviendra l'équivalent de l'utilisateur lambda de Windows (Lulz to the troll ).

Euh... Si du temps est passé à la création d'un framework, c'est pour éviter de repasser ce temps dans l'utilisation de PHP, de gagner du temps dans l'utilisation de PHP conjointement avec le framework... Ou je ne te suis pas...

Avec un framework, je doute qu'on utilise pleinement PHP... Non tu ne me suis pas.

Le débat est très bien ici, je ne vais pas m'amuser à le suivre sur deux endroits différents... Si tu souhaites alimenter celui-ci, tu peux reprendre des commentaires de là-bas, citant l'auteur, qu'on puisse en débattre ici. Sinon, j'ai survolé l'article, pas lu en détail. Suffisamment pour avoir une idée globale.

À mon avis tu devrais le lire au complet. Tu saurais vraiment de quoi je parle. Mais bon, on risque de prendre ça pour de la pub vu que je suis l'auteur.
C'est pris en note. Je le ferais, et je ferais de même avec un conversation d'un développeur qui est pro-framework (Ouais, j'essaie de m'ouvrir aux idées des autres même si ce n'est pas facile à accepter).

[stealth35]

je suis assez de l'avis de l'article et cette belle phrase le résume très bien

Le framework reste un outil, il ne remplacera jamais un développeur.

On peu très bien s'en sortir en étant full framework sans trop savoir ce qui se passe derrière, mais on risque a un moment donnée d'être limité.
La prog c'est de la gymnastique et si on pratique pas on perd, les framework on tendance à mâcher les choses pour biensur ne pas "réinventer la roue", mais c'est bon de savoir quand même comment ca marche on y gagne en crédibilité et en indépendance.

[Benjamin Delespierre]

Je n'ai pas encore eu le temps de tout lire (quel thread intéressant d'ailleurs) mais je prends le temps d'exprimer mon opinion, ceci étant dit.

Je vais raconter mon histoire, je suis arrivé dans une entreprise ou il y avait 3 développeurs PHP qui faisaient tout ce qu'ils pouvaient pour améliorer un soft existant codé à l'emporte pièce en phtml sans aucune réutilisabilité ni sécurité. Devant les contraintes de temps qui m'étaient imposées, je n'ai pas eu le luxe de me mettre à un framework existant et encore moins de former mes collègues. Tout ceux qui dans mon entourage on cotoyé des frameworks PHP me l'ont dit: il te faut au moins un an de dév sur ce composant pour le maitriser (dixit Symphony). N'ayant pas non plus d'expert sous la main pour me chaperoner, j'ai jugé l'exercice trop risqué. J'ai alors commencé par m'écrire quelques helpers, des fonctions basiques pour mutualiser des traitements, j'ai attaqué par un mécanisme de templating utilisant des méta-balises dans du XHTML parsé par PHP, puis je me suis mis à créer des couches d'abstraction pour mes données, toujours afin de gagner du temps, et ainsi de suite. Au bout de quelques mois j'ai rassemblé toutes les pièces de ce qui allait devenir une ersatz de framework, je l'ai normalisé, j'ai créé des couches applicatives selon le modèles 3tiers, organisé mes composants autours du MVC, je me suis beaucoup inspiré des design patterns existants et j'ai continuellement amélioré ce qui n'était qu'au départ quelques helpers, par exemple, la couche modèle à subi 3 redesigns majeurs.

Aujourd'hui, nous utilisons ce framework maison pour nos produits, certes il n'est pas parfait et il n'est pas de la classe d'un ZF ou d'un Symphony mais sa flexibilité et sa généricité nous permettent de couvrir la plupart des cas d'usage de nos applications. De plus, j'ai pu écrire des guidelines et des documentations qui font qu'on peut travailler à plusieurs dessus plus efficacement et en toute sécurité. Je ne prétends pas avoir inventé l'eau tiède, j'ai juste créé un outil pour mes besoins et cet outil me satisfait avant tout parce que je le maitrise à fond. C'était didactique, enrichissant et productif. ça ne sortira probablement jamais de notre boite et je vois d'ici comment améliorer ce que j'ai créé mais on a réussi l'essentiel: gagner en productivité.

Les framework sont le mal ? Au contraire, les frameworks sont surtout un excelent moyen de travailler ensemble et c'est ça qui fait la différence.


--- EDIT

Ce thread me rappelle de (très) nombreux autres sur les framework Javascript. Je m'y était attardé du temps ou je me tâtait entre jQuery, Prototype et Mootools (finalement j'ai choisi d'investir dans jQuery pour pas raconter ma vie). On y retrouvait globalement les mêmes arguments mais pour moi qui n'ai jamais vraiment rien compris à Js, l'usage d'un framework qui me simplifiait le DOM, le XHR et le traversing m'a été salutaire. Maintenant je comprends beaucoup mieux, partir du framework pour descendre dans les couches bas niveau du langage est à mon sens bien plus aisé que l'inverse.

[grunk]

Dans ce cas faut s'arranger. Imposez un cadre de travail ou un "esprit de travail"

Le terme framework ne se limite pas à ZF et symphony. Comme Benjamin Delespierre j'utiliseun framework maison qui répond totalement à mes besoins. Moins lourd que les grand du millieu, mais suffisament efficace pour gagner en productivité.

A partir du moment ou tes développeurs utiliseent les même classes de bases , où chacun respecte une charte de développement on peut dire que tu utilises un framework. Framework n'est pas synonyme de MVC et d'usine à gaz.

Voilà pourquoi j'ai l'impression que les gens qui utilisent un framework n'ont pas quitté leurs habitudes des bancs d'écoles (c'est un exemple, une comparaison avec les écoliers), toujours vouloir en faire le moins possible

J'aurais tendance à penser le contraire. Utiliser un framework c'est un pas de plus vers l'industrialisation (c'est à la mode en ce moment). Et faut pas se leurrer dans la vraie vie , quand on te demande un projet pour hier (parce que c'est souvent comme ça que ca se passe) effectivement tu cherches à en faire le moins possible pour gagner du temps et respecter les délais qu'on t'imposes.

La prog c'est de la gymnastique et si on pratique pas on perd, les framework on tendance à mâcher les choses pour biensur ne pas "réinventer la roue", mais c'est bon de savoir quand même comment ca marche on y gagne en crédibilité et en indépendance.

Je suis d'accord avec ça. Même si réinventer la roue de ne sert à rien , quand on débute faire son petit framework (par exemple) en regardant comment sont fait les autres est très bénéfique pour la suite et permet de ne pas être trop déconnecté de ce qui se passe dans la boite noir qu'est le framework.

[Thes32]

D'abord il ne faut pas attaché le concept des frameworks au monde de PHP, les frameworks existent dans tous les langages industrialisés, certains ont même été l'objet de l'essor de langage (rails par exemple pour ruby), d'autres comme spring, struts ou hibbernate font presque partie du langage (java pour ne pas le citer) et sont devenus des outils dont un dév. web java ne peut se passer.

Détrompez-vous aucun framework ne code à votre place, il est surtout là pour définir l'architecture et les (bonnes) méthodes d'organisation du projet ce qui est indispensable pour tout projet de grande envergure.

Comme l'as dit grunk ne limitons pas les frameworks à ZF ou symfony ils en existent beaucoup d'autres ( eZ Components par exemple <3 ) .

En conclusion, utilisez un framework c'est bien !

[gwinyam]

Et comme je l'ai dit plus haut, la finance n'a pas à se mêler de ce qui ne la regarde pas. Non?

Sauf que la finance, c'est elle qui te nourrit. Donc elle a son droit de regard.

[MaitrePylos]

Bonjour,

Dans ce cas faut s'arranger. Imposez un cadre de travail ou un "esprit de travail".

Je croyais que c'était la définition d'un FrameWork ?

Une façon de penser unique, propre à vous (et non à celle des autres, cf frameworks).

Attention, tu laisses sous-entendre qu'utiliser un Framework est justement de se limiter à la pensée unique.......De même si on travaille en équipe, qui impose les standards.

Utilisez un Framework, c'est mettre des standards en place non ?

Maintenant le choix du Framework....j'ai toujours crus que c'était le rôle du chef de projet de choisir, vous avez l'air de travailler dans des boites où vous avez une grande liberté dans le choix de vos outils....Dans mon cadre de travail on m'impose :

- le langage (également le framework).

- la DB

- le IDE

- l'OS

Enfin tout, vous avez de la chance de pouvoir choisir et vous permettre de critiquer.

Un des points avec lequel je suis d'accord est le suivant :

Je trouve qu'un framework devrait s'adresser qu'aux développeurs possédant une certaine expérience assez importante (est-ce chose faite?). Ces développeurs expérimentés seront mieux aptes à savoir ce qui est à retenir et ce qui ne l'est pas. Tandis que le comportement à utiliser pour manipuler un framework aura de plus grosses répercutions sur le débutant.

Et donc le chef de projet et éventuellement moi (oui, je sais que je suis pompeux, mais j'ai l'expérience), allons imposer le cadre de travail, c'est pour cela que nous en utilisons plusieurs (ZF et STATO), je suis même en train de lorgner du côté de HOA (dans le cadre de formation à PHP).

Maintenant l'expérience rentre également en compte, dois-je utiliser

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
 
$valide_mail = new ZEND_VALIDATE_EMAIL();
 
if($valide_mail->isValid($mail)){
 
//blabla
 
}

Ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
 
$mail = filter_var('bob@example.com', FILTER_VALIDATE_EMAIL);
 
if($mail !=FALSE){
 
//blabla
 
}

Cela se jouera sur nos testes de performance et framework ou pas nous prendrons le plus léger (en fait on modifie les conventions de framework, suivant le besoin).

Mais bon il faut avouer, que dans un nouveau projet, prendre Atomik ou Stato ou.....c'est quand même agréable d'avoir un système MVC performant sans avoir rien à coder...maintenant ce qu'on en fait !

[stealth35]

je pense qu'il est bon de savoir se qui se cache derrière

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$valide_mail = new Zend_Validate_Email();
 
if($valide_mail->isValid($mail)){
 
//blabla
 
}

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$mail = filter_var('bob@example.com', FILTER_VALIDATE_EMAIL);
 
if($mail !=FALSE){
 
//blabla
 
}

Je suis sur que peu de gens savent faire la différence entre les 2 méthodes, et quelles sont leurs points forts/faibles.

Et d'ailleurs filter_var n'est qu'un outils a lui aussi, on peu presque parler de module type framework comme la lib SPL.

Après moi je me pose une question : est-ce crédible (en tant que développeur) de coder orienté framework sans avoir une réel connaissance de l'api de base d'un language ?

Sans y répondre ca me fait penser un peu a la différence entre "webmaster" et un "développeur".
Et on peu être bon en PHP sans connaitre le fonctionnement en C de PHP.

[HeadCoder]

Excusez moi de cette absence, je suis peu disponible la semaine.

Le terme framework ne se limite pas à ZF et symphony. Comme Benjamin Delespierre j'utiliseun framework maison qui répond totalement à mes besoins. Moins lourd que les grand du millieu, mais suffisament efficace pour gagner en productivité.

Et ce framework maison, alors on peut dire qu'il fait partie de ce bel exemple que vous aimez tant: recréer la roue. C'est ce que vous avez fait.

A partir du moment ou tes développeurs utiliseent les même classes de bases , où chacun respecte une charte de développement on peut dire que tu utilises un framework. Framework n'est pas synonyme de MVC et d'usine à gaz.

Exactement. Le problème, c'est que les gens prennent un framework pour un tas de fonctions et de scripts plutôt qu'un outil qui agit sur le plan cognitif.

J'aurais tendance à penser le contraire. Utiliser un framework c'est un pas de plus vers l'industrialisation (c'est à la mode en ce moment). Et faut pas se leurrer dans la vraie vie , quand on te demande un projet pour hier (parce que c'est souvent comme ça que ca se passe) effectivement tu cherches à en faire le moins possible pour gagner du temps et respecter les délais qu'on t'imposes.

Donc tu ne voudras jamais être un boulanger. Tu ne portes aucun intérêt à tes projets.

Je croyais que c'était la définition d'un FrameWork ?

Oui, mais sans les fonctions et les scripts déjà faits?

gwinyam -> En effet. À mon avis il faudrait essayer de le penser autrement. Et si la finance donnait un peu plus de confiance envers les autres et se fermait un peu plus les yeux? Car après tout, sans les autres domaines, elle n'ira pas loin.

Vous savez tout aussi bien que moi que vous "gagnez" au plan technique. C'est bien beau de parler code, fonctions, architectures, etc mais ce n'est pas là que se situe le problème (sinon, toute cette discussion sert à que dalle). Le problème, il est au niveau cognitif, réflexion, etc. Bref, tout ce qui est théorique. Dans l'article, la majorité des points sont sur ces aspects et non sur le plan technique. Alors ça ne sert à rien de parler de la technique.

J'aimerais savoir d'où vient cette si grande confiance que vous avez envers les frameworks. Vous n'avez jamais peur qu'il arrive quelque chose avec? Qu'il ne soit pas fiable? Ou qu'il arrive d'autres types de problèmes...

[gwinyam]

J'aimerais savoir d'où vient cette si grande confiance que vous avez envers les frameworks. Vous n'avez jamais peur qu'il arrive quelque chose avec? Qu'il ne soit pas fiable? Ou qu'il arrive d'autres types de problèmes...

Bien au contraire, des problèmes, il y en a sans arrêt, la simple existence de ce forum suffit à le prouver. Des problèmes de formation ou de mauvaise utilisation majoritairement, enfin c'est ce que je pense.

Mais pour la fiabilité, bien au contraire. Je prends l'exemple du ZF (désolé, c'est le seul que je connaisse suffisamment), il y a une importante communauté internationale d'utilisateurs pour aider, remonter des bugs, l'équipe de développement effectue de nombre tests unitaires, la documentation est traduite en plusieurs langues...

Et si t'as peur d'avoir des problèmes en utilisant quelque chose, laisse tomber de suite l'informatique, parce que c'est une vie de problèmes à résoudre.

[dourouc05]

Et si la finance donnait un peu plus de confiance envers les autres et se fermait un peu plus les yeux? Car après tout, sans les autres domaines, elle n'ira pas loin.

Le problème est que la finance fonctionne en circuit très fermé pour le moment : l'argent sert à faire de l'argent... Les entreprises cotées en bourse ont une partie qui fait de l'argent avec de l'argent, justement, pour avoir une croissance suffisante que pour subsister en bourse. Mais on s'éloigne.

Vous savez tout aussi bien que moi que vous "gagnez" au plan technique. C'est bien beau de parler code, fonctions, architectures, etc mais ce n'est pas là que se situe le problème (sinon, toute cette discussion sert à que dalle). Le problème, il est au niveau cognitif, réflexion, etc. Bref, tout ce qui est théorique. Dans l'article, la majorité des points sont sur ces aspects et non sur le plan technique. Alors ça ne sert à rien de parler de la technique.

Deux visions du code : l'idéaliste et le pragmatique. Tu envisages le code comme certains envisagent de philosopher toute leur vie ; en face, des gens qui envisagent le code comme un gagne-pain. Il est donc évident que les points de vue soient fort divergents : celui qui code pour (sur)vivre veut avoir un truc qui ne l'ennuie pas trop à la maintenance mais il ne veut pas trop réfléchir non plus car peu d'envie. L'idéaliste veut faire le meilleur code possible, etc., il ne réfléchit pas du tout à ce niveau, il peut envisager de se passer d'outils facilitant au final un tant soit peu la maintenance, il peut voir la philosophie, la beauté des objets fractals se cachant dans son code, il va réfléchir à quarante deux fois avant d'écrire quelque chose : est-ce bien là le meilleur à faire ? ; son pendant plus terre-à-terre réfléchira seulement deux fois : est-ce bien ce qui m'apportera le moins de soucis ?

J'aimerais savoir d'où vient cette si grande confiance que vous avez envers les frameworks. Vous n'avez jamais peur qu'il arrive quelque chose avec? Qu'il ne soit pas fiable? Ou qu'il arrive d'autres types de problèmes...

Je n'ai jamais eu de problème avec les frameworks ; de toute façon, si jamais j'en ai un, je le soumets sur leur bug tracker et il est résolu pour la prochaine version, en général. Ou alors c'est un problème très pathologique (mixer dans un module symfony et DokuWiki, qui définissent des helpers de même nom, il y en a un des deux qui doit bien trinquer quelque part...).

Aussi, quand j'ai fait mon choix de framework, je n'étais pas du tout guidé par la raison, plus par les on-dit, par les sites qui l'utilisent ; qu'avais-je d'autre comme choix ? Quand j'ai vu que DailyMotion, par exemple, utilisait une version beta de symfony... je me suis dit que les versions stables devaient être très stables ! (Le discours pro-framework, aussi appelé "source"). De plus, c'est un framework de français... Tant qu'à faire, autant que ce soit du presque local. Il y avait aussi le ZF. Mais bon, la doc me plaisait bien moins.

Peur de quoi ? Si ce framework est si bien utilisé... pourquoi donc moi, petit développeur, pourrais-je le mettre en doute ?

Donc tu ne voudras jamais être un boulanger. Tu ne portes aucun intérêt à tes projets.

Tiens, quel bel exemple...

Mais pourquoi porter un quelconque intérêt aux projets quand tu es le développeur gagne-pain ? Dans le même genre, le balayeur public travaille et gagne sa vie, il est très heureux comme ça. Bon, il aimerait faire mieux... il a au moins la satisfaction de travailler. Peu doivent y prendre plaisir.

Le problème, c'est que les gens prennent un framework pour un tas de fonctions et de scripts plutôt qu'un outil qui agit sur le plan cognitif.

À l'origine, c'est quand même ce que c'est : beaucoup de devs ont déjà fait leur framework perso, je n'ai pas fait exception... je n'ai juste jamais fini, j'ai découvert symfony avant. Et puisque c'était déjà fait, bien mieux fait (Doctrine, Admin Generator sont les deux points qui m'ont fait basculer définitivement de ce côté, surtout avec une telle intégration). Quand je travaillais, pauvre fou, là dessus... c'était très peu de fonctions, beaucoup d'objets, de wrappers, pour abstraire tout ce qui peut l'être, faire que mon code puisse être aussi lisible, sans appel superflu à MySQL direct, ce qui m'empêchait en plus de faire des tests rapides ou des benchmarks en local (passer à SQLite est mieux en ce cas).