Discussion :

[frfancha]

J'ai bosser sur un projet en parallèle avec une grosse boite. Honnêtement du haut de mes quelques années d'expérience dans l'informatique pro, c'était soit de gros branquignol, soit des feignants... Par exemple champ Code Postal à 255 caractères en saisie libre... Et moi coter WS j'ai du surblinder mes vérifications parce qu'aucune données envoyée n'était vérifier ou correctement calibrée. Et ça malgré de multiple réunion... En même temps ils avait dans les 2 ans de retard
Le client à fini par les dégager et engager un autre prestataire pour finir le travail et qu'est ce que ça fait du bien de travailler avec quelqu'un qui sais ce qu'il fait...

Bref, j'suis pas certain que ce soit qu'une question de moyen. C'est une question de volontés.

Heu là l'exemple est pas terrible, de toute façon les bonnes pratiques de base c'est que TOUTES les vérifications sont faites côté serveur, même si certaines sont déjà faites côté client.
C'est vraiment la base de la base.
Donc que le champ code postal soit pourri côté client ou pas ça change strictement RIEN au travail à faire.
Maintenant ça améliore l'expérience utilisateur si il a un retour immédiat côté client en cas d'erreur au lieu d'attendre que la validation serveur l'arrête bien sûr.

[herdans]

Béotien
Les frameworks sont des normes qui rassurent les gens aux commandes. Si les sbires développent dans un framework, ils seront plus facilement remplaçables techniquement par d'autres pions, quand des sacrifices seront nécessaires pour optimiser la marge.

Développeur
Du point de vue développeur, ces frameworks permettent d'automatiser certains processus donc de gagner du temps. L'inconvénient c'est que la complexité se reporte sur la maîtrise de la techno, au lieu de l'écriture du code.

Sécurité
Au niveau SSI, l'utilisation croissante de framework, expose les projets peu maintenus au risque que le site soit piraté. En effet, l'exploit d'une faille de sécurité touchera potentiellement un nombre proportionnel de site conçu à partir de ces frameworks.

Utilisateur
En tout cas ceux utilisés pour valider l'acceptation du RGPD, cookies ... nuisent grandement à la navigation de l'utilisateur.

[defZero]

Quel est votre avis sur le sujet ?

Tous projets est soumis à la loi universelle du triangle d'Or, donc il faut que le MOA (Maitre d'Ouvrage) et le MOE (Maitre d'Oeuvre) se mettent d'accord sur ce qui est le plus important pour le projet, entre Couts, Délais et Qualité.
Sachant qu'il ne pourront pas avoir les 3 et que les 2 critères ayant le plus d'importance en France sont généralement Couts & Délais.

Partant de là, la question de l'utilité des framework, n'en est même plus une.
C'est à date, le seule moyen d'apporter un minimum de Qualité sur une base de code faite rapidement et à moindre frais, car le critère Qualité est externalisé.

C'est cette externalisation qui pause un vrai problème de confiance et de ressources.
Les Framework étant également soumis, comme tous projets, au triangle d'Or, il faut déterminer les critères ayant étaient prioritaire.
Et cela me parait difficile sans de multiple équipes de review & test, ce qui implique de "faire confiance" en une équipe de dev, qui n'as pas forcement les ressources nécessaires.

Bref, tout le monde est d'accord pour dire que les Frameworks ne sont pas le nirvana, mais on ne peut tout simplement pas faire sans, dans l'état actuel des contraintes imposé.

P.S. : La solution étant en grande partie d’arrêter de faire croire aux clients que tout peut être fait par n'importe qui et à n'importe quel prix, dans un délais correspondant parfaitement aux désidérata.
En claire, il faudrait vraiment que les MOE apprennent à dire "non" au clients.
Chose dont je doute qu'elle arrive un jour .

Les frameworks Web détruisent-ils vraiment les performances du Web ?

Par rapport à quoi ? (les perf c'est toujours relatif pour moi)

Certains algorithme implémenter dans des Frameworks sont largement plus rapide et optimisé que ce que j’aurais su coder moi même .
Après, les problèmes de performances des Frameworks Web, sont principalement du, je pense, au fait que le Tree Shaking et d'autres optimisations sont tout simplement très compliquées à mettre en place sur une base de code JS & CSS (ressource externes, généré dynamiquement, ...etc).

Le Web est partit dans une direction à l'opposé de ce pourquoi il à était conçue, tout en voulant garder les même bloques de bases.
Forcement, ça complique tout et tous ce qui est compliqué, finit forcement par avoir des couts (performance, dettes techno, ...etc).
Les bloques de construction du Web actuel et l'utilisation qui en est faites, sont les seules responsables des critiques qui sont faites au Web aujourd'hui.
Maintenant, si on reconstruisait le Web avec des Technos d'aujourd'hui et avec l’expérience accumulé, je crois bien que l'on serait sur quelque chose de plus simple, cohérent et adapter à l'usage qui en est fait.

Enfin, tout ça pour dire que la faute et à partager entre Utilisateurs, Clients et MOE.

Quelles sont votre position et votre stratégie sur les frameworks ?

Je les utilisent qu'en j'en est besoin (ou pas le choix ), mais je pense que c'est notre lot à tous dans le métier.
Par contre, si l'on vient me voir pour me demander de faire une SPA avec tel ou tel Framework, parce que "c'est une demande client", alors que le Framework, de même que le fait d’implémenter une SPA, ne ce justifie pas, je vais pas être bonheur .

[Marco46]

C'est à date, le seule moyen d'apporter un minimum de Qualité sur une base de code faite rapidement et à moindre frais, car le critère Qualité est externalisé.

Un framework ou une lib, d'une manière générale une dépendance, ne sert pas à apporter de la qualité, elle sert à éviter de réinventer la roue.

L'usage d'un framework ou d'une lib n'a absolument aucun rapport avec la qualité du code source d'un projet. Zéro. Ça sert à augmenter (un peu) la productivité et à uniformiser certaines choses comme par exemple mettre à jour le DOM, gérer le routage d'une SPA, avoir un système de composants réutilisables, etc ...

[Sodium]

Un framework ou une lib, d'une manière générale une dépendance, ne sert pas à apporter de la qualité, elle sert à éviter de réinventer la roue.

Je ne dirais pas que le principal intérêt est de ne réinventer la roue. C'est plutôt de ne pas la réinventer à chaque fois.
Développer soi-même ses propres codes, c'est très bien. Sauf qu'une majorité de besoins sont communs à l'ensemble des projets. Donc à un moment il faut bien finir par avoir des outils facilement réutilisable. On peut alors soit écrire son framework dans son coin, soit faire plutôt confiance à une base améliorée, testée et maintenue depuis des années par une large communauté, avec une certaine assurance qualité derrière, notamment une documentation précise des recommandations pour garder un code qui reste compatible le plus longtemps possible avec les mises à jour de version.

[defZero]

Un framework ou une lib, d'une manière générale une dépendance, ne sert pas à apporter de la qualité, elle sert à éviter de réinventer la roue.

Déjà un Framework, c'est autre chose qu'une simple lib.
Entre une lib qui apporte un tas de fonctionnalités et un Framework qui impose une architecture, il y a un gouffre à ne pas franchir (genre jamais ).
Ensuite, effectivement, en théorie, mais en pratique, la lib / Framework seront plus utilisé et donc mieux testé et donc forcement plus sécure que du code écrit dans sont coin, pour les bonnes et les plus utilisées (celles qui ont notre confiance normalement ), s'entend.
Donc, oui en théorie, je suis d'accord que ça n'as pas de rapport directe avec la qualité, mais dans la pratique, ça ce vérifie tous les jours.

Donc sur ton commentaire, je dirais que de ne pas "réinventer la roue", justement apporte en soit un certain gage de qualité (SI la "roue" est assez bien codé, testé, maintenu) sur un projet qui ne serait pas forcement atteint si l'on devait recoder tout en vanilla à chaque fois (avec un tas de bug potentiellement différent sur chaque implémentations particulière et des coups de maintenances qui exploseraient).

L'usage d'un framework ou d'une lib n'a absolument aucun rapport avec la qualité du code source d'un projet. Zéro.

T'es pas sérieux ?
Si oui, je pense que soit tu est un génie qui s'ignore, soit tu à du louper un truc à un embranchement .
Sinon, mea culpa, je n'avais par compris le l'ironie.

Ça sert à augmenter (un peu) la productivité et à uniformiser certaines choses comme par exemple mettre à jour le DOM, gérer le routage d'une SPA, avoir un système de composants réutilisables, etc ...

WTF ?
Parce qu'un système d'Authentification, d’Autorisation ou autres, validés et débuggés par des experts dans leurs domaines, ça ne fait gagner qu' "un peut" de productivité pour toi ?
Un génie le gars, j'en était sur.

Personnellement, je serait purement incapable d'arriver au niveau de qualité atteint par certains Framework / Lib (si même capable de les devs tout court ).
Alors les réduire à un "simple gain de temps" me fait dire que soit tu surestime très largement tes capacités, soit tu n'as jamais eu à faire des choses très complexes.

Pour finir je dirais que le propre d'un "bon dev" devrait être, entre autres choses, de savoir rester humble devant le travail accomplit par ses pères.
D'autant plus quand le dit travail est fournit gracieusement à la communauté et est reviewer par tout une communauté constitué d'expert et de passionnés averties dans leurs domaines respectifs.

[kilroyFR]

Tout le monde en informatique a connu un jour ou l'autre quelqu'un dans une equipe qui se croit plus malin et prefere tout reinventer plutot que de faire de l'assemblage de composants existants.
Personnellement je prefere assembler des briques metiers (qui ne font qu'une chose) et ne pas reinventer la roue carrée (car de toutes façons on refait generalement a notre sauce avec des bugs en plus). On ne maitrise pas plus pour autant. Je prefere corriger un composant partagé par la communauté et en faire profiter tout le monde.
On a tous des tonnes de composants internes qui refont ce qui a deja ete fait par d'autres dans des composants open source plus complets.
Je ne comprends plus l'interet.
A un epoque ou tout le monde se fout des pb de memoire (consommation a gogo des Gb de ram, tout pousser sur le client, rien sur le serveur, des clients qui fonctionnent a des puissances > a celles de certains pc etc.). Dans ma boite en tout cas les nouveaux devs ne se posent jamais ces questions, bossent a ressources infinies, en archi micro services. C'est pas assez rapides ni puissants ? leur reponse est simple : il faut ajouter de la ram et de la CPU voir des serveurs supplementaires.
JAMAIS ils ne se disent qu'ils ont pondé du mauvais code ou pas optimisé du tout.
Et ces memes personnes n'ont pas le reflexe d'utiliser des frameworks existants, se croyant meilleurs que ce qui existe. La realité est bien differente. Le principe c'est surtout se faire plaisir car de toutes façons la maintenance, le suivi ils s'en foutent puisqu'ils auront changé de boite dans les 3 ans (pour aller chercher une remuneration plus interessante ailleurs).
Je prefere bosser avec une communauté de gens qui aident a faire grandir un composant plutot que des devs dans ma boite sur qui on ne pourra pas compter ad vitam.

[Marco46]

Déjà un Framework, c'est autre chose qu'une simple lib.
Entre une lib qui apporte un tas de fonctionnalités et un Framework qui impose une architecture, il y a un gouffre à ne pas franchir (genre jamais ).

Je ne sais pas ce que tu appelles une architecture mais la présence d'un framework ou d'une lib dans un projet ne fait rien du tout pour l'architecture du projet. Avoir tel type de fichier dans tel répertoire ce n'est pas de l'architecture.

Tu peux parfaitement développer une application Angular par exemple sans le moindre effort de conception technique et donc sans aucune architecture logicielle. C'est même malheureusement très fréquent.

Ensuite, effectivement, en théorie, mais en pratique, la lib / Framework seront plus utilisé et donc mieux testé et donc forcement plus sécure que du code écrit dans sont coin, pour les bonnes et les plus utilisées (celles qui ont notre confiance normalement ), s'entend.
Donc, oui en théorie, je suis d'accord que ça n'as pas de rapport directe avec la qualité, mais dans la pratique, ça ce vérifie tous les jours.

Ça n'a pas de rapport avec la qualité du code de ton projet. La qualité d'une code d'une dépendance ne fait pas parti de ton projet. C'est une dépendance, tu utilises le livrable de cette dépendance, pas son code source.

Donc sur ton commentaire, je dirais que de ne pas "réinventer la roue", justement apporte en soit un certain gage de qualité (SI la "roue" est assez bien codé, testé, maintenu) sur un projet qui ne serait pas forcement atteint si l'on devait recoder tout en vanilla à chaque fois (avec un tas de bug potentiellement différent sur chaque implémentations particulière et des coups de maintenances qui exploseraient).

Oui, c'est la raison d'être d'une dépendance.

T'es pas sérieux ?
Si oui, je pense que soit tu est un génie qui s'ignore, soit tu à du louper un truc à un embranchement .
Sinon, mea culpa, je n'avais par compris le l'ironie.

J'ai l'impression que tu ne comprends pas la différence entre le code de ton projet et ce qu'est une dépendance ..

WTF ?
Parce qu'un système d'Authentification, d’Autorisation ou autres, validés et débuggés par des experts dans leurs domaines, ça ne fait gagner qu' "un peut" de productivité pour toi ?

Ça c'est encore autre chose, tu pars dans tous les sens cher ami. On parlait des frameworks web, la gestion de l'authentification est un sujet transverse qui va bien au delà et qui fait appel à des normes et des standards internationaux c'est complètement hors sujet.

Un génie le gars, j'en était sur.

Mouai on se calme mon p'tit gars te laisse pas emporter par ton enthousiasme ...

Personnellement, je serait purement incapable d'arriver au niveau de qualité atteint par certains Framework / Lib (si même capable de les devs tout court ).
Alors les réduire à un "simple gain de temps" me fait dire que soit tu surestime très largement tes capacités, soit tu n'as jamais eu à faire des choses très complexes.

Où est-ce que j'ai écrit que je n'utilisais pas de framework ou de libs et que j'écrivais tout moi-même ?!?

Oui ça sert principalement à une chose simple : Gagner du temps.

Pour finir je dirais que le propre d'un "bon dev" devrait être, entre autres choses, de savoir rester humble devant le travail accomplit par ses pères.

Oui, commence par appliquer ça à toi même avant d'envoyer des "ça doit être un génie" et des "tu surestimes tes capacités". Hein la poutre tout ça ...

D'autant plus quand le dit travail est fournit gracieusement à la communauté et est reviewer par tout une communauté constitué d'expert et de passionnés averties dans leurs domaines respectifs.

Houlala oui oui Facebook et Google fournissent "gracieusement" leur travail à la communauté Il n'y a aucune arrière pensée derrière ni aucune stratégie d'ensemble

Et bien sûr les PR sur React et Angular sont review par des experts passionnés et bénévoles qui font ça à côté de leur travail

[Marco46]

Pour clarifier, parce que j'ai l'impression qu'il y a beaucoup de juniors sur ce genre de fils de discussion.

En génie logiciel la qualité du code source c'est le fait d'écrire un code qui utilise un style consistant et standard, de nommer proprement ses variables et ses fonctions, de limiter la complexité des fonctions, de conserver des fichiers de code source de taille raisonnable, d'éviter les duplications, de l'écrire de telle sorte qu'il soit testable, d'avoir des tests automatisés, etc ...

On peut mesurer une partie de ces critères via des outils (code climate, Sonar, etc ...) qui vont analyser le code source généralement pendant la phase d'intégration continue.

C'est ça la qualité du code source d'un projet.

Le fait d'utiliser telle ou telle dépendance n'a pas de rapport avec la qualité du code parce que le code qui est intégré sous forme de dépendance n'est pas pris dans l'analyse.

Donc non on ne peut pas dire qu'utiliser tel ou tel framework ou lib améliore la qualité du projet parce que tu peux écrire de la merde dans un projet avec Angular aussi sûrement qu'avec ou sans n'importe quel autre outil.

Autre point sur l'architecture. L'architecture ça sert principalement à dégager les abstractions qui modéliseront au mieux les concepts métiers que tu dois retranscrire dans ton projet. Là aussi le but est toujours le même : Découplage, ré-utilisabilité, simplicité etc ...

En quoi le fait d'utiliser Angular ou autre garanti quoi que ce soit ? En rien du tout. C'est pas parce que Angular te permet d'écrire des composants et des services qu'ils vont être pertinents par rapport à ton métier.

TLDR : Tu peux utiliser les meilleurs couteaux et la meilleure batterie de cuisine du monde, si tu ne sais pas cuisiner tu feras de la merde.

Pour en revenir au point de départ de defZero sur l'externalisation, le fait d'utiliser des frameworks sur des équipes d'externes n'aide pas à grand chose, c'est une goutte d'eau dans l'océan. Le problème principal c'est de vouloir faire faire à des armées d'externes juniors sous payés des tâches qui devraient être dévolues à des équipes mixtes de seniors / confirmés / juniors au plus près du métier.

[xXxNeWgEnErAtIoN]

De toute façon le Javascript c'est un langage pour les mauvais développeurs, aucun développeur sérieux ne code avec ce langage.

C'est un langage tout droit sorti des enfers.

[Invité]

Pour clarifier, parce que j'ai l'impression qu'il y a beaucoup de juniors sur ce genre de fils de discussion.

En génie logiciel la qualité du code source c'est le fait d'écrire un code qui utilise un style consistant et standard, de nommer proprement ses variables et ses fonctions, de limiter la complexité des fonctions, de conserver des fichiers de code source de taille raisonnable, d'éviter les duplications, de l'écrire de telle sorte qu'il soit testable, d'avoir des tests automatisés, etc ...

On peut mesurer une partie de ces critères via des outils (code climate, Sonar, etc ...) qui vont analyser le code source généralement pendant la phase d'intégration continue.

C'est ça la qualité du code source d'un projet.

Le fait d'utiliser telle ou telle dépendance n'a pas de rapport avec la qualité du code parce que le code qui est intégré sous forme de dépendance n'est pas pris dans l'analyse.

Donc non on ne peut pas dire qu'utiliser tel ou tel framework ou lib améliore la qualité du projet parce que tu peux écrire de la merde dans un projet avec Angular aussi sûrement qu'avec ou sans n'importe quel autre outil.

Autre point sur l'architecture. L'architecture ça sert principalement à dégager les abstractions qui modéliseront au mieux les concepts métiers que tu dois retranscrire dans ton projet. Là aussi le but est toujours le même : Découplage, ré-utilisabilité, simplicité etc ...

En quoi le fait d'utiliser Angular ou autre garanti quoi que ce soit ? En rien du tout. C'est pas parce que Angular te permet d'écrire des composants et des services qu'ils vont être pertinents par rapport à ton métier.

TLDR : Tu peux utiliser les meilleurs couteaux et la meilleure batterie de cuisine du monde, si tu ne sais pas cuisiner tu feras de la merde.

Pour en revenir au point de départ de defZero sur l'externalisation, le fait d'utiliser des frameworks sur des équipes d'externes n'aide pas à grand chose, c'est une goutte d'eau dans l'océan. Le problème principal c'est de vouloir faire faire à des armées d'externes juniors sous payés des tâches qui devraient être dévolues à des équipes mixtes de seniors / confirmés / juniors au plus près du métier.

D'accord sur tout ça, juste pour préciser au niveau de l'architecture que certains frameworks te poussent vers certaines pratiques plus que d'autres. Tu peux toujours faire autrement, mais il arrive un moment où tu fini par d'avantage te battre contre le framework qu'à être productif. Clairement si ça se produit c'est que le choix du framework était mauvais pour ce cas précis mais c'est un autre sujet.

[walfrat]

Un autre détail qui tue : les chiffrages qui doivent être fait à l'heure près mais quasiment uniquement sur le fonctionnel hein.

Si tu fait toute un appli web de gestion de données à partir juste d'un framework avec les élément technique autour "classiques" tu vas faire un chiffrage ou le temps passer à faire vraiment les fonctions métiers par rapport à faire des éléments techniques autour est loin de passer vis à vis des clients (parce que restriction budgétaires).

Les "classiques" sont :

• gestion utilisateur
• authentification SSO intégré avec le client
• Utilisation de l'adresse web pour identifier chaque état de ton appli web (cas SAP) afin de pouvoir faire des liens et de recharger la page en l'état
• tableaux avec filtres, tris
• Graphe, export PDF de données.
• internationalisation
• "sécurité" (oui je met des guillemets, vous savez tous pourquoi )

En toute logique on devrait concevoir chaque élément de notre application avant de l'implémenter.

Perso en 10 ans de développement je dois encore avoir à mettre une ligne "Conception" dans mes chiffrages (conception logicielle je veux dire, pas l'architecture système).

Petite anecdote : sur un projet, des gens "non développeurs" on recommandé JOOMLA, car dans mon appli qui n'avais rien avoir avec il fallait ajouté du SSO.

[vbarr]

Je suis d'accord avec l'article, mais pas avec les raisons évoquées. Ce qui coûte cher, c'est la main d’œuvre, pas l'électricité. Les devs utilisent les outils qu'ils connaissent déjà et avec lesquels ils sont les plus productifs car il faut que ça aille vite.
Faire différent projets avec les mêmes outils permet aussi de réutiliser son code et diminuer la charge mentale associée à chaque projet, pour soi et les autres devs qui travailleraient sur le projet si c'est outils sont "standard".
Mais c'est vrai qu'on se comporte comme les rois du pétrole des années 70 comme quelqu'un a dit...

[JackIsJack]

Je suis le seul à n'avoir aucun problème de lenteur sur le web ?

[grunk]

Dans 99% des cas le critère principal d'un site c'est le prix.
Comme c'est toujours "trop cher" on fait des choix qui permettent de réduire les coûts. Utiliser un framework reconnu , même si il est plus lourd que de from scratch, est la solution la plus efficace en terme de coûts.

Et il faut admettre que en tant que développeur qu'en tu as fait un projet sur un fw moderne , c'est quand même déclicats de repasser sur du code vanilla. Tout est plus chiant et compliqué.
Je prend l'exemple d'Angular , j'ai pas par exemple pas à me soucier des compatibilités ESX des navigateur , je fait tous en TS et ca transpile ce qu'il faut derrière. Ça à surement un coût en performance mais c'est tellement confortable que je m'en tamponne.

A titre d'exemple ma plus grosse app fait 670Ko gzippé et ca représente une grosse 50 aine de composants, 4 services, de multiple pipe et guard ... Comparer au 4 Mo d'assets de type image ou CSS c'est pas grand chose au final.

Après on est actuellement à une période ou certains on des connexion 10Gb à la maison et d'autre à peine 1Mb d'adsl , du coup on ne peut pas se permettre de développer pour le pire des cas, il faut trouver le juste millieu.

[Edrixal]

Heu là l'exemple est pas terrible, de toute façon les bonnes pratiques de base c'est que TOUTES les vérifications sont faites côté serveur, même si certaines sont déjà faites côté client.
C'est vraiment la base de la base.
Donc que le champ code postal soit pourri côté client ou pas ça change strictement RIEN au travail à faire.
Maintenant ça améliore l'expérience utilisateur si il a un retour immédiat côté client en cas d'erreur au lieu d'attendre que la validation serveur l'arrête bien sûr.

Ouai sauf que les données passe d'abord par leur serveur avant de les envoyer aux WS. Ils stocks tout ce qui est saisie, font leur traitement puis nous envoie les informations.
Sauf qu'il y à des tas d'information dont nos outils ont besoin dont eux ne se servent pas et qu'ils ne vérifient pas.

Le plus intelligent dans l'histoire c'est que l'utilisateur saisie ses données et valide. Si toutes les données nécessaire à leur traitement sont OK, tout est valider. Ils envoie ensuite le flux à nos WS. Mais si les données sont pourris nous ont bloque (histoire de pas récupérer n'importe quoi ou parce qu'on a pas suffisamment d'information). Du coup l'utilisateur pense que tout c'est bien dérouler alors que non. Et ce sont les gestionnaires qui doivent retravailler les données qu'à saisie l'utilisateur (Parfois en les recontactant pour avoir des précisions ou récupérer les informations manquante) afin de refaire passer le flux.

Alors y'a des choses qu'on à mis en place pour tenter de limiter les ressaisies parce que les gestionnaires ne veulent pas passer leur temps à relancer les flux. Mais on ne peut pas tout corriger...

Lorsqu'on à l'adresse au complet saisie dans le champ code postal, on ne peut pas ce permettre de la découper pour obtenir le CP le numéro de rue, le nom de la rue, la ville et si c'est un bis/ter en sachant que les informations peuvent être saisie dans n'importe quel ordre voir être incomplètes. Surtout quand derrière une partie des informations ont été ressaisie au bon endroit avec des différences d'orthographe...
Idem quand dans le numéro de contrat on reçois des phrases complètes...

Ont à pas les équipes nécessaire pour mettre en place un similis d'IA qui pourra analyser en profondeur chaque donnée afin d'éviter une ressaisie du flux. Si ce travail avait été fait en amont, l'utilisateur aurait été forcer de vérifier ses données ce qui aurait largement diminuer le nombre de flux en erreur. Actuellement on est passer d'un 60% à 10/15% grâce à nos ajouts. Mais ont a fini largement hors devis. Et ceux qui on repris le projet commence à ajouter des vérifications pour justement réduire au possible le nombre d’échec. Car ses WS ont été mis en place pour que les gestionnaires n'ai plus de saisie à faire et puisse ce concentrer sur le traitement des dossiers.

[Dgamax]

Quand je vois la conso CPU de nos sites aujourd'hui fait via des CMS, c'est une horreur, et au final nos clients ne sont pas content car leur site est lent et quand il faut optimiser, c'est la grosse galère pour les dev, c'est une horreur tout ça :p
Pour tout hébergeur, les CMS c'est une plait, ça bouffe énormément de ressources pour afficher pas grand chose au final, c'est triste..
Sans parler de la sécurité...

[PomFritz]

Il va falloir que je migre tout mon JQuery, sinon je vais passer pour un c**
Tout ça va (re-)finir en CMS et on va dire que c'est trop lent, trop lourd, pas sécurisé, etc...
Le dev Web c'est un empilement de caca. C'est pourri à la base. La seule solution serait un "langage" homogène qui gère tout ça à partir d'un véritable code typé et débugable avec des moyens modernes. Mais, après 20 ans, on est toujours dans la bricole. Qu'on s'en rende compte est déjà un bon début.

[Sodium]

Quand je vois la conso CPU de nos sites aujourd'hui fait via des CMS, c'est une horreur, et au final nos clients ne sont pas content car leur site est lent et quand il faut optimiser, c'est la grosse galère pour les dev, c'est une horreur tout ça :p
Pour tout hébergeur, les CMS c'est une plait, ça bouffe énormément de ressources pour afficher pas grand chose au final, c'est triste..
Sans parler de la sécurité...

Je viens d'installer un Wordpress pour une amie et après un premier chargement initial qui doit sûrement mettre des trucs en cache, le temps de latence sur les pages n'est pas décelable.
Dans tous les cas, il faut être réaliste, les serveurs beaucoup moins cher que les humains, mieux vaut monter en puissance plutôt que de multiplier le temps de dev par 10.
Et si l'on a besoin d'une application ultra-performante, c'est que le projet est suffisamment ambitieuse pour nécessiter une équipe derrière qui fasse les bons choix techniques.

Il va falloir que je migre tout mon JQuery, sinon je vais passer pour un c**
Tout ça va (re-)finir en CMS et on va dire que c'est trop lent, trop lourd, pas sécurisé, etc...
Le dev Web c'est un empilement de caca. C'est pourri à la base. La seule solution serait un "langage" homogène qui gère tout ça à partir d'un véritable code typé et débugable avec des moyens modernes. Mais, après 20 ans, on est toujours dans la bricole. Qu'on s'en rende compte est déjà un bon début.

Du Symfony ou de l'Angular, c'est tout sauf de la bricole. Si tu fais toujours tout en jQuery, effectivement c'est du bricolage et tu ne peux t'en prendre qu'à toi-même, il est temps d'évoluer car le web lui évolue.

[xXxNeWgEnErAtIoN]

Angular c'est de la bricole, le front c'est une vaste blague, le jus c'est pour les collégiens.

Et maintenant ils vont pourrir le back avec du nodejs de la mort.

Le web en général ils ont un problème