Et dire que c’était le framework de mon premier amour ! Sous ce titre un peu ridicule[1] se cache un véritable cri du cœur. Ou pourquoi j’ai décidé de ne plus utiliser les technos de Sensio.
Mise à jour : deux ans plus tard, j’ai écrit un retour d’expérience sur ma migration vers Python et Django.
Un peu d’histoire
Comprendre les propos qui vont suivre nécessite d’avoir un aperçu de la vie du framework. Si vous n’aimez pas l’histoire, vous pouvez passer directement à la section suivante.
La première version de symfony est publiée en 2005. La version 1.0 voit le jour début 2007. Mi-2008 débarque la version 1.1, avec une refonte majeure de l’architecture interne, et l’arrivée (notamment) du framework du formulaire. La version 1.2 suit rapidement, fin 2008, ajoutant pas mal de fonctionnalités sympa. Enfin, fin 2009 sortent en parallèle les versions 1.3 et 1.4, avec l’intégration d’un beau mailer tout neuf, pas mal de travail sur les forms, et encore d’autres trucs sympa.
Ensuite ? Plus rien… Sensio a en effet décidé de ne pas poursuivre le développement de symfony en tant que tel, mais de réécrire le projet de zéro pour donner naissance à Symfony2. La branche 1.x ne verra donc pas d’ajout de nouvelles fonctionnalités, et ne sera plus supportée après 2012.
La nouvelle version du framework a été révélée la première fois en février 2010, mais l’idée de la réécriture date de bien avant. Je me souviens avoir assisté à une présentation Symfony par Fabien Potencier en 2008, et déjà, la réécriture du projet était évoquée.
Symfony2, au moment de la publication de cet article (juin 2011), est encore en beta, et la stable est attendue pour juillet.
Awesome framework is awesome !
Contrairement à ce que mon titre pourrait laisser croire, je tiens symfony 1.x et ses créateurs en haute estime. Malgré quelques erreurs de jeunesse et problèmes qui apparaissent à l’usage, le framework est de haute qualité. ORM, architecture MVC, formulaires, outils de tests unitaires et fonctionnels, gestion des caches, générateur d’admin, documentation abondante et j’en passe en font une solution complète et robuste.
Mais plus important, symfony a contribué à diffuser les bonnes pratiques et outils de développement à une grande échelle. Avant symfony, aucun projet dans le monde PHP n’avait autant insisté sur l’importance de la programmation objet, de l’architecture du code, des tests automatisés, des développements itératifs, etc.
La plus belle réussite du projet, à mon humble avis, est d’avoir aidé le monde du développement web à sortir de son amateurisme bon enfant, pour le hisser vers les standards de compétence qu’on peut trouver dans d’autres branches du développement logiciel.
Bien entendu, on trouvera toujours une palanquée de zigotos se prétendant développeurs web parce qu’ils ont écrits trois lignes de PHP. Mais en s’imposant, symfony a aidé à séparer le bon grain de l’ivraie en permettant l’émergence d’une communauté de véritables professionnels.
C’est grâce à symfony et à son écosystème que j’ai découvert le développement itératif, les tests automatisés, et que j’ai eu mon premier contact avec les méthodes agiles. Et rien que pour ça, je tire mon chapeau à ce framework.
Vis ma vie de freelance
Mais alors, pourquoi aller voir ailleurs ? J’y viens.
Pour ceux qui ne sont pas encore au courant, sachez que je suis développeur web freelance. Ce qui signifie que je travaille seul, et que je dois assurer tous les aspects d’une prestation de développement web de A à Z (prospection, avant-vente, réponse aux appels d’offre, développement, gestion de projet, gestion administrative et commerciale, maintenance, etc.)
Nous vivons dans un monde qui évolue trés vite. Chaque semaine voit son arrivée de nouvelles technos, certaines demeureront, d’autres disparaitront. Mais décider d’apprendre à utiliser une certaine technologie, comme un framework, pour pouvoir ensuite l’inclure dans mes prestations, c’est un choix difficile, et un investissement trés lourd.
C’est un investissement trés lourd, puisque cela signifie que je vais devoir me former, lire de la doc, faire des tutos, tester sur des petits projets personnels, et tout cela prends beaucoup de temps. Et quand on est freelance et qu’on facture à la journée, je peux vous dire qu’on est trés conscient que le temps, c’est de l’argent.
C’est un investissement trés lourd, puisque cela signifie que j’accepte, pendant un temps plus ou moins long, d’être moins efficace dans mon travail. Une techno donnée ne me permettra d’être efficient que lorsque je la maîtriserai suffisamment pour passer plus de temps à produire qu’à chercher de la doc.
C’est un investissement trés lourd, puisque cela signifie aussi que le premier projet vendu dans cette techno sera hasardeux et commercialement risqué. Et comme je suis honnête, cela signifie aussi que je vendrai mon jour de travail moins cher à mes clients, parce que je ne peux garantir à 100% l’application des bonnes pratiques relatives à cette techno.
Bref, décider d’ajouter une techno à ma trousse à outil, c’est un investissement lourd, et comme pour tout investissement, j’en attends un bénéfice. Si je galère pendant 6 ou 9 mois pour redevenir efficient, j’espère que l’outil choisi restera valable pendant au moins 4 ou 5 ans.
Symfony, I am disappoint !
Mon véritable problème est qu’avec symfony, j’ai l’impression de ne jamais avoir récolté les bénéfices de mon investissement.
Symfony est une trés bonne techno. C’est aussi une techno qui est trés loin d’être parfaite, et qui aurait nécessité encore beaucoup d’ajustements. Sauf que… Dans le cul Lulu ! Parce qu’en 2009, boum ! Branche 1.x gelée ! Les nouvelles fonctionnalités ? Pas la peine, on est en train de tout réécrire ! Les bugs vraiment bloquants et complexes à corriger ? Trop dur, c’est un problème d’architecture ! Mais pas d’inquiètude, on est en train de tout réécrire, ça sera corrigé dans 2 ans.
Malgré tous mes efforts, je ne parviens pas à me débarrasser du sentiment que les nombreux arguments avancés à l’origine pour promouvoir symfony n’étaient que de la merde marketing.
Sensio mettait en avant que symfony était supporté par une entreprise, et pas une communauté de hippies pas sérieux. Qui a essayé de soumettre des bugs après le gel de la branche 1.x sait ce qu’il en est de ce fameux support. D’ailleurs, à ma connaissance, Kris Wallsmith, release manager de la dernière version stable, n’est pas un employé de Sensio.
Sensio mettait en avant que symfony était une techno pérenne, avec des LTS et tout le toutim. Sauf qu’une LTS ne sert pas à grand chose si le développement du projet s’arrête derrière. Ah, ça, mes clients à qui j’ai vendu une techno « LTS », ils vont bien rigoler en 2012, quand je leur dirai qu’ils faut réécrire leur site s’ils veulent continuer à bénéficier de mises à jour de sécurité.
Sensio mettait en avant que symfony était une techno bâtie sur l’expérience, inspirée par les meilleurs projets de l’époque. À l’utilisation, on s’aperçoit trés vite (et dans la douleur) que symfony est surtout bati empiriquement. Tous ceux qui ont essayé de créer un site multilingue, ou des formulaires imbriqués, ou d’utiliser le générateur de backend sur des « vrais » projets me rejoindront probablement.
Sensio mettait en avant que symfony était abondamment documenté. Sauf que l’info, elle peut être dans le livre d’introduction, ou dans le tuto de démarrage, ou dans le livre pratique de noël, ou dans le livre de référence, ou dans le tuto sur les formulaires, ou dans le tuto spécifique sur doctrine, ou dans un billet sur le blog, etc. Et attention à ne pas se gourrer entre la version doctrine ou propel du document. Qui plus est, les mêmes docs ne sont pas forcément disponible selon la version du framework, et bien évidemment, via un moteur de recherche, on ne sait jamais sur quelle version on va tomber. Bref, la doc de symfony, elle est trés bien sur le papier, mais en pratique, c’est vraiment casse-bombon.
D’ailleurs, c’est ça tout le problème de symfony. C’est toujours trés bien sur le papier, mais en vrai, ça laisse un petit goût bizarre dans la bouche Une petite impression de finalement, c’est pas si bien que ça. Symfony, c’est une techno pas finie, pas mature, et Sensio a choisi de tout reprendre à zéro plutôt que de terminer ce qu’ils avaient commencé.
Et maintenant ?
En tant que freelance, professionnel du développement web, j’ai maintenant deux possibilités :
- Je persévère, je me mets à Symfony2, je prends le temps de me former, je paie les pots cassés pendant quelques mois, j’attends que la techno soit stable, j’attends que les compétences se diffusent, j’attends que la communauté atteigne une taille suffisante, j’attends que les plugins et extensions apparaissent, j’attends les premiers retours d’expérience sur la mise en place de vrais projets, sans garantie que tout ne recommence pas dans 5 ans.
- Je vais voir ailleurs si je peux trouver mieux.
Alors, à votre avis, je fais quoi ? Et bien, j’ai fait ce que tout bon développeur web doit savoir faire : j’ai été curieux. J’ai sauté une grande marche, et je suis carrément allé voir dans d’autres écosystèmes, d’autres communautés. J’ai testé python, j’ai testé flask, j’ai testé django, et ce que j’ai vu m’a plu.
Django, ce n’est bien sûr pas parfait, mais c’est aussi bien en pratique que symfony sur le papier. Ce n’est pas une techno de frimeurs, on n’en dit pas plus que ce qu’on en fait. L’avenir me dira si c’est un bon choix.
Pour conclure. Je ne dis pas que Symfony2 ne sera pas une techno géniale, et qu’elle ne doit pas être utilisée. Je ne dis pas que je ne toucherai jamais un projet en Symfony2. Je ne dis pas que prendre la décision de tout réécrire a été mauvaise. J’imagine que ce fut un choix trés difficile. Je dis et répète que j’admire et loue les équipes qui travaillent sur symfony, et que toutes ces remarques sont faites avec humilité, en ayant conscience que la critique est aisée, mais l’art est difficile.
Simplement, à mon niveau, pour mon cas personnel, je ne peux plus considérer symfony comme une techno viable.
Et rien ne me dit que dans 5 ans, le même schéma ne se reproduira pas. Rien ne me dit que dans 5 ans, Fabien Potencier ne va pas péter un boulon pour aller élever des chèvres dans le désert. Et alors, quel avenir pour symfony ?
Je suis allé voir ailleurs, et j’y ai trouvé mieux. Un petit pas pour l’humanité, mais un grand pas pour moi ?
Mise à jour : deux ans plus tard, j’ai écrit un retour d’expérience sur ma migration vers Python et Django.
Notes :
- en encore, vous ne me voyez pas le chanter devant mon écran [retour]
Article intéressant, mais tu peux ajouter des références quand tu parles de :
- Bugs majeurs non supportés
- Sensio a dit que
Ca permettrait de consolider ton article et modérer les trolls (qui nous guettent)
Symfony1 est en fin de vie après 6ans de service, je trouve ce délais plutôt viable pour un projet open source. Deplus, le projet Symfony est en phase de transition pour devenir encore plus mature et stable avec la version 2.
Pour que Symfony2 devienne viable pour un freelance, la communauté doit fournir des briques logiciels facilement re-utilisables. cf https://github.com/sonata-project et https://github.com/FriendsOfSymfony
Entièrement d’accord avec presque tout !
C’est d’ailleurs pourquoi je n’ai pris Symfony dans mes projets (après avoir testé pas mal de temps quand même).
C’est une vision très réaliste de ton métier.
Je ne connais Symphony que de nom, mais eu les même dilemmes avec d’autres outils de développement logiciel. Quelle techno choisir : la plus complète, celle qui permet de développer vite, celle qui est soutenue par un mastodonte ou par une communauté dynamique, celle qui est très fiable mais pas très sexy…
Je pense qu’il faut se décider par rapport à :
– le profil de ses clients et de leurs projets
– ses propres aspirations et croyances
– ses compétences techniques (et rester humble).
Article très intéressant
J’ai la même vision que toi (n’ayant pas encore testé Symfony2) par rapport au développement trop rapide du framework… Je trouve ça vraiment dommage parce que j’ai appris énormément de choses avec, que j’ai professionnalisé par mal de codes, mais qu’au final, au moment où j’ai commencé à maitriser la techno, Sf2 était déjà en chantier… C’est juste dommage…
@Thomas R. 6 ans, ce n’est pas si long pour une techno destinée aux entreprises, open-source ou pas. C’est à peine le temps que les plugins intéressants apparaissent, que les compétences se diffusent sur le marché, que les retours sur des cas d’utilisation à grande échelle soint intégrés. Bref, que la technologie soit vraiment mature.
Je ne considére pas sf2 comme une évolution de sf1. Sf1 est bel est bien mort, et sf2 est un projet à part entière.
Je comprends la frustration de voir la fin d’une technologie qu’on a utilisé des années s’arrêter mais dans le cas de symfony, je pense que c’était nécessaire pour permettre au framework de continuer d’évoluer dans le bon sens. Comme tu l’as bien fait remarquer, symfony 1 péchait sur de nombreux points comme les formulaires et l’admin generator. Tout réécrire permet de rectifier le tir et de se débarrasser des erreurs de jeunesse.
Maintenant il faut savoir que symfony 1.x est loin d’être un projet mort. Son développement continuera aussi longtemps qu’il sera nécessaire, maintenu par la communauté certes mais maintenu tout de même. C’est le moment idéal pour demander des droits de commit si on a des améliorations a proposer.
« Et rien ne me dit que dans 5 ans, le même schéma ne se reproduira pas. »
Symfony aurait été une techno propriétaire, j’aurais compris ces craintes mais sur un projet Open Source, le problème ne se pose pas. Bien sur, il est difficile de se passer de la maison mère, mais ce n’est pas impossible.
Ce que j’aurai tendance a proposer pour une bonne transition souple est le schéma suivant:
Continuer a maintenir les projets existant symfony 1.x en restant sur cette technologie.
Créer les nouveaux projets avec Django, car Django c’est le bien.
Faire de la veille techno sur les évolutions de Symfony 2 pour être capable de juger dans le futur s’il est pertinent de démarrer des projets avec ce framework.
Pour ma part, j’ai survolé très superficiellement symfony 2 car je dois bien avouer que je suis fatigué de coder du PHP et je prends beaucoup plus de plaisir a faire du python. J’ai cependant remarqué quelques similitudes sur les 2 frameworks notamment sur le routing et les templates.
>Et rien ne me dit que dans 5 ans, le même schéma ne se reproduira pas
Je pense que c’est une erreur de croire qu’une techno comme un framework peut durer plus de 5 ans. Les besoins des entreprises évoluent, les technos web évoluent, le language sur lequels ils sont batis évolue aussi, et donc les frameworks doivent aussi évoluer. Et forcément, un jour ou l’autre, les coûts pour adapter un framework aux nouveaux besoins et usages, devient trop important parce que de base, son architecture n’a pas été pensé pour (c’est normal, personne ne peut prédire l’avenir).
Bref, tout framework passe forcément un jour ou l’autre par la case « réécriture ». (je connais un peu, ça fait 10 ans que je développe des frameworks).
Tu passes à Django, Ok. Mais y passer parce que tu crois que Django va rester Django encore dans 5 ans, est une très mauvaise raison de passer à Django. Il faut passer à une autre techno non pas pour sa pérénité, mais PAR LES BESOINS AUXQUELS ELLE REPOND. Dans 2 ans, dans 4 ans, si ça se trouve, les core dev de Django voudront eux aussi refaire tout from scratch. Et ça, tu ne peux pas le prédire.
Si tu cherches une techno (surtout web), qui dure plus de 5 ans, 10 ans, change tout de suite de métier. (remarque, y a des technos qui durent, le COBOL ou le Fortran par exemple, encore très utilisés dans certains domaines d’activité comme les banques &co, mais ce n’est pas du web
)
Tu t’es investi dans une techno. La pérennité de la techno, surtout quand elle est open-source, elle ne tient pas à celui qui la créer, mais à ceux qui l’utilisent.
Vu que tu sembles être un expert dans Symfony, et vu qu’ils semblent qu’il y ait de nombreuses personnes qui regrettent l’arrêt de Symfony 1.x, pourquoi ne pas prendre en charge vous même le projet. C’est un projet open-source, et à priori, rien n’empêche de le maintenir.
La dynamique communautaire et la mâturité de celle-ci est un gros progrès de symfony : ça ne relève pas que de l’éducation des développeurs ayant appris à l’utiliser.
Même si Fabien Potencier part élever des chèvres en Patagonie, et que le framework n’avance plus aussi vite – vu sa part de contribution à l’outil, il y a quand même une relève … dans plusieurs personnes.
Syndrôme Apple. Un dieu et beaucoup de prêtres qu’on oublie mais pourtant indispensables à la réussite du projet
Le problème existe tout autant pour les non-freelance. Ce n’est jamais facile de justifier le choix d’une nouvelle techno plutôt qu’une autre au sein d’une grosse DSI…
Alors quand on constate que techniquement ça tient la route mais qu’un an après on apprend que la version choisie va être abandonnée et totalement réécrite… c’est un peu hard aussi à faire passer à sa hiérarchie.
Fallait utiliser ZF ! (OK je sors ->[])
Sinon bon billet. Encore une illustration que repartir à zéro est TOUJOURS une mauvaise idée : http://www.joelonsoftware.com/articles/fog0000000069.html
Très intéressant comme article, pour ma part j’utilise en agence WordPress, qui peut être utilisé comme un CMS, un moteur de blog etc… Niveau admin bein c’est à la fois flexible et rigide, l’interface peut être totalement intégrée à celle de WordPress ou bien complètement différente et faire ce que l’on veut.
Niveau programmation c’est comme on le souhaite, OO ou non.
Il y a une miriade d’APIs dans ce CMS, en gros on peut tout faire avec WordPress avec un peu de dev.
L’interface est d’ailleurs très appréciée des clients et ça fonctionne sur de gros et petits sites
( Certains font tourner 5-6 sites à 30 000 visites avec un seul serveur, et puis WordPress.com c’est des millions de blogs ).
La nouvelle version 3.2 ( qui va bientôt sortir ) passe en PHP5 et Mysql5, un gain de rapidité non négligeable dans certains cas. L’interface à été revue et le thème de base aussi. La communauté est assez énorme et c’est vraiment très utilisé aux US…
Ca demande un petit temps d’adaptation mais une fois cette étape franchie on se rend compte que c’est un excellent CMS
.
@Rahe: C’est quoi le rapport entre WordPress et Symfony ?
@Emmanuel : Il parlait d’autre écosystèmes de développement, en voici un très bon
.
Disclaimer : J’ai utilisé sf1, j’utilise sf2 et je travaille à Sensio Labs.
Je suis entièrement du même avis que laurentj. Si apprendre de nouvelles technos te pose un problème, le problème n’est pas dans symfony mais dans ton approche du web. Le web évolue en permanence, et bien plus vite que les autres technos.
On ne sait pas de quoi demain sera fait, et ce dont le web aura besoin. symfony 1 est-il un framework capable de suivre ces évolutions ? Ma réponse à la question est non. Il est trop lourd, trop lent, et n’est pas assez respectueux du protocole HTTP. Or, à mon goût, ces problématiques là sont la base des problématiques web. Symfony2 répond à cela, pour l’instant, mais personne ne sait s’il sera encore pertinent dans x années, tout simplement parce que personne sait si le web sera le même.
Je suis assez d’accord avec la problématique d’un point de vue freelance, étant moi même freelance.
Par contre, il n’est fait nul part allusion au passage de 5.2 > 5.3, et du fait que le langage dans sa version 5.3 offre plus d’abstraction (late binding par exemple, lambda functions qui permet des fonctions d’ordre supérieurs (higher order funcs), ce qui est juste **énorme** pour du php).
Ensuite il n’est pas fait allusion non plus au fait que la php 5.2 n’est plus supporté.
Donc, à quoi bon faire fonctionner un framework qui n’est pas dimensionné pour du 5.3 car codé pour du 5.2 ?
Du coup je me dis qu’on fait ici porter beaucoup de choses à Sensio sans parler de Mister Potencier, alors qu’ils ne font, dans une certaine mesure, que suivre les évolutions du langage, il me semble.
De plus, rien n’interdit à une entreprise tierce de fournir du support sur du symfony 1.4. Toi-même en freelance tu pourrais offrir ce support, si tu le désirais.
@laurentj @Marc Non, non, non messieurs, mon problème n’est pas d’apprendre de nouvelles technos. Je le fais tout le temps. Je DIS même clairement que je suis parti apprendre une nouvelle techno, parce que celle que j’utilisais ne me plaisait plus.
Ce que je dis, c’est que si une techno est suffisamment complexe pour nécessiter plusiers mois d’apprentissage avant de pouvoir être productif avec, son temps de vie global doit être en conséquence. Une techno complexe comme un framework nécessite un temps certain pour parvenir à maturité.
Je dis également qu’il y avait un fort décalage entre la présentation du framework et la réalité.
Je suis entièrement d’accord avec vos commentaires, et ils ne contredisent pas mon propos. En revanche, vous faites fi de mes autres arguments, ce qui est un peu dommage.
Faut savoir casser pour reconstruire de zéro avec de bonnes bases, et remerci Sensio de savoir le faire même si cela peut en décevoir et énerver certains. Et puis, tu ne leur dois rien, tu ne paye pas ce framework.
Oui cela créer une nouvelle courbe d’apprentissage à gravir mais à apprendre Django, c’est que tu n’y es pas trop réfractaire.
Dans tous les cas, Django serai également mon second choix actuellement, c’est une bonne solution.
Je te rejoins parfaitement sur la stratégie marketing de Sensio. Quand on annonce un Long Term Support, on cible clairement les entreprises. Tuer une branche massivement utilisée en production est une hérésie commerciale, bien que ça se justifie technologiquement. On ne peut pas attendre d’énormes DSI qu’elles suivent les vents d’un inventeur génial qui essaye de suivre les avancées techniques du Web au jour le jour. Sensio n’est pas Fabien Potencier, et ce dernier devrait tâcher de s’en souvenir. Une netreprise qui s’est engagée dans un discours commercial ciblé doit tenir ses engagements sous peine de bouillon assuré. L’avenir nous dira le goût de cette soupe (mais sans moi, tout comme toi)
Merde, les mecs ! Les source, bordel de prout !
C’est de la diffamation là ce que vous faites !
Idem, article sympa.
Qu’est-ce qui te garantie que Django est une solution plus pérenne que Symfony ?
@Do Django et Symfony sont apparu à la même époque (2005). Symfony 1 est mort, Django vit toujours. Donc, Django est plus pérenne que Symfony, c’est juste un constat
Sinon, bien évidemment, rien ne le garanti, mais il y a une vrai communauté derrière, et c’est un projet geré de manière démocratique (en tout cas, plus que pour symfony).
Symfony2 est aussi géré de manière démocratique. Les contributeurs ont aussi leur mot à dire dans la vie du projet. Ca se voit avec les nombreuses demandes de participations aux RFC sur la mailing list des développeurs et dans la part importante que représente les contributeurs à Symfony2. Il y a en effet aujourd’hui presque 250 contributeurs au code de Symfony2.
@Hugo Hamon Merci pour la précision sur Symfony2, qui témoigne que les choses évoluent dans le bon sens. Toutefois, mon propos ne porte que sur symfony premier du nom. Je pense qu’on peut considérer que sf1 et sf2 sont deux projets bien distincts, et que le second aurait trés bien pu porter un nom complètement différent.
Bonjour,
Il me semble avoir lu ou vu une conférence sur le sujet de la compatibilité sf1 et sf2. Il me semble bien que sensio à penser à une méthode pour réutiliser son code sf1 dans sf2 mais j’arrive plus à retrouver la source.
Thibault ! Tu n’as aucune source, aucune référence ?
Tout ce que tu dis, tu ne l’appuies pas. Tu sors de ça de ta mémoire, d’un souvenir lointain que tu as.
Merci de donner des détails, des références, parce que là, vraiment, on a que ta parole. Certaines personnes vont se faire une idée fausse du framework, de Sensio, alors que ce que tu dis n’est pas appuyé.
Perso, j’pense que tu te plantes sur le discours de Sensio et les bugs majeurs de symfony. Le truc c’est que ton article ne me donne aucun moyen de vérifier.
J’suis ton blog régulièrement, et j’t'avoue que là… ça craint. Des preuves, des sources, des références pour pouvoir vérifier ce que tu dis.
WordPress n’est pas un framework web. C’est une plateforme de blog qu’on peut bidouiller (avec des plugins) pour avoir une sorte de CMS.
A ce moment là autant se tourner vers Drupal.
@thibault Je l’ai bien compris. Gérer un produit Open-Source de façon « démocratique » n’a pas que des avantages. On le voit avec Symfony2, on laisse beaucoup plus de champ d’action à la communauté mais ça implique aussi un sacré retard sur la sortie de la distribution finale. La version 2 était prévue pour le début d’année, puis reportée à mars et là voilà enfin presque prête pour juillet. Ces retards successifs ont en partie été dus (et ce n’est pas une critique) à l’effort de la communauté qui a contribué au projet. Il a fallu essayer de contenter tout le monde et essayer d’accueillir le maximum de contributions externes. Revoir le code de la communauté et l’intégrer prend aussi du temps.
Dans symfony 1.x, il est vrai que ça n’a pas été le cas et que le projet était géré de manière plus « dictatorial » parce que la core team était bien plus restreinte. Mais ce n’est pas complètement la faute à la core team à mon sens. Symfony 1.x n’a pas pu bénéficié autant des contributions de la communauté à cause de SVN. Subversion n’était pas du tout l’outil adapté pour accueillir des contributions du monde entier. Git (et surtout Github.com) ont largement favorisé toutes ces contributions aujourd’hui.
Si symfony 1.x avait démarré sur Git, peut-être que le projet aurait pris un tout autre visage. Néanmoins si l’on compare avec ZF, c’est pratiquement pareil. La core team du projet est restreinte et assez peu ouverte aux contributions externes.
Les responsables du projet préfèrent garder la maîtrise et éviter que le projet parte dans le n’importe quoi selon moi.
En même temps, à l’impossible nul n’est tenu et il est dans un certaine mesure illusoire que tes clients croient à un support « éternel », surtout dans le monde du web. Au delà du produit en lui-même, je pense que le client doit surtout s’assurer qu’il y a des compétences sur le marché et que la technologie est mature.
C’est par ex le principal défaut fait à python jusqu’à il y a peu. Les compétences françaises étant ce qu’elles étaient, il était risqué de choisir un socle python. Les choses semblent vouloir changer et c’est tant mieux.
Autant je pense que Django est un projet assez établi, autant flask (bien que très prometteur), ne me semble pas encore offrir les garanties que tu sembles vouloir promouvoir auprès de tes clients.
Tout ça pour dire qu’il faut être honnête de partout (Sensio dans ses engagements, toi vis à vis de tes clients, tes clients vis à vis de leurs demandes, etc) afin que tous les acteurs puissent faire le meilleur choix possible à un instant T.
@Sylvio: c’est là que l’on voit que tu ne connais pas du tout WordPress et toutes ses possibilités, c’est un CMS auquel il manque peut. Ce n’est pas un CMS click click comme l’est Drupal, c’estu n vrai CMS de dev, tu en fais ce que tu veux.
Apostrophe et Diem sont pour moi bien plus orientés « facile pour le dev » que l’est WordPress.
Ceci dit je n’ai pas bouffé autant de WordPress que d’Apostrophe ou de Diem.
@Rahe WordPress est bel et bien un CMS. Un système de gestion de contenus. Un framework te permet d’aller au delà et de réaliser des applications métiers sur mesure. Ce qu’il est (presque) impossible à réaliser à partir d’une base WordPress.
La plupart de nos clients chez Sensio sont des grands comptes pour lesquels on développe des applications métiers. Ces applications n’ont pas forcément de couche CMS donc utiliser un CMS comme WordPress ou Drupoil ^^ n’est clairement pas adapté pour répondre au besoin.
Il y a un truc qui me chagrine sur ta lecture du « LTS ».
Si ton problème est que S1 n’évolue plus en terme de fonctionnalités alors je crois que tu n’as pas compris ce qui était entendu au départ par LTS. Toutes les références que j’ai définissent comme support le fait d’appliquer les corrections de sécurité et de bugs majeurs. Les évolutions, les bugs mineurs, et même les corrections de sécurité qui demanderaient des changements profonds ne font pas partie du support.
Maintenant tu peux continuer à l’utiliser même sans évolution du framework. S’il correspondait à tes besoins alors c’est toujours le cas. Éventuellement il ne correspond pas à tes nouveaux besoins si ces derniers ont évolué mais ça personne n’a pu t’en apporter la promesse.
Maintenant si ce que tu veux dire c’est que les problèmes de sécurité ne sont pas corrigé et les patch correspondants refusés, alors là il y a un sérieux problème avec le mainteneur. Je serai étonné qu’on en soit là mais si c’est le cas c’est un problème qui peut être résolu.
Par contre j’ai du mal avec les commentaires sur les « 6 ans de support ». Un support ça ne se calcule pas du début de la publication à la fin de la publication, mais du dernier jour où la version est la version « recommandée » (ou premier jour de son abandon) au dernier jour du support. Le logiciel a beau avoir été créé il y a 10 ans, si je prends la dernière version en date et qu’un mois après on me dit « ce n’est plus maintenu », je considère le support comme quasi nul.
Ici c’est encore Symfony 1 qui est recommandé et en « stable ». Nous n’avons pas encore commencé la période de support. Pas 6 ans, même pas un seul jour. Bref, c’est une LTS si à partir de la première version stable de Symfony 2, on suit encore les corrections de sécurité et de bugs majeurs pendant plusieurs années (on va dire 2 ans ou plus).
Si ce n’est pas le cas, alors effectivement, il y aura un gros problème avec la communication Sensio autour du terme « LTS ». Mais pour l’instant ça me semble prématuré de critiquer cet aspect (ou de le glorifier)
@Alexandre Salomé Pour les références, c’est un discours qui relate un parcours personnel, un vécu, un ressenti. Je ne vois pas trop comment référencer un ressenti. Pour référencer convenablement chaque point, il faudrait écrire une thèse.
Regarde le nombre de bugs ouverts dans trac. Regarde le texte d’intro sur symfony-project.org. Lit les interviews de F Potencier. Fait quelques recherche dans Google et constate que tu ne tombera jamais sur la même version de la doc. C’est de ça dont je parle dans mon article.
Sinon, trés précisément, sur quoi tu voudrais une référence précise ?
@Hugo Hamon +1 pour l’argumentaire sur git. Néanmoins, je pense qu’il s’agit avant tout d’un problème politique que technique.
@Flask Actuellement, je vends du django. Flask est il est vrai trop jeune (mais je crois que mon cv n’est pas à jour sur ce point).
@Sylvio @Rahe Même s’il est possible de tordre WordPress pour en faire à peu près n’importe quoi, je ne pense pas qu’on puisse le placer au même niveau qu’un vrai framework. Cela-dit, c’est une discussion vraiment hors sujet.
Je développe tous mes projets avec SF.x depuis les beta 0.6 donc depuis plus de 5 ans.
Il faut bien voir qu’à la sortie de la 1.x, il n’y avait rien d’équivalent en PHP.
Le web évolue à une vitesse folle. On ne peut en aucun cas promettre à un client un projet pérenne sur une durée de plus de 5 ans.
Je dis ça après 9 ans d’expérience à essayer de faire des sites évolutifs et où je dois faire comprendre à mes clients et à ma boss que leur site au bout de 5 ans est comme une Renault Safrane.
Il est bien mais il date… Or le web vieillit très vite (plus vite que les bagnoles) et un site qui n’est plus en phase avec son époque est soit boudé par ses visiteurs soit has-been dans les réponses aux nouveaux usages (exemple: n’importe quel client veut aujourd’hui pouvoir gérer l’intégralité du contenu de son site ou voir son site compatible iphone donc sans flash).
On ne peut en aucun cas au niveau du web promettre à un client un site qui ne sera pas complètement refait après 5 ans. Je ne le crois pas.
On ne peut pas voir l’avenir et les (très bons) choix que l’on fait aujourd’hui seront peut-être mauvais demain.
Bref, il faut partir du postulat qu’un site doit subir au moins une petite refonte tous les 2/3 ans et une refonte complète tous les 5 ans si l’on veut avoir un site en phase avec les usages (ergonomie, nouveaux usages, etc) et technologies.
Avant la sortie de SF 1.x, on en était à essayer de promouvoir l’usage de PHP5 et la plupart des choses qui existaient (avant 2006 on va dire) en opensource étaient des projets amateurs avec une communauté réduite, quasi aucune doc.
Il faut donc relativiser. C’était déjà presque hors norme voir extrêmement novateur il y’a 5 voir 6 ans de sortir un framework aussi pertinent comportant un admin generator, des helpers ajax et j’en passe.
Aujourd’hui ? C’est clair qu’une version 1.5 me ferait clairement de l’oeil (voir du pied).
D’ailleurs personne n’empêche une communauté de se former et de développer cette version 1.5.
Sensio à décider pour aller plus vite de ne pas arriver à SF 2.0 en passant par de multiples versions de « transitions » compatibles entre elle 1.5, 1.6… 1.9., 2.0 demandant chacune leur lot de mise à jour équivalent au final à une refonte totale.
C’est sûrement ce choix qui est critiquable et discutable.
Mais un site développé en 1.0 et mis à jour pour 1.1, 1.2, 1.3 puis 1.4 (oui oui) verrait sûrement un travail équivalent à une passage 1.4 => 2.0.
Cependant, la version 2.0 est nécessaire et logique. Il est clair que Symfony 2 fait table rase du passé et n’a rien à voir avec SF1.x, c’est lourd et déroutant (je suis en train de le tester et de le vivre).
Est-ce qu’il serait raisonnable de faire perdurer Symfony 1.x et d’avoir une version 1.5 qui ne chamboulerait pas tous et promettrait une évolution sympa mais pas révolutionnaire et de voir arriver les trucs nouveaux dans 3 ans ?
En aucun cas, il faut passer à Symfony 2 parce que avant on était (bien) sur Symfony 1.
De ce fait, Symfony 2 n’est plus Symfony (pas seulement sur le plan du code) et méritera donc d’être étudié et testé face à ses concurrents lorsque le besoin de changer de framework apparaîtra.
Alexandre Salomé: http://trac.symfony-project.org/report/23 + http://guru.sensiolabs.com/ = CQFD
Faut arrêter de vouloir le beurre, l’argent de la crémière et le cul de la crèmerie (ou l’inverse, je sais plus)
@Eric D. Je ne critique aucunement la gestion des LTS de sf1, qui était excellente. Cela dit, sf1.4 ne sera effectivement maintenue que jusqu’à novembre 2012.
Fixer une LTS n’empêche pas de poursuivre les développements ensuite. Me dérange le fait qu’on n’ait pas laissé symfony parvenir au niveau de maturité qu’on était en droit d’en attendre.
à ce moment là je dirai « c’est l’open source ».
Tu as quelque chose gratuitement et basé sur l’intérêt de chacun à le faire évoluer. Tu n’as pas eu d’engagement là dessus, et tu n’en auras pas plus sur d’autres projets que Symfony (pas plus Django qu’ailleurs).
Peut être que tel ou tel projet n’aura pas fait de réécriture sur une certaine période alors que Symfony l’a fait, mais si tu avais demandé aux mainteneurs de Django « est-ce que vous m’assurez que vous continuerez les évolutions sur cette base dans 2 ans et pas sur une nouvelle » tu aurais eu un beau « on ne sait pas ».
L’alternative c’est de payer quelqu’un à faire quelque chose de non rentable pour lui. Je doute que toi, Freelance, tu souhaites absorber les coûts d’évolution de Symfony 1.4 par toi même, et je vois mal au nom de quoi Sensio le ferait s’il n’y a pas intérêt.
Même dans les société où on paye cher le support, les versions anciennes ont très très rarement des évolutions fonctionnelles. Je n’ai même aucun exemple en tête.
Tu n’es pas en « droit » d’attendre quelque chose sur ce côté là. Il n’y a pas eu ce genre de promesses, il n’y en aura jamais, pas plus chez Sensio qu’ailleurs.
Par contre, la garantie que tu as, c’est que Sensio fait de l’Open Source. Peut être qu’une grosse organisation aura suffisamment investit dessus pour faire évoluer elle-même S1.4. Peut être que plein de gens comme toi vont se grouper pour le faire. Au pire si vraiment tu y as intérêt, tu peux le faire toi ou payer quelqu’un pour le faire.
Si tu vois en Django un monde meilleur de ce point de vue là, j’ai peur que tu te mettes le doigt dans l’oeil jusqu’au coude comme on dit. Surtout qu’il y a vraisembablement moins de sites conséquent en production sur Django, surtout de sites qui risquent de ne pas suivre les évolutions de versions, et donc que l’abandon d’une potentielle ancienne version sera d’autant plus brutal.
@Franck :
REPORT 23 : cf ce qui est déjà dit sur les LTS. En gros si y’a une faille de sécurité, un bug critique, OK. Rajouter des features, c’est pas l’objectif du LTS. Les tickets ouverts, ça ne veut rien dire. Si tu me trouves un exemple *concret* d’un bug non supporté.
GURU : Il n’est nullement question de support de symfony, mais expertise sur symfony.
@thibault : trouves moi le parfait exemple de bug non-supporté, qui à ton avis, rentre dans du LTS.
@Alexandre Salomé
Je ne te donne que l’exemple des tickets que j’ai moi même posté, parce que je les connais. Il y en a sans doute un paquet d’autres :
http://trac.symfony-project.org/ticket/8229 (c’est un bug d’intégration avec doctrine, mais doctrine ne gère pas. Ne sera pas corrigé. Admettons)
http://trac.symfony-project.org/ticket/8226 (bug mineur, mais branche gelée, jamais corrigé. Note que la réponse du mainteneur est emblématique de ce sur quoi je râle.)
http://trac.symfony-project.org/ticket/8273 (bug mineur, régression suite à l’ajout d’une nouvelle feature mineure (alors que la branche est censée être « gelée » !), jamais corrigé)
http://trac.symfony-project.org/ticket/8199 (impossible de méler héritage et i18n sans hacker à la main des fichiers autogénérés. « c’est un bug doctrine, trop complexe à corriger, on ne traitera pas »)
Note que ce sont 4 tickets, sur les 5 que j’ai soumis dans ma vie de symfonian. Joli score, non ? Je ne vais pas passer ma vie à en chercher d’autres, mais le bug tracker est plein de bugs ouverts. Si tu veux plus de référence, je pense qu’il n’y a qu’à se baisser.
@Eric D. Je n’exige rien de Sensio, et je ne me sens en droit de rien exiger. D’ailleurs, je ne crois rien dire de tel dans l’article, et je suis parfaitement conscient des tenants et aboutissants de l’open-source.
Je n’idéalise pas non plus django. Je souligne que la manière dont ce projet est géré convient bien mieux à mon besoin propre, que j’ai tâché de décrire en détail.
Toutefois, je n’aime pas trop le double discours. D’un côté, une entreprise avec un discours commercial de pérennité, de maturité, de haute qualité, etc. Et d’un autre côté, on envoie tout à la poubelle en disant « c’est l’open source ». Trop facile.
Parce qu’un projet est open-source n’est pas une raison valable pour faire n’importe quoi avec. Et ce n’est pas une raison pour ne pas pointer ses défauts.
Si demain, L. Torvald s’amuse à introduire des backdors dans le kernel Linux, ou les devs de mozilla des popups aléatoires avec des images de renard, faudra-t-il se taire et dire « ah, c’est l’open-source » ? Bien entendu, c’est un exemple extremement tiré par les cheveux.
Quoi qu’il en soit, on a une entreprise qui promet des choses, et qui n’a pas tenu ses promesses (de mon point de vue, qui est subjectif). Que le projet soit open-source ou non, j’en tire les conséquences, et je vais voir ailleurs.
Salut !
Perso je n’ai jamais travaillé avec Symfony 1.x mais je comprend ta frustration d’autant que Symfony2 change du tout au tout. J’ai l’impression que tu en as plus après Sensio qu’après Symfony lui-même, et à vrai dire je suis assez d’accord avec toi sur les faux arguments qui étaient (et qui sont) avancés.
Mais comme beaucoup l’ont dit, le web change, les technos aussi et rien ne dit que Django n’aura pas aussi à subir une évolution majeure dans quelques temps.
Il y aura toujours des clients qui voudront absolument du PHP, et dans ce cas il sera sans doute difficile de leur imposer du python ou de leur proposer du sf1.x… Il y toujours ZF avec la deuxième version qui devrait arriver, ou CodeIgniter mais pas sur qu’ils bien plus « viables ». Eux aussi vont évoluer.
Je n’étais pas un grand fan des frameworks mais pour avoir un peu testé Symfony2, j’en suis vraiment stupéfait. Le temps d’apprentissage est certes non négligeable mais le framework répond vraiment à toutes les problématiques du développement web (ou quasi, bien pour l’instant je n’en ai pas trouvé !). A ma connaissance il n’y a pas, en PHP, d’équivalent aussi complet.
Bref, si d’aventure il t’arrivait d’avoir à apprendre Sf2, je te conseille le tutoriel suivant : http://j-place.developpez.com/tutoriels/php/creer-premiere-application-web-avec-symfony2/
A++
Si tu veux gagner de l’argent facilement auprès de tes clients, mets-toi à Drupal.
Au final, d’après ce que tu dis j’ai l’impression que tu reproches surtout le fait que de nombreux (trop) tickets ont été passé en wontfix (ici je ne juge pas aussi de la décision) sans être résolu (que ce soient les tiens ou non).
La surpromesse étant la conséquence de ta position donc: la fermeture de ces tickets constituent donc un manquement aux promesses de stabilité des versions de SF.
Pour ma part, j’ai eu une fois une déconvenue similaire.
Au départ, l’helper format_currency arrondissait les nombres aux centimes supérieur (ex: 1.126 => 1,13€).
D’une version mineure à l’autre (1.2.x à 1.2.x il me semble), ils ont décidés que c’était pas bien et que l’arrondis devait être fait coté model et pas coté helper donc plus d’arrondis (1.126 => 1,12€).
Je vous raconte pas l’incidence que peux avoir une telle décision sur un site e-commerce qui voit un grand nombre de prix changé d’un seul coup après une mise à jour mineure… Et je vous raconte pas la galère pour trouver la source du bug quand on cherche partout sauf dans Symfony…
Je ne juge pas car je ne sais pas si l’herbe est plus verte ailleurs. Est-ce que le nombre de ticket non résolu est vraiment plus élevé qu’ailleurs chez Symfony ?
Est-ce qu’il est trop élevé par rapport à ce que Sensio promet car j’imagine que le « 100% ticket résolu » est impossible. Est-ce que le message de Sensio est donc trop prometteur ?
Dur de répondre
Pour ma part globalement, je suis très satisfait de Symfony 1.x mais je n’ai jamais testé autre chose. Ah si WordPress, arf
Mmm, de PHP vers python et Django, tu n’es pas le premier :
http://neokraft.net/2010/07/11/et-jai-aime-coder
Les gars arrêtez de vous faire mal, quoiqu’il en soit ça fait ch*** un grand nombre de personnes, le fait est là.
Freezer pendant 2 ans les features d’un framework web, sans assurer aucune rétro-compatibilité ensuite ça pique, quoique les gens en disent.
Les faits sont là, et le choix est assez évident :
- Aller voir ailleurs (et peut être ré-étudier Symfony2 quand il sera sorti)
- Utiliser Symfony2 de suite, si on a l’argent pour
Les deux choix se défendent. Merci pour ton point de vue Thibault en tout cas, je partage le constat sur bien des points.
Je partage également ton avis : on n’a pas laissé sa chance à symfony 1.x de devenir ce qu’il aurait dû être. C’est juste dommage que le projet ait été complètement freezé. J’attends le fork communautaire
Pingback: • PHP 5.4, major/minor upgrades, backwards compatibility and the dependency spiral | test.ical.ly
Je suis a peu près dans le même cas que toi mais avec ZF. J’espère qu’il ne feront pas les mêmes choix. A priori ça a l’air mieux parti car bien que ZF2 avance, il sort encore des nouvelles releases pour ZF…
Et même si je touche un peu a python, il n’est pas question pour moi de franchir le pas définitivement.
Je ne donnerai pas mon avis sur l’article, symfony, sensio, la météo ou autre, non, le seul truc qui me choque dans cet article, ce sont les commentaires qui en suivent.
Un gars pond un article où il donne sa vision des choses, son ressenti, ses expériences. Il explique le contexte pour que tout le monde comprenne qu’il y a une raison et que c’est pas juste qu’il s’est levé ce matin du mauvais pied et qu’il avait envie de cracher gratuitement sur quelqu’un… et après tout ça, on vient lui dire qu’il a tord.
Non.
Il est tout à fait impossible d’avoir tord avec un ressenti. Il explique ce qu’il ressent, c’est comme ça.
Vous ne partagez pas le même point de vue, ok ? Exprimez-le, mais p****n, dites pas que tout ça c’est faux…
On va bientôt plus avoir le droit de s’exprimer sur son propre blog…
vindiou…
J’ai appris Symfony 1.4, ExtJS 3, (X)HTML 4 et vim. Maintenant je vais devoir apprendre Symfony 2, ExtJS 4 et HTML 5 (heureusement vim est inaltérable
.
Ca fait partie de la vie de développeur, sinon j’aurais fait prof d’histoire.
Sensio a développé un framework et l’a publié sous licence libre. Les utilisateurs qui gagnent leur vie, ou tout au moins une partie de leur, grâce à l’utilisation de ce framework devraient maintenir cette branche 1.x. En occultant le fait que ce serait un juste retour des choses, c’est simplement du bon sens.
@Guillaume Encore une fois, apprendre de nouvelles technos n’est pas le problème, ni le point de l’article. Et encore une fois, le fait qu’un logiciel soit open-source ne devrait pas être un argument parapluie pour que l’éditeur puisse se débarasser de toutes responsabilités.
Un trés bon exemple similaire ici :
http://mike.kaply.com/2011/06/23/understanding-the-corporate-impact/
« »"
Tu passes à Django, Ok. Mais y passer parce que tu crois que Django va rester Django encore dans 5 ans, est une très mauvaise raison de passer à Django.
« »"
J’utilise Django depuis plus de 5 ans (depuis la 0.9.1 si mon souvenir est bon), et pendant ce temps, Django a énormément évolué et continue à évoluer… tout en restant Django. Les évolutions, ça se gère.
« »"
Dans 2 ans, dans 4 ans, si ça se trouve, les core dev de Django voudront eux aussi refaire tout from scratch.
« »"
Ayant suivi les évolutions du projet depuis sa première release public, je me permet d’en douter très fortement. Ils ont pris leur temps avant la première version stable justement pour éviter un tel risque.
Il faut arrêter de se prendre la tête avec toutes ces histoires sérieux. Le web évolue très vite et on ne peut pas aller contre.
Si Symfony a été entièrement réécrit ce n’est pas juste pour s’amuser. C’est d’une part pour bénéficier des nouveautés offertes par le langage PHP et d’autre part pour combler tout un tas de lacunes que symfony 1.x traîne encore derrière lui.
Le simple fait de passer Symfony à PHP 5.3 pour bénéficier des nouvelles fonctionnalités cassait obligatoirement la compatibilité. Donc autant repartir sur un projet neuf avec des bases seines qui comblent les lacunes du passé et qui s’appuient sur les bonnes pratiques d’aujourd’hui.
Maintenir un projet Open-Source comme Symfony demande énormément de temps. La core team préfère se focaliser sur la nouvelle version plutôt que de maintenir une vieille version pour des années.
La fin du support de symfony 1.x en décembre 2012 est annoncée depuis très longtemps. C’est ensuite aux agences et aux prestataires de se prendre leurs responsabilités et de se donner les moyens de continuer avec une version qui ne bougera plus ou bien d’aller de l’avant en utilisant une nouvelle version.
Un framework n’est qu’un outil !!! Qu’il s’agisse de Symfony, ZF, Django, Rails ou autre, ça reste un outil. Un outil, ça se remplace quand il est cassé ou quand il ne répond plus correctement au besoin.
Avant, les bucherons coupaient leurs arbres avec une scie manuelle. Aujourd’hui, la scie a été remplacée par des tronçonneuses ou des engins mécaniques. L’outil a changé mais le but au final c’est toujours de couper du bois.
Avec un framework web, la finalité reste la même : développer des applications web sur mesure.
A vous de choisir l’outil qui vous semble le plus adapté et avec lequel vous serez le plus productif tout en honorant vos engagements de délais et de qualité auprès de votre client.
Je partage en grande partie ton avis. Même si faisant parti d’un grand compte, j’ai plus de temps pour me former à sf2, il faut quand même justifier le temps passé.
Il ne faut pas sous-estimer la courbe d’apprentissage et l’investissement nécessaire lors du changement de Framework. D’autant que cet investissement doit être facilité par une documentation claire et accessible, et moi qui est débuté avec cakePHP, la doc de ce dernier est a des années lumières de celle de sf (et ce n’est pas un problème de contenu). Sf a une documentation beaucoup trop morcelée sans accès à un sommaire unique digne de ce nom, et je ne m’édenterais pas sur le moteur de recherche du site qui est rarement pertinent (voir jamais).
Tous cela fait que même si sf est supérieur, il demande un investissement en temps plus grand et c’est bien dommage. J’espère que la documentation de Sf2 sera beaucoup plus cohérente et accessible (une bonne indexation sur un bon moteur de recherches serais déjà un grand progrès).
Et encore bravo pour nous faire partager ton ressenti, s’est important aussi de partager nos expériences et nos impressions.
oui merci pour ce billet, on se sent moins seul, je suis sur le même constat quand au cout d’une migration sur sf2 (qui se voit chez d’autres) mais surtout la gestion des releases/bugs/docs/support que j’ai du mal à suivre. Pour l’instant je n’irai pas plus loin que quelques proto sur sf2 pour tester et je ne pense plus utiliser sf1.4 pour de nouveaux projets.
Personnellement je comprends la frustration de l’auteur, on commence à apprendre quelque chose et un jour on nous dit qu’il faut changer.
J’ai eu la même expérience dans mes études, première année cours de flash en AS2, l’année suivante le prof nous dit, « bon cette année on passe à l’AS3, on repart à zéro! ».
Qu’est-ce qu’il faut se dire dans ces cas là, deux choses, soit on fait avec en ce disant que tout ce qu’on a déjà appris c’était pas inutile, soit on reste sur ce qu’on connaît.
Après tu es freelance, je comprends que le temps c’est de l’argent, et tout seul c’est pas facile. Mais si tu as besoin d’aide pour te mettre (qui sait!) à SF2, sache qu’il y a une communauté prête à aider, moi le premier.
Pour le côté marketing, c’est vrai que j’ai toujours souris en entendant le discours que « oui SF 1 ou 2, c’est le plus rapide sur le marché du php, on est les plus fort! »…C’est une stratégie de communication voir manipulation pour attirer les masses et former une communauté…On cautionne ou pas.
Quand à la documentation, celle de SF1 avec Jobeet moi je l’ai bien appréciée (la doc avancée également), celle de SF2 j’en trouve certaines bâclées (formulaire), d’autres bien expliquées (Système de cache par exemple). Peut-être qu’un tutoriel style jobeet serait vraiment un plus, mais j’avais lu que ça ne se ferait pas, dommage, pourquoi ?
Allez, bon courage quand même !
@Gilles
> Quand à la documentation, celle de SF1 avec Jobeet moi je l’ai bien appréciée (la doc avancée également), celle de SF2 j’en trouve certaines bâclées (formulaire)…
La doc ça prend du temps à écrire. Pour l’instant elle est ce qu’elle et elle évolue tous les jours grâce à Ryan et Fabien mais aussi grâce à la communauté qui contribue. Je t’invite à forker le dépôt Github et proposer toi aussi des améliorations de la doc.
La partie sur les formulaire va être améliorée au fil du temps. Les formulaires sont l’un des derniers outils à être stabilisés dans le framework. Normal que la doc ne soit pas encore forcément à la hauteur. Elle ne contient que l’essentiel pour l’instant.
> Peut-être qu’un tutoriel style jobeet serait vraiment un plus, mais j’avais lu que ça ne se ferait pas, dommage, pourquoi ?
Pour l’instant ce n’est pas au programme mais ça changera peut être. La raison est simple. On veut éviter à tout prix d’avoir la même documentation de SF1. Il y a trop de choses dans la doc de SF1 et on ne s’y retrouve plus.
La seconde raison c’est le temps que ça prend à écrire une documentation comme Jobeet. Ce sont des journées de travail donc si des personnes veulent entreprendre ce travail, ils sont les bienvenus là encore. Toutes les bonnes volontés sont accueillies. Pour avoir participer activement à la doc, je peux témoigner du travail que ça représente et malheureusement peu sont les personnes qui tentent d’aller jusqu’au bout après avoir démarré à traduire un ou deux chapitres par exemple.
@Hugo
Le mot bâclé était un peu fort et je le retire. Pour ce qui est de contribuer à la doc, j’aimerai bien, mais les longues rédactions en anglais me limiterait hélas…Difficile de vouloir aider avec un anglais écrit approximatif.
Autre idée pour aider les développeurs même sans une documentation complète, le partage sous github de site réalisé (un genre d’AcmeBundle mais complet…backend/frontend) sous sf2 par exemple. Là aussi je rêve, mais des exemples entiers et fonctionnels aident aussi bien à la compréhension que de la documentation. Ce qui revient à créer un Jobeet like mais sans doc je l’avoue..AcmePizzaBundle par exemple propose quelque chose, sans documentation, mais ça existe. Peut-être regrouper sur le site de symfony ce genre d’exemples éparpillés…
Un petit commentaire de mon avis de jeune qui n’utilise absolument pas symfony dans le monde du travail parce que je ne travaille pas.
Néanmoins, je pense avoir le droit de donner mon ressenti quand même.
Je parle uniquement de symfony1. Symfony2 est un beau produit, sûrement avec beaucoup d’avenir, et une communauté acquise avec la branche 1 qui garanti une meilleure pérennité à mon sens, ou plutôt de meilleurs décisions si possible.
J’ai commencé symfony1 quand j’avais de mémoire 12 ans, ou plutôt il y a 4 ans, après un temps de développement web (même si j’ai testé ZF, le verbose java-like c’est bof). Je pense que la plupart ici utilisant des frameworks, et vu à l’époque la réputation – méritée – de PHP (pas pro, pas de communauté, pas …) c’était juste un avancement énorme (d’ailleurs ça a failli être en perl si ma mémoire est bonne, et un grand ouf !). Donc, oui, symfony je l’utilise encore aujourd’hui mais c’est vrai que je suis déçu. Je n’ai pas de clients à satisfaire donc je n’invoquerais pas la raison professionnelle (même si c’est sûrement la plus viable ici). L’argument que je vais donner est simple : symfony1 n’est plus supporté. Comment ça « le nombre de tickets ouvert n’est pas un argument » ? Ah bon ? Donc, le fait que des bugs (mineurs en fournissant la correction) n’aient été corrigés depuis 1 an (5 ou 6) n’est pas un argument sur le fait que le framework ne soit pas maintenu ? Une LTS a été promise, je suis désolé mais elle n’est pas là. Je ne parle pas des bugs avec les nested forms qui relèvent du masochisme à corriger, mais qu’on ne me dise pas que des bugs de 3 lignes avec des helpers pré-corrigés ne sont pas mergeables !
Néanmoins, j’ai de gros espoirs sur Symfony2 qui s’annonce être un bon produit. J’espère juste que, dans quelques années, lorsque l’on se rendra compte que l’architecture n’est plus adaptée (et ça arrivera !), on préfèrera faire un refactoring plutôt que de jeter encore une fois tout à la poubelle.
_Jeter tout à la poubelle dès que quelque chose se fait rattraper par le temps dans un domaine avec l’évolution la plus rapide – à mes yeux – en programmation est st … Inconsidéré. Absolument inconsidéré, et je vois mal comment on peut demander à autant de gens professionnels de faire ce choix.
Enfin bon, moi je reste avec mon Rails hyper-hype.
« Jeter tout à la poubelle dès que quelque chose se fait rattraper par le temps dans un domaine avec l’évolution la plus rapide – à mes yeux – en programmation est st … Inconsidéré. » Un gros win pour ce commentaire \o/ Sinon, t’as vraiment commencé symfony à 12 ans, ou c’est juste une figure de style ?
Absolument pas une figure de style. J’ai commencé le PHP un peu après mes dix ans, symfony deux ans plus tard et je me mets un peu à Symfony 2
. Et oui, j’ai 16 ans. y’a pas d’âge pour apprécier le bon code
Développeur Symfony à 12 ans (!!!), le futur fabpot est là (ou le futur lead-dev de Symfony 8.0, au choix)
Bonne idée ! (enfin, si on en arrive au 8 c’est qu’il y aura eu un problème quelque part, sachant qu’on critique ici le « cassage » entre la 1.x et la 2.x. Je veux dire : s’il y a 6 versions qui sortent en une dizaine d’années, on peut parier que certains LTS vont valser). Quelle casse pour Symfony 8 ?
version 1 : symfony
version 2 : Symfony
version 3 : (complétez !)
Je suis en plein dans Symfony2 sur un projet assez complexe et je rejoint Thibault sur plusieurs points:
- la durée d’apprentissage vs la rentabilité
- la doc (quelques idées envoyées en vrac avec quelques exemples, pourquoi ne pas relier au moins les références aux cas d’écoles???)
En bref j’attends d’abord d’un framework qu’il me permette de ne pas réinventer la roue : pour aller plus vite, gagner du temps.
Pour l’instant, j’ai l’impression d’en perdre beaucoup sur des choses simples pour pas grand chose.
Bonjour,
Pour la migration, j’ai trouvé cette doc’ qui me semble bien pour faire la transition entre Symfony1 et 2 :
http://symfony.com/doc/current/cookbook/symfony1.html
je connais pas mal symfony1.4 et j ai teste symfony2 aujourd hui.
C est pas mal les namespace, mais c est un peu chiant pour faire du refactoring ??
@Charles tu entends quoi par refactoring ?