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.

[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.

[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.

[Traroth2]

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

L'idée de base d'un framework, c'est de faire bien une fois le boulot ayant le moins de valeur ajoutée, le boulot qui enquiquine tout le monde mais qu'on est obligé de faire pour chaque projet, et de réutiliser ensuite ce qu'on a fait sans avoir à le refaire, ce qui permet au développeur de se concentrer sur le boulot réellement créatif.

[Invité]

@dourouc : "PDO c'est objet donc c'est abstrait de la base de donnée donc c'est très mauvais"

A ben en fait si c'est bien Car tu n'a pas a te soucier "j'utilise mysql_connect ou sqllite_connect" peut importe ton sgbd quand tu en change t'as pas a réapprendre des liste et des listes de méthodes.

[dourouc05]

@dourouc : "PDO, c'est objet donc c'est extrêmement mauvais ; c'est abstrait de la base de données, c'est encore pire."

A ben en fait si c'est bien Car tu n'a pas a te soucier "j'utilise mysql_connect ou sqllite_connect" peut importe ton sgbd quand tu en change t'as pas a réapprendre des liste et des listes de méthodes.

C'était de l'ironie pure et dure ! (Au passage, je remets les mots exacts ; ce n'est pas parce que c'ets objet que c'ets abstrait, on peut donner des couches d'abstraction de base de données sans objet : on définit une interface dans la documentation qu'on implémente pour plusieurs bases de données et on inclut le fichier qui contient les implémentation pour la base de données qu'on veut).

[demenvil]

Moi je pense que l'utilisation d'un FW est vraiment quelque chose de bien, et pas seulement dans le domaine du web.
@Manulion
Puis le coup de c'est la régression assurée Je ne voit pas ce que ça vient faire là.. c'est un peu le sens contraire d'un FW! Diminuer le temps de développement d'un projet X en proposant des outils et une manière de s'organiser (MVC)..Etc des arguments dans ce style nous pourrions t'en donner pleins.
Sache que si les FW sont là c'est pour le confort des devs! Perso je ne me vois pas tous recommencer à chaque fois
Quand à la manière de penser son code là aussi un dev à largement le choix! Soit il créer sont propre FW soit il à le choix entre une sacré liste!
http://fr.wikipedia.org/wiki/Liste_de_frameworks_PHP
Tu imagines des gros projets sans l'utilisation d'un FW je pense que ce pourrait-être un peu l'anarchie !
(D'après moi) Aujourd'hui les framework php sont tellement nombreux que je pense que n'importe quel développeurs puissent trouver son bonheur ! Puis je pense aussi que toutes personnes capable d'utilisé un FW aussi complexe qu'il soit ou pas et aussi capable de créer le sien.
Ensuite cela à déjà était dit, On ne connais pas ton expérience dans le domaine de la programmation, notamment dans le travail en équipe (>5 dev) Et je ne pense pas que tu es une grande expérience.. vu que tu n'as que 15 ans. Et remettre quelque chose comme ça sous forme de buzz sans réel expérience c'est moyen je trouve...
Et petit dernière question
As tu déjà développer un site avec un FW php de A à Z ? Si oui avec lequel?
Merci

[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 !

[smoser]

Bonsoir,

Je me suis mis à lire ici-même les commentaires qui y ont été postés. Je me rends compte que l'on a passablement dévié de l'article de base. Cependant, les interventions étant intéressantes je vais y amener mon propre point de vue.

Selon moi il est tout d'abord nécessaire de distinguer le public cible, car la réponse peut fortement diverger selon celui-ci.

** Public cible / but **
- Etudiant-Amateur / Apprendre les concepts :
Débuter par l'apprentissage de l'utilisation d'un framework sans passer d'abord par l'apprentissage des concepts de base... n'est pas une bonne chose. Utiliser un framework c'est se simplifier la vie, ne coder que le "strict nécessaire", le code "métier". Or lorsque l'on apprend... le but est plutôt d'apprendre les concepts sous-jacents, "comment ça marche", "comment c'est construit". Or les frameworks imbriquent des concepts (algorithmes, designs patterns, ...) complexes et les assemblent le tout pour que vous n'ayez pas à vous en soucier lorsque vous codez. Il vaut mieux : 1) apprendre les concepts de base et ensuite 2) ouvrir le code source d'un framework pour voir comment ils ont été implémentés... que l'inverse.

- Professionnel / Développer des applications :
On peut voir un framework comme une boîte à outils. Si cette boîte correspond à nos besoins... autant l'utiliser ! Cela nous fait gagner du temps et assure par le biais de la communauté qui est autour du framework : 1) une certaine stabilité du produit 2) une certaine sécurité d'implémentation 3) une certaine évolutivité 4) la re-usabilité du travail déjà fait par d'autres personnes (modules, plugins, extensions, ...)

Si la boîte à outils ne correspond pas à nos besoins :
a) en choisir une autre qui correspond mieux à nos besoins
b) modifier/adapter l'existant à nos besoins (quitte à créer un "fork" du framework)
c) ne pas utiliser de frameworks existants car aucun ne convient (et/ou cela demande trop de temps/argent de les adapter) et coder soi-même le produit qui répondra aux besoins soit sous la forme d'un framework, soit sans framework (cela dépend du temps et des besoins/objectifs).

En industrie, ce qui compte c'est :
1) Satisfaire aux besoins du client
2) Dans les délais
3) En retirer un bénéfice suffisant pour faire tourner la société
4) Assurer une formation continue suffisante à son personnel (ou renouveler le personnel ... c'est une question de choix) pour qu'il effectue son travail : efficacement, rapidement, de manière "professionnelle".

Le choix d'utiliser ou non un framework dépend des points précédents....

- Chercheur / Créer de nouvelles technologies :
Dans ce cadre, utiliser un framework n'est pas toujours la bonne solution. Les frameworks ont souvent des limitations assez contraignantes intrinsèques à l'architecture choisie lors de son développement. Un chercheur qui doit innover aura parfois avantage à créer son propre framework qui correspond à ses besoins précis! Par contre, il est toujours intéressant pour le chercheur de comparer les différents frameworks et les différentes architectures qui ont été implémentées pour se faire son propre avis, sa propre idée de ce qu'il veut ou ne veut pas. Il utilisera plutôt les frameworks en regardant "comment ils sont faits" pour s'imprégner des idées/fonctionnalités qui les composent pour créer le sien, quitte à réutiliser du code source (fonctions, class) dans sa propre application.

** Découverte de vulnérabilité **
Concernant le point évoqué sur la découverte d'une vulnérabilité, je pense que l'on est hors sujet. Que l'on utilise un framework ou non, le problème se pose. La différence va se situer sur 2 points importants :
- La vulnérabilité est intrinsèque au framework utilisé. Dans ce cas, la mise à jour du framework par le client (s'il n'y a pas eu de modifications de son code source pour y implémenter de nouvelles fonctionnalités "maison") va résoudre le problème sans se soucier de l'application créée et vendue par le fournisseur.

- La vulnérabilité est intrinsèque au code créé par le fournisseur. Dans ce cas, soit le client a sousrcit à une "garantie de support" auprès du fournisseur, auquel cas il demande au fournisseur un patch pour corriger le problème; soit le client n'a rien souscrit de tel et se débrouille lui-même pour créer le patch.

Créer une application sans framework ne sous-entend pas que l'on n'utilise pas de classes, de fonctions, ... qui évitent de répéter le même bout de code source à plusieurs endroits !

** Gratuité du framework **
Le critère de choix d'un framework pour sa gratuité n'est pas un argument valable. On ne choisit pas un framework plutôt qu'un autre pour son prix, on le choisit pour sa capacité à répondre à des besoins réalisables en un temps donné dans un budget donné.

** Transmission des informations / Gestion de l'information **
Je pense que la critique sur le manque de transparence de la gestion de l'information n'est pas raisonnable. Dans un framework, on va justement utiliser des couches d'abstraction pour pouvoir séparer les données du reste du code. A cet effet, on concentre toute l'information dans des lieux connus. Si on a un doute sur la sécurité du transfert de l'information, rien n'empêche d'ajouter une couche d'abstraction qui traitera de la sécurité, du chiffrement, ... de l'information et qui restera indépendante (ne touchera pas au code) du reste du framework.

** De l'utilisation d'un framework **
A mon sens utiliser ou non un framework ne remet pas en question les connaissances "métiers" du développeur. Ce n'est pas parce que l'on utilise un framework que le développeur perd ses compétences. C'est à lui de se tenir à jour, cela fait partie de sa formation continue. Cela n'a rien à voir avec l'utilisation d'un framework ou non.

Utiliser un outil plus simple permet d'être plus efficace, et donc de se concentrer sur les véritables problèmes que le développeur aura à traiter : les algorithmes métiers à implémenter. S'il doit se soucier à chaque fois de la sécurité des données, de l'usage des sessions, de la persistence, de la mise en cache, ... dans son développement il va perdre beaucoup de temps à coder des choses qui sont hors de ce qui lui est explicitement demandé ! : coder les algorithmes métiers !

** Confiance dans le code source du framework **
Ce point est crucial lors d'un développement ! Si l'on ne peut pas faire confiance à la qualité du code source déjà développé... il n'est tout simplement pas envisageable d'utiliser le framework en question. C'est pourquoi : la réactivité de la communauté aux bugs soumis, aux suggestions, ... est très importante. C'est également pour cette raison que certaines sociétés se spécialisent dans le support d'un framework et le font payer... Il faut utiliser un framework en connaissance de cause, en sachant si à chaque bug trouvé il va falloir passer nous-mêmes des heures, des jours, ... à le corriger nous-même ou si on peut faire confiance à la communauté pour résoudre rapidement le bug et proposer un patch, une nouvelle release, ...

** Framework = centaines de fonctions inutiles **
Sur ce point je suis souvent d'accord. A quoi sert-il d'utiliser un truc très complexe bourré de fonctionnalités si l'on veut en utiliser qu'un dixième ? Les deux gros points noirs des frameworks sont :
-- la lourdeur de la solution : nombre de fonctionnalités que nous n'utiliserons jamais et qui sont implémentées.... et qui sont susceptibles d'être buguées !!!
-- le temps d'exécution de la solution : plus le framework est évolué, complexe, plus il a de couches d'abstraction, moins il est rapide !!!
Il serait vraiment très judicieux d'édifier des frameworks sur lesquels on "compile" (comprendre "intègre" dans le cadre du php) que les fonctionnalités utiles et utilisées ! Des frameworks où l'on choisit à l'installation les modules que l'on veut et que l'on ne veut pas intégrer.... même au niveau du "core" du framework.

** Beauté du code **
La beauté du code source... C'est sympa de coder pour la beauté du code... mais cela ne permet pas de gagner son salaire. Cela n'est possible que si l'on est Amateur-Etudiant-Chercheur. Dans le cadre de l'employé, la beauté du code n'est pas un aspect très important... ce qui est important c'est que "ça marche" et que "en cas de problème le code puisse être vite corrigé" (temps de maintenance faible)

** Réunion d'une communauté autour d'un framework **
L'utilisation d'un framework a également un autre avantage. Celui de fédérer une communauté à sa cause ! Grâce à cela, n'importe qui peut proposer des nouvelles fonctionnalités, identifier et résoudre des bugs, et également avoir des idées que nous n'aurions pas eu nous-mêmes ! Oui car lorsque l'on fait un projet à plusieurs il est fortement probable que les collègues aient une autre vision que la vôtre, d'autres idées, d'autres suggestions... par le biais de leur propre expérience, formation... Cela est un avantage indéniable sur un projet ! Pouvoir avoir plusieurs idées différentes pour résoudre le même problème et pouvoir choisir celle qui nous convient le mieux !

[Joker-eph]

** Framework = centaines de fonctions inutiles **
Sur ce point je suis souvent d'accord. A quoi sert-il d'utiliser un truc très complexe bourré de fonctionnalités si l'on veut en utiliser qu'un dixième ? Les deux gros points noirs des frameworks sont :
-- la lourdeur de la solution : nombre de fonctionnalités que nous n'utiliserons jamais et qui sont implémentées.... et qui sont susceptibles d'être buguées !!!
-- le temps d'exécution de la solution : plus le framework est évolué, complexe, plus il a de couches d'abstraction, moins il est rapide !!!
Il serait vraiment très judicieux d'édifier des frameworks sur lesquels on "compile" (comprendre "intègre" dans le cadre du php) que les fonctionnalités utiles et utilisées ! Des frameworks où l'on choisit à l'installation les modules que l'on veut et que l'on ne veut pas intégrer.... même au niveau du "core" du framework.

C'est vraiment un des seuls points auquel j'ai du mal à adhérer...
Mon système d'exploitation possède plein de fonctionnalités qui me sont "inutiles", idem pour mon traitement de texte, etc.

Toutes ces fonctions "inutile" sont désactivés dans le framework si je ne m'en sert pas, par exemple : si je n'active pas explicitement les sessions, mon framework ne chargera pas les composants dédiés à la gestion des sessions, dès lors que m'importe qu'il y ait quelques (centaines de) lignes de php inutiles, puisqu'elles sont dans des fichiers qui ne seront jamais lu/chargés/exécutés/...

Pour rester dans le framework, mais en changeant de langage : on trouve beaucoup de "framework" javascript qui propose de personnalisé le package que l'on va télécharger en choisissant quelles fonctionnalités on souhaite utiliser. Mais ça se comprend mieux parceque le packaging se fait dans un fichier unique qui est toujours téléchargé et parsé par le navigateur du client.

[Michel Rotta]

** Framework = centaines de fonctions inutiles **

C'est aussi un point qui m'a interpellé sur ton intervention.

Effectivement, certains framework ne chargent que les modules utilisé ou permettent de désactiver les modules inutiles pour une application. C'est le mieux.

Mais si je sors du domaine des Framework et me jette à pied joint dans celui, différent, des tableurs. Que je prends comme référence les deux gros du marchés (excel et calc (OOo) ). Si je regarde les utilisateurs, ils vont utiliser, pour 95% d'entre eux, dans les 1% des fonctionnalités. Et encore. Et là, cela semble normal...

Je pense donc que, sauf question pertinente de performances, c'est un faux problème.

Et que l'on ne viennent pas me dire que PHP est plus rapide pour afficher "Hello word", et plus simple. C'est vrai ! Mais cela n'a aucun intérêt. Quoique, mon framework de prédilection, correctement configuré, affichera, à la deuxième lecture, le "Hello World", plus vite qu'un bête code PHP... Si si !