Discussion :

[smoser]

Concernant ma critique sur le code "inutile", je me base sur deux aspects :
- la sécurité
- le package minimal.

Pour la sécurité, si vous reprenez l'exemple des suites bureautiques... l'utilisateur a beau utiliser 1-10% des fonctionnalités..... toutes les autres sont présentes et actives. Il n'y a pas moyen de les désactiver ni de les retirer. Chacune de ces fonctionnalités (non utilisée par l'utilisateur) est susceptible d'être buguée et de conduire à devoir patcher le produit entier. Car le produit est considéré comme un "tout" non modulaire.

Pour le package minimal, si l'on considère bêtement l'espace disque, notre solution n'est pas minimale si l'on a des centaines de lignes de codes désactivées dans le produit... Elles restent présentes.

Mon intervention minimale sur ce point provient du fait que je suis déjà tombé sur des produits (pas forcément des frameworks) qui proposent 36'000 fonctionnalités dans leur produit et qu'il n'est pas possible de ne pas les installer.... C'est également le cas dans certains frameworks.

C'est probablement parce que je viens d'une formation en informatique technique plutôt que logicielle que j'ai en tête ce genre de problématiques. Quand on est limité à 32k en mémoire vive... à 1-2Mb en mémoire disque, on fait attention à n'implémenter que le strict nécessaire. C'est également pour cela que j'ai parlé de "compiler". L'exemple est également flagrant lorsque l'on développe des malwares, on essaie d'avoir le package minimal pour limiter au maximum la détection de son téléchargement.

Concernant les frameworks qui implémentent des manières de désactiver les modules désirés (même au niveau core, si si j'insiste sur le core!), voire de ne pas les installer c'est parfait ! Personnellement je n'en connais pas.... J'en connais uniquement pour désactiver des modules additionnels, mais pas pour les fonctionnalités intrinsèques au core (caching,persistence,sessions,plurilinguisme,templating,...).

[Michel Rotta]

Zend, qui n'a pas à proprement de core, le permet.

symfony 1.x a aussi la possibilité de désactiver presque toutes les fonctionalités inutiles.

Symfony 2 est lui encore plus souple, il ne les charges que si c'est nécessaire.

Les autres, je ne les fréquente pas, donc je n'ai pas d'avis.


Pour ce qui est de l'installation, il faut bidouiller pour retirer ce qui ne sert pas. Mais, dans le monde des sites web, on est rarement limité en place par le framework. On peut l'être à cause des fichiers enregistrés par les utilisateurs, mais alors, la place récupérée par le framework est minime.

Il vaut mieux bien configurer son cache et son accélérateur PHP le gains en performance sera plus flagrant.

Et je maintient, je peux envoyer une page "Hello World", avec mon framework, plus vite qu'une simple page en PHP, à partir du deuxième envoie.

[Joker-eph]

Pour le package minimal, si l'on considère bêtement l'espace disque, notre solution n'est pas minimale si l'on a des centaines de lignes de codes désactivées dans le produit... Elles restent présentes.

Absolument négligeable vu les coûts du stockage de nos jours...

Concernant les frameworks qui implémentent des manières de désactiver les modules désirés (même au niveau core, si si j'insiste sur le core!), voire de ne pas les installer c'est parfait ! Personnellement je n'en connais pas.... J'en connais uniquement pour désactiver des modules additionnels, mais pas pour les fonctionnalités intrinsèques au core (caching,persistence,sessions,plurilinguisme,templating,...).

J'ajoute Cakephp à la liste : les "core components" ne sont pas chargés si non explicitement demandés.

Michel> Je suis étonné par ce que tu annonces sur le hello world : le temps de vérifier si la donnée est à jour dans le cache devrait être au moins aussi coûteux qu'un echo "hello world !" non ?

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

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

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

[Michel Rotta]

hello,

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.

Une situation sortie de son contexte ne peut aider à la compréhension du tout. Il s'agissait d'une mise en cache de la totalité d'une page et comme dit, c'est une situation extrême. En effet, la mise en cache partiel d'éléments d'une page apporte un grand plus en terme de performance et, ça, j'utilise régulièrement.

Personnellement, je n'ai jamais pris le temps d'apprendre à travailler avec un Framework pour deux raisons :
-Le temps nécessaire à son apprentissage est beaucoup plus que le développement de A à Z de mon propre code.
-Tout je dis bien tout framework, application, tout les developpeur mettent des portes pour les utiliser au cas ou, et ça ne m'intéresse pas d'avoir des failles ou des portes dérobés dans mon propre système voila
et vous ne me direz pas le contraire, les Framework ont tendance à baisser le niveau des programmeurs web, allez demandez à un programmeur php par exemple qui bosse dépuis 5 ou 6ans sur un Framework, je paris que mysql connect et il l'a oublier bref

Maintenant chacun voit, mais c'est un peu aberrant qu'on oblige les développeur à bosser sur un Framework

Chacun son point de vue, cependant, je me permet de revenir sur quelques remarques :

• "Le temps nécessaire à son apprentissage est beaucoup plus que le développement de A à Z de mon propre code." Je pense que le temps d'apprendre à utiliser un framework s'il convient aux types de développement régulièrement entrepris, est au contraire un gains de temps à la longue et évite de réécrire encore et encore le même code. A moins que tu n'utilises régulièrement les mêmes bibliothèques, mais dans ce cas, tu as ton propre framework...
• "ça ne m'intéresse pas d'avoir des failles ou des portes dérobés dans mon propre système" deux choses. Le code des framework est ouvert (en PHP du moins). J'ai très régulièrement parcouru le code source du miens, s'il y avait des portes dérobées, elles auraient été trouvée depuis longtemps. Prétendre que tous les frameworks sont susceptible d'avoir des portes dérobées c'est du grand n'importe quoi et relève du niveau des procès en sorcellerie du moyen age. Trouves moi une porte dérobée dans un des grand framework actuel.
  
  Quant aux failles, il y en as. Certaines sont connues, d'autres pas mais elles sont moins nombreuse et plus vite bouchée que celle du code d'un développeur qui travail seul et écrit le même code de mutliples fois.

Le framework, bien choisi, bien utilisé sera ici gage de sécurité.

[Traroth2]

Sans jugement de valeur, ce débat me rappelle une discussion sur un sujet différent que j'ai eu il y a quelques temps : la photo. Je discutais avec un photographe professionnel, et il me disait qu'en fait, ce sont les pros qui sont les premiers demandeurs de fonctionnalités avancées sur les appareils, comme l'autofocus, les programmes, les modes rafales, bref tout ce qui permet de gagner du temps.
Un amateur éclairé va faire ses photos en prenant tout son temps, en mode manuel, en évaluant son exposition avec une cellule manuelle, etc, alors que le pro va devoir rendre un book de 200 photos et qu'il n'a pas le temps de rigoler. Donc tout ce qui lui fera gagner du temps est bon à prendre. J'ai vu comme ça une démonstration il y a un an ou 2 d'un modèle pro de Canon, qui est une vraie chaine de production photo : on commande tout son studio depuis son appareil (éclairage, déclenchement) et les photos sont directement transmis sur son PC par Wi-Fi. Productivité maximum.

Pour le développement, c'est pareil. Réinventer la roue, ça peut être un challenge passionnant, surtout si on essaye de faire mieux que ce qui existe déjà. Mais un développeur professionnel en train de créer un produit logiciel dans une entreprise qui va lui imposer des délais plutôt drastiques n'a tout simplement pas le temps de faire ça. Un framework qui va faire tout le boiler plate code à sa place, c'est une bénédiction !

[RunCodePhp]

Cet article n'est ni plus ni moins que de la "morale à la petite semaine", et rien que de la morale, limite discourt sectaire.

Ce n'est en rien une analyse sur le réel intérêt ou danger de l'usage d'un FrameWork.

Vraiment, désolé, mais il m'a été impossible de le lire dans son intégralité :
Discourt trop long, les même idées qui se répètent, trop moraliste, limite insultant envers ceux qui utilisent les FrameWork (surement tous des abrutis), j'en passe et des meilleurs.

Désolé, mais là, à part faire un "buzz", je ne vois vraiment rien à retirer de cet article.
Aucune vrai analyse, arguments, sinon que de la philo.


Utiliser un FrameWork "c'est pas bien" ou "c'est le mal" ... on va aller loin avec ça.


Moi qui m'attendais à une vrai synthèse du pour et du contre, et surtout une vrai alternative du "sans FrameWork".
La seule alternative serait de créer son propre FrameWork.

[diden138]

Bonjour,
Personnellement, je n'ai jamais pris le temps d'apprendre à travailler avec un Framework pour deux raisons :
-Le temps nécessaire à son apprentissage est beaucoup plus que le développement de A à Z de mon propre code.
-Tout je dis bien tout framework, application, tout les developpeur mettent des portes pour les utiliser au cas ou, et ça ne m'intéresse pas d'avoir des failles ou des portes dérobés dans mon propre système voila
et vous ne me direz pas le contraire, les Framework ont tendance à baisser le niveau des programmeurs web, allez demandez à un programmeur php par exemple qui bosse dépuis 5 ou 6ans sur un Framework, je paris que mysql connect et il l'a oublier bref

Maintenant chacun voit, mais c'est un peu aberrant qu'on oblige les développeur à bosser sur un Framework

Cordiales Salutations,

[Invité]

je paris que mysql connect et il l'a oublier bref

La question qui tue : et alors ? Si un jour il a plus son framework : il cherche comment se connecter a mysql sans !

EDIT : tu fait comment ?

- tu utilise cette fonction a chaque fois que tu accède a ta base ? Ton code est instable, indebuggable, impossible a faire évoluer ...
- tu t'es crée une classe pour faire tes accès en base, en faisant abstraction du type de bdd : bienvenu dans le monde du framework, et dans peu de temps tu ne saura plus faire mysql_connect parce que tu préfère faire "$mesdonnees = maClassDeBaseDeDonne->select("select * from matable")"

[stailer]

je paris que mysql connect et il l'a oublier bref

Oui et j'ai envie de dire : HEUREUSEMENT

[dourouc05]

Oui et j'ai envie de dire : HEUREUSEMENT

Version un peu plus longue que "heureusement" : pourquoi diable se limiter à des bases MySQL ? SQLite fonctionne extrêmement bien pour des petites tâches, pas besoin de sortir un monstre comme MySQL (surtout que je préfère généralement Postgsre, c'est une affaire de goût plus probablement...).

Aussi, pourquoi donc encore quelqu'un pourrait oser connaître les méthodes en mysql_ ? mysqli, c'est évident que c'est plus récent, plus recommandé, donc c'est mauvais. PDO, c'est objet donc c'est extrêmement mauvais ; c'est abstrait de la base de données, c'est encore pire.

(Ceci étant bien évidemment ironique).

Où va-t-on avec ce genre de commentaires ? On devrait presque brûler en place publique tous ceux qui osent dire qu'on oublie mysql_connect() !

[Invité]

@dourouc : le problème n'est pas de donnaitre mysql_ , mais de connaitre directement une méthode d'accès au données, il faut absolument en faire abstration et mettre une couche par dessus tout ça : c'est complexe et repetitif, il faut absolument l'oublier (que ce soit sqllite ou mysqli)

[stailer]

pourquoi diable se limiter à des bases MySQL ?

Tout à fait c'est pour ça que je fais du MySQL, du SQLite , du SQL Server et même : de l'Access ...

mysql_connect()

Oui c'est mysqli_connect.. mais tu vas pas me croire : à choisir je préfère PDO

EDIT : A noter que je n'ai aucun souci depuis 6 ans avec mes connexions à mes BDD en PHP. La plupart sont des sites webs très visités et d'autres des applications en intranet : aucun souci particulier de connexion ou de performance aujourd'hui.
Mais qui sait ? le téléphone va peut-être sonner aujourd'hui ?
Je plaisante...

[sinople]

Il est clair que certains dans ce débat ont une vision réductrice de l'informatique...

L'utilisation d'un framework dans l'industrie est une bonne chose car elle réduit considérablement le temps (et par conséquent le cout du développement) si l'on accepte ces inconvénients (dépendance au framework par ex.). Je ne pense même pas que ça baisse le niveau de qualité du travail (on peut réfléchir à d'autres chose et rien ne dit que la roue qu'on réinvente soit la plus ronde...)

Néanmoins heureusement que certains on encore le temps de faire de la branlette intellectuelle, pour créer et évoluer les framework entre autre. Mais ce n'est pas à la portée de tous (financièrement et/ou intellectuellement).

Et pis bon tant qu'à faire autant réinventer PHP voir le C et graver son propre processeur si on pousse à l'extrême la pensée de l'auteur.

[Invité]

@dourouc, j'avais pas saisi l'ironie, autant pour moi

@sinople : même dans l'industrie on fait évoluer les framework, on se base pas sur du travail fait volontairement sur des projets open source,si il y a un bug, une fonctionnalité qui manquerai, faut pas hésiter a résoudre le problème plutot que essayer de "contourner " le framework (ce qui est la pire des choses a faire : trouver des "hack" pour contourner les défauts d'une framework, en général els résultats sont vraiment a ch... anter).

[pseudocode]

Il y a plusieurs types de framework : technique, service, applicatif, ... La plupart des gens qui sont mécontents des frameworks sont ceux qui n'ont pas choisi le bon au départ, ou qui se retrouvent limités par les contraintes imposées*


(*) Généralement plus tard dans le développement, lorsqu'on veut enrichir sont application de fonctions avancées.