Quel langage / framework choisir ?

[Grafikart]

La question se posera au moment du développement mais pour le moment j'hésite entre Laravel / Symfony et Rails.

Ruby on Rails

J'aime le langage et je trouve que le framework permet d'avancer rapidement et offre de bons outils. En revanche, le code peut rapidement être difficile à parcourir à cause du méta-programming qui est fréquent dans le framework et pas sûr que tout le monde soit en mesure de participer dans ce choix technique.

Avantages

• Tests unitaires avec rspec
• Code facile à lire et à écrire
• Moteur de template slim

Inconvénients

• Performance à surveiller
• L'ORM qui engendre des "fat model"
• Je n'ai pas autant d'expérience qu'avec PHP
• Absence de typage
• Le meta programming est à double tranchant

Symfony

J'aime bien l'approche Data Mapper de l'ORM Doctrine fournit dans le framework mais il a de nombreuses limitations qui bloquent assez rapidement (relation polymorphique, hydratation des liaisons pas forcément évidente...) du coup j'ai peur de perdre un temps considérable sur cette partie là.

Avantages

• Facile de trouver des personnes pour collaborer
• Code bien séparé au niveau de la couche base de données par défaut
• Moteur de template Twig

Inconvénients

• Code en général plus long qu'avez les autres frameworks
• L'ORM risque d'être limitant rapidement

Laravel

J'aime bien le code (un peu comme pour rails) mais d'expérience le code devient rapidement difficile à gérer au niveau des Model qui finissent pas englober pas mal de logique (relation, persistance, mutateurs...).

Avantages

• Code facile à écrire / lire
• L'ORM contient les fonctions nécessaire au site

Inconvénients

• L'ORM qui engendre des "fat model"
• Il faudra penser à éviter d'utiliser les façades
• Les mises à jours peuvent être difficiles

Le reste ?

Evidemment il existe d'autres frameworks / langage mais je préfère rester sur qqchose que je maitrise pour créer un code propre ce coup ci ;)

[brandonsueur]

Si tu souhaites avoir du monde qui participe sur le projet, apporter en même temps de la simplicité je pense qu'il serait judicieux de choisir Laravel. 🙂

[acanoenfr]

Après le site web en full javascript ou typescript, ça pourrait être super intéressant. A voir maintenant, tout dépend, comme tu l'as dit @Grafikart, de tes compétences et tes besoins.

[ghost]

Étant désormais un grand fan de Laravel et on vu des besoins "simple" que demande un site comme le tiens, je serais tenté de dire Laravel.

Ayant une petite expérience avec SF & Laravel je trouve le choix de SF judicieux pour les institutionnels. et assez "gros".

En revanche, je suis pas forcément d'accord avec @brandonsueur, il y aura bien plus de gens pour mettre la main à la patte avec SF que Laravel. On sait tous que en France SF explose (et de loin) Laravel pour ce qui est de la popularité.

Autre point @Grafikart, si jamais tu venais à faire une série un peu "avancé" sur Laravel pour expliquer le développement, ça serait un contenu supplémentaire. Le contenu SF est quand même déja bien en place sur Grafikart actuellement (et le contenu Laravel un peu outdated).

[quenti77]

Pour laravel :

• Si vraiment les gens (et j'en fait parti) préfère twig à blade, on peut très bien l'utiliser via un package et très facilement.
• La ou je travail on s'interdit d'utiliser les façades mais on peut utiliser 2, 3 fonctions comme view() ou response() dans les contrôleurs car c'est vraiment du basique et pour aller plus vite. Tous le reste c'est de l'injection de dépendance.
• Je sais pas de quelle mise à jour tu parles mais si tu parle du framework, ils était en version 5.6 et j'ai fais assez facilement la migration vers la 5.7 et vers la 5.8 (la version 6 est assez facile aussi mais le soucis est sur les dépendances ou certaines ne sont pas encore à jour pour nous).
• Toujours de notre côté, la on pars sur du DDD un peu plus mais avant on était pour les données sur du services -> (queryies) -> model, et on essaye toujours que le code soit le plus simple possible (comme le fait laravel ^^).

Par contre je suis pas contre de voir autre chose que du laravel. Je voulais juste éviter de voir des points comme MAJ difficile ou autre.

[TuxBoy]

Laravel serait un bon choix, il offre vraiment une flexibilité au niveau de l'organisation, il y a l'organisation par Domain (https://stitcher.io/blog/organise-by-domain) de plus, depuis la version 6 ils ont grandement améliorer les perfs (LazyCollection par exemple) et il respecte aussi le Semantic versioning sur le framework maintenant. Pour alléger la partie Model on peut toujours mettre tout ce qui concerne les requêtes dans une classe dédié (genre un repository, plus facile à tester aussi je pense).

ça serait vraiment bien de voir le site Grafikart sur du Laravel :)
Une question comme ça @Grafikart tu n'as pas du tout pensé à CakePHP ?

[Mcdostone]

Je ne sais pas trop quoi répondre à cette question car je ne sais pas si Grafikart a prévu du refactoring sur sa database. Je m'explique: Grafikart énonces par exemple le fait qu'il n'y ait pas de relation polymorphique dans SF (je connais pas le framework). La question que je me pose du coup, c'est: utilises-tu cette fonctionnalité pour le site actuelle?

Conclusion: Pour ma part, il est trop tot pour que je puisse donner un avis pertinent. Certes Grafikart énonce ce qu'il le pousse à refaire le site (c.f. README.md) mais il me semble difficile de choisir un framework sans connaitre les besoins. Je ne sais pas si je suis assez clair.

[SwithFr]

Avis de cœur, mais pas forcément le plus objectif, je partirais sur du Laravel pour la simplicité ce qui est aussi son point faible, trop de façons de faire une même chose ce qui obscurci le code.
La problématique des models qui se chargent en complexité que tu évoques peut-être "contournée" ou limité avec une couche Repository et/ou en définissant en amont de ce à quoi va être limité le model pour ne pas le complexifier avec le temps.

[farpat]

Mon choix subjectif : Laravel 6
=>
Le code est plus " métier " que Symfony : Juste attention à imposer " une norme " de code pour faire les choses de la même façon.
ROR, je ne connais pas plus que ça.

Mon choix objectif : Symfony 4
=> C'est le framework le plus connu en France. Il a des points positifs par rapport à son " concurrent " Laravel (attention c'est subjectif) :

• ORM mieux structuré (pour les relations polymorphiques, il y a des astuces sur stackoverflow)
• Un code plus " strict " (PS : Je déteste le composant Form de Symfony ^^)

[Grafikart]

@Mcdostone Oui j'ai pas mal de relation de ce type. Par exemple :

• les "langages" sont associé à la fois aux tutoriels et aux formations
• Les commentaires sont associé aux articles / tutoriels / formations
• Les reports (forum) sont associé aux Sujets et aux réponses

Dans tous les cas le choix se fera après la conception du diagramme de base de données donc on pourra voir les problèmes à ce moment là pour reparler du choix.

[ndalaba]

J'ai été confronté au même problème que toi.
Le choix entre symfony et laravel (désolé pour ruby, connais pas)

Eloquent > doctrine
blade = twig
Je préfère le routing de symfony(annotation), moins de fichiers à gérer.

La différence s'est faite au niveau du testing
Pour les tests unitaires et fonctionnel (laravel c'est beaucoup plus simple à mettre en place).
Constat personnel.

Après j'ai voulu combiné symfony et eloquent
https://github.com/wouterj/WouterJEloquentBundle/blob/master/Resources/docs/usage.rst#eloquent-orm
mais au final j'ai hésité.

[zimski]

Je partirai sur du Rails

• Pour du site mode content, les performances ne sont pas un grand sujet, The cache is king et encore mieux d’être derrière un CDN.
• StimulusJs offre un bon compromis pour le frontend pour avoir des petits compostant frontend facile à coder et à maintenir, pas besoin de tomber dans du react ou vue.
• Trix qui permet d'avoir un éditeur pour les blog/post avec de l'upload de photo out of the box.

Le méta-programing, c'est très simple faut l'éviter :)

La partie recherche pour un avoir une bonne expérience de recherche, Algolia propose un bon service Saas de recherche, ce qui permet de réduire la complexité interne et virer la couche Elastic Search

Un bon exemple d'un site ROR qui est très performant, il est open-source en plus
dev.to

[maxchene]

Pourquoi pas un petit retour aux sources avec CakePHP (3 ou 4 )qui a bien évolué depuis .

[rebelor]

Tu fais des tutos sur le PHP, y a même de quoi faire ton propre CMS (si vraiment un CMS est nécessaire puisque tu sais exactement ce que tu veux et ce que tu ne veux pas!) alors :
Et pourquoi pas ton propre code ? (là je vais sûrement me faire incendier mais bon pas grave)

[Sh1n1x]

Hello Graf',

Au vu du site actuel et de la technologie utilisée, je partirai sur RoR car :

• Migration de la BDD easy + Model + certaines parties du code (j'imagine la gem Devise et ton interface d'administration)
• Rapidité de développement (et re-dev des vieux controllers/views)

En gros tu as tout à gagner en repartant sur Rails car ça va t'éviter de devoir réécrire un bon 40% du code backend.

[tmicka23]

Hello,
moi je dirais RoR, pour les raisons invoquées par @Sh1n1x et @zimski, et aussi parce que je pourrais participer ! 😆
sinon en dehors de rails, je te pousserais sur Laravel, qui regroupe pas mal d'avantages de Rails, notamment la "simplicité" du code, et puis c'est du PHP, donc facile de trouver des collaborateurs... pour ce qui est des inconvénients, vu ton expérience je suis sûr que tu trouveras des solutions pour chaque technos...

####### EDIT ##########
Rails te permettrais de mettre à jour la formation sur Ruby on Rails aujourd'hui en version 6 et qui apporte de nombreux changement intéressants...
####### END EDIT ######

alors +10 pour RoR et +1 pour Laravel

[okeb]

Salut Jonathan @Grafikart

Pour ma part non choix se porterait vers RUBY ON RAILS
C'est vrai que tu liste des inconvénients, mais avec la nouvelle version 6 je pense qu'il y a de quoi en faire. Et c'est vrai que les models peuvent vite devenir gros mais on a toujours des concern.

En ce qui concern le typage, il n'y a pas vraiment d'alternative, physique la force de ruby c'est justement d'un peu contrebalancer ça. Est ce problématique vraiment?🤔 Honnêtement je ne pense pas.

Donc voilà d'autant plus que si tu change d'avis avec les vuejs et react c'est direct intégré avec turbolinks en deux lignes de code. Perso je suis passé sur ROR a cause de la vitesse de chargement de grafikart.fr malgré le tout plein d'info. C'est pas le meilleur des argument mais ROR n'est pas pour rien.

Recrit grafikart.fr plus proprement avec ROR+swelte+css en dure+MySQL

Donc voilà pour moi c'est le ruby qui l'emporte. D'autant plus que ce ne sera pas un enfer de le mettre a jour où le maintenir

[florentsorel]

Je partirais sur du Zend Framework 3 ☺️ ou Laminas (le jour où on aura des nouvelles dessus 🙄)
J'utiliserais zend-db en écrivant les requêtes SQL à la main.

Parmis tes choix je prendrais Symfony.
Ce que je n'aime pas dans Symfony c'est la configuration par défaut en ayant des validateurs et l'association de sgdb au sein même de l'entité. Pour moi l'entité c'est juste une classe métier qui ne doit pas comprendre d'annotation pour de l'applicatif ou de l'infrastructure.

Personnellement je ne fais pas de relation polymorphique, je crée autant de table que j'ai d'association. Une table PostCategory, une table VideoCategory, etc.
Le fait de faire un where sur ton type ne me plaît pas, que ça soit en terme de performance ou même à écrire.

[betaWeb]

Salut @Grafikart,

Je suis tes vidéos depuis assez longtemps, et je pense que le choix le plus judicieux pour toi serait d'utiliser Laravel. Parce que celui-ci reste rapide à mettre en place, dispose de beaucoup de fonctionnalités embarquées qui faciliteront le dev et est, si on adopte une bonne archi, facilement scalable. Et puis tu aimes travailler avec ce framework il me semble :)
Ca serait le choix de la logique compte tenu de ce que tu as à implémenter (ça reste relativement 'simple', y'a rien de bien complexe).

Après je me demandais : quid du backoffice ? Tu penses le dissocier du front (autre nom de domaine, autre projet, autre techno) ? Ou bien le développer en parallèle sur le même projet ?

[mouhssinelghazzali]

@Grafikart oui je suis d'accord avec toi avant de choisir le framework il faut faire la conception pour tu pourras savoir les problèmes avec la solution si tu termines la conception j'aimerais de voir la conception de la base de données et je suis disponible si tu as besoin d'aide ou de qlq chose

[Grafikart]

@mouhssinelghazzali Je viens de mettre la structure de la base de données sur un autre ticket : #34

@betaWeb Pour le backoffice pour moi ça serait dans le même code car ça me permet de réutiliser les model et le code de l'application.

[Gawaboumgaa]

Pour Ruby On Rails, ça te permettra de réutiliser certaines briques existante, Ruby c'est simple et facile à comprendre pour les débutants qui veulent contribuer et avec RoR 6, on a de quoi faire ;)

[zkiller]

Fait ton propre framework basé sur les middleware cela permettrais même de faire des vidéos.

[agentcobra]

@Grafikart tu n'as pas proposé cakephp !

[bernard-ng]

Pour le langage je propose PHP, et pour le framework symfony, en regardant les Inconvénients et avantages que @Grafikart retient de symfony et laravel, on peut facilement gérer symfony :

• Facile de trouver des personnes pour collaborer (c'est aussi pourquoi on est passé à l'opensource non ? sinon à quoi ça servirait ? )

• Code bien séparé au niveau de la couche base de données par défaut ( encore mieux pour organiser le code )

• Moteur de template Twig ( pour ceux qui utilise twig, vous savez combien ce moteur nous fait gagner en temps et surtout les fonctionnalités disponible )

• Code en général plus long qu'avez les autres frameworks ( plus long mais si on peut facilement le mettre à jour c'est bon ! plutôt qu'un code rapide mais qui pourrait rendre les mises à jours difficile )

[ksom]

Pour le langage je propose PHP, et pour le framework Symfony.
Je rejoins le commentaire de @bernard-ng

Pour les relations polymorphique je ne vois pas le soucis avec Doctrine.
En effet il est possible de gérer cela d'une très bonne manière.

Pour cela 2 choix:
Avec une seule table (utile parfois mais ce je préfère l'autre solution) :
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/inheritance-mapping.html#single-table-inheritance
Avec le join strategy (2 tables):
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/inheritance-mapping.html#class-table-inheritance

Je l'ai déjà utiliser dans un gros projet sans aucun problème.
Tu aurais par exemple 3 entités: Category, TutorialCategory, FormationCategory.
De cette manière tu auras un repository pour chaque. Et le CategoryRepository serait commun à tous.

Je sais que dans ta video tu annonçais que tu ne préférais pas aller vers API/Client.
En disant que ca serait probablement galère et que les frameworks évoluent tout le temps.
J'aurais pour ma part Voter PHP Symfony Api-Platform pour le backend (tu as une full API expose en ayant juste décrit tes entités). Et Angular pour le front (il est stable depuis longtemps, et pour avoir fait des MAJ sur les projets entre Angular 2 jusqu’à 7 je n'ai jamais rencontre de galère.
Pour la SEO no problem c'est embed il y a le server side rendering super easy a mettre en place je l'ai déjà fait de multiple fois.
[EDITED] En gros le server side rendering est gérer simplement avec un petit serveur node qui est fournit (rien a réaliser comme travaille) qui va s'occuper de parser la page demandée cote serveur avant de la renvoyer cote client donc elle est complètement rendered comme ca le serait avec la manière classique. [END EDITED]
Pour le cache -> no problem également c'est gérer directement dans angular avec PWA qui permet d'utiliser le site comme une app mobile ou une app desktop (sans avoir a ouvrir chrome et accéder au site via URL). Et qui ne demande quasiment aucun travail supplémentaire.
[EDITED] Un autre avantage mais qui est moindre étant donne que les videos sont host sur youtube et que je suis pas sur qu'il permettent de les stores (a vérifier) est que le site est accessible offline grace au PWA. Si les videos étaient host sur ton site ca serait possible : exemple sur stackoverflow, un autre exemple et peut être meme possible avec Youtube.[END EDITED]

Avoir le site sous forme d'API aurait permit entre autre par la suite de faire une application native avec Flutter (Google) qui est juste incroyable et qui par exemple aurait pu servir de tutoriel. Pour rappel Flutter permet de créer une application full native iOS et Android (rien a voir avec React ou Ionic ou tout autre cross platform mobile app).

Flutter permet aussi de faire des applications Desktop et Web avec le meme codebase !
Je me suis pas prononcer sur Flutter pour le client Web car je ne suis pas sur s'il a ou non des restrictions en SEO étant donne qu'il utilise un canvas.

[arbims]

@Grafikart tu n'a pas pensé a cakephp dans ça nouvelle version c'est très léger et l'orm très fort et il utilise les route comme dans laravel

[AlbertBeweb]

Sf tout simplement car il est français sans partir dans un chauvinisme extrême, nous avons la chance d'avoir quelque chose de bien et typiquement tout le monde va voir si l'herbe est plus verte ailleurs avec toutes les bonnes raisons que chacun a.
Mais je trouve que supporté nos entreprises françaises commence par là :)
Si ça blesse certains, cela est mon avis et je privilégiai toujours un français si la qualité et les produits sont a peut près similaires.

[tmicka23]

@Grafikart j'ai cru comprendre que le typage était un élément important pour toi de plus en plus, voilà de quoi avancer dans ce sens en Ruby ...
https://youtu.be/jielBIZ40mw

[agentcobra]

PHP 7 permet du typage fort en mode strict

[ksom]

PHP 7 permet du typage fort en mode strict

Et avec 7.4 qui vient de sortir on peut meme typer les propriétés de classes ! ;)

[Grafikart]

Le choix a été fait ! Et pour la partie backend cela sera du coup du Symfony.

Cela n'a pas été un choix simple mais voila mon raisonnement :

• Par rapport à du Nuxt / Next / Sapper, même si je trouve ces outils intéressants je n'ai pas été convaincu par leur utilisation dans les faits et je reste un très fervent partisan du code généré côté serveur avec le minimum de logique métier côté front. Le site est avant tout consulté par des personnes qui ne consultent qu'une ou 2 pages (qui arrivent par les moteur de recherche) et je ne pense pas correspondre au cas d'utilisation de ce genre d'outil. Aussi, je ne suis pas à l'aise avec la nature dynamique du langage JavaScript et je préfère donc limiter son utilisation au front.

• Par rapport à Laravel. C'est un framework que j'apprécie particulièrement et avec lequel je suis plus productif que Symfony. Cependant à l'usage, et dans le long terme, j'ai peur de me retrouver avec les mêmes problèmes qu'avec mon code Rails avec beaucoup de logique un peu partout et une absence de structure au niveau des models. C'est ce dernier point qui constitue un dealbreaker pour moi car il n'est pas évident avec Laravel de connaitre la forme d'un objet (type model) vu qu'il se base sur des méthodes magique pour récupérer les différentes propriétés.

• Par rapport à Rails. Même problème qu'avec le JS, la nature trop dynamique du langage fait qu'il est parfois difficile de connaitre la "forme" d'un objet et l'abondance du meta-programming a déjà montré ses limites dans la version actuelle.

[Ephraim-tuto]

Bonsoir