Symfony ou Django ou [Flask] ? Angular/React/ [Vuejs 3] /Stimulus?

La valeur d’un framework c’est aussi la standardisation et que d’autres personnes en dehors de ton entreprise peuvent le connaître et que tu n’as donc pas besoin de les former. Un framework maison unique au monde, ou utilisé par 3 pèlerins dans l’univers(exemple) ça devient un problème quand tu dois passer le relai à un autre dev.

2 « J'aime »

C’est intéressant : mais Flask est si léger que cela ? Trop d’après toi ? Et par rapport à ce que j’ai décrit plus haut, j’ai des besoins contradictoires: petit mais ça risque de se complexifier, seul mais je voudrais que ça soit maintenable, et puis mon employabilité que je puisse utiliser mes connaissances ailleurs ?

Flask c’est bien. Surtout rempli de whisky. (ok je sors)

3 « J'aime »

Et sinon je vous ai déjà parlé d’Elixir ? :sweat_smile:

3 « J'aime »

Pour revenir au PHP, mon petit coeur de spécialiste Symfony se tord à la lecture de certains commentaires.
Sans Symfony, point de Laravel. Mais ce dernier est très bien pour débuter dans le monde des frameworks PHP solides basés sur les libs de packagist (c’est un écosystème). La rolls dans le genre c’est Symfony évidemment. Il a montré la voie a tous les autres et on considère même qu’il a sauvé PHP à lui seul… Si tu maîtrise les concepts de SF, tu maîtrises de fait 90% des concepts de tous les frameworks modernes quel que soit le langage (js/ruby/python/…). Donc cracher sur SF, j’accepte pas ;).

Mais pour débuter, oui Laravel, très bien. Go, fonce. La communauté fr est hyper importante et trouver de l’aide sera très facile. Ensuite, un jour tu seras limités, surement, et tu passeras à Symfony :wink:

Les frameworks en vogue sont

  • tout ce qui est basé sur Symfony (Laravel, Drupal, et le maître Symfony)
  • React qui est du JS plutôt avancé dont j’adore la philosophie. Angular son concurrent est vieux dans sa conception déjà…
  • mention spécial à Django qui a sorti le python pour faire autre chose que du « scripting ».

Ils ne sont pas du tout incompatibles (au contraire, on un projet : API sous SF, front en React, calcul des chiffres du soir en python). Les autres reste loin dans l’utilisation et même s’ils sont sexys, le marché du travail est une niche au contraire des framework sus cités.

T’as du boulot pour 10ans en maîtrisant ces technos.

On parle là de dev web open source. Il existe à coté des écosystèmes complets fermés de type LightRay par exemple… mais c’est un autre thread qu’il faut ouvrir.

:smile: :+1: Et en plus fait par des petits français !

yes!

Cool. :slight_smile:

Heu là non. :slight_smile: J’ai beaucoup appris en regardant les codes existants, en dépiotant les github et stackoverflow. Je préfère nettement l’open source.

édit : Comme tu l’as compris je me dirige davantage vers Django (ou Flask), vu mon profil et mes souhaits à propos des données scientifiques et industrielles.

Il ne faut pas confondre le voyage avec la destination. Ce que je décrivais est une esthétique, un idéal vers lesquels tendre (la « culture DevOps » et la « culture Agile »). Ce n’est pas un truc qu’on décide du jour au lendemain, même à l’échelle du DSI d’une grosse boîte. Ça prend du temps.

Mais c’est intéressant, même quand on bosse seul, même en étant le seul informaticien de la boîte, de mettre en place une culture (la « culture Philippe » du coup !). Parce que justement certaines de ces choses sont plus faciles à faire seul. Quand tu dis « échange de demande de fonctionnalités à l’arrache tout à l’oral », tu ne te doutes peut-être pas du nombre de chefs de projets et de développeurs qui pleurent des larmes de bonheur à l’idée que ça existe, un utilisateur à qui on peut parler en direct :slight_smile:

Entièrement d’accord avec toi. Quelqu’un a fait la curation des outils, la doc, et les gens sont recrutables directement avec les compétences pour réaliser des projets. Je ne nie pas la valeur de tout ça, loin de moi l’idée.

Et je dis bien que je suis biaisé quand je dis que je n’aime pas les gros frameworks. Ça vient largement du fait que je suis un couteau-suisse, pas une lame de rasoir. Et c’est pour ça que je me permets de conseiller @Phil dans ce sens, c’est que j’ai l’impression que c’est aussi vers ça qu’il tend (et que ça lui plaît).

Comme disait un de mes chefs de projets, pour enchaîner une deuxième métaphore, parfois un mec qui sait faire du tunning sur une R5, c’est plus utile qu’un mec qui connaît le fonctionnement d’un moteur v8 sur le bout des doigts.

J’avais ce discours ya 10ans. Je ne suis plus du tout d’accord avec, parce que le web ne peut plus se contenter de développeur qui font leur tambouille tout seul.
Parce que framework ne rime pas forcement avec enfermement techno. C’est l’inverse dans SF, bien au contraire.
Parce que framework n’oblige pas à réinventer la roue à chaque développement (vous en avez pas marre de refaire un CRUD à chaque fois ? sérieux…)
Parce que framework ça veut dire bosser plus facilement en équipe.

Quand on me parle de moteur maison, je fuis à chaque fois car c’est toujours la même rengaine : ils ont réinventé la roue et évidemment ya des failles partout car on ne remplace pas le développement sur 15ans d’un framework par des équipes et collaborateurs du monde entier par 3 gus dans un bureau qui pensent faire mieux que tout le monde…

Mais je suis peut être déjà trop vieux… je suis aussi agile sur une R5 qu’un moteur V8 avec l’experience :wink:

1 « J'aime »

Ah mais qu’on se comprenne bien, je n’ai pas dit que je préconise du zéro framework, et de tout faire à la main. Mais j’ai une préférence infinie pour les frameworks légers, et l’approche micro-services.

merci.

heu pas sûr :slight_smile:

Mon cœur balance entre Django et Flask quand je lis les messages ici. Surtout que je n’ai pas fait beaucoup de framework, j’ai besoin d’un minimum de structure, pas de réinventer la roue. Et je ne voudrais pas me retrouver avec un truc qui part dans tous les sens. Pour R Shiny, selon mon niveau d’expérience j’ai essayé plusieurs organisations, je me suis amélioré. Mais bon c’est trop made by Philippe. Et sur R Shiny on a le choix entre packages ou rien. Or les packages c’est pour livrer en stand-alone du R, ce que je ne veux pas faire, je fais un site. D’où mon choix de ma propre structure puisque R Shiny n’est pas fait pour les gros sites. J’ai peur d’avoir les mêmes soucis avec Flask.

Si si en BI on m’a proposé des missions que j’ai refusé où l’utilisateur était vraiment inaccessible par choix. Des postes de proxy product owner où on voit ni utilisateurs ni développeurs sauf peut-être par email et zoom.Tu me diras c’est déjà ça.

Mais le plus fort c’était une proposition dans une banque pour un poste de CP+dév BI. C’était en entretiens avec plusieurs candidats ensemble. J’ai posé la même question selon tout les angles possibles. Je peux discuter avec les utilisateurs ? Non non c’est un intermédiaire et en plus ce n’est même pas un AMOA. Impossible, niet. Pour la petite histoire j’ai dit pendant l’entretien collectif qu’à ce compte ça ne m’intéressait pas alors que j’avais l’impression d’être parmi ceux qui pouvait récupérer ce poste.

Donc j’évite les gros comptes sauf les gros comptes industriels où ils ont une culture moins bureaucratique.

1 « J'aime »

Je précise : je pense que tu as un profil couteau-suisse. Rien que ton récit de tes expériences et des technos que tu as abordées, ça trace une trajectoire de quelqu’un qui veut avoir du recul, et pas juste de la maîtrise technique. C’est mon impression. Dis-nous si je me trompe :slight_smile:

Oui tout à fait mais j’ai du mal à voir à partir de cela ce qui me ferait pencher vers Flask. :yum:

Mais j’ai l’impression à te lire que Django est la rigidité incarnée et que Flask c’est certes la liberté pour toi, mais je lis aussi par ailleurs dans ce fil que c’est aussi être en roue libre totale. C’est un peu extrême.

Il y un excellent point avec R, un écosystème très fiable. Tout en ayant une bonne interaction avec le shell et ssh etc . Avec des dépendances fiables sans doute grâce au CRAN (Comprehensive R Archive Network). Avec en plus un bon système d’appel à Python ainsi qu’une compilation avec du C++ multi plateforme quand on veut du compilé. (Je n’ai pas fait du C++ pour R mais lu des solutions comme cela, et lors des installs de packages on le voit aussi agir avec C++).

Tout ça pour dire qu’avec Flask dès qu’on sort des sentiers balisés, et statistiquement on en sort très vite puisque ce framework est léger, c’est à chacun sa solution. Je veux éviter quand même d’être avec ma machette dans les bois à progresser dans les ronces et broussailles alors qu’il y a un chemin à côté. Ce qui n’a pas l’air d’être le cas avec Django.(**)

As-tu des éléments à me donner pour me prouver que la légèreté de Flask n’est pas trop légère ?

J’ai trouvé un article assez bien fait sur une comparaison des fonctionnalités.

Pas de debug visuel pour Django. Mais qu’il n’y ait pas de MVC ni de forms (*) dans Flask me gêne.

Flask : « The structure of the project layout for Flask web framework is random.» :smiley:

edit : *= Pas de forms ça veut dire pas de CRUD ? Il faut tout se fader ? :slight_smile: Alors que justement je viens de R Shiny qui ne sait pas gérer les forms et que je cherche un framework qui le fasse. Ou alors je n’ai pas compris.

édit 2: ** pour mes analogies foireuses, Django serait une autoroute de laquelle on ne peut pas sortir ?

:kissing_heart:

J’ai une entreprise partenaire qui a un monolithe legacy monstrueux et on l’aide à tout transformer/moderniser en micro service : après 3 ans de boulot, leur projet respire enfin et en plus avec un peu d’IA, de sémantiques & co on peut faire de plus en plus d’orchestration autonome et automatique.

Côté dev, ils revivent aussi avec une plus grosse liberté dans les techno.

Le point noir, c’est clairement le spaghetti que ça peut devenir si c’est fait au pifaumetre et pas/mal documenté.

Dans R Shiny il y a un unique point d’entrée.

J’ai dû installer une solution externe à Shiny, un package R qui s’appelle plumber, pour faire quelques Api. C’est vrai que ça m’avait gêné. Après c’est sans doute RStudio qui arbitre entre ses licences commerciales et ouvertes pour Shiny.

edit : Je ne cherche pas à remplacer R Shiny là où il est bon. Je cherche un framework qui sache compléter R Shiny là où il pêche.

Pas sans connaître plus précisément tes besoins.

Mais je veux faire la distinction entre ce que j’avais compris au départ comme « j’aimerais apprendre X » et ce qui ressort un peu plus de tes dernières réponses, qui est plutôt « j’aimerais me servir de X de manière concrète pour renforcer ce que mon projet fait déjà ». Les deux besoins ne tirent pas les mêmes rapports engagement/bénéfices.

Flask est avantageux pour apprendre moins de choses, moins structurées, mais les mettre en application rapidement. Du coup c’est aussi avantageux pour embrayer vite sur les outillages annexes (puisque tu as plus de « bande passante cérébrale » pour emmagasiner ces savoirs là en même temps). C’est un meilleur choix pour se former en autodidacte, et/ou pour prototyper.

Dans cette optique, un exemple de plan de formation serait de créer une API REST qui correspond actuellement à une de tes ressources principales dans une des bases de données SQL que tu as. Du pur CRUD à trois niveaux : au niveau SQL (Alchemy), au niveau REST (Flask REST), et au niveau IHM (du simple JQuery ce sera déjà tip top). Si tu sais faire une vue comme ça, du modèle jusqu’à l’IHM, tu auras le feeling de ce que ça implique au niveau Python. Ajoute quelques tests unitaires, et tu as déjà un vrai projet minimaliste de micro-service.

Note : si tu vas dans cette direction, tu peux jeter un oeil aux dossiers « exemple » dans les projets Flask, il y a souvent des choses sympa pour foncer tête baissée.

En revanche, si tu veux plutôt bosser en mode framework, avec Django, je te conseillerais une autre approche. Prends la documentation du projet, et lis-la. Vraiment… Tu prends les concepts, un par un, et tu lis la théorie avant même d’y toucher. Quand tu as lu la doc, là tu prend un projet existant (type « pet shop »), et tu pars de ça pour y intégrer une vue à toi.

Ce sont deux approches radicalement différentes. Je crois que je n’ai pas besoin de dire laquelle je préfère :slight_smile:

1 « J'aime »

Côté IHM du Jquery ? Il y a un système de template avec Jinja2 pourtant ?

En fait je veux apprendre mais pas seulement pour la beauté du geste. R Shiny est très bon en dashboard, courbe et même gestion de l’IHM. En revanche pour ce qui est mise à jour de données c’est pas trop ça que ce soit front (absence de forms) que back où j’ai recrée un système de forms basique mais non modulaire que je dois réécrire à chaque fois. D’ailleurs j’ai aussi du créer un système de mise à jour pour SQL server, qui me génère des requêtes SQL à partir d’un dataframe.

Et donc pour jouer sur les mots c’est plutôt une recherche de complément de ce qu’il ne sait pas faire, mais pas un renforcement ni un remplacement.

édit : mais aussi un apprentissage de quelque chose de complet pour enrichir mon CV.

Comme mon pitch c’est « pour apprendre, plus c’est simple, plus c’est rapide, mieux c’est ! », bah JQuery (ou même du pur JS) adossé à une API REST de type CRUD tu ne peux pas faire plus simple et efficace. Un appel Ajax sur un bouton « ajouter », un appel sur un bouton « supprimer », un appel pour remplir un tableau, et un appel pour éditer une ligne du tableau… Et tu as une app. Côté serveur, tu sers une API. Côté client ton JS génère la vue. Et tu es presque à l’état de l’art en terme d’architecture web ultra-light.

Tu peux très bien faire ta vue côté serveur. On fait ça depuis les années 80, une époque où les clients n’était pas assez rapides pour gérer quoi que ce soit. Mais en 2020 c’est plutôt un anti-pattern (même si ça revient à la mode régulièrement…). Que ça soit en Python ou PHP, ou même avec JSP dans le monde Java, ou NodeJS sur le backend dans le monde JS, c’est pas très fifou à mes yeux. Ton serveur est là pour faire le gros du travail (tenir la charge), pas pour gérer de l’IHM. D’ailleurs, quand tu commences à penser Cloud, qu’est-ce que tu préfères : une IHM générée côté serveur où c’est toi qui paies le CPU à la seconde, ou une IHM générée côté client ?* :slight_smile:

-* La réponse sérieuse est : ça dépend du coût de la seconde de CPU par rapport au coup des Ko de données sur le réseau quand tu transfères la page avec le JS hors cache…

L’idée du micro service est de tout rentre indépendants et de ne passer plus que par des webservice (REST ou autre comme soap) pour faire tout communiquer.

Vu que ton ihm et ton modèle seront chacun dans un coin, il n’y a plus de limitation technique imposée par la communication. Il faudra documenter tes endpoint et c’est tout. Tu peux aussi bien faire du python, du Java, du R, etc. N’importe quoi du moment que tu peux consommer un webservice. Tu as même des extensions pour navigateur (voir le navigateur lui même) qui te propose ça.

La, on parle même pas de micro service mais juste de service. Quand on va plus loin dans la servicisation(?), c’est chaque bloque fonctionnel qui propose un endpoint pour une plus grande interoperabilité.

(Et après, on parle plus de programmation orientée objet mais de programmation orientée agent quand on ajoute de la proaction)

C’est vraiment une philosophie de développement.

Il faut donc que tu te penches sur 2 choses : ce qui t’amuse ( parce que c’est important) et ce qui te rend service (parce que ça te nourrit).

Dans cette optique plutôt que tout réinventer il faudrait passer par de l’Angular ou du Vue.js (ou du React). J’ai d’ailleurs vu, lorsque j’étais PO, un projet en back Java, dont les échanges avec l’IHM était uniquement via Api. Avec de l’Angular.

Ce n’est pas de l’AS400 ni du gros système non plus. Il me semble que R Shiny fonctionne de façon transparente comme tu me dis. Quand on fait un Ctrl-U on ne voit que quelques div cibles. À partir d’un fichier ui.R il génére tout un IHM (qu’on voit avec F12) . Mais c’est lui gère les échanges entre front et back (sauf quand j’ai fait un truc en ajax dont @Mistermick m’a aidé à corriger un souci là (lien)) .

Une absence de CRUD et de template ne me gêne pas dans un IHM interactif sans beaucoup de saisie, en revanche avec pas mal de saisie je n’en dirai pas autant.

Ça m’amuse de réinventer la roue mais pas pour tout, c’est-à-dire ou bien pour apprendre ou bien pour tordre à ma manière une fonctionnalité dont je préfère mon implémentation à celle existante. Après, tout refaire pour le plaisir, ben non ça m’amuse moins surtout quand il existe des solutions solides et bien pensées. Ce que j’ai fait pour mon gros projet en R Shiny : ne m’interdire aucun développement hors des sentiers battus si nécessaire, mais utiliser les helpers et gestion de l’IHM quand ça fonctionne bien.

Et en plus si je vais vers du Flask, très léger, ça veut dire qu’il faut aussi que je me mette à un framework front. C’est-à-dire remplacer un apprentissage Django par un apprentissage Flask + un apprentissage Vue.js ( *** ) . D’un framework léger Flask je vais me retrouver dans un tunnel d’apprentissage et de mise en place. ( ** )

Plus je vous lis tout les 2, plus je me dis que Django serait préférable à tout point de vue. Une fois que je me serai fait les dents dessus peut-être que je me mettrai Flask + Vue.js après une expérience plus importante en Django. ( * )

À moins que Django soit une usine à gaz. Ce qui ne semble pas être le cas dans l’exemple du projet «jllorencetti/pets» dont le lien github a été posté dans un des messages précédents.

edit : *= Et pour des micros projets Flask sera sûrement pertinent, amusant et intéressant, mais pour un projet de taille moyenne je n’en suis pas persuadé. :slight_smile:

édit 2: ** en plus avec du Flask+Vue j’aurais moins de fonctionnalités qu’avec Django tout seul ! J’y perds en investissement de mise en place comparé aux fonctionnalités.

édit 3: *** Je n’arrête pas de parler de Vue.js car il me paraît plus souple qu’Angular qui me paraît assez rigide et avec une courbe d’apprentissage assez forte . Et la syntaxe de React me gêne notamment, mais pas que, à cause du fait de mélanger du js avec de l’html sans quote .

Angular ou VueJS ou ReactJS vs JQuery en fait tu retombes exactement sur le même débat fondamental : est-ce que tu veux embarquer un framework structurant, lire sa doc, te prendre sa lourdeur.

Tu peux appliquer quasi-strictement tous les mêmes critères que j’ai mentionnés pour Flask vs Django, pour faire ton choix. Sauf qu’en plus, dans le monde JS, tu oublies le LTS (ce que mentionnait déjà @damaki plus haut)… Dans un an ton code sera de la dette technique si tu ne le tiens pas à jour. Alors que du code JQuery tu peux le laisser tourner des années en montant juste la version de la lib (les fonctions de bases sont maintenant trèèèèès rarement dépréciées).