Discussion :

[Chen norris]

ExtJS travaille effectivement avec des datastores, des models, des proxys, … en plus des composants graphiques : autant de complexité apportée à la couche présentation n'est pas normal. Si je résume ta pensée sur comment on développe une appli web, au vu des contraintes du monde de l'entreprise (créer vite plein d'interfaces avec beaucoup de données), il faut aller vite sans se soucier du contenu du résultat final ?

Petite analyse :
Je prends deux sites web assez répandus dans le monde de l'informatique : google et nexus. Le premier n'utilise pas ExtJS, le second, si. Je vais au plus simple puisque je reste sur la page d'accueil. En apparence, l'un comme l'autre sont relativement simples (champ de recherche au centre). Penchons-nous d'abord sur la complexité du code HTML de ces deux sites, avec la vue 3D de la console Firefox :

À gauche Google, à droite Nexus.

Je compte le nombre de niveaux : Google en a 14, Nexus 28. Rien que deux fois plus. Cela ne te choque pas ? Regardons le poids de chacune des deux pages : Google 838.22 ko, Nexus 1421.42 ko.
Toujours pas convaincu ? Petit coup d'œil sur la rapidité de chargement : 1.26 s pour Google (puis 400 à 500ms pour les chargements suivants), 3.95 s pour Nexus. Malgré une potentielle mise en cache, Nexus reste entre 3 et 4s pour les chargements suivants à cause du rendu du DOM : ne me dit quand même pas que ça te paraît normal ? OK, ce ne sont pas les mêmes serveurs derrière donc pas forcément le même temps de réponse mais la tendance démontre quand même qu'un site complexe mettra toujours plus de temps à répondre, à s'afficher, à réagir. « oui mais il y a plein de traitements à faire derrière, c'est pour ça que ça met du temps », je l'ai déjà entendu plein de fois en entreprise. Sauf que créer quelque chose de fonctionnel sans rien optimiser derrière, ça n'est pas travailler proprement.

Si après cette analyse ça ne te choque toujours pas de produire des interfaces 2 à 3 fois plus lourdes par leur complexité et leur poids, moi si.

Et pour ce qui est des API avec des langages traduits en langage machine (le C), la comparaison n'a rien à voir : comme j'expliquais dans un post précédent, le web n'est pas traduit en langage machine, il est interprété par les navigateurs. Preuve en est que lors d'un bug, avec ExtJS, c'est la console Javascript que tu regardes. Et au passage, autre point assez négatif en ce qui concerne les messages d'erreurs générés pas ExtJS : TypeError: this.addEvents is not a function, TypeError: cfg is undefined, … là encore, c'est très brouillon dans la compréhension.

Je pense qu'il ne viendrait à aucun développeur d'aujourd'hui l'idée de dire que tout ça est à mettre à la poubelle.

J'ai simplement donné un retour d'expérience très mitigé sur ExtJS mais en aucun cas je n'ai dit qu'il était à mettre à la poubelle. Relis-moi, tu verras que je n'interdis pas son usage, je le déconseille dès lors qu'on veut une appli complexe et j'indique qu'il aurait besoin de changer beaucoup de choses dans son fonctionnement.
Bien que négative, ma critique ne doit pas être considérée comme un rejet total de ce framework. Moi le premier, je considère que toute critique est bonne à entendre, qu'elle soit positive ou négative, du moment qu'elle reste constructive et qu'elle se base sur de vrais arguments.

[sekaijin]

Je crois que là face à tant de fermeture d'esprit de critique caricaturale je n'ai rien à dire tu as de toit même enterré tout tes argument.

Autant ExtJS est criticable autant l'absurdité de tes propos sur le monde de l'entreprise rends tes critique vide de sens.

Je clos le discussion.

JYT
PS: j'espère que les lecteurs seront assez ouvert d'esprit pour tenter d'extraire de ce flots d'absurdité les vrai critique d'ExtJS car il y en a.

[Chen norris]

[…] fermeture d'esprit de critique caricaturale […] l'absurdité de tes propos […] ce flots d'absurdités

C'est dommage de prendre mon argumentation de manière aussi personnelle et de clore la discussion ainsi. De notre débat sont pourtant ressortis beaucoup de points. Chaque lecteur qui viendra ici sera libre de choisir quelle position il souhaite prendre, inutile de choisir la voie de l'agressivité.

[sekaijin]

La définition d'un Modèle de donnée n'est pas une affaire d'IHM la définition des Classe de traitement n'est pas une affaire de présentation. et un Contrôleur est là pour contrôler un composant. ce Composant n'est pas nécessairement un élément d'une vue.

traduit en

ExtJS travaille effectivement avec des datastores, des models, des proxys, … en plus des composants graphiques : autant de complexité apportée à la couche présentation n'est pas normal.

Quant à la maintenabilité là encore c'est très mal connaitre le framwork car justement un des très gros point fort d'ExtJS c'est de permettre à peut de frais de faire des chose claire propre maintenable.

traduit en

Si je résume ta pensée sur comment on développe une appli web, au vu des contraintes du monde de l'entreprise (créer vite plein d'interfaces avec beaucoup de données), il faut aller vite sans se soucier du contenu du résultat final ?

Que dois-je comprendre que c'est constructif, conforme à la réalité de l'entreprise, que cela reflète les méthodes rigoureuse mise en place pour assurer un qualité logicielle importante ?

perso j'appelle ça une caricature absurde
A+JYT

[Chen norris]

Je ne suis pas sûr de savoir dans quel sens tu vas quand tu parles de « conforme à la réalité de l'entreprise ». Si cela implique que mes propos sont en décalage avec le monde de l'entreprise, alors je suis 100% d'accord avec toi : ma thèse relève plus des principes qu'il faudrait idéalement voir appliqués plutôt que des principes qui sont actuellement suivis.