Discussion :

[Michel Rotta]

Hé hé hé ! (rire bête sadique et méchant).

Avec symfony, il est possible de gérer, dans des cas extrêmes, du cache en html pure.

Le switch est alors effectué par apache, sans passé par le PHP.

Imaginons une url http://www.world.test/hello/world.html (type d'url que l'on peut trouver sous symfony). A la première exécution, la page n'existe pas. Donc on lance PHP, la page est générée et mise en cache, tel quel, sur le serveur.

Au deuxième passage, apache voit la page, il la retourne donc, sans lancer PHP.

Il est possible dans le framework d'effacer automatiquement cette page si l'on en change le contenu, partant du fait qu'elle soit modifiable.

Il est évident qu'il s'agit ici d'un comportement extrême, il est rare, dans une application, que toute une page et son layout soit statique dans le temps. Mais, après tout, comparer le temps d'exécution d'un Hello Work en PHP avec celui d'un framework est extrême aussi.

[Joker-eph]

Et comment tu gères l'invalidation de la page "cachée" ?

[gwinyam]

Au pif, le fait d'en modifier le contenu sert de déclencheur?

[Michel Rotta]

Soit c'est une vraie page statique, comme pour "Hello world" et elle ne change jamais...

Si non, gwinyam a raison, tu as un plugin qui le gère, si tu modifies la page, il efface le fichier dans le "cache". Si tu lis la page est que le fichier n'est pas caché, il crée la page en html dans le cache.

Que l'on soit bien d'accord, c'est un outil extrême, il est très rare que l'on ait à afficher une page avec un layout qui ne change pas, ou ne s'adapte pas au dernières news, ou à un calendrier ou ... Dans la vraie vie, je n'ai jamais utilisé.

[gilwath]

un framework est un cadre pour développer, un framework par exemple ne me diras pas comment doit être présenter et traité l'information, qui doit rester le cœur métier d'un développeur.

[HeadCoder]

J'ai commencé l'écriture du prochain article sur ce sujet (bref une suite quoi). Si jamais vous avez une suggestion de point à aborder, n'hésitez pas (que ce soit pour ou contre le framework). Et non, ce sujet n'est pas tabou!

[yann2]

Framework ? Pensée unique ?

Bah oui, c'est pour ça qu'on utilise un cadre de travail... c'est marrant quand même de faire passer un avantage d'un framework pour un inconvénient Surtout que l'expression utilisée est une signification de ce que tu discrédites. Framework == Cadre de travail donc OUI ça impose des choses mais, c'est voulu !

Sinon pour 15 ans tu as l'air de connaître pas mal de choses et tu as largement le temps de changer d'avis
Tu relèves notamment un point intéressant en disant que chaque projet est différent et a son propre contexte. La plupart des développeurs de frameworks en sont conscient et tentent de régler ce problème en trouvant un juste milieu entre customisation et simplicité d'utilisation. (sans oublier que parfois l'utilisation de tel ou tel framework n'est peut être pas adapté )

bon maintenant je vais lire le débat...

[HeadCoder]

Framework ? Pensée unique ?

Bah oui, c'est pour ça qu'on utilise un cadre de travail... c'est marrant quand même de faire passer un avantage d'un framework pour un inconvénient Surtout que l'expression utilisée est une signification de ce que tu discrédites. Framework == Cadre de travail donc OUI ça impose des choses mais, c'est voulu !

Sinon pour 15 ans tu as l'air de connaître pas mal de choses et tu as largement le temps de changer d'avis
Tu relèves notamment un point intéressant en disant que chaque projet est différent et a son propre contexte. La plupart des développeurs de frameworks en sont conscient et tentent de régler ce problème en trouvant un juste milieu entre customisation et simplicité d'utilisation. (sans oublier que parfois l'utilisation de tel ou tel framework n'est peut être pas adapté )

bon maintenant je vais lire le débat...

Sûrement que je vais changer d'avis mais jusqu'à présent, personne ne m'a convaincu ;-) .
Ce point est important, mais le framework s'en fout lui...

Pour ceux que ça intéresse, un des créateurs du framework Lithium m'a donné un lien vers sa conférence sur Lithium. Lui aussi est d'avis que "Framework sucks" (il le dit mot pour mot). Cette diapositive peut sûrement amener d'autres points importants. La voici: [ame="http://www.slideshare.net/nateabele/lithium-the-framework-for-people-who-hate-frameworks-tokyo-edition"]Lithium: The Framework for People Who Hate Frameworks, Tokyo Edition@@AMEPARAM@@ssplayer2.swf?doc=tokyo-lithium-101012172805-phpapp01&stripped_title=lithium-the-framework-for-people-who-hate-frameworks-tokyo-edition@@AMEPARAM@@tokyo-lithium-101012172805-phpapp01@@AMEPARAM@@lithium-the-framework-for-people-who-hate-frameworks-tokyo-edition[/ame] .

[Benjamin Delespierre]

Lithium me plait. Je vais aller y jeter un oeil. Tu le pratiques ? Si oui depuis combien de temps ?

Je cherchais justement un framework avec une grande flexibilité. J'arrivais pas à me décider entre Symphony et Zend, voilà une autre alternative... J'ai retrouvé dans ces slides certains concepts que j'ai mis en place dans mes outils mais Lithium à l'air (à première vue) plus structuré que ma boite à outils: j'ai des contraintes / dépendances / couplages trop forts et je n'arrive plus à arrondir les angles.

Tu connais d'autres articles / liens qui réfèrent à ce projet ?

Une remarque, j'ai failli arrêter la lecture dès les premières slides à cause de leur bla bla évangéliste "les framework bark bark etc."

[HeadCoder]

Lithium me plait. Je vais aller y jeter un oeil. Tu le pratiques ? Si oui depuis combien de temps ?

Je cherchais justement un framework avec une grande flexibilité. J'arrivais pas à me décider entre Symphony et Zend, voilà une autre alternative... J'ai retrouvé dans ces slides certains concepts que j'ai mis en place dans mes outils mais Lithium à l'air (à première vue) plus structuré que ma boite à outils: j'ai des contraintes / dépendances / couplages trop forts et je n'arrive plus à arrondir les angles.

Tu connais d'autres articles / liens qui réfèrent à ce projet ?

Une remarque, j'ai failli arrêter la lecture dès les premières slides à cause de leur bla bla évangéliste "les framework bark bark etc."

Bien-sûr que non que je ne l'utilise pas (ça ferait tout un comble).

Non, je n'ai eu ce lien que par le biais d'un de ses développeurs que j'ai rencontré à une conférence.

Leur blah blah est tout de même réaliste ;-) !

[Michel Rotta]

Je vais en rester sur le même point. Pousser ton raisonnement (qui est intéressant sous certains aspect) à l'extrême revient à supprimer tous les langages de développement.

Je vais juste te mettre devant un dilemme. Dans la version 5.3 de PHP qui est un langage et non un framework, ont été inclue certaines avancée qui était auparavant fournies par des frameworks (zend framework ici). Ce qui me pose des problèmes. Doit on les ignorer au motif qu'elles sont issues d'un framewok ? Doit-on les utiliser parce qu'elles font partie d'un langage et donc sont utilisable ? Mais dans ce cas, pourquoi pouvoir les utiliser maintenant alors qu'il y a un an elles n'en étaient pas dignes ?


Un autre exemple, le PDO. C'est une couche d'abstraction qui est maintenant largement utilisée mais récente dans PHP. Auparavant on utilisait (Oh horreur) un framework qui le faisait notamment Créol, a quel moment étions nous dans l'erreur ? En utilisant un framework pour accéder et sécuriser les données ? Maintenant en utilisant PDO alors qu'il reste possible de s'en passer ?


De nombreuses évolutions de PHP sont ainsi dues à l'intégration de fonctionnalités développées dans des framework dans un premier temps. Doit-on encore utiliser un tel langage qui inclus dans son sains la représentation du diable ?

[HeadCoder]

Je vais en rester sur le même point. Pousser ton raisonnement (qui est intéressant sous certains aspect) à l'extrême revient à supprimer tous les langages de développement.

Si je n'inclue pas Ruby dans mon raisonnement, c'est qu'on peut difficilement faire autrement sans Ruby On Rails. Idem pour le C et le C++ (et là ça ne se discute pas: essaie de créer une interface utilisateur sans Qt ou GTK...) , Java, et les autres. Le JavaScript pourrait être inclus dans mon raisonnement. D'après ce qu'on m'a dit, on peut réaliser ce que jQuery nous propose sans jQuery mais ça reste tout aussi compliqué. Voilà pourquoi je ne parle que de PHP. C'est le langage que je connais le mieux, et tout ce qu'un framework propose (ou tout en partie), on peut le réaliser sans celui-ci (et sans trop de difficulté).
Une partie de mon raisonnement peut tout de même s'adresser à tous les autres langages (pensée unique, mauvais aspects au niveau de la créativité et de la réflexion, etc) mais sera vite étouffée par l'aspect technique.

Je vais juste te mettre devant un dilemme. Dans la version 5.3 de PHP qui est un langage et non un framework, ont été inclue certaines avancée qui était auparavant fournies par des frameworks (zend framework ici). Ce qui me pose des problèmes. Doit on les ignorer au motif qu'elles sont issues d'un framewok ? Doit-on les utiliser parce qu'elles font partie d'un langage et donc sont utilisable ? Mais dans ce cas, pourquoi pouvoir les utiliser maintenant alors qu'il y a un an elles n'en étaient pas dignes ?


Un autre exemple, le PDO. C'est une couche d'abstraction qui est maintenant largement utilisée mais récente dans PHP. Auparavant on utilisait (Oh horreur) un framework qui le faisait notamment Créol, a quel moment étions nous dans l'erreur ? En utilisant un framework pour accéder et sécuriser les données ? Maintenant en utilisant PDO alors qu'il reste possible de s'en passer ?

De nombreuses évolutions de PHP sont ainsi dues à l'intégration de fonctionnalités développées dans des framework dans un premier temps. Doit-on encore utiliser un tel langage qui inclus dans son sains la représentation du diable ?

Ouais, tout un dilemme. Je n'ai pas de réponse toute mâchée pour te répondre. En revanche, ceci pourrait peut-être nous éclairer:
Supposons que nous interprêtons ces avancées comme des réponses à des questions. Alors posons cette question:
"Est-ce qu'un framework induit de la pensée unique ou est-ce qu'il apporte une réponse standard à une question standard?"
Si cette réponse standard peut être appliquée sans la pensée unique, alors je ne vois pas pourquoi il ne faudrait pas appliquer la réponse (l'avancée offerte par le framework).

[RunCodePhp]

Salut

Ce qui me semble vraiment nécessaire, ce serait de faire ce que tous font, et cela dans tout secteurs ou domaines confondus :
C'est de faire un simple tableau et dresser la liste des avantages et inconvénients.
C'est le BABA quand on est fasse à un choix.

Toutes solutions ont des avantages et inconvénients, ça coule de source.

Il faudrait donc 2 tableaux.
Tableau 1 :
- Avantages et inconvénient de la réalisation de plusieurs projets sans FrameWork
- Tableau 2 : Avantages et inconvénient de la réalisation de plusieurs projets avec FrameWork (et le ou les FrameWork au besoin car il en existe plusieurs)


Toujours est il que lorsqu'on dresse cette fameuse liste et qu'on ignore les avantages, c'est qu'on tout simplement pas objectif, l'analyse ne vaudra donc pas un sous, ça ne tiendra la route un seconde.
Autant ne rien faire car personne ne se ralliera à la cause mal argumentée.


D'ailleurs, à aucun moment je n'ai vu ou reconnaitre les avantages que proposent l'usage d'un FrameWork.
De même que je n'est pas vu non plus les avantages ou inconvénients (ne serait ce majeur) de ne pas utiliser de FrameWork.
Tout ça dans un cadre professionnel bien sûr, donc en prenant compte que le temps c'est de l'argent, donc que les développeurs soient le plus productifs possible.
Aussi, il me semble aussi important de ce placer en tant que client fasse à l'achat d'une application Web : Le prix surtout.


Après, et c'est l'étape ultime : On regarde du quel coté penche la balance.
Ce dire en tout objectivité : Est ce que les avantages de telles ou telle solutions sont suffisantes pour l'adopter ?
Ou inversement : Est ce que les inconvénients de telle ou telle solution suffisant pour l'éliminer, ne pas l'adopter.


L'idée que ces FrameWork débouchent sur une sorte de pensée uniques, qui est quasi le seul argument (ou le principal) dans cette affaire, Ok, à mon avis beaucoup seront d'accords, on peu tous l'admettre ou le percevoir.
De même qu'on peu tous percevoir que l'usage des FrameWork peu déboucher sur une mauvaise connaissance du langage Php, ou d'oublier les fondamentaux avec le temps (encore que là, c'est pas dit car un FrameWork ne fait pas tout, il faudra quand même programmer l'application).

Mais la vrai question : Est ce suffisamment fort comme argument pour décider de ne pas les utiliser ?

Bref ... il faut une balance, et peser, non ?
Débattre sur une seule idée, ou 2, pourquoi pas, mais c'est maigre à mon sens.



Toujours est il que de mon coté, je me pose depuis pas mal de temps cette question, et à mon sens un FrameWork apporte tellement d'avantages qu'à eux seuls suffisent pour aller dans ce sens.
Les arguments que tu avances ne pèsent malheureusement pas assez lourd face à ce choix, et je pense que tu auras énormément de mal à lutter contre.


L'argument principal qu'est "la pensée unique", ça déjà été évoqué : C'est justement ceci qui est recherché, tout ça dans le but principal qui est d'éviter de coder 100 fois la même chose.

En tout cas, ne pas voir, ou percevoir que la plus grande majorité (la généralité) des projets sur le Web ont tous exactement les même problèmes à résoudre, à gérer, de même qu'ils ont tous des fonctionnalités communes (de base j'entends) est une erreur à mon sens.
Il n'y a rien de plus normal que de vouloir rationaliser un code, ne serait ce que de base tel un FrameWork pour éviter de re-coder la même chose.


On retrouve tout ça partout, et pas seulement dans l'informatique ou Php.


Quand on achète un balai pour balayer la poussière, l'idée principale est exactement la même.
C'est long et pénible de devoir ramasser chaque grain de poussière dans sa maison, non ?
Donc fabriquer un balai fera gagner du temps et des efforts en moins.

Ensuite, qu'un industriel ait l'idée d'en fabriquer à la chaine par million, est ce si marginal que ça ?

Puis en tant que client, (car il est important aussi de ce placer en tant que client), est ce si marginal que ça de vouloir payer moins cher le balai industriel dans la grande surface que celui fabriquer par un artisan ?

[HeadCoder]

J'ai finit de rédiger ma réponse (globale) à cette discussion. Elle se trouve ici -> http://www.coding-by-head.tk/pourquo...du-mal-suite-1

J'aimerais avoir votre avis sur quelques points que j'ai amené (c'est bien de tourner autour du pot, mais c'est mieux d'amener d'autres pots à suivre... ). Notamment sur la méthode de rémunération des développeurs.

Sur quoi nous basons-nous pour rémunérer un développeur? Je pense qu'on devrait rémunérer un développeur sur ses réflexions par apport aux problèmes qu'il tente de résoudre. C'est compliqué à expliquer. Je préfère vous citer le paragraphe:

Oui. Pourquoi ne pas changer l’élément qui détermine le salaire du développeur? Certes la question est énorme (et loin d’aboutir) mais tout de même pensable. Dans un premier temps, sur quoi se basons-nous pour rémunérer un développeur? Non je ne suis pas entrain de vous dire qu’il faut changer cela juste pour le plaisir. Je me demandais s’il serait possible de juger un développeur sur la qualité de ses solutions et de ses réflexions apportées sur les problèmes et les situations sur lesquels il doit travailler. Oui, je possède une approche beaucoup plus axée sur l’abstrait et la pensée plutôt que par la pratique la technique. Je crois même que l’avenir devrait aller là.

Existe-il plusieurs techniques pour déterminer la rémunération d’un développeur?

Une autre petite idée, serait de spécialiser les frameworks. Créer un framework qui serait adapter pour un type de projet en particulier. Cela apporterait des avantages comme:

Cela serait beaucoup plus bénéfique (et rejoindrait l’idée de la diversification du développeur). Non vous ne serez pas contraints à utiliser plusieurs frameworks en même temps. Au contraire, vous utiliserez un framework qui est adapté pour votre type de projet et qui possède beaucoup plus d’émotions pour celui-ci.

C'est très farfelu je sais. Mais je suis jeune et j'aime apporter une vision pour un tant soit peu qu'elle relate une curiosité de mon cru.

Arrive-t-il qu'en entreprise, le développeur doive utiliser plus qu'un framework? Dans quelles circonstances, pourquoi?

Vous savez lorsqu'on a parlé des réalités de la finance ("Framework = gain de temps = gain d'argent", "la finance est ce qui nous fait vivre", etc). Comment cela s'exprime sur le terrain? Comment se manifestent les pressions exercées par l'administration ou les cadres pour que le développement se passe vite et fasse gagner le plus d'argent possible?

Merci de vos participations à cette discussion. Tout cela est très enrichissant.

[ke2007]

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

Dans ce cas il faut comprendre les employeurs de prendre déjà des gens avec des connaissances sur des frameworks et que les équipes de la boites utilisent ses dits frameworks.

C'est une perte de temps énorme pour une équipe et un employeur de prendre quelqu'un et de tout lui expliquer la façon de coder de l'équipe, en plus du fonctionnement et du rôle du projet.

Je pense que ce qui te dérange et le phénomène de mode qu'il y a autour et que beaucoup utilise des framework sans être capable de créer une appli web sans.

Mais malheureusement un framework offre très souvent des codes plus propre et plus performant que n'importe quel framework que tu auras créé.

Mais libre à toi de t'en faire un plus léger juste pour ton besoin, mais de tte façon quelque soit ce que tu codes il y en aura un derrière et c'est ridicule de réinventer la roue même si on le fait toujours un peu et si on l'a tous déjà fait.

[dourouc05]

Sur quoi nous basons-nous pour rémunérer un développeur? Je pense qu'on devrait rémunérer un développeur sur ses réflexions par apport aux problèmes qu'il tente de résoudre. C'est compliqué à expliquer. Je préfère vous citer le paragraphe:

On peut trouver un parallèle aisé dans la finance actuelle, notamment en termes de cotation des actions et autres bouses du marché d'échange. Actuellement, on ne cote ces entreprises que sur des critères financiers, uniquement financiers, que de la finance, à savoir si ça va rapporter plus ou moins de 10 % de rendement cette année, de 50 % l'année suivante, etc., sachant que ceux qui croient que la croissance peut être exponentielle indéfiniment sont soit cons, soit un économiste (c'est pas de moi mais je ne sais plus qui l'a dit, si quelqu'un arrive à retrouver...).

Un des projets européens serait de lancer un agence de cotation qui ne se base plus que sur ces critères bassement matériels, mais plutôt sur de vrais critères : respect de l'environnement, des travailleurs, etc. C'est exactement ce que tu proposes mais à une autre échelle et dans un autre monde. Inutile de dire que, à présent, rien ne s'est fait... même si ces agences de cotation sont un peu plus qu'un peu à l'origine de la crise financière de 2008.

Un parallèle ? Actuellement, certains devs sont payés sur leur rendement, ce qu'ils codent et qui semble fonctionner. Tu proposes, fier européen, de transgresser ce fonctionnement et d'aller vers un mieux collectif : du beau code qu'on peut maintenir, notamment, donc moins à l'origine de bogues car tout quidam (ou presque) peut le comprendre. Mais, un seul symbole dirigeant le monde (oui, celui-là même qui sert pour déclarer des variables en Perl comme en PHP), ce n'est qu'une utopie... pour le moment.

[bubulemaster]

Finalement après avoir lu presque tout.
Le framework c'est bien pour les gens auquels ça convient et pas bien au autre personne.
En fait, j'ai l'impression que finalement peut importe la réalité (FMK bien/pas bien), c'est plutôt ce qu'on en ressent.

Pour ma part, j'ai commencé à développer un projet sans framework PHP et je me suis rendu compte que ça me simplifirait la vie. Du coup, il y a tellement de framework que je m'en suis développé un à moi.

Après, je pense que les frameworks c'est comme les pièces Renault, ça va pas sur des Citroën. Un framework répond à un besoin. Mais faut pas s'obliger à l'utiliser.

C'est juste que si on utilise un framework, il faut connaitre quand même le fonctionnement de PHP et le fonctionnement du framework (et oui dès fois je m'apperçois que j'ai oublié comment fonctionne mon framework du coup je perds du temps )

Une chose est significative, c'est qu'à voir le nombre de framework, les gens ne se laissent pas dicter leur pensée.

[Invité]

La ou l'auteur se trompe et donc n'a du jamais utiliser un framework dans un projet : c'est que le framework ne fait rien ! (en tout cas rien qui nous concerne). J'ai vraiment envie de savoir sur quels genre de projet l'auteur a travaillé avec un framework et sans (je parle pas de framework maison, je dit bien sans framework du tout).

Un framework web c'est ridicule : un peu d'url rewriting, cache, redirection de requete vers des appels methode,, des api utilitaire (accès en base, lecture d'xml, soap etc...), de la sécu... Mais en gros que des choses que de dans tout les cas tu va faire toi même avec des chances de te tromper, de mélanger tes classes ... un framework va t'obliger a une certaine rigueur, a mettre les choses dans les bonnes cases.

De plus , la plupart du temps faut mettre en place des "facade" entre ton code métier et le framework, comme ça ton code n'en dépends pas, et tu peux migrer si besoin est ou réutiliser sur d'autre projet avec d'autre framework.

Quand dans mon système je crée une nouvelle tarification, j'implémente notre algo métier et c'est moi qui le fait ! Pourquoi ? Ben parce que c'est mon boulot !

Mon boulot ? Implémenter des demande métier de mon patron

Mon boulot ? Certainement pas faire des classes utilitaire déjà fait/debuggé/utilisée.


Quant à l'argument : "Ne pas en utiliser quand on est débutant" je le transformerai en "ne pas utiliser un outil quand on sait pas ce qu'il fait", et "ne pas utiliser un outil qui un jour a bien servi pour régler tout mes problèmes" (a part pour la bière mais c'est un autre débat)

Et puis le "effet de mode", dans ces cas la on peut le dire sur tout "y'a un effet de mode sur les langages, sur l'internet, et même sur l'informatique, tout les recruteur veulent absolument que tu t'y connaissent en informatique ! alors qu'on est es artistes !!"

Cet article ne mérite vraiment pas une news, mettez un article de quelqu'un qui a fait ses preuves, monté des gros projets, mais la c'est exagéré.

[jonoz]

En fait, l'utilité première d'un framework est de proposer une architecture applicative relativement fiable et efficace.

Par exemple, je connais MVC, j'ai déjà écrit un mini-ORM (générateur de classes + bibliothèque de validateurs), un moteur de template...mon petit framework en fait et pourtant aujourd'hui je fais du Symfony dans un métier où j'ai la chance de choisir mes technologies.

Pourquoi ? En premier lieu parce que conçu au fil du temps, sur une durée de plusieurs années, mon framework perso est relativement bordélique (bien que commenté et documenté). Ensuite parce qu'un outil utilisé par un grand nombre de développeurs est un gros plus : beaucoup de mes besoins classiques sont couverts. Enfin, parce qu'une équipe dédiée qui a fait ses preuves travaille à le faire évoluer.

En gros, ce n'est pas parce que je sais faire les choses que je devrais passer mon temps à les réinventer.

De manière générale, le niveau de langage et la pertinence de l'articlé lié ne sont malheureusement pas à la mesure de l'arrogance du dit texte.

En tant qu'utilisateur de framework (en Php mais aussi en JEE - Play notamment mais aussi EJB), je suis scandalisé quand je me fais traiter de fainéant par quelqu'un dont je n'ai pour le moment pas idée de l'expérience ou des compétences. Sur le fait d'avoir lu toutes les sources de l'outil, j'aimerais savoir combien de développeurs se sont bouquinés les sources de la stdlib, par exemple.

Par ailleurs, c'est extrêmement réducteur de parler de paresse intellectuelle.
Si être développeur c'est réécrire à l'infini des choses qui existent déjà dans un ensemble qui a l'avantage d'être formalisé et structuré de façon à être utilisable dans quantité de situations, alors je ne suis pas développeur.

Il me semble que le vrai boulot intéressant c'est surtout la conception, tout le travail d'ingénierie... J'ai vu quantité de développeurs ayant une parfaite connaissance des arcanes de leur langage de prédilection qui se trouvent incapables de faire ce travail. Quand on écrit un DAO, on les a tous écrits. Si les fonctionnalités standard sont insuffisantes, on dérive, on surcharge...ce serait idiot de réécrire des Beans (POJO) à la main de façon systématique.

Enfin, l'utilisation d'un framework présuppose qu'un grand travail personnel ait été effectué en amont car choisir le framework adapté à son besoin nécessite de s'être investi un minimum dans plusieurs solutions existantes et savoir s'en rendre maître représente un travail encore plus conséquent.

Pour conclure, il convient de nuancer mon point de vue : pour moi, un framework simplifie le travail purement technique pour permettre au développeur de se concentrer sur ce sur quoi il a réellement de se pencher : les aspects métiers. Son utilisation est recommandée pour mener à bien un projet qui implique une majorité de problématiques standards. Dans un contexte pur R&D, c'est un peu différent.

[kaymak]

hello,
je trouve l'article intéressant, par le fait qu'il remet en cause l'utilisation bête et méchante des frameworks, pour tout est n'importe quoi.

Mais, les arguments ne me semblent pas tenir la route (cela mériterait des précisions de ma part, mais je n'ai pas le temps).

Par contre,

Il est évident qu'il s'agit ici d'un comportement extrême, il est rare, dans une application, que toute une page et son layout soit statique dans le temps.

Tu dois pas souvent faire des sites internets avec du trafic, tu saurais que la majeure partie de ton traffic sur un appli web, de commerce disons, est générée par des visiteurs lambda dont le contenu affiché change assez peu.
Suffisamment pour qu'une mise en cache, intelligente et efficace, fasse s’effondrer les charges de machines.

Maintenant, si le layout complet n'est pas mis en cache, souvent c'est par bloc, et là encore, cela aide à faire chuter les charges.
Je ne connais pas bien sf, mais j'imagine qu'il intègre ces éléments, et les mécanismes de gestion de cache.
En tout cas, si effectivement, le formatage de la pensée et du code peut être une facilité à double tranchant, c'est aussi une force pour un framework que de proposer ces mécanismes de manières simplifiés et fonctionnelles, par exemple.

En contre exemple, si l'admin generator de sf est très pratique, je pense vraiment que la solution de pré-génération semi-statique est mauvaise (corrigé moi si je me trompe sur le fonctionnement de ce module).

Bref, je suis pour les fw, mais pas n'importe comment ni à n'importe quel prix.

a+