19-02-2015, 12:06 PM
J'ai oublié de préciser que je parle de développement dans un but de production, pas d'apprentissage.
Et même pour l'apprentissage, je pense qu'il vaut mieux tester chaque framework et en regarder les entrailles. Ce qu'on développe nous-même est souvent bien plus basique et moins réfléchi : on apprend mieux en regarder le travail de vrais experts. Donc selon moi, réinventer la roue pour la comprendre reste infiniment moins efficace qu'inspecter une multitudes de roues différentes. Et ça développe en plus la capacité d'adaptation, indispensable quand on développe. Si tu as vraiment du temps à consacrer au développement de ton propre framework au lieu de créer ton jeu (ce qui a l'air d'être ta volonté principale), je te conseille plutôt de faire ça : ce sera infiniment plus enrichissant.
Le fait est que je ne crois pas (je n'y crois plus serait plus exact) aux frameworks minimalistes : au final ils font tous la même chose. Ils ne sont minimalistes qu'au début (je préfère le terme incomplet, plus réaliste). Idem pour la légèreté : mais qu'est-ce que ça veut dire, objectivement, léger ? Et rapide ? Est-ce que vous avez vraiment mesuré les performances (avec des outils, pas au feeling) d'applications Symfony/Laravel/Rails/etc. et celles vos applications avec frameworks maison, sur le même matériel ? J'en doute. Je sais que certains ont comparé objectivement des frameworks industriels minimalistes (type Sinatra) avec des frameworks industriels full-stack (type Rails) et il en ressort que l'overhead des frameworks full-stack est souvent observés sur des tests basiques (le fameux hello world), mais que dans la vraie vie c'est négligeable, à plus forte raison quand les outils proposés par le framework full-stack lui permettent de prendre les devants (grâce aux outils de fragment caching intégrés, ou même de caches de requêtes, etc.). Et l'avantage, c'est que puisqu'ils sont soutenus par des communautés et distribués sous forme de package, on profitera très facilement du travail des dizaines de personnes qui contribuent à le rendre meilleur et plus performant.
Je ne dis pas que les solutions artisanales ne fonctionnent pas, je dis simplement que c'est loin d'être optimal : que ce soit en temps homme ou en temps machine.
Donc effectivement, quand des outils existent, que tu te donnes un peu de temps pour les essayer et qu'ils te plaisent : utilise-le. Ce que tu pourrais recréer différemment sera forcément moins bien, moins sûr, moins rapide (à développer, debug et exécuter), moins bien maintenu. Ceux qui apportent des idées novatrices sont toujours des équipes solidaires, sponsorisées par leur employeur, et qui fédèrent des communautés (si quelque arrive à me donner un contre-exemple, je tire mon chapeau).
Concernant les scripts de mise en production, avec compilation des JS/CSS, il y a 2 approches : soit compilé sur la machine locale et envoyé sur la machine (ça utilise généralement Rsync ou SCP, plutôt que du FTP, désolé Prélude
), soit exécuté sur la machine (qui dispose bien sûr de quelques outils installés). A nouveau, la mise en production gagne à être industrialisée. L'avantage c'est que ça ne suppose pas l'utilisation d'un framework. On peut utiliser Mina ou Capistrano sur des projets développés avec n'importe quel langage, et même s'ils n'utilisent pas du framework. C'est juste qu'ils proposent souvent des bonus qui fonctionnent bien avec les frameworks industriels, donc encore une occasion de gagner du temps.
Effectivement, si tu as du mal à imaginer comment déployer via un script, c'est peut-être que tu ne vois pas assez large : laisse-donc tomber ton framework perso et regarde ce qui se fait. Je t'assure que tu en auras pour ton temps !
@ Xenos : L'argumentaire me semble invalide : quand tu changes de techno côté serveur (déjà hyper improbable) en cours de projet, le portage des vues sera le cadet de tes soucis. Et je ne vois pas en quoi passer par une couche intermédiaire de XML peut être bénéfique plutôt que de rendre directement du HTML, du JSON, du XML (RSS/Atom), etc. Surtout quand les différents rendus exigent un traitement différents (tu n'auras pas les mêmes requêtes SQL si tu rends le flux RSS de tes articles, la liste de tes articles sur ton site Web ou une réponse d'API JSON).
Et même pour l'apprentissage, je pense qu'il vaut mieux tester chaque framework et en regarder les entrailles. Ce qu'on développe nous-même est souvent bien plus basique et moins réfléchi : on apprend mieux en regarder le travail de vrais experts. Donc selon moi, réinventer la roue pour la comprendre reste infiniment moins efficace qu'inspecter une multitudes de roues différentes. Et ça développe en plus la capacité d'adaptation, indispensable quand on développe. Si tu as vraiment du temps à consacrer au développement de ton propre framework au lieu de créer ton jeu (ce qui a l'air d'être ta volonté principale), je te conseille plutôt de faire ça : ce sera infiniment plus enrichissant.
Le fait est que je ne crois pas (je n'y crois plus serait plus exact) aux frameworks minimalistes : au final ils font tous la même chose. Ils ne sont minimalistes qu'au début (je préfère le terme incomplet, plus réaliste). Idem pour la légèreté : mais qu'est-ce que ça veut dire, objectivement, léger ? Et rapide ? Est-ce que vous avez vraiment mesuré les performances (avec des outils, pas au feeling) d'applications Symfony/Laravel/Rails/etc. et celles vos applications avec frameworks maison, sur le même matériel ? J'en doute. Je sais que certains ont comparé objectivement des frameworks industriels minimalistes (type Sinatra) avec des frameworks industriels full-stack (type Rails) et il en ressort que l'overhead des frameworks full-stack est souvent observés sur des tests basiques (le fameux hello world), mais que dans la vraie vie c'est négligeable, à plus forte raison quand les outils proposés par le framework full-stack lui permettent de prendre les devants (grâce aux outils de fragment caching intégrés, ou même de caches de requêtes, etc.). Et l'avantage, c'est que puisqu'ils sont soutenus par des communautés et distribués sous forme de package, on profitera très facilement du travail des dizaines de personnes qui contribuent à le rendre meilleur et plus performant.
Je ne dis pas que les solutions artisanales ne fonctionnent pas, je dis simplement que c'est loin d'être optimal : que ce soit en temps homme ou en temps machine.
Donc effectivement, quand des outils existent, que tu te donnes un peu de temps pour les essayer et qu'ils te plaisent : utilise-le. Ce que tu pourrais recréer différemment sera forcément moins bien, moins sûr, moins rapide (à développer, debug et exécuter), moins bien maintenu. Ceux qui apportent des idées novatrices sont toujours des équipes solidaires, sponsorisées par leur employeur, et qui fédèrent des communautés (si quelque arrive à me donner un contre-exemple, je tire mon chapeau).
Concernant les scripts de mise en production, avec compilation des JS/CSS, il y a 2 approches : soit compilé sur la machine locale et envoyé sur la machine (ça utilise généralement Rsync ou SCP, plutôt que du FTP, désolé Prélude
), soit exécuté sur la machine (qui dispose bien sûr de quelques outils installés). A nouveau, la mise en production gagne à être industrialisée. L'avantage c'est que ça ne suppose pas l'utilisation d'un framework. On peut utiliser Mina ou Capistrano sur des projets développés avec n'importe quel langage, et même s'ils n'utilisent pas du framework. C'est juste qu'ils proposent souvent des bonus qui fonctionnent bien avec les frameworks industriels, donc encore une occasion de gagner du temps.Effectivement, si tu as du mal à imaginer comment déployer via un script, c'est peut-être que tu ne vois pas assez large : laisse-donc tomber ton framework perso et regarde ce qui se fait. Je t'assure que tu en auras pour ton temps !
@ Xenos : L'argumentaire me semble invalide : quand tu changes de techno côté serveur (déjà hyper improbable) en cours de projet, le portage des vues sera le cadet de tes soucis. Et je ne vois pas en quoi passer par une couche intermédiaire de XML peut être bénéfique plutôt que de rendre directement du HTML, du JSON, du XML (RSS/Atom), etc. Surtout quand les différents rendus exigent un traitement différents (tu n'auras pas les mêmes requêtes SQL si tu rends le flux RSS de tes articles, la liste de tes articles sur ton site Web ou une réponse d'API JSON).