Je ne connais pas très bien symfony, donc difficile de te donner une comparaison complète. De ce que je connais de symfony, il semble que cela soit un framework plus lourd que Jelix (en terme de ligne de code et temps d'execution). M'enfin faudrait faire des benchs sérieux pour voir.
Cependant, il y a quelques points que j'ai regardé, et sur lequel je pense que Jelix est supérieur. Par exemple, propel ou doctrine c'est bien, mais ce sont des trucs énormes, voir bloatware. En effet, les trucs à la activeRecord "redécouvrent" à chaque requête http le schema d'une table ou d'une base de donnée et inclus donc tout un mécanisme pour générer entièrement les requêtes SQL dynamiquement, à chaque fois qu'il faut faire une requête SQL. (bien que les implémentations tentent de mettre des systèmes de cache un peu partout dans leur code, mais c'est à mon sens plus des bouts de scotch qu'autre chose).
Ça a un intérêt en développement, c'est même sexy à utiliser, mais c'est, pour moi, un truc complètement contre productif dans un environnement en production, une fois que le site est en ligne, dans la mesure où à partir de ce moment là, les schemas des tables ne bougent plus. Partant du constat que la façon la plus performante de faire des requêtes est de les écrire en dur dans le code (ou quasi en dur, puisque généralement on a des paramètres), jDao a été crée en ce sens, tout en évitant au développeur d'écrire des trucs rébarbatifs, voir même du code non sécurisé (puisque jDao génère du code qui est tient compte des problèmatique de SQL injection). À partir d'un fichier qui décrit le mapping (fichier qui peut être généré par une ligne de commande), jDao, à la première execution, génère une classe une bonne fois pour toute, avec des requêtes en dur dans le code de cette classe, comme si tu avais fait toi même la classe métier et écris toi même les requêtes. jDao est ainsi plus léger et permet au framework de ne pas avoir à "redécouvrir" à chaque execution de page la structure d'un enregistrement ou autre. À noter cependant que jDao n'est peut être pas encore aussi puissant que doctrine ou propel, mais je pense de toute façon que son principe de fonctionnement est plus interressant au niveau des performances.
Et j'ai essayé d'avoir la même philosophie dans les autres composants de Jelix : tout est fait dans jelix pour que l'application soit performante, et pour éviter autant que possible, d'une part d'avoir des traitements qui sont inutiles dans un context de production comme je viens de l'expliquer, et d'autre part d'avoir du code mort (des trucs jamais utilisé par l'applis mais toujours chargé), y compris du code qui serait propre à une version de PHP (donc qui serait "mort" pour d'autres versions de PHP): tu peux te construire un framework jelix optimisé pour ta version de PHP, tu as même une édition "GOLD" qui inclus une extension PHP à installer sur le serveur, et qui prend en charge certains traitements de PHP, accélérant donc le fonctionnement.
Et je rajouterai que ce n'est pas par hasard si Jelix a été choisi par les développeurs de la plateforme over-blog, sur laquelle plus de 5 millions de pages sont lues par jour (et même plus, ce chiffre est vieux), et hébergeant plus de 630 000 blogs.
Bon après, en dehors des considérations sur la performance, un framework se juge sur les possibilités qu'il offre par rapport à ses propres besoins dans ses projets (il y a aussi une part de "feeling", vis à vis de la manière dont on créer une application avec tel ou tel framework). Et ça, il n'y a que toi qui puisse faire la part des choses, et donc, plutôt que de lire mon argumentation qui pourrait de toute manière toujours être prise comme totalement partiale et subjective :-), le mieux est que tu ailles voir un peu les quelques tutoriaux pour te faire une idée du truc.
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Jelix 1.0 beta 3. Évalué à 3.
Cependant, il y a quelques points que j'ai regardé, et sur lequel je pense que Jelix est supérieur. Par exemple, propel ou doctrine c'est bien, mais ce sont des trucs énormes, voir bloatware. En effet, les trucs à la activeRecord "redécouvrent" à chaque requête http le schema d'une table ou d'une base de donnée et inclus donc tout un mécanisme pour générer entièrement les requêtes SQL dynamiquement, à chaque fois qu'il faut faire une requête SQL. (bien que les implémentations tentent de mettre des systèmes de cache un peu partout dans leur code, mais c'est à mon sens plus des bouts de scotch qu'autre chose).
Ça a un intérêt en développement, c'est même sexy à utiliser, mais c'est, pour moi, un truc complètement contre productif dans un environnement en production, une fois que le site est en ligne, dans la mesure où à partir de ce moment là, les schemas des tables ne bougent plus. Partant du constat que la façon la plus performante de faire des requêtes est de les écrire en dur dans le code (ou quasi en dur, puisque généralement on a des paramètres), jDao a été crée en ce sens, tout en évitant au développeur d'écrire des trucs rébarbatifs, voir même du code non sécurisé (puisque jDao génère du code qui est tient compte des problèmatique de SQL injection). À partir d'un fichier qui décrit le mapping (fichier qui peut être généré par une ligne de commande), jDao, à la première execution, génère une classe une bonne fois pour toute, avec des requêtes en dur dans le code de cette classe, comme si tu avais fait toi même la classe métier et écris toi même les requêtes. jDao est ainsi plus léger et permet au framework de ne pas avoir à "redécouvrir" à chaque execution de page la structure d'un enregistrement ou autre. À noter cependant que jDao n'est peut être pas encore aussi puissant que doctrine ou propel, mais je pense de toute façon que son principe de fonctionnement est plus interressant au niveau des performances.
Et j'ai essayé d'avoir la même philosophie dans les autres composants de Jelix : tout est fait dans jelix pour que l'application soit performante, et pour éviter autant que possible, d'une part d'avoir des traitements qui sont inutiles dans un context de production comme je viens de l'expliquer, et d'autre part d'avoir du code mort (des trucs jamais utilisé par l'applis mais toujours chargé), y compris du code qui serait propre à une version de PHP (donc qui serait "mort" pour d'autres versions de PHP): tu peux te construire un framework jelix optimisé pour ta version de PHP, tu as même une édition "GOLD" qui inclus une extension PHP à installer sur le serveur, et qui prend en charge certains traitements de PHP, accélérant donc le fonctionnement.
Et je rajouterai que ce n'est pas par hasard si Jelix a été choisi par les développeurs de la plateforme over-blog, sur laquelle plus de 5 millions de pages sont lues par jour (et même plus, ce chiffre est vieux), et hébergeant plus de 630 000 blogs.
Bon après, en dehors des considérations sur la performance, un framework se juge sur les possibilités qu'il offre par rapport à ses propres besoins dans ses projets (il y a aussi une part de "feeling", vis à vis de la manière dont on créer une application avec tel ou tel framework). Et ça, il n'y a que toi qui puisse faire la part des choses, et donc, plutôt que de lire mon argumentation qui pourrait de toute manière toujours être prise comme totalement partiale et subjective :-), le mieux est que tu ailles voir un peu les quelques tutoriaux pour te faire une idée du truc.