Discussion :

[openaccess]

L'article pose un point de vue de développeur....

Or dans la majorité des cas le développeur travaille pour un client final... C'est ça qu'il faut voir pour se positionner "pour ou contre".

Quand un client fait développer un site par un prestataire, si ce dernier n'a pas utilisé de framework répandu (Zend, symfony, cakePHP, etc.), bonjour les dégâts si le client souhaite un jour changer de prestataire...

J'ai eu plusieurs clients pour qui j'ai du reprendre le développement du site qui avait été développé sans CMS ou sans framework. Quand le site est petit et simple, pas de soucis. Quand le site est gros => usine à gaz...

On passe plus de temps à comprendre la logique du développeur (et a corriger les erreurs) qu'à apprendre l'utilisation d'un framework..

Le cout de la prestation finale est forcement plus élevé...

Codez un site sans framework ou sans CMS c'est presque prendre en otage le client.

Ensuite pour un projet perso, c'est effectivement au choix...

Au niveau des délais aussi c'est très différent.. Utiliser un framework fait gagner un temps énorme (et donc de l'argent)...

Le temps nécessaire à son apprentissage est beaucoup plus que le développement de A à Z de mon propre code.

C'est faux ! Apprendre à utiliser un framework n'est pas si long... La seule chose c'est qu'il faut connaitre l'architecture MVC et la programmation objet. Ensuite il suffit de comprendre la logique interne au framework... Ca prend du temps effectivement, mais rien comparé au temps gagné à utiliser un framework sur un gros projet.

[squelos]

Un framework c'est quoi en fait ? C'est un outil. Rien n'empeche de réaliser son propre outil non ? Certaines démarches vont dans ce sens d'ailleurs : on commencer par créer l'outil.

Donc l'utilisation de framework ne me parait pas une mauvaise chose. Mais apres je ne suis pas un développeur web ...

[stealth35]

Mais apres je ne suis pas un développeur web ...

donc tu dis un truc sans connaissance de cause ?

[Camille_B]

donc tu dis un truc sans connaissance de cause ?

La problématique des framework ne recouvre pas que le dev web.

[camus3]

Un framework c'est quoi en fait ? C'est un outil. Rien n'empeche de réaliser son propre outil non ? Certaines démarches vont dans ce sens d'ailleurs : on commencer par créer l'outil.

La question est de savoir si il y a déjà des outils meilleurs que ceux que tu peux développer toi même. un framework avec une communauté de 500 dev actifs sera meilleurs que ta solution perso , à part si tu es un génie ( sans doute hein).

La problématique des framework ne recouvre pas que le dev web.

Sauf que le sujet ici est bien entendu l'utilisation de frameworks php donc de développement web.

De toute façon , la meilleurs façon d'apprendre est d'aller mettre son nez dans le code des autres. Zend ou Symfony ont une architecture très complexe , ce qui les rend intéressant à étudier.

[stealth35]

La problématique des framework ne recouvre pas que le dev web.

peu importe, tout dev sachant que la spécialisation vient surtout a la fin, sait que y'a des framework dans beaucoup de langage, le probleme de la "spécialité web" c'est qu'il y'a énormément d'amateurisme, et c'est dur de bossé avec ca, des mec qui touche pas mal, qui sois diplômé et autodidacte expert, c'est pas eu qu'on des problèmes sur le forum, c'est ceux qui improvisent framework ou pas ?
Quand je vois que l'auteur a 15 ans (j'ai vu vite fais je sais pas si c'est une blague ou pas) même si moi aussi je faisais de la prog pour les copains et compagnie, bossé en entreprise en tant que développeur ca na rien a voir, on parle pas de fainéantise on pas d'industrialisation.
La prog c'est sympa y'a de quoi s'amusé, mais c'est un vrai métier aussi, c'est comme la cuisine, cuisiner pour 5 potes, et avoir un gastro de 150 couverts c'est pas la même chose, et les outils non plus.
De toute façon il suffis de lire les commentaire pour voir qui a de l'expérience et qui n'en a pas

[TekP@f]

My 2 cents ...

A ceux qui sont contre les frameworks :

Un framework, c'est quoi ? On peut le résumer à une super bibliothèque bien architecturée (si si).
Et vous, comme vous n'utilisez pas de framework, je suppose (j'en suis même sûr) que vous avez tout de même construits vos propres bibliothèques, avec vos propres habitudes, vos propres nomenclatures... pour être plus efficace.
Et quand vous vous lancez dans un nouveau projet, vous reprenez ces mêmes bibliothèques, ce même socle commun pour ne pas tout refaire.

Vous ne trouvez pas que ça ressemble étrangement à un framework également ? C'est juste qu'il n'a pas de nom

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

A ceux qui sont pour les frameworks :

Je pense que l'idée de l'article de base est de faire réagir sur certains comportements que peut engendrer l'utilisation excessive et idiote des frameworks. En gros, une mauvaise utilisation peut transformer des développeurs intelligents en vulgaires pousse-boutons s'ils ne sont pas assez curieux sur leur métier (mais ça, c'est inéluctable à mon avis, framework ou pas framework)

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

[laville]

Bonjour à vous,

Juste un petit mot pour faire un retour d'expérience sur l'implémentation d'un Framework en entreprise.

Pour moi, l'utilisation du Framework a permis à mon client de se prémunir du mauvais goût si je puis dire de certains développeurs qui aiment tout faire maison et eux même, à savoir :
- La couche d'accès aux bdd
- L'interface qui se veut commune quelque soit l'application
- La gestion des droits commune puisqu'effectuee via ldap
- La gestion de la session qui est faite maison..
- Etc

Aujourd'hui j'ai réalisé une lib dans le respect du Framework utilisé, la gestion des l'internationalisation et du Menu etc est standard... Et c'est pas de la flemme mais de la standardisation. On attend pas de voir s'exprimer le talent d'un developeur sur des points génériques mais plus sur des points technique à savoir la partie métier du site. C'est là que le développeur doit agir.

souvent les personnes réfractaires aux Framework sont les "puristes" et ceux qui ne savent pas proprement coder et n'arrivent donc pas à comprendre la philosophie du Framework. Si tu comprends sa philosophie tu peux implémenter la tienne

Mais qui dit Framework dit lourdeur et rigueur et pour ce qui est de la rigueur des fois ce serait pas plus Mal pour les débutants

Voilà mon avis sur le sujet.

[SlashEne]

Est ce qu'on devrait manger avec les main ou avec une fourchette ???
Ben ça dépends... peut être ni l'un ni l'autre car au japon c'est avec des baguettes.

Comment tu le sais ? ben tu utilises ta tête, oui celle que tu as et qui est censé comprendre ce que dit les "business people", leur faire cracher leur besoins, et les questionner jusqu'a ce que eux même sachent ce qu'ils veulent pour leur fournir un truc qui leur convient.

Est ce que le developpeur sera remplacé ? ben ça dépend du projet... ce dont je suis sur c'est qu'actuellement le gars qui me fait des couilles en or a un problème et que c'est moins cher de me payer que de trouver lui même la réponse.

Si je dois construire la réponse, on m'appellera développeur.
Si je dois lui proposer un produit déja fait, on m'appellera consultant.
Si je dois faire construire la solution par quelqu'un d'autre à cause d'un manque de connaissance technique requise de ma part, on m'appellera architecte.

Donc en clair, le métier de developpeur web ne disparaitra pas à cause des framework, il évoluera...

Aujourd'hui tu te poses la question d'utiliser PDO vs mysql_fetch ou je ne sais quoi ?
Demain tu te poseras la question d'utiliser une base de donnée relationnel ou pas... (multi dimensionnel ? graph ? Key-Value store distribué ? systeme de fichier distribué ?)

Le métier reste le même mais les questions que tu te poseras vont changer, et le plus souvent, vont augmenté et c'est ce qui te donne encore plus de valeur.

[Kelpan]

Désolé, j'ai pas tout lu...

Je ne suis pas d'accord avec l'auteur de l'article. (bien que je l'aurais été à une époque où j'étais plus jeune).

La réalité vient avec l'expérience professionnelle lorsque tu réalises qu'on te demande de la qualité en un minimum de temps.

Si tu prends en compte le nombre de projet à réaliser, la maintenance et surtout le turn-over de tes gars, tu peux pas te permettre que chacun code à sa façon.

Le framework te permet d'avoir une base commune de programmation et de mettre en place des normes de développement.

Je suis convaincu qu'il y a des gens comme toi qui peuvent faire des dev nickel sans passer par un framework. Mais t'imagines pas le bordel à la maintenance si on n'a pas de socle commun pour comprendre et déboguer les programmes.
C'est la faillite assuré.

C'est peut-être pas l'image que tu avais de la programmation, mais je t'assure que je prendrais pas un gars comme toi dans mon équipe, en tout cas.

Bonne continuation

[Paul TOTH]

j'ajoute ici un copier/coller de mon commentaire sur le site:

Je suis presque d’accord avec ton article, à ceci près qu’il n’est qu’une vision des choses.

Je m’explique, quand je rencontre un client qui veux un développement web en PHP, il m’expose sont projet, je lui expose ma solution et là généralement il me parle d’un framework qui devrait permettre de réaliser son projet.

Ma réponse est toujours la même : je suis développeur PHP et pas webmaster (terme qui ne veux rien dire au passage ). Il y a sans doute de très bons framework qui permettent de très belles réalisations, mais ce n’est pas mon métier. Si vous avez besoin d’un joomla ou d’un Synphony, vous trouverez des tas de gens qui maîtrisent ces outils, je leur laisse la place. Par contre si vous avez besoin d’une vraie compétence de développement, je suis votre homme.

Pourquoi je ne me mets pas à développer avec des framework ? tout simplement car ma compétence à un prix qui est incompatible avec eux Je ne vais pas apprendre à maîtriser un outil qui va faire baisser mon tarif pour résister à la concurrence. Je reste sur un tarif de développeur avec des missions de développement où la compétence à son importance.

De même sous Windows je développe avec Delphi et non .Net ou WinDev…il y a sans doute de la place pour tout le monde, j’ai choisi la mienne.

[OlivierZitouni]

Je ne suis pas dév mais je possède un site eCommerce, je vis de celui-là.

Pour les formulaires de contact, je n'ose imaginer ce que m'aurait couté ce que peux m'offrir un Wufoo.com et son iFrame à mettre en 10 secondes.

La différence : avoir un dév php qui devra créer ce formulaire et le modifier au fur et à mesure des besoins, ça m'aurait couté qqs milliers d'euros la première année.. alors qu'avec un framework, 10€/mois et très facile à faire.

Ce n'est pas tant le coût qui m'intéresse mais surtout la liberté de ne pas devoir passer par un dev php (cher et difficile à trouver un bon) et de pouvoir faire ça seul sans aucune connaissance technique..

ps : je sais bien que je donne l'impression d'ôter le pain de la bouche des devs avec cette opinion, mais je sais que vous êtes plus intelligent que cela..

[jonoz]

Ma réponse est toujours la même : je suis développeur PHP et pas webmaster (terme qui ne veux rien dire au passage ). Il y a sans doute de très bons framework qui permettent de très belles réalisations, mais ce n’est pas mon métier. Si vous avez besoin d’un joomla ou d’un Synphony, vous trouverez des tas de gens qui maîtrisent ces outils, je leur laisse la place. Par contre si vous avez besoin d’une vraie compétence de développement, je suis votre homme.

Pourquoi je ne me mets pas à développer avec des framework ? tout simplement car ma compétence à un prix qui est incompatible avec eux Je ne vais pas apprendre à maîtriser un outil qui va faire baisser mon tarif pour résister à la concurrence. Je reste sur un tarif de développeur avec des missions de développement où la compétence à son importance.

Pourquoi une application devrait-elle rapporter moins d'argent si on la développe avec un framework ? Quand je fais du Symfony le prix de jour ne baisse pas (le nombre de jours baisse, et encore, souvent je peux simplement prendre juste plus de temps pour le travail de spécification).

En réalité, votre attitude est plutôt de frimer devant votre client, et je suis sur que vous avez quinze bons arguments bien préparés s'il vous demande quel framework vous utilisez... En tout cas, ne pas utiliser de framework ce n'est surement pas être développeur. Au contraire, votre stratégie est d'essayer de vendre plus cher un livrable qui sera moins robuste et moins carré.

Méfiez-vous, les clients deviennent informés depuis quelques temps...et il n'est pas dit que votre compétence (qui est plus chère, en dépit de connaissances que vous avez en moins...puisque vous ne connaissez pas de fw) conserve son prix élevé très longtemps.

Enfin, mettre dans le même panier Joomla! et Symfony est une erreur de compréhension indigne de vos coûteuses mais néanmoins dispensables compétences.

[RunCodePhp]

j'ajoute ici un copier/coller de mon commentaire sur le site :

Si vous avez besoin d’un joomla ou d’un Synphony, vous trouverez des tas de gens qui maîtrisent ces outils, je leur laisse la place. Par contre si vous avez besoin d’une vraie compétence de développement, je suis votre homme

Il y a une grosse confusion à mon sens :
Joomla est un CMS (Content Managment System), donc un Soft clé en main pour faire de la gestion de contenu (rédactionnel en particulier).

Pour Symfony (et non Synphony), même si je ne connais pas (pas utiliser), est un FrameWork, tout comme Zend, CakePhp, etc, etc .., c'est donc juste un environnement de travail, théoriquement ça s'arrête là.
C'est avec ce genre d'outils qu'il sera possible de créer plus vite, un blog, un forum, un site e-commerce, gestion de contenu, du spécifique, etc, etc ...
Mais il va falloir quand même : Spécifier, concevoir et enfin programmer.

D'ailleurs, je doute qu'un de tes clients te demande Symfony, car il aura du mal à faire quoi que ce soit avec.

Bref, ça n'a rien avoir tout de même, non ?
Joomla est d'ailleurs basé de ZendFrameWork, sauf erreur.



@OlivierZitouni

Je ne suis pas dév mais je possède un site eCommerce, je vis de celui-là.

Ce n'est pas tant le coût qui m'intéresse mais surtout la liberté de ne pas devoir passer par un dev php (cher et difficile à trouver un bon) et de pouvoir faire ça seul sans aucune connaissance technique..

Même réponse que ci-dessus : Tu ne feras strictement rien avec un FrameWork si tu n'est pas développeur.

Tu fais une grosse confusion, un FrameWork n'est en rien un Soft clé main, et encore moins un site e-commerce, c'est un environnement de travail pour des développeurs, et rien que pour des développeurs.



Sérieux, c'est à croire que vous avez lu un article, être d'accord avec ces idées sans même savoir de quoi il était question.

Sur Wikipédia : http://fr.wikipedia.org/wiki/Framework
Et comme il s'agit de FrameWork en Php tout particulièrement : http://fr.wikipedia.org/wiki/Liste_de_frameworks_PHP

[the_kramp]

Alors, ce genre d'opinion : les framework c'est bien ou c'est mal. Je pense que ca n'a aucun intérêt.
La question qu'il faut se poser:
dans quel cas, qu'est ce que je vais utiliser?
une application avec une équipe de 10 dev ou un site web vitrine que je vais tout seul? quelle architecture ? quels besoins?
Les frameworks proposent une manière de travailler qui va permettre à une équipe de l'adopter en plus de réutiliser certains de ces composants.

En tous cas j'ai vu des projets de grosse envergure avec autant de conventions, de styles, de librairies qu'il y avait de développeur où un framework aurait été du pain bénit.
D'autre fois, une usine à gaz déployée pour faire ce qu'un script seul ferait en quelques lignes.
Et j'ai malheureusement aussi vu beaucoup de boites qui utilisent leur framework partout et surtout là où il n'est pas la meilleure technologie, voire qu'il n'est pas du tout adapté au projet.

Tout n'est pas aussi simple que c'est bien ou c'est mal.

[jonoz]

Tout n'est pas aussi simple que c'est bien ou c'est mal.

Bah en fait, les fw c'est le bien quand les développeurs connaissent déjà bien le langage et sont familiers avec les notions de POO, de design patterns (m'enfin s'ils sont salés en POO normalement, ils maîtrisent au moins les patterns du GoF).

Après, il faut savoir que Symfony par exemple a un coût de déploiement. Ca ne prend pas 200 ans à mettre en place, mais il faut le faire.

A noter que j'ai vu beaucoup plus d'usines à gaz dans le cadre de l'utilisation d'un fw maison (qui a en plus souvent le bon goût d'évoluer en cours de projet) que dans l'utilisation de Symfony là où un script de 50 lignes aurait suffi.

De manière générale, même si ce débat n'est pas des plus passionnants (notamment parce que le seul argument avancé par les anti-fw est la mauvaise foi, simplement dûe à une certaine méconnaissance du sujet), il a au moins le mérite (ou bien le tort...) de montrer le peu de professionnalisme qui règne dans le monde du web, où tout le monde s'improvise tout et n'importe quoi (ça vaut pour les développeurs mais aussi pour les chefs de projets, les architectes...) et prétend tout savoir sur tout. Demandez à n'importe quel ingénieur dans à peu près n'importe quel domaine s'il utilise un set d'outils techniques et méthodologiques destiné à cadrer son travail. S'il vous répond non, ne signez pas le contrat.

Et pour tout ceux qui se prétendent "vrais développeurs" parce qu'ils font tout à la paluche, dites-vous bien que n'importe quel autodidacte peut en quelques temps avoir une connaissance au moins égale si ce n'est supérieure à la vôtre sur le langage (surtout pour Php qui est quand même bien accessible). Ce qui fait d'eux des amateurs et de nous des professionnels est notre capacité à être productif et à savoir choisir nos outils, ainsi que notre capacité à fiabiliser les développements.

Pour terminer sur la confusion CMS/Framework, je suis d'accord avec RunCodePhp sur quasiment toute la ligne. Je nuancerai néanmoins la question de l'aspect clé en main du CMS. Un CMS c'est quand même un boulot certain à mettre en place, paramétrer, personnaliser...D'ailleurs, je n'ai aucun problème à installer un Drupal (qui est quand même nettement plus puissant que Joomla sur beaucoup de points) si c'est approprié au besoin de mon client (avec Drupal on peut même faire du web applicatif si le besoin n'est pas trop complexe).

En tout cas, on peut clairement dire qu'il FAUT utiliser un fw pour être un "vrai" développeur web parce que dans le cas du tout à la mimine, il n'y a aucune assurance minimale de qualité (pas de tests unitaires, une architecture logicielle souvent douteuse, des redondances...).

Par contre, il faut au minimum être formé ou s'auto-former sérieusement au fw que l'on veut utiliser, avoir une bonne maîtrise des concepts sur lesquels il se fonde et être capable de faire preuve de discernement (ex: un design pattern est surpuissant pour répondre à UN problème donné, si on l'emploie pour tenter de solutionner un autre problème, on risque de le voir se transformer en anti-pattern, plus nuisible que bénéfique). En gros, la performance doit primer dans tous les cas, mais un peu d'élégance ne fait pas de mal, et il se trouve que très souvent ces deux notions riment.


Enfin, j'aimerais juste évoquer une notion que je ne pense pas avoir vue sur ce thread : l'appropriation de l'outil. En fait, je ne peux pas vraiment dire que nous utilisons Symfony. Nous utilisons notre Symfony, dans le sens où nous réutilisons des helpers ou plugins que ma team a écrit d'un projet à l'autre.
Quand certaines contraintes méthodologiques du fw ne nous conviennent pas, nous nous en affranchissons, mais nous nous le permettons uniquement quand notre niveau de maîtrise de la partie concernée est suffisante. En somme, on se fait une sorte de fw perso sur la base de quelque chose de vraiment puissant et relativement complet.

Le danger vient des gens qui prennent tout pour argent comptant, qui ne s'interrogent pas sur leur façon de travailler et qui mettent les problèmes sur le dos des autres et/ou des outils (et malheureusement, dieu sait qu'ils sont quelques uns).

-------------------------------
Et comme je poste et je poste sur ce thread pour donner des avis qui peuvent sembler péremptoires, un aperçu de mes références :

-> 6 applis conséquentes en Symfony (durée projet >= 4 mois)
-> 7 applis conséquentes en JEE (durée projet >= 4 mois)
-> Une trentaine de sites sous Joomla! 1.0 et 1.5 (avec parfois du VirtueMart)
-> Une douzaine de sites sous Drupal
-> 3 ans d'admin système et réseau dans le public, le privé
-> Un an de Flex/JEE
-> Des dizaines d'applis/sites en php fait main
-> De l'architecture et du dimensionnement à gogo (mon pêché mignon)
-> De l'encadrement d'équipes de développement
-> Un Bac+5 en informatique, spécialité architecture et ingénierie web

[syber]

Pour avoir travaillé avec projets avec et sans frameworks, mon choix est très vite fait.

Si vous souhaitez reinventez la roue tous les jours, corrigés des bugs qui n'ont rien à voir avec la partie métier n'utilisez pas de frameworks.

La question ( mais cela a déjà été dit ) c'est quel framework.

Depuis que je travaille (+10ans dev php) j'ai pratiquement toujours travaillé en équipe. Mon objectif quand j'intègre quelqu'un dans mon équipe est de la faire coder comme le reste de l'équipe. Charte de nommage documentation algo ( si avec des relectures on y arrive ). Avoir l'impression que c'est vous qui avez écrit n'importe quelle ligne de code est très reposant. Je ne cherche pas à effacer l'individu. Mais du code ne doit pas être non plus un espace de liberté artistique où les développeurs peuvent laisser libre court à leur imagination. Pour cela la relecture de code est quand même quelque chose de très productifs. Mais reprendre le code de quelqu'un qui a autant d'expérience que vous n'est pas forcément évident. Le framework règle pas mal de solutions de ce côté. Il est plus facile de faire adhérer un développeur à du code qui vient de l'extérieur. Après il y a framework, librairies et bout de code spécialisé >>PDFLib, eZPdf, JpGraph, Artichow, PEAR, ZendFramework, Symphony<< Le framework apporte beaucoup de solutions. Méthodes de travail, organisation des fichiers. Je vais être dur avec les personnes qui sont contre les frameworks mais je pense que c'est par manque d'expérience qu'ils expriment dans ce sens. Il faut arrêter de voir le php comme un outil artisanal où l'on peut tout faire nous même et se projeter un peu plus loin sur l'objectif final. Produire une application en un minimum de temps, avec un minimum de bug et avec une facilité de maintenance et d'évolutions. Toujours se projeter un peu plus loin que la simple demande qui est faite.

PS pour moi c'est le Zend. Permet de facilement de migrer car il est possible de s'en servir autant en librairies qu'en framework. Passerelle facilitant entre les migration de projet.

[stailer]

@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, 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.

Enfin, mettre dans le même panier Joomla! et Symfony est une erreur de compréhension indigne de vos coûteuses mais néanmoins dispensables compétences.

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

@syber

PS pour moi c'est le Zend. Permet de facilement de migrer car il est possible de s'en servir autant en librairies qu'en framework. Passerelle facilitant entre les migration de projet.

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

[Patriarch24]

Je pense que ce qu'il faut condamner c'est "utiliser un framework pour utiliser un framework". C'est-à-dire sans qu'il s'agisse d'un choix réfléchi : il doit correspondre à des besoins d'architecture, de fonctionnalités etc. Beaucoup de gens disent qu'ils développent en PHP parce qu'ils connaissent Symfony. C'est simplement réducteur, car s'ils sont amenés à travailler avec Zend, il seront perdus ; c'est le fameux symptôme de la pensée unique. A mon avis, c'est dans ce sens qu'il faut prendre le sujet : ce ne sont pas les frameworks qui "sont le mal", mais l'utilisation qu'on en fait.

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.

Quand j'ai lu ça, j'ai bondi. Rien n'oblige personne à utiliser un framework. Après, il faut bien qu'il ait une direction, une philosophie. Celui qui n'y adhère pas ne l'utilise pas. Ceci étant, les frameworks "pros" sont développés en respectant de bonnes pratiques - que beaucoup feraient bien de suivre - sont testés et permettent de s'affranchir de la réinvention de la roue. Rien n'empêche que si on veut la réinventer, on peut (le problème c'est que ça coûte du temps, et qu'elle finira sûrement carrée ou à la limite ovale).

Certains arguent que le vrai développeur doit tout faire lui-même. Pourquoi pas, mais dans ce cas, il faut pousser le raisonnement plus loin et recoder toutes les fonctions des APIs standards (je sais on peut encore pousser plus loin). Et recommencer éternellement. Si certains trouvent un plaisir quelconque à recommencer sans cesse les mêmes choses, à s'arracher les cheveux sur des solutions techniques sans intérêt intellectuel (car déjà vu et revu), qu'ils fassent. Personnellement, je n'ai jamais rien trouvé de plus intéressant et épanouissant que d'essayer de trouver des solutions à mes problèmes d'architecture en analysant des frameworks (et pas que des frameworks web, croyez-moi je bosse en Java et il y a de quoi faire !). De manière à se concentrer sur l'essentiel in fine : l'implémentation des besoins du client, et non l'élaboration d'une solution technique.

Enfin, pour ceux qui aiment réinventer la roue, à leur sauce, je les invite à essayer de développer un framework. Il n'y a rien de plus gratifiant de rassembler une communauté autour d'un ensemble d'idées, même s'il ne s'agit pas de la philosophie de tout un peuple.

[vincent.mbg]

Bonjour à tous

Le temps n’est pas une excuse valable pour l’utilisation d’un framework.
S’il en est une pour vous, alors cela prouve tout l’intérêt que vous portez
à votre projet, c’est à dire aucun.

A bon ! Les clients auraient-ils tous leur temps pour être servie et cela à n'importe quel coût ?!

Que les développeurs soient déçus par la simplification de leur travail est une chose. Certes, il est plus plaisant intellectuellement de faire de l'assembleur et de gérer soie
même la totalité des ressource.

L'informatique étant une succession de couches d'abstractions et ne peut pas être différente sinon on serait encore tous à tisser les programmes avec des câbles dans des tore magnétique. Il faut accepter le fait qu'il arrive un moment où on a fait le tour des solutions et qu'il n'y a plus rien à inventer jusqu'à une certaine couche.

Aujourd'hui tout le monde accepte le C (Je pense) et personne (ou très peu) remet en question l'abstraction du langage machine qu'il nous offre. Les framework sont simplement les dernières couches d'abstraction (pour le moment) dans le développement web. Je trouve ça bizarre d'être contre.