Discussion :

[davcha]

Donc... Les framework, c'est pas bien, parce que ça nous impose une façon de penser...

Mais le paradigme objet (n'importe quel paradigme en fait) aussi nous impose une façon de penser... Donc les langages, c'est pas bien ?

J'ai surtout l'impression qu'on est un peu submergé par la technique ici.
En fait, le développement d'un logiciel commence un peu avant le choix d'utiliser ou non un framework.
"Généralement", on a quand même une phase de conception, où on réfléchit en faisant de beaux diagrammes pour donner l'impression aux clients qu'on sait ce qu'on fait.

Bon, après, il y a tout de même quelque chose d'évident, c'est que des sites web ou des applications web, on en fait un paquet depuis un bon bout de temps, maintenant. Entre une application de gestion et une autre, on va toujours afficher des menus, des tableaux, des boutons....
On ne va pas constamment réinventer tout ce qui a été fait depuis 20 ans dans ce domaine.
Déjà, pas de tableaux, vous imaginez ? On les remplace par quoi, alors ? On est reparti dans un questionnement conceptuel, avec cette question.

Bref. S'il y a des framework, c'est aussi parce que les applications qu'on produit sont sensiblement similaires.

[GaapTap]

bonjour a tous

j'ai l'impression de voir une guerre de tranchés.... je vais donc essayer de donner mon opinion en espérant ne pas me faire tirer dessus moi pauvre et innocent developpeur

bon pour commencer ça fait quelques années que je fais du dev web, seul ou en collaboration et pour finir sur de simples sites comme de gros de e-commerce.

j'ai vu marqué MVC ou autres, il est indéniable que les frameworks (presque tous) contiennent cette philosophie de découpage et tant mieux, mais revenons a ce que je pense...

pour des sites de quelques pages sans gros traitement, je suis d'accord un framework est du superflue et surtout trop lourd pour si peu (comme quelqu'un l'a dit plus haut).

pour des sites moyens et gros demandant des traitements, des opérations sur les BDD,webservices ou autres déjà je me positionne sur un framework.

(ne me demandez pas comment quantifier la taille d'un site elle est suggestive a chaque personne ce qui induit un choix de technologie)

Plus pratique a maintenir, contient déjà des librairies et l'ORM intégré (pour celui que j'utilise) lorsque je change un champ ou que je rajoute une table, je peux (grâce tjrs a l'ORM intégré) tout regenerer sans toucher aux librairies qui utilisent les tables.

Le framework m'oblige a faire du MVC, a mieux découper mes librairies, a uniformiser mon code pas me lobotomiser .

Il me permet d'avoir plusieurs sites basés sur le même framework, d'utiliser les mêmes librairies d'utilitaires sans avoir a les mettre dans un répertoire commun, ou mieux un fichier dans chaque application (provocant des oublis de mise a jours -> des bugs -> oublis de test d'applications etc...).

Il me permet d'intégrer mes tests unitaires et fonctionnels en son sein.

je conçois aussi que l'on peut tout faire sans framework, mais si ils existent c'est qu'il y a une demande ou un besoin, effet de mode je ne pense pas les plus vieux framework php date (je me souviens avoir découvert celui de zend en 2005-2006).

Donc pour ma part je n'ai vu que des bons côtés surtout quand tu dois développer X sites internes tu n'as alors plus qu'un svn qui contient tout et qui se base sur les mêmes bases.

Cela n'a pas empêcher que nous nous sommes appropriés le framwork avec notre propre philosophie, mais on est tous partis sur une base commune.

donc pour finir le framwork provoque la paresse, peut être, gain de temps et minimalisation des erreurs c'est certain.

mais n'oublions pas :

Il y a au moins 7 facons possibles de ne pas se comprendre !

Entre ce que je dis,
Ce que je croix dire,
Ce que je veux dire,
Ce que je pense,
Ce que vous voulez entendre,
Ce que vous entendez,
Ce que vous croyez en comprendre,
Et ce que vous comprenez

[syber]

Il me permet d'avoir plusieurs sites basés sur le même framework, d'utiliser les mêmes librairies d'utilitaires sans avoir a les mettre dans un répertoire commun, ou mieux un fichier dans chaque application (provocant des oublis de mise a jours -> des bugs -> oublis de test d'applications etc...).

Je suis d'accord. Il faut rationaliser les développements. Même un site qui peut paraître petit est sans intérêt peut être amené à grossir ( nous ne sommes pas à l'abri d'un succès ). Maintenant c'est une question d'anticipation. Avoir une architecture logiciel qui tient la route dès le début évite des déboires après. Et puis la mise en place d'une architecture MVC est très rapide, l'excuse du coût et du temps sont surtout l'excuse de l'ignorance.

Bref. S'il y a des framework, c'est aussi parce que les applications qu'on produit sont sensiblement similaires.

Oui. C'est tellement simple que cela ne l'est pas pour tout le monde.

Pour rassurer les bricoleurs PHP du dimanche, je regarde régulièrement le code de mon framework pour savoir ce qui s'y passe. L'utilisation d'un framework n'interdit pas la curiosité.

Pour ma part, je vais arrêter la discussion. Il est de ses conversations qui sont sans fin.
Etre pragmatique doit être une qualité pour un informaticien.

Par contre je vais me délecter des quelques irréductibles qui voudront avoir le dernier mot pour conclure que les frameworks c'est mal.


PS: en informatique plus on avance moins on en sait et meilleur on devient.

[bugsan]

Un framework est aussi une grande source d'inspiration pour notre propre code.

[Paul TOTH]

@Paul TOTH

Et ben... comme je te l'ai déjà dit dans le thread concernant IE6, ou j'étais assez déçu que tu défendes ce navigateur FINI,

je ne me souviens pas avoir défendu IE6...peut-être, tout dépend du contexte. ceci dit il est encore bien présent, pas pour notre bien, mais il faut faire avec parfois.

ton bouquin sur Delphi7 m'a beaucoup aidé quand j'ai débuté en prog il y a quelques années.

Mais la en voyant de nouveau ton avis sur les Frameworks, tu me donnes vraiment l'impression de ne pas avoir évolué avec les outils d'aujourd'hui.

Quand tu parles d'utilisation de frameworks et de pertes d'argent notamment, tu mélanges tout et n'importe quoi. Ca n'a rien à voir.
De plus, de nombreux clients ne savent même pas ce qu'est un framework et demandent uniquement : "UN DEVELOPPEMENT". Après tu fais comme tu veux ou presque.

Et non, ce sont mes clients qui me parlent de framework, que veux tu

+1 .. T'es tu vraiment intéressé à ces outils de dev ces dernières années ? à leur intégration dans Netbeans ou Eclipse ?

@syber


Yes ! au début, avant de me lancer dans le MVC, je l'utilisais également qu'en composants. C'est l'un de ses avantages mais on m'a dit que c'était possible aussi avec Symfony

je travaille à l'ancienne, et je continuerais à le faire tant que je m'y retrouve et mes clients avec moi

[diden138]

Quelqu'un m'a dit plus haut que les Framework c'est sécurisé, c'est opensource il n y a aucune porte dérobé...etc. sous prétexte qu'il y a une grosse communauté derrière et que lui même a vérifié waw impressionné
Savez vous OpenBSD depuis combien d'année il existe ? surement plus que les Framework web, et pourtant c'est jusqu'à maintenant que certaines personnes ont découvert des portes dérobés et ça a provoqué un scandale.
Alors oui les framework sont beau et tout mais dès qu'il s'agit d'une application d'argent, de données sensibles vaut mieux éviter. d'ailleur j'ai jamais vu une application de business en full php (avec ou sans utilisation de framework)
Tous ce que je sais c'est qu'il faut respecter le choix de chacun, un developpeur qui n'utilise pas un framework ne veut pas dire que c'est un amateur bien au contraire je dis bien au contraire parceque 90% des gens qui utilisent les framework sont des amateurs et ne connaissent même le php avant d'apprendre à utiliser un framework, c'est pas moi qui le dit cherchez sur le net bref chacun fait ce qu'il veut mais l'utilisation ou non d'un framework ne veux absolument rien dire
Pour info : je bosse avec mon propre framework depuis des années et jamais eu de prob (ni de sécurité, ni de fonctionnement) et au moins je sais à 100% ce qu'il y a sous le capot et ça c'est une chose très importante pour un développeur sensé et non une machine à coder, il faut arrêter les pensés genre wawouuu ceux qui ont fait symphony c'est des craques et tout et nous on peut pas faire mieux


Cordiales Salutations,

[martopioche]

Comme beaucoup je pense, je découvre l'article sur les RSS de Developpez. Et ce genre de réponse me fait rejoindre l'auteur :

En fait, le développement d'un logiciel commence un peu avant le choix d'utiliser ou non un framework.
"Généralement", on a quand même une phase de conception, où on réfléchit en faisant de beaux diagrammes pour donner l'impression aux clients qu'on sait ce qu'on fait.

Car en fait, c'est assez rare. Entre les réponses à appel d'offre qui ne vendent que les outils habituels de la boite, ou la cellule architecture qui impose les technos, les projets se construisent autour des outils.

Ensuite, une des choses que l'on peut reprocher à l'utilisation des frameworks (et non au framework en eux même, tout du moins, pas directement), c'est que leur utilisation dépasse rarement le tuto customisé. Rare sont ceux qui vont fouiller les docs obscures, des fois le code en lui même si le framework est open source, pour en tirer des astuces souvent bien plus pertinentes pour le besoin. Connaitre un framework peut être tout aussi long et complexe que connaitre le langage sur lequel il repose.

Enfin, l'auteur reproche une "pensée unique", pour des outils comme ROR, Django ou Grails, c'est vrai, et ils ne s'en cachent pas d'après leur paradigme "Convention over Configuration". On vante souvent leur efficacité, leur productivité. C'est vrai, mais en ayant à l'esprit dans quel cas les utiliser afin d'en tirer tout le bénéfice. Sortez des sentiers battus, et ces outils sont plus une plaie qu'autre chose.

En conclusion, je reste persuadé que pour un développeur, l'intérêt d'un Framework est de figurer sur son CV car c'est un critère de sélection. Je crois en leur utilité, mais je suis aussi déçu et frustré de voir bien souvent avec quelle qualité médiocre ils sont utilisés, souvent vendus "pour vendre du framework car techno moderne à la mode"

[turcotm]

FW communautaire ou FW interne a une entreprise, je ne connais personne qui en utilise pas. Je ne connais personne qui ré écrit a chaque site qu'il développe, toute les fonctionnalités.

Donc, le FW n'est pas un antéchrist. C'est seulement un outil pour sauvé du temps et espéré faire de l'argent.

Merci

Michel

[jonoz]

Pour info : je bosse avec mon propre framework depuis des années et jamais eu de prob (ni de sécurité, ni de fonctionnement) et au moins je sais à 100% ce qu'il y a sous le capot et ça c'est une chose très importante pour un développeur sensé et non une machine à coder, il faut arrêter les pensés genre wawouuu ceux qui ont fait symphony c'est des craques et tout et nous on peut pas faire mieux

Personne ne dit que l'on ne peut pas faire mieux.

C'est plutôt qu'il est difficile de faire aussi bien ou mieux avec le temps dont la plupart des personnes disposent.

Je veux bien expliquer à celui qui me paie que j'aurais besoin de l'équipe un mois ou deux pour écrire un 5000e FW php ou JEE. Je doute que celà lui convienne... Du coup, si je veux le faire, c'est sur mon temps perso. Or, il se trouve que d'une part j'ai d'autres choses à y faire et d'autre part j'ai déjà des outils faits par d'autres qui me conviennent.

Sans compter tout le travail de documentation qui accompagnent tout bon outil.

D'ailleurs Symfony n'invente pas grand chose, c'est juste dans les grandes lignes une excellente transposition en php de plein de concepts d'architectures J2EE.

Par ailleurs, ça me fait vraiment bien rire les petits malins qui regardent un FW et se disent "mouarf, ma library à moi que j'ai fait avec mes petites mains est juste mieux" . Comme dit plus haut, je me suis fait mon framework à moi avec mes petites mains. J'ai entre autre intégré une gestion des actions avec des fichiers xml (genre actionmappings), un générateur de classe + un set de validators (qui constituent un ORM "light"), un moteur de templates, un gestionnaire de workflow, des sets de decorators/delegations pour les beans (opérations db, peuplement et dump xml...), un wrapper de session, un wrapper de requêtes, une gestion de droits universelle, une intégration de PhpUnit, la réécriture d'url avec déduction de l'url de la façon d'afficher une entité (xhtml, xml, json, doc pdf...)...

Bref, ça fait des tonnes de trucs, ça le fait bien, je connais tous les rouages de la bête, j'ai passé des plombes à refactorer encore et encore au fur et à mesure que mes connaissances en POO et en architecture ont évolué.
Du coup, je n'ai pas non plus refactoré l'intégralité du système au fur et à mesure, et plein de choses nécessiteraient d'être remises au goût du jour.

Donne moi 6 mois, je te pond un truc carré de chez carré, avec des tutos en plus de la doc autogénérée...mais je les ai pas. Et quand un collègue ou un autre presta reprend mon code, je fais quoi ? Je passe une semaine ou deux à le former ?

Quand à la personne qui dit que pondre une architecture MVC ça prend pas longtemps, je ne suis pas tout à fait d'accord. Ca se pond en dix minutes quand on veut un truc de base et que l'on est prêt à mettre les mains dans le système de routage toutes les cinq minutes. Si on veut quelque chose de plus efficace en termes de productivité ça requiert un peu plus de travail, de réflexion et donc de temps.

FW communautaire ou FW interne a une entreprise, je ne connais personne qui en utilise pas. Je ne connais personne qui ré écrit a chaque site qu'il développe, toute les fonctionnalités.

Bah il y a les rois du copier-coller...

Entre les réponses à appel d'offre qui ne vendent que les outils habituels de la boite, ou la cellule architecture qui impose les technos, les projets se construisent autour des outils.

Ensuite, une des choses que l'on peut reprocher à l'utilisation des frameworks (et non au framework en eux même, tout du moins, pas directement), c'est que leur utilisation dépasse rarement le tuto customisé. Rare sont ceux qui vont fouiller les docs obscures, des fois le code en lui même si le framework est open source, pour en tirer des astuces souvent bien plus pertinentes pour le besoin. Connaitre un framework peut être tout aussi long et complexe que connaitre le langage sur lequel il repose.

Enfin, l'auteur reproche une "pensée unique", pour des outils comme ROR, Django ou Grails, c'est vrai, et ils ne s'en cachent pas d'après leur paradigme "Convention over Configuration". On vante souvent leur efficacité, leur productivité. C'est vrai, mais en ayant à l'esprit dans quel cas les utiliser afin d'en tirer tout le bénéfice. Sortez des sentiers battus, et ces outils sont plus une plaie qu'autre chose.

En conclusion, je reste persuadé que pour un développeur, l'intérêt d'un Framework est de figurer sur son CV car c'est un critère de sélection. Je crois en leur utilité, mais je suis aussi déçu et frustré de voir bien souvent avec quelle qualité médiocre ils sont utilisés, souvent vendus "pour vendre du framework car techno moderne à la mode"

Pour le premier point, c'est logique que la boite vende ce qu'elle sait faire. Peu de sociétés ont les ressources humaines et financière pour adopter un nouvel outil qui ne servira que sur un projet et qui est plus adapté d'environ un cheveu et demi que celui d'à côté au projet.

L'inconvénient "Convention over Configuration" n'est valable que quand les développeurs ne sont pas assez rigoureux pour respecter les conventions, auquel cas, il faut probablement changer de développeur. La valeur première du FW est méthodologique. L'orgueil est malheureusement une caractéristique humaine assez répandue et beaucoup de gens ont du mal à suivre une consigne simple. Je peux rédiger des pages et des pages de normes d'écriture de code, ce sera toujours moins efficace que d'avoir un système qui implique que le code mal écrit ne fonctionne pas.

En tout cas, pour moi, le développeur ou l'architecte ne doit être créatif que quand une solution qui représente un compromis raisonnable temps/gain n'existe pas.

Quand on fait un Facebook ou un Google, ok. Quand on fait un site dynamique, une boutique ou une petite gesco, des solutions existent déjà.

[pseudocode]

Tous ce que je sais c'est qu'il faut respecter le choix de chacun, un developpeur qui n'utilise pas un framework ne veut pas dire que c'est un amateur bien au contraire je dis bien au contraire parceque 90% des gens qui utilisent les framework sont des amateurs et ne connaissent même le php avant d'apprendre à utiliser un framework, c'est pas moi qui le dit cherchez sur le net bref chacun fait ce qu'il veut mais l'utilisation ou non d'un framework ne veux absolument rien dire

Certes, 90% des gens utilisant un framework usuel ne seraient pas capable de développer leur propre framework. Tout comme 90% des gens utilisant gcc ne seraient pas capable d'écrire leur propre compilateur.

Mais est-ce que ca prouve pour autant que ces programmeurs sont mauvais dans leur métier ?

Développeur d'application et développeur de framework (ou autres librairies techniques), ce sont deux choses différentes. Les finalités des deux développements sont également différents : ergonomie, sécurité, évolutivité, maintenabilité, performance, fiabilité, adaptabilité, .... Le fonctionnel ne fait pas tout.

Pour info : je bosse avec mon propre framework depuis des années et jamais eu de prob (ni de sécurité, ni de fonctionnement) et au moins je sais à 100% ce qu'il y a sous le capot et ça c'est une chose très importante pour un développeur sensé et non une machine à coder, il faut arrêter les pensés genre wawouuu ceux qui ont fait symphony c'est des craques et tout et nous on peut pas faire mieux

La force d'un framework ce n'est pas la "puissance" des fonctions proposées ou la "complexité" du code. C'est la faculté de structurer efficacement le développement d'une application. Cette efficacité peut se quantifier en terme de productivité, de coût, de pérennité, ou autre. C'est pour cela qu'il est important de bien choisir un framework en fonction de ses propres objectifs projet.

[turcotm]

Certes, 90% des gens utilisant un framework usuel ne seraient pas capable de développer leur propre framework. Tout comme 90% des gens utilisant gcc ne seraient pas capable d'écrire leur propre compilateur.

Mais est-ce que ca prouve pour autant que ces programmeurs sont mauvais dans leur métier ?

Généralement, les gens qui font leur propre FW sont ceux qui ont une certaine expérience. Un FW c'est un coffre a outil. L'apprentie plombier a un petit coffre alors que le sénior a généralement un gros coffre.

[Michel Rotta]

Quelqu'un m'a dit plus haut que les Framework c'est sécurisé, c'est opensource il n y a aucune porte dérobé...etc. sous prétexte qu'il y a une grosse communauté derrière et que lui même a vérifié waw impressionné

Mdr ! Oui, c'est moi.

Et je t'ai mis au défi de me cité une porte dérobée dans un des grands framework du marché. Défi relevé vu que tu as trouvé une porte dérobée dans ... bsd qui est un système d'exploitation. Caramba, encore raté !

Maintenant, comparer le code d'un système d'exploitation à celui d'un framework, c'est un peu comme considérer que le mec qui bricole sa tondeuse électrique est capable de réparer une centrale nucléaire. Totalement hors sujet.

---------------------------

Généralement, les gens qui font leur propre FW sont ceux qui ont une certaine expérience. Un FW c'est un coffre a outil. L'apprentie plombier a un petit coffre alors que le sénior a généralement un gros coffre.

J'aurais tendance à dire que ceux qui ont de l'expérience auraient plutôt tendance à utiliser du travail bien fait et déjà éprouvé plutôt que de ce lancer dans une entreprise hasardeuse de création d'un framework empirique maison. Même si, dans de rares occasions, cela peu marcher, c'est plutôt un truc destiné à ce casser la gueule à court terme.

-----------------------------

Accessoirement, avoir sur son CV la connaissance d'un (ou plusieurs) framework est un plus actuellement dans le cadre de la recherche d'un nouveau poste ou contrat de service.


Oui, de plus en plus de clients souhaitent uniformiser la maintenance de leurs application. Ils imaginent que passer par un framework va standardiser les méthodes de développement. Imagines parce que, hélas, il reste plein de méthode plus ou moins bonnes (voir très mauvaises) d'utiliser un même framework et que deux personnes différentes peuvent produire des codes totalements différent, à partir d'un même framework et pour un même projet.

[stealth35]

Maintenant, comparer le code d'un système d'exploitation à celui d'un framework, c'est un peu comme considérer que le mec qui bricole sa tondeuse électrique est capable de réparer une centrale nucléaire. Totalement hors sujet.

j'en connais un :

[syber]

Pour info : je bosse avec mon propre framework depuis des années et jamais eu de prob (ni de sécurité, ni de fonctionnement) et au moins je sais à 100% ce qu'il y a sous le capot et ça c'est une chose très importante pour un développeur sensé et non une machine à coder, il faut arrêter les pensés genre wawouuu ceux qui ont fait symphony c'est des craques et tout et nous on peut pas faire mieux

22 ans et cela fait des années que tu bosses sur ton propre framework.

Maintenant si tu as beaucoup d'énergie mets la à profit de la communauté. La même qui te fournit ton langage PHP.

Ton framework est il sur des applications sensibles. J'ai des sites que personne visite. Dès lors je n'ai pas grand risque de sécurité. Maintenant si tu es si fier de ton framework rend le public et à la critique de tous.

Pour info sur un framework PHP tu as le droit d'ouvrir le capot pour voir ce qu'il y a dedans. Ce ne sont pas des boîtes noires.

Dernière question tu as testé quoi comme framework. Et combien de temps as tu passé sur ces derniers pour le confronter à ton framework maison.

Pour comparaison, va expliquer à quelqu'un du BTP qu'il doit faire son béton à la pelle et pas à la bétonnière car il ne l'a pas crée. Tu risques de goûter à la pelle.

[turcotm]

J'aurais tendance à dire que ceux qui ont de l'expérience auraient plutôt tendance à utiliser du travail bien fait et déjà éprouvé plutôt que de ce lancer dans une entreprise hasardeuse de création d'un framework empirique maison. Même si, dans de rares occasions, cela peu marcher, c'est plutôt un truc destiné à ce casser la gueule à court terme.

Je suis d'accord en générale avec ton point de vue. Je ne partage quand même pas celui de la qualification d'un FW. La première fois que j'ai entendu parler de FW, ce doit être en 1995 ou 96. A l'époque nous parlions de FW pour ColdFusion une vedette payante qui n’a pas durée. Trop couteux à mettre en place.

Contrairement a la définition de wikipedia qui en est une parmi tant d'autre, nous devrions voir un FW comme un coffre a outil ou si tu préfères un portfolio de nos réalisations qui sont réutilisable.

Pour faire simple, moi je considère que tout ce qui est réutilisable, fait partie de sont FW perso.

Pour ce qui est des FW communautaire, je suis ni chaud ni froid.

[jonoz]

Je suis d'accord en générale avec ton point de vue. Je ne partage quand même pas celui de la qualification d'un FW. La première fois que j'ai entendu parler de FW, ce doit être en 1995 ou 96. A l'époque nous parlions de FW pour ColdFusion une vedette payante qui n’a pas durée. Trop couteux à mettre en place.

Contrairement a la définition de wikipedia qui en est une parmi tant d'autre, nous devrions voir un FW comme un coffre a outil ou si tu préfères un portfolio de nos réalisations qui sont réutilisable.

Pour faire simple, moi je considère que tout ce qui est réutilisable, fait partie de sont FW perso.

Pour ce qui est des FW communautaire, je suis ni chaud ni froid.

Eh bien s'il n'y a pas de composante architecturale et méthodologique, c'est juste une library / un helper. C'est un aspect du FW.

[turcotm]

Eh bien s'il n'y a pas de composante architecturale et méthodologique, c'est juste une library / un helper. C'est un aspect du FW.

A la base, c'est quoi un FW?

Hé ben un ensemble de librairie. Et les composantes archi et les autres trucs? Ce sont des librairies.

Si tu boss avec un FW qui fait tout et même la vaisselle et le lavage des chaussettes, c'est le droit de celui qui l'utilise.

[GaapTap]

est il possible de voir autant de généralisation, d'affirmation de soi sur de fausses vérités ???

aux détracteurs des gens qui disent que ceux qui utilisent des frameworks ne savent pas développer, je vous répondrais que c'est après de longues années comme vous a tout se faire que l'on a décidé d'opter pour une nouvelle orientation qui semble meilleur pour nous et mauvaise pour vous.

Mais arrêtez de dénigrer les uns ou les autres, le monde est fait de différence de choix d'algorythme et de choix technologique pour pouvoir contenter tout le monde sans se cracher dessus....impressionnant

[jonoz]

A la base, c'est quoi un FW?

Hé ben un ensemble de librairie. Et les composantes archi et les autres trucs? Ce sont des librairies.

Si tu boss avec un FW qui fait tout et même la vaisselle et le lavage des chaussettes, c'est le droit de celui qui l'utilise.

J'ai un peu l'impression de pinailler mais comme ça porte sur le fondement même du débat...

Un FW n'est en rien un ensemble de libraries. C'est un cadre de travail structuré qui peut (ou pas, quand un framework est purement méthodologique tel que Scrum) comporter des libraries/utilitaires.

Par exemple, PhpMailer, Fpdf ou gd sont des libraries (bibliothèques de fonctions utilitaires qui répondent à des besoins très spécifiques sans organiser pour autant leur relation avec les autres agents externes, laquelle relation est laissée à la charge de leur utilisateur).

Autre exemple : tu peux inclure dans ton appli java des libs, ça n'aura pas du tout le même impact sur l'archtecture et le processus de développement que si tu mets en place le FW Spring-MVC.

[jonoz]

Le problème de fond, c'est que l'article ne propose pas d'arguments autres que :
- l'utilisation d'un framework implique une méconnaissance du langage
- elle rend le développeur paresseux et lui donne moins de contrôle sur son travail

Les arguments qui lui ont été opposés sont :
- l'utilisation d'un FW rationalise le processus de développement
- elle augmente la qualité et la fiabilité du code produit
- elle permet de tirer partie de l'expérience d'autres pour notamment gagner du temps
- elle permet de se concentrer sur la conception du modèle de données et les aspects métiers
- elle simplifie le travail en équipe

Je ne pense pas qu'il soit nécessaire d'expliciter les points ci-dessus car ils sont mesurables, ils s'agit de faits (et non de suppositions) et n'importe quel utilisateur de FW pourra te le dire.

Un projet échoue parce qu'il a mal été spécifié, parce qu'il a mal été managé, parce que la charge de travail a été mal évaluée, parce que les développeurs n'ont pas fait le boulot consciencieusement... la liste peut s'allonger à l'infini, mais on n'y verra pas apparaitre "parce que le FW est pourri", parce que si c'était le cas, ça voudrait qu'un autre élément de la chaîne de production cherche à masquer ses déficiences.

Après, un FW ne rend pas un développeur plus consciencieux ou plus rigoureux (bien que celà l'aide sans doute sur ce point au moins un petit peu).

Honnêtement, on parle d'informatique à vocation professionnelle, donc d'impératifs de rentabilité et de productivité. Pouvoir produire du code robuste en un minimum de temps est donc dans ce cas un gros avantage. Il faut bien imaginer que si l'adoption des FW a été si forte et rapide, c'est parce qu'il répondent à un réel besoin des pros. L'effet "hype" est en fait un phénomène négligeable, mon client se moque de savoir comment je fais tant que je lui livre un outil fiable, qui réponde à son besoin et qui ne le lie pas trop à moi; du coup, lui dire que je fais du Symfony ne m'aide absolument pas à lui faire signer le bon de commande.

Du coup, après moult projets dont la bonne tenue à moyen terme ne s'est pas toujours passé comme nous l'espérions, un certain nombre de professionnels ont adopté des outils qui permettent de simplifier les choses.

C'est une conséquence logique du retour d'expérience, qui permet de limiter l'effet que nous connaissons tous : une fois le projet livré, on pense à toutes les meilleures façons dont on aurait pu faire tel ou tel truc. Ce phénomène est souvent encore présent mais dans une moindre mesure. Pour comprendre de quoi il s'agit, il faut juste le vivre.

Maintenant, en ce qui concerne la connaissance du langage, le langage n'est qu'un support. N'importe quel singe savant qui connait par coeur toutes les subtilités d'une obscure fonction ne vaut rien en tant que professionnel si on le compare à quelqu'un qui aura passé moins de temps à lire la doc, au profit de l'acquisition de connaissances en architecture, méthode et génie logiciel.

Et je vais insister un peu sur ce dernier point en affirmant que quiconque n'a pas un certain niveau de connaissance en ce domaine ne pourra pas utiliser un FW du tout de façon basique.

Du coup, le framework comme le développement à la paluche mettent tous les deux le développeur face à ses compétences et ses responsabilités. Un mauvais développeur le restera quelle que soit sa façon de travailler.

Si par contre le mec sait concevoir, connait les patterns et algos classiques, alors peu m'importe qu'il aille voir dans la doc de php comment marche echo.