Je ne comprends pas trop pourquoi les gens partent sur tous ces microframeworks, vu que deux minutes plus tard tu as dix extentions / plugins / ou partie développer pour mettre authentification / sécu etc.
Tu prends django + django-restframework (fait par Tom Christie) et hop tu as la même chose.
Je pense surtout que beaucoup de personnes ne voient pas qu'on peut très facilement retirer des modules de django (enfin ne pas les charger). Un petit ajoute dans le settings, et tu retirent le moteur de template, les middlwares non voulus etc.
Après encore, faut pas hésiter de sortir du cadre de l'orm etc. Je vois beaucoup trop de dev vouloir absolument faire fonctionner un truc non prévu par le framework en utilisant le framework.
Django va sortir l'agsi pour sa prochaine version (mais pas encore l'orm en async) se qui va peut être le rendre un peu plus hype.
Je crois aussi que beaucoup de personnes préfèrent avoir un "outil modulaire qui n'impose rien" pour faire croire ou se persuader qu'ils ont "choisi" une voie particulière pour un projet "particulier".
On prend l'exemple de node et nestjs (pareil pour flask) :
Je peux choisir ce que je veux, de base c'est super light
Je suis libre de choisir exactement ce que je veux mettre.
Au final un service rest ordinaire avec : une authentification / une gestion de permission / de filtre / des requetes sur des bases de donnée etc.
La différence : 50 modules installés (issue de la communauté, maintenu ou pas par un mec dans son coin), une conf maison, des "choix maison" sur des problématiques tellement courants (comme la gestion de la session) et l'oubli de fonctionnalité de sécu. Mais ça fait plaisir aux devs / chefs de projet.
J'entends aussi (concernant le choix nodejs) c'est le même langage que le front : c'est faux !!!
Tu prend du nestjs et de l'angular : oui c'est en typescript (c'est les mêmes boucles for, la même façon de faire des class ok) mais ça s'arrete là.
- Le backend c'est une api node pour l'accès disque, l'accès à la base de donnée, peut-être un orm (typeorm), de la sérialisation etc, via l'api de node.
- Le frontend : Du HTML, du css, un moteur de template, une api pour manipuler le dom, la gestion des évents utilisateurs, les animations etc.
Bref, un argument pour justifier de coller deux métiers complement différents (oui une personne peut avoir la double compétence, mais c'est bien une double) à un junior qui a être propulsé dev full stack.
Petit scénario :
- On a une supper idée : on va prendre un dev, mais on n'a pas de sous donc ça va être stage / alternance / junior (en fonction du budget)
- Il faut une techno en back et en front rapide à apprendre : ok pour du js, on fait une pierre deux coups
- en back faut pas un truc compliqué, le mec doit codé la solution en deux jours, donc on choisi un truc avec rien dedans, une doc qui se lit en une heure et puis si nécessaire on ajoutera des trucs petits à petit
- en front on va prendre du react, c'est pareil de base il n'y a rien, il pourra démarrer le projet tout de suite.
Attention, je ne dis pas que c'est des mauvais choix, je dis que c'est souvent à partir de mauvaises raisons que ces choix sont fait.
[^] # Re: Et Django?
Posté par fsx999 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 10.
Non c'est pas du tout mort.
Je ne comprends pas trop pourquoi les gens partent sur tous ces microframeworks, vu que deux minutes plus tard tu as dix extentions / plugins / ou partie développer pour mettre authentification / sécu etc.
Tu prends django + django-restframework (fait par Tom Christie) et hop tu as la même chose.
Je pense surtout que beaucoup de personnes ne voient pas qu'on peut très facilement retirer des modules de django (enfin ne pas les charger). Un petit ajoute dans le settings, et tu retirent le moteur de template, les middlwares non voulus etc.
Après encore, faut pas hésiter de sortir du cadre de l'orm etc. Je vois beaucoup trop de dev vouloir absolument faire fonctionner un truc non prévu par le framework en utilisant le framework.
Django va sortir l'agsi pour sa prochaine version (mais pas encore l'orm en async) se qui va peut être le rendre un peu plus hype.
Je crois aussi que beaucoup de personnes préfèrent avoir un "outil modulaire qui n'impose rien" pour faire croire ou se persuader qu'ils ont "choisi" une voie particulière pour un projet "particulier".
On prend l'exemple de node et nestjs (pareil pour flask) :
Au final un service rest ordinaire avec : une authentification / une gestion de permission / de filtre / des requetes sur des bases de donnée etc.
La différence : 50 modules installés (issue de la communauté, maintenu ou pas par un mec dans son coin), une conf maison, des "choix maison" sur des problématiques tellement courants (comme la gestion de la session) et l'oubli de fonctionnalité de sécu. Mais ça fait plaisir aux devs / chefs de projet.
J'entends aussi (concernant le choix nodejs) c'est le même langage que le front : c'est faux !!!
Tu prend du nestjs et de l'angular : oui c'est en typescript (c'est les mêmes boucles for, la même façon de faire des class ok) mais ça s'arrete là.
- Le backend c'est une api node pour l'accès disque, l'accès à la base de donnée, peut-être un orm (typeorm), de la sérialisation etc, via l'api de node.
- Le frontend : Du HTML, du css, un moteur de template, une api pour manipuler le dom, la gestion des évents utilisateurs, les animations etc.
Bref, un argument pour justifier de coller deux métiers complement différents (oui une personne peut avoir la double compétence, mais c'est bien une double) à un junior qui a être propulsé dev full stack.
Petit scénario :
- On a une supper idée : on va prendre un dev, mais on n'a pas de sous donc ça va être stage / alternance / junior (en fonction du budget)
- Il faut une techno en back et en front rapide à apprendre : ok pour du js, on fait une pierre deux coups
- en back faut pas un truc compliqué, le mec doit codé la solution en deux jours, donc on choisi un truc avec rien dedans, une doc qui se lit en une heure et puis si nécessaire on ajoutera des trucs petits à petit
- en front on va prendre du react, c'est pareil de base il n'y a rien, il pourra démarrer le projet tout de suite.
Attention, je ne dis pas que c'est des mauvais choix, je dis que c'est souvent à partir de mauvaises raisons que ces choix sont fait.