[Ext JS] Choisir mon framework : Extjs ou jQuery ?

Version imprimable

06/02/2009, 14h51
max-mag

[Ext JS] Choisir mon framework : Extjs ou jQuery ?

Bonjour,

Je suis codeur php, et je dois me mettre un peu au javascript (et ajax) pour mes interfaces web. Je cherche "mon" framework javascript (ou plutôt ma bibliothèque de fonction). Je dis "mon" framework, car je suis convaincu que tous ont des défauts et avantages, et chaque codeur ses préférences.

J'étais parti sur Dojo au départ, mais j'en suis vite revenu car ces défauts sont rédhibitoires pour moi :
- quelques problèmes avec IE
- super lourd à charger quand il s'agit de faire "juste" une validation d'email par exemple.

J'ai revu ma copie, fait le tour de mes besoins et des forums, parcouru les docs, et je me retrouve à avoir sélectionné 2 : ExtJS et jQuery.

Bien-sûr, je ne cherche pas un framework javascript juste pour valider une adresse email, mais cela fait aussi parti des besoins.

Je préfèrerai utiliser ExtJS, car plus évolué (framework de haut niveau), mais ne vais je pas tomber dans le piège de la lenteur évoquée pour Dojo ?
Les performances pour les éléments simples (type validation de formulaire) sont très importantes pour moi, et tant qu'à faire, je préfère me former sur 1 framework plutôt que 2.

Merci de vos conseils.
06/02/2009, 15h28
DoubleU

Tu as besoin de quoi exactement? Parce que c'est quand même à partir de ce besoin que tu dois te déterminer ^^
06/02/2009, 16h50
max-mag
Voici mes besoins génériques :
- licence : open source préférée, mais pas obligatoire
- projet actif, une bonne communauté
- un apprentissage pas trop difficile (pour un développeur)
- une documentation bien faite, complète (si possible en français, mais l'anglais va bien aussi). Rien à voir avec Javascript, mais pour cela Zend Framework est bien.
- Cross over impeccable : le code doit être (vraiment et toujours) fonctionnel quelque soit le navigateur (je suis déçu de Dojo à ce niveau)
- rapidité : doit être rapide pour les opérations simples (type validation de champ, fausse popup, onglet) dans le navigateur internet (je suis également déçu de Dojo à ce niveau, quand on charge dojo juste pour ça)
- Facilité de débogage, rapidité de développement.
- Je code avec Eclipse PDT, si cela a un intérêt.
Ce que j'ai besoin de prime abord :
- onglets
- slideshow et lightbox
- fausse popup
- Editeur WYSIWYG léger (facultatif)
- faire des menus
D'autres besoins naitront certainement au fil du temps (c'est pourquoi je pensais à ExtJS), mais chaque chose en son temps (jQuery suffirait).
06/02/2009, 17h03
DoubleU

Alors j'aurais tendance à dire Ext, parce que c'est un framework spécialisé dans le GUI et donc tu aurais presque le tout avec une vraie cohérence graphique.

Avec jQuery, faut souvent aller piocher dans des plugins persos et tu te retrouves vites avec des choses qui vont visuellement mal ensemble.

Mais peut etre que d'autres auront un avis différent, je connais pas très bien jQuery.
07/02/2009, 03h58
emmanuel.remy

Un peu d'huile sur le feu
Salut,

Prends Ext c'est un excellent framework - et en plus tu disposeras de php-ext.

Mais attention. Ext est un excellent framework.
Tout comme jQuery.
Tout comme Prototype.
Tout comme Dojo.
Tout comme YahooUI.
Tout comme Mootools.
Tout comme Dhtml Goodies.
Tout comme ..

Tout ceci n'est à mon humble avis que querelle de clocher. Actuellement il n'y en a pas de "mauvais", ils sont tous bons, et disposent bien souvent d'un tronc commun de fonctions. A la base ils sont régulièrement l'union de plusieurs librairies opensources communes... De là à dire qu'ils tendent tous à faire presque la même chose avec presque la même aisance, il n'y a pas grand pas à franchir. Un exemple: à quel framework appartient ce code (pose d'un événement onclick sur toute balise P) ?
Code:

1 2 3 4 $("p").click(function () { $(this).slideUp(); });
C'est du jQuery.

Et à quel framework appartient ce code (pose d'un événement onclick sur toute balise P) ?
Code:

1 2 3 4 $("p").click(function(){ $(this).addClass("expanded"); });
C'est du Dojo.

Tu vois la différence ?

Alors évidemment chacun de nous a ses propres besoins, mais ces frameworks sont tellement maléables qu'au final tous peuvent convenir. Un aura besoin de plugins, l'autre de plus de code JS, etc...

Le problème qui se pose plutôt c'est de très bien connaitre le framework que tu choisis. Car sans cela, et même armé du meilleur framework du monde, tu peux générer la pire des performances.

Rapidité, qualité du rendu ou encore facilité de codage sont avant tout liés à la connaissance du framework.

Prenons l'exemple de Dojo (mais cela s'applique aussi bien aux autres) que tu as certainement un peu manipulé d'après ton post, et qui t'a déçu.
Il fonctionne sous la forme de packages (un peu comme java) et ne télécharge au fil de l'eau que ce dont il a besoin. Tu veux valider des emails en étant cross-plateformes (événementiel, etc...), cela te coute 26ko de téléchargement (aussi peu que les autres). Beaucoup de programmeurs téléchargent trop de packages pour rien, ce qui évidemment ralentit le client JS. Et si tu as besoin de composants graphiques tu ajoutes alors quelques librairies (dijit) en choisissant bien sûr uniquement celles dont tu as besoin. Et si cela ne suffit pas, tu disposes d'un Builder qui regroupe l'ensemble de tes librairies utilisées dans ton projet pour n'en faire qu'une seule optimisée à télécharger. Pour le débug il est nativement intégré à Firebug, c'est un pur bonheur (j'exagère un peu mais c'est l'aspect avocat du diable qui ressort !). Il gère nativement Google GEARS, les sources de données JSON, REST, OPML, FLICKER, PICASA etc... Et aussi Adobe AIR. On lui reproche aussi de ne pas disposer d'une fonction $ (comme Prototype ou jQuery) mais de devoir appeler dojo.query: il suffit d'écrire $ = dojo.query et le tour est joué (voir ici pour plus de détails).
D'un autre côté, je trouve personnellement que la communauté est très en retard sur la qualité graphique des templates CSS proposés qui sont ridiculement amateurs en comparaison de Ext. Mais c'est full opensource alors que Ext mérite une lecture très attentive de la licence.
Enfin tu souhaites pouvoir comparer les rapidités des frameworks ? Beaucoup l'ont fait et les résultats sont souvent étonnants. Regarde un peu par exemple ici. Ce n'est pas exhaustif, mais c'est instructif.

En bref, connaître avant tout au mieux son framework - quel qu'il soit - et savoir comment fonctionne le chargement d'une page Html à travers une requête HTTP (cela évite de faire n'importe quoi), voilà l'essentiel pour réussir un dev client JS.

Sans vouloir donner l'impression de rouler pour Dojo (ce qui n'est pas le cas, je travaille aussi bien avec Prototype ou GWT), j'espère avoir pu t'ouvrir un angle de réflexion différent.

Finalement tu te sens à l'aise avec Ext, ou tu le trouves élégant, ou il répond à tes besoins ? Lance toi.

ERE

PS: de tous les tests que j'ai faits... Adobe Flex les enterre tous... :D
09/02/2009, 09h28
DoubleU

Ouais fin bon, faut aussi comparer ce qui est comparable hein ;)

Ext et prototype ou jQuery, ca n'a strictement rien à voir...
23/02/2009, 14h39
kaymak

Moi j'avais choisit yui 2.6.des patates (qui est maintenant passé en 2.7)
Car il fournit de base pas mal d'éléments, et que c'est yahoo.

Ben je trouve qu'il remplit très bien son rôle. Le seuls bémol que j'ai est l'extension de l'existant sur lequel je galère un peu.
Mais bon de la à te dire si cela vient du langage (js est particulièrement difficile à développer je trouve) ou le fw, je ne sais pas te dire.

Maintenant ils en sont à yui 3, c'est dire si ils font des progrès, et pour ce que j'en ai vu ils ont vraiment l'air d'avoir réaliser un gros effort pour améliorer en profondeur le fw.

Après j'aime pas la charte graphique de YUI, m'enfin ça je m'en fou pour l'heure.

http://developer.yahoo.com/yui/
http://developer.yahoo.com/yui/3/

a plus
03/03/2009, 22h11
RomainVALERI

Citation:

Envoyé par emmanuel.remy

Salut,
...

...
PS: de tous les tests que j'ai faits... Adobe Flex les enterre tous... :D

D'abord, merci pour l'ensemble de ton propos, aussi intéressant que documenté, avec l'éloquence mais sans la prétention... bravo :king:

Cependant : c'est très mal de jouer avec notre curiosité de développeur comme ça... :nono:
Après un avis aussi détaillé et complet, cette petite allusion fuyante à propos de Flex m'a laissé sur ma faim...
A une vache près, comme ça, à quels avantages mirrifiques pensais-tu en faveur de Flex ? ^^

ps : juste avant de lire ton post, j'allais poster en faveur de Prototype mais ton message m'en a dissuadé ^^ (j'avais effectivement déjà le sentiment que les frameworks devaient se valoir à peu près, mais ton argumentation me donne à penser que j'étais en dessous de la vérité...)
18/02/2015, 11h21
Chen norris
Petit déterrage de topic mais je me dis que n'importe qui peut passer par là et trouver mon avis utile, après tout…

Prototype
Des 3 frameworks JS évoqués ci-dessus, j'ai commencé avec Prototype. Par rapport à du JS classique, c'est beau, c'est lisible, c'est compatible sous tous les navigateurs, … bref, du pur bonheur. La personne qui me l'avait conseillé a suivi d'assez près mes développements histoire que je parte dans la bonne direction, que je prenne de bonnes habitudes. Je me suis retrouvé avec des pages structurées, hyper propres (HTML = présentation pure, JS = dynamisation de la page, CSS = mise en forme, et enfin des templates pour les zones qui changent). Aujourd'hui encore, je continue à développer de cette manière, je n'ai encore rien trouvé de mieux.

JQuery
Puis on m'a parlé de JQuery. Ne faisant pas partie de cette catégorie de développeurs grincheux incapables de faire l'effort de s'intéresser à de nouvelles technos (mini-troll, désolé ^^), j'ai regardé comment JQuery fonctionnait. On est vraiment très très proche de Prototype. Pour faire simple : l'opérateur $$ devient $ et certaines méthodes changent un petit peu de nom (addClass au lieu de addClassName, …). Cette bibliothèque présente pour moi 2 avantages sur Prototype : son poids (plus léger) et des fonctionnalités supplémentaires (animations, par exemple). Petit à petit, j'ai donc abandonné Prototype et JQuery est devenu ma référence.

ExtJS
Récemment, il m'a ensuite été demandé de faire des développements avec ExtJS. Les interfaces sont chouettes, on reste cohérent dans le style visuel (tout est homogène) et les accès aux données sont relativement propres. Pour un formulaire ou un tableau, c'est nickel. Puis est venu le temps de travailler un peu plus au corps ce framework pour avoir des interfaces un peu plus complexes (tableaux à double entrée, verrouillage de colonnes, …) et là, ça a été un véritable drame.
- De base, rien n'est proposé dans ce framework : tout doit être développé manuellement via des plugins. Au final, on va chercher des morceaux de codes copiés/collés au hasard de nos recherches sur le net, dans l'espoir que ça réponde à notre problématique.
- Du côté du code source généré, je ne m'en étais pas rendu compte au départ mais c'est du grand n'importe quoi : on a des <table> et des <div> imbriqués de partout, des images en guise de couleur de fond, … d'un point de vue du respect des standards du web, c'est une honte. Petit exemple pour mieux se rendre compte de l'étendue des dégâts : les boutons des formulaires sont en fait des <table> 3x3 pour pouvoir faire des bords arrondis :weird:. Je m'avance peut-être un peu mais pour moi, on ne code plus comme ça depuis la fin des années 90…
- Les accès en base de données sont biens de base, mais dès qu'on veut rafraichir la page uniquement dans certaines conditions, on passe des heures à s'arracher les cheveux et à limite vouloir se pendre (de base, il faut obligatoirement recharger les données pour actualiser l'affichage d'une grille, ce qui implique l'enregistrement de ces données → contrainte aussi inutile qu'agaçante).
- La personnalisation des contrôles consiste à y aller à tâtons : il est nécessaire de bidouiller tantôt le code, tantôt les feuilles de style sans pouvoir anticiper l'impact, tant il y a de classes CSS à modifier.
- Du code ExtJS mélange de l'interface (boutons, listes déroulante, cadres, …) avec des traitements (appels Ajax, …) : c'est franchement sale.
- Les forums sur ExtJS sont assez fournis (en anglais, certes, mais quand on est développeur, c'est le minimum). On finit par trouver plus ou moins ce qu'on cherche (même s'il faut savoir faire preuve d'acharnement parfois). Les mecs de Sencha répondent volontiers pour donner un coup de main mais sont parfois d'une mauvaise foi hallucinante dès lors qu'on critique un tant soit peu leur framework. Très décevant de leur part.
- ExtJS possède plusieurs versions : les développeurs de Sencha n'ont rien trouvé de mieux à faire que de changer radicalement la manière de déclarer les objets d'une version à l'autre. Pire encore : certaines fonctionnalités disparaissent d'une version à l'autre, on ne sait pas pourquoi. Alors il y a peut-être une subtilité que je ne saisis pas dans ce framework mais je me dis que je ne dois pas être le seul à pester contre cette logique.
Tant d'inconvénients pour un framework, de surcroît payant, on hallucine. Avec toutes ces contraintes, je suis donc repassé sous JQuery pour les interfaces les plus complexes, où à titre informatif, je me suis rendu compte que je divisais mes temps de développement par 5.

Conclusion
Vous l'aurez compris : énorme déception en ce qui concerne ExtJS (et je pèse mes mots). Proposer une interface graphique avec un framework JS n'est pas une mauvaise idée à la base, mais en y réfléchissant : c'est une hérésie. Le JS ne devrait selon moi servir qu'à dynamiser une page, en aucun cas il ne doit se substituer à ce que propose déjà CSS en ce qui concerne la présentation. C'est peut-être chiant aux yeux de certains mais je suis désolé, être développeur, c'est savoir rester propre et arrêter de vouloir se simplifier toujours plus la tâche au détriment de la qualité du code derrière et du respect des standards. CSS est certes un langage assez particulier, aux comportements parfois très aléatoires… mais être développeur web implique de le connaître (ou alors il faut changer d'orientation).
Selon moi, JQuery reste donc à l'heure actuelle LA référence en terme de framework JS. Seul point positif pour ExtJS : bien pour des interfaces graphiques très simples, si on n'a que peu de temps pour les réaliser, si on passe outre le fait qu'il est payant et si on accepte de se faire maudire par le développeur qui s'occupera de maintenir le code plus tard.

Merci pour votre lecture en tous cas, car c'est un bien gros pavé que j'ai pondu là :mrgreen:
20/02/2015, 07h35
sekaijin

Pour moi la question ne se pose pas en ces termes

J'ai des pages HTML et je veux avec JavaScript ajouter des fonctionnalités aux éléments de la page
Pour cela j'ai besoin de retrouver facilement les éléments de ma page et de fonction qui permettent d'ajouter ces fonctionnalités.
C’est le domaine de prédilection de JQuery. L’inconvénient est l’hétérogénéité des plugins

J'ai une page blanche et je veux en JavaScript créer une grille de données un menu et une zone de saisie.
Je ne parle donc pas d'élément HTML mais de grille, de menu et de zone de saisie
Ma page étant blanche j'ai besoin d'un framework qui possède ces composants me permet de les implémenter sans avoir au préalable à me plonger dans le cambouis du HTML. C’est le gros avantage de ExtJs face à JQuery les composants sont riches homogènes et nombreux. Pourquoi devrais-je créer du HTML le faire interpréter au navigateur puis chercher les éléments créer pour ajouter via JavaScript des fonctionnalités que HTML ne connais pas. Alors que mon besoin est de créer un objet complexe. C'est l'esprit d’ExtJS. Et je reconnais qu’ExtJS produit un HTML (tout terrain même de vieux navigateur le supporte) un peu pourave. Mais je ne manipule jamais avec lui de HTML.

L’approche est très différente

Autre point JQuery s'adapte bien aux sites multipages
ExtJs est plutôt pensé application singlePage

C’est volontairement que j'utilise site pour l'un et application pour l'autre.

En résumé
Avec Jquery je pense site web page html et enrichissement
Avec Extjs je pense application composants applicatifs données modélisation.
A+JYT
23/02/2015, 11h31
Chen norris

Dans certains contextes, je comprends tout à fait cette approche de vouloir se simplifier la tâche et aller au plus vite. Quand on dit :

Citation:

Envoyé par sekaijin

sans avoir au préalable à me plonger dans le cambouis du HTML

on paraphrase le fameux « sans avoir à ré-inventer la roue » mais est-ce qu'au final ça ne se fait pas au détriment de la qualité de ce qui est produit derrière ? J'ai vu tellement de développeurs aller au plus simple à cause de délais imposés par le commercial et/ou le client (ou qui ne souhaitent simplement pas se casser la tête). Sauf que derrière, dans 99% des cas, on se retrouve avec un truc fait à l'arrache et vraiment pas propre. Et je ne parle même pas de la maintenabilité.

Le cambouis du HTML fait pour moi partie intégrante du métier de développeur web. Avec un minimum de connaissances en HTML et CSS, on arrive très vite aux résultats attendus. Après, encore faut-il faire l'effort de connaître HTML et CSS… C'est tout le problème de beaucoup de développeurs je trouve : la fainéantise pour tout ce qui concerne la partie graphique. Après, il ne faut s'étonner de voir des chefs de projet considérer les développeurs comme de bêtes machines à produire du code.

Pour recentrer le débat sur ExtJS : avoir un framework qui te génère tes composants, oui. Mais qu'il le fasse de manière beaucoup plus propre. Sur les premières versions, on peut lui excuser de ne pas être parfaitement rodé mais à l'heure du web 3.0, il ne peut plus rester aussi rigide.
24/02/2015, 00h38
sekaijin

Je ne suis pas d'accord

lorsque tu développe un programme pour Windows tu créés des fenêtres des menus des boutons
pourtant l'API repose sur un couche de dessin qui elle trace des ligne des trait des rectangles et des texte.

Tu choisis un framework pour faire un dev Windows qui lui va tracer les traits mais tu ne trace pas un rectangle pour dessiner un menu ou une fenêtre. tu laisse le framwork le faire pour toi.

Si tu choisis un framework qui dessine comme un pied mais qui est efficace dans sont exécution le changerait tu pour un qui dessine proprement mais s'avère peu efficace ?
Bien sur l'idéal serait d'avoir un framework propre et efficace.

lorsque je trvaille avec Jquery je trace des traits et des lignes je fais du HTML et avec ce HTML j'essais de lui donner l'apparence des composants complexes dont j'ai besoin.

lorsque je fait du ExtJS je Mets des grid des menus des fenêtres dans mon application.

La question est JQuery vs ExtJS

ma réponses est ce n'est pas le même usage.

Quand à la qualité du code HTML produit je ne louerais pas celui d'ExtJS Mais j'ai vu suffisamment d'horreur en JQuery pour m'abstenir de les confronter les deux sur ce terrain.

Alors non quand je dis que je ne veux pas mettre les main dans le cambouis du HTML je ne dis pas que je me moque de la qualité

la seule qualité qui m'importe est cette vu de l'utilisateur.
Mon Appli s'exécute-telle sur toute les plateforme ciblée ?
Les performance sont-elles à la hauteur ?
Les objet de l'IHM sont-ils facile à comprendre par l'utilisateur ?
Leur maniement est-il aisé ?
Les personnes chargées de la maintenance Comprennent-ils l'architecture de l'application ?
etc.

Que mon application utilise canevas, SVG, ou HTML n'a aucune importance.
Si demain ExtJS décide de ne plus se baser sur HTML mais dessin tout dans un canevas et que mon appli gagne en perf en facilité d'usage en facilité de dev en facilité de maintenance je n'y vois aucun inconvénient.

lorsque je fais du ExtJS je ne fais jamais de HTML. le seul produit l'est pour lancer l'application et je n'y touche pas.

Lorsque je fait du ExtJS je suis clairement dans la même optique que lorsque j'utilise un framework pour faire des Appli MacOS ou un autre pour des appli Windows ou encore un multiplateforme comme QT.

Si je devais faire un jeux graphique pour Windows alors oui j'utiliserais les API sous-jacentes tout comme il lorsque je fais des page web j'utilise HTML et donc JQuery.

Quant au développer Web justement La philosophie de ExtJS c'est de proposer de sortir de mode de raisonnement Web et de revenir à celui des application native.
Oubliez les web faites vos application comme vous feriez une application Windows on se charge du reste.

Je suis d'accord sur un point j'aimerais que le HTML produit soit mieux foutu. Mais mes Application ExtJS fonctionnent de IE 6 à tous les dernier navigateur et malheureusement IE 6 est toujours présent en entreprise et si effectivement on fait des chose super avec les dernier navigateur lorsqu'on ouvre ces page sur IE 6 c'est la misère.

Dans la vie il y a l'idéal et la réalité. les gens de sencha ont fait des compromis. je pense qu'ils peuvent s'améliorer.

pour finir je ne pense pas que traiter de fainéants les développeur qui utilise des framework de haut niveau soit une bonne façon de faire avancer le débat. J'ai développé des appli en traçant des rectangles et des lignes pour faire du multi fenêtrage car il n'y avait rien d'autre. Utiliser un framework qui fait des fenêtre de menus et des boutons n'est pas être un fainéant, c'est être pragmatique.

A+JYT
24/02/2015, 11h19
Chen norris
Je te rejoins sur le fait qu'un framework qui génère des composants compatibles tous navigateurs toutes versions confondues est l'idéal dans le monde de l'entreprise. Mais quand tu parles de tracer des lignes et des rectangles pour avoir des fenêtres, c'est un peu trop radical. Pour simple exemple, CSS permet de transformer un div en une popup en seulement quelques lignes et de manière plutôt propre :
- une ombre : box-shadow,
- un cadre : border,
- une couleur de fond : background (avec possibilité de faire des dégradés, mettre des images, des motifs répétés, des hachures, …),
- un titre : border-top plus épais,
- le texte du titre : le pseudo élément :before,
- …
Alors OK, ce code CSS n'est pas compatible sur tous navigateurs mais à charge du framework d'apporter les modifs nécessaires aux éléments DOM pour un affichage identique partout (détection de la version du navigateur et éventuellement adaptation de l'arborescence DOM). Côté utilisateur et côté développeur, c'est complètement transparent.

Pour être moins radical, je verrai plus un framework qui se baserait sur des propriétés complémentaires des éléments DOM pour y attacher des listeners, des données associées (grid, menu, …). Imaginons par exemple un truc comme ça :
Code:

1 2 3 4 5 6 <div id="" extjs-type="popup"> <div extjs-type="menu" extjs-data="…" /> <div extjs-type="grid" extjs-data="…" /> … </div>
Côté framework, les propriétés qui commencent par "extjs-" seraient parsées pour mettre en place toute la dynamique qui va bien derrière. Le code JS écrit par le développeur redeviendrait 100% du traitement et ne mélangerait plus traitement et présentation (ce que je reproche notamment à ExtJS).

Ton argumentation me paraît bonne, mais plus pour un framework qui ne soit pas encore abouti.
Et en ce qui concerne les "développeurs fainéants", je n'étais pas très précis et je m'en excuse : je parlais des "développeurs" (je mets volontairement des guillemets) qui choisissent un framework qui leur fait tout car ne maitrisant pas du tout l'HTML et le CSS (comme par exemple quelqu'un qui choisirait Word pour développer son site perso). En aucun cas je ne mettrai dans la case "développeurs fainéants" tous ceux qui choisissent ExtJS dans une pure optique d'efficacité.
24/02/2015, 14h08
sekaijin

encore une fois ce que tu décrit est l'approche radicalement opposée à la philosophie de ExtJS

dans de nombreux framework l'approche consiste à faire ce que tu propose
j'écrit du HTML et j'ai un mécanisme qui le transforme pour obtenir l'effet escompté.

l'approche ExtJS et quelque autre est de dire si je veux un grid je crée un grid le ne crée pas autre chose pour le transformer ensuite.

Imagine un ExtJS qui te produite un code HTML5 super clean
tu fais new panel layout border
new menu new grid et le framwork te pond un HTML 5 clean
à quoi peut bien dans cette façon de faire d'écrire du HTML ?

tu fais pas une table qu'un code va transformer en grid triable synchronisé à un datastrore et avec toutes les actions nécessaire. tu fais un new grid.

il ne set donc à rien de marquer les tag pour les parser vu que tu construit.

je peux faire à JQuery exactement les critiques symétriques à celles que tu fait à ExtJS
en JQuery le ne peux pas créer une grid et garder une référence sur l'objet crée.
je suis obligé de créer du HTML pouis de rechercher dans le DOM les objets que le moteur HTML à crée pour moi pour ensuite les transformer en créant d'autres élément HTML qui à leur tour sont interprété par le moteur HTML qu'il faut que je cherche pour etc...
alors que moi je veux créer une grid.

évidement JQuery n'est pas fait pour ça
tout comme ExtJS n'est pas fait pour écrire du HTML et le transformer.

les deux approche ont leur avantage et leur inconvénients et vouloir utiliser l'un pour faire le travail de l'autre c'est se tromper d'outil.

Si tu construit un mur avec une bêche tu vas trouver que c'est un outil de m#rd@.
mais si tu retourne ton jardin avec une truelle tu aura la même réaction.

lorsque je parle de traits et de rectangles, je n'exagère pas. c'est réellement ainsi qu'on faisait des IHM
heureusement on a rapidement crée des composants complexe qu'on pouvait implémenter sans se poser la question de savoir comment il était implémenté dans les API de bas niveau. et c'est toujours ainsi que ça fonctionne.

Citation:

quand tu parles de tracer des lignes et des rectangles pour avoir des fenêtres, c'est un peu trop radical. Pour simple exemple, CSS permet de transformer un div en une popup en seulement quelques lignes et de manière plutôt propre :

Oui mais pourquoi si je fais myMenu = new Menu({....}) et que cela implémente ce que tu dit ça ne serait pas bien ? pourquoi devrais écrie du HTML le marquer pour le repérer le donner au moteur HTML pour l'interpréter attendre d'être sur que les éléments du DOM son créer pour les rechercher et leur appliquer des transformations pour enfin obtenir un menu qu'il faut ensuite que je cherche pour obtenir une référence à mettre dans myMenu ?
Je pense que si myMenu = new Menu({....}) produit directement le DOM que tu propose (pas le HTML mais le DOM) et que j'obtiens la référence j'ai l'outil dont j'ai besoin dans de nombreux cas. et je n'ai pas besoin de me plonger dans le DOM produit vu que le composant à travers sa référence me permet de le manipuler à ma guise.

ExtJS fais ça. le DOM produit n'est pas le meilleur qui soit loin de là cela est dû à des compromis pour la compatibilité (entre autre)

lorsque avec JQuery tu fais $.Ajax.... tu ne vas pas voir si JQuery utilise un code super clean pour traiter les diverses implémentations de XMLHttpRequest tu lui fais confiance. ce qui t'intéresse c'est que ça fonctionne sur tous les navigateurs que tu vise, que c'est efficace et qu'il n'y a pas de bug. et si tu es curieux tu peux aller voir le code et tu peux t'étonner de voir des façon de faire que tu n'aurais peut-être pas choisi. Mais cela ne remet pas en cause ton choix quant à la pertinence de ton choix.

pourtant je constate très souvent des question sur $.Ajax qui en fait sont du au fait que le développeur n'a pas bien compris son usage. et s'il connaissait XMLHttpRequest il ne poserais pas la question.

mais en fait le developpeur JQuery se moque bien de XMLHttpRequest ce qu'il veut et dois faire c'est bien comprendre l'API $Ajax et bien en saisir l'usage.

si je pousse ton raisonnement il ne faut pas utiliser les framwork les API CSS javascript et HTML sont suffisante
exactement comme l'API dessin de windows l'est pour faire des IHM.

A+JYT
25/02/2015, 11h49
Chen norris

Effectivement, contrairement à mes attentes, la philosophie d'ExtJS est de générer du code HTML à partir de JS et non pas de dynamiser une interface écrite directement en HTML. Ta comparaison avec la bêche et la truelle illustre parfaitement ça ^^

Mais c'est justement cette approche qui me déplaît : générer du code d'un langage à partir d'un autre langage, ce n'est pas naturel. Que JQuery s'occupe de simplifier le code JS : très bien. Et même si on ne connaît l'implémentation qu'il fait de $.ajax, ça reste du JS pur. Utiliser un framework : oui, mais un framework devrait se limiter au langage auquel il appartient. Le fait de mêler JS et HTML me semble très brouillon dans la mesure où on perd la notion de modèle en couche (ici, la séparation présentation / traitement). J'ai d'ailleurs un peu eu la même réaction (celle-ci → 8O) quand j'ai entendu parler d'un framework Java qui générait directement des interfaces web : on n'écrit pas en Java des interfaces web (comme on n'utilise pas une bêche pour construire un mur).

Pendant plusieurs années le web a mêlé présentation et traitement (événements JS directement dans le code HTML, balises script un peu n'importe où, …) et c'était à mon sens un manque d'organisation. Oublier de garder une organisation en couche me fait un peu peur quant à la qualité des sites qui en découlent (en terme de maintenabilité).
25/02/2015, 13h33
sekaijin

tout ça n'est qu'une question de choix et de cible
suivant ce que tu veux faire une approche et plus adapté que l'autre.

Un des inconvénients de JQuery est qu'il faut maitriser plusieurs langages alors que ExtJS te permet de tout faire en JS
là encore c'est une question de choix et pour moi il n'y en a pas de meilleur il sont différent pour des besoin différent.

Quant à utiliser un langage pour en produire un autre c'est le B.A.BA de l'informatique on fait du C qui produit du code intermédiaire qui lui même et traduit en langage machine.
l'interprète HTML ne fait rien d'autre que traduire du Code HTML en DOM qui lui-même est traduit en langage machine.

JS fait de même.

quant à la séparation des couche ce n'est pas un problème de langage.
dans ExtJS tu as des composants d'IHM qui implémentent la couche présentation
des Contrôleur qui implémentent le contrôle des modèle qui implémentent le métier des datastores qui implémentent la persistance. les couche sont bien séparée. de façon claire simple et homogène.

bien sur rien n'empêche un développeur de bricoler un truc qui passe outre cette séparation mais justement contrairement à JQuery ExtJS propose une vrai séparation des couches. et c'est une des raisons qu'il est utilisé par les entreprises.

pour Finir ExtJS ne génère pas de HTML (sauf pour le templating) il implémente directement des objets DOM. ce qui est pour moi un gros avantage. cela évite bien des complication et des cycles. lorsqu'on passe par HTML on doit donner le HTML au moteur d'interprétation du navigateur pour que celui-ci produise un DOM alors que lorsqu'on crée des objet DOM on n'a rien à interpréter. mais surtout lorsqu'on veut récupérer une référence sur un élément du DOM il faut le rechercher lorsqu'on travaille avec HTML alors que lorsqu'on le crée directement on a nativement la référence dont on a besoin.

l'inconvénient de créer le DOM directement en JavaScript est que l'API DOM est très verbeuse. d'où l'introduction de framework comme ExtJS qui crée un DOM pour des objets complexe directement.

A+JYT

Citation:

Envoyé par sekaijin

on fait du C qui produit du code intermédiaire qui lui même et traduit en langage machine
[...]
l'interprète HTML ne fait rien d'autre que traduire du Code HTML en DOM qui lui-même est traduit en langage machine.

Oui pour le C, mais non pour le DOM qui lui, est interprété tel quel par le navigateur. De la même manière qu'un document Word, Photoshop, ou autre est compris tel quel par les applications, sans passer par la case "langage machine". Le rôle de W3C est justement d'imposer un format standard pour les documents HTML ("document" est ici au sens "fichier informatique").

Citation:

Envoyé par sekaijin

ExtJS ne génère pas de HTML (sauf pour le templating) il implémente directement des objets DOM.

La manipulation du DOM est très coûteuse en terme de performances en JS. Utiliser le JS pour générer du contenu est un usage détourné et inapproprié. Garder une référence sur un élément DOM pourrait être un bon argument mais :

la récupération d'une référence peut se fait facilement via les sélecteurs CSS,
garder des références est coûteux en terme de mémoire, occasionnant une baisse de rapidité et de fluidité de navigation.

Un autre souci dans l'usage de JS pour produire du HTML est qu'HTML est en constante évolution. Il y aura donc toujours un train de retard entre les possibilités offertes par HTML (apparition de nouvelles balises, nouvelles propriétés dans les feuilles de style, …) et ce qu'un tel framework permettra. À l'heure actuelle, on se confronte d'ailleurs déjà à ce souci dès lors qu'on veut créer un composant qui réponde à des besoins très personnels : obligation d'aller soi-même étendre un composant puis bidouille de templates et de méthodes… templates qui ne sont au final rien d'autre que de l'HTML. Et je ne parle pas de la complexité des méthodes qui oblige à comprendre le fonctionnement global du composant qu'on étend :

Exemple : je doute que quelqu'un sache exactement à quoi correspond chaque variable dans le bout de code suivant
Code:

1 2 3 4 5 6 7 8 9 10 11 refreshSummaryById : function(gid){ var g = Ext.getDom(gid); if(!g){ return false; } var rs = []; this.grid.getStore().each(function(r){ if(r._groupId == gid){ rs[rs.length] = r; }
Autant pour des interfaces simples (en passant outre la qualité du code qui est produit derrière), je suis d'accord, on gagne du temps à avoir des composants tout prêts. Mais vu qu'on perd tout le bénéfice dès qu'on veut quelque chose de spécifique, j'ai du mal à saisir l'intérêt d'un tel framework.

25/02/2015, 19h35
sekaijin

en entreprise mes application utilisent 99% de composants standard de ExtJS
et dans le 1% des cas restant ce n'est qu'une adaptation de ces composant.

En terme de qualité du code à produire par le développeur comme tout le framwork est homogène (contrairement au plugins de JQuery) on gagne en efficacité en maintenabilite et on peut industrialiser le dev. l'usine logicielle peut compiler le code ExtJS, passer des test unitaires facile à écrire car tout est homogène, Exécuter du JS dans des outils de test sans avoir de navigateur à piloter, passer des vérification de qualité de code etc. chose qu'il est difficile d'industrialiser lorsque le code ne peut fonctionner qu'en présence de plusieurs langages, d'outil externe (navigateur) et de plugins Issus de différentes sources qui donc on des modèle de programmation qui divergent.

enfin la séparation des couches permet de donner le travail à plusieurs équipes. alors que dans JQuery l'adhérence est importante et mieux vaut découper le travail par domaine fonctionnel. chaque équipe doit développer le la persistance jusqu'à l'IHM pour son domaine. Avec ExtJS on peut découper par couche une équipe fait l'IHM donc vu de l'utilisateur toute l'application semble homogène en terme d'ergonomie. le métier est fait par une autre donc toutes les domaines métier son homogène et donc facile à maintenir et faire évoluer. et la persistance est délégué à des spécialistes qui ne connaissent rien à l'HIM.

Lorsque l'application fait des dizaines de milliers de lignes de code tant côté serveur que côté client. le bricolage du DOM est loin des préoccupations. l'important c'est le métier, les échanges client serveur, la persistance cela représente plus de 70% d'une application. l'IHM c'est presque rien. donc si un framework offre les composants IHM prêt à l'emploie, un modèle de dev simple à mettre en oeuvre pour le gros du dev et de plus permet d'industrialiser le développement et de le répartir efficacement sur plusieurs équipes.

Je crois que les intérêts de tel framework ne sont pas à ignorer.

Encore une fois ExtJS et JQuery ne sont pas comparable ce sont deux outils différents pour des usages différents.

Ce n'est pas un hasard si JQuery est si populaire auprès des éditeur de sites Web et ExtJS auprès des créateurs de WebApp au sein des entreprises.

Le simple fait d'avoir un compilateur en dit long sur le public visé.

A+JYT

99% en standard et 1% de spécifique, oui si tu ne cherches pas à faire d'écran vraiment poussé. C'est ce que je disais au départ à savoir qu'ExtJS était très bien pour des écrans de base. Mais dès que tu veux quelque chose de vraiment adapté à tes besoins, il faut s'armer de patience. Choisir ExtJS pour développer ses interfaces, c'est donc s'imposer comme contrainte de ne pas chercher plus que ce qui est proposé. C'est peut-être très personnel mais détruire toute possibilité de créativité, pas pour moi. Je veux pouvoir avoir des composants comme bon me semble et pas comme Sencha l'a décidé.
Je ne vois d'ailleurs pas comment le web (et à plus grande échelle le monde de l'informatique) pourrait évoluer sans cette créativité de la part des développeurs.

Citation:

Envoyé par sekaijin

le bricolage du DOM est loin des préoccupations

Cette mentalité si chère au monde de l'entreprise… "tant que le résultat est là, on est content, sans se préoccuper du comment". En gros, dans le cas d'ExtJS, on se fiche totalement du code HTML tant que visuellement on obtient ce qu'on veut. C'est assez réducteur.
D'une manière générale, cette philosophie est malheureusement très voire trop répandue dans le monde de l'informatique. Elle donne lieu à des arrachages de cheveux pour le support et l'évolution des applications (sauf que les développeurs s'en fichent, ce n'est pas forcément eux qui repassent derrière). Petit article qui aborde ce phénomène de boudage du "girly code" :
http://headrush.typepad.com/creating...ike_a_gir.html

Citation:

Envoyé par sekaijin

Avec ExtJS on peut découper par couche

Comment peux-tu dire ça ? Qu'il s'agisse de la présentation ou des traitements, tout est codé au même endroit avec ExtJS :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 var monComposant = new Ext.grid.GridPanel({ // traitement columns: [{ dataIndex: "col1", // traitement header: "Colonne 1", // présentation sortable: true, width: 80 // présentation }, { css: "text-align: center;", // présentation dataIndex: "col2", // traitement header: "Colonne 2", // présentation sortable: true, width: 80 // présentation }], store: monStore // traitement stripeRows: true, // présentation ...
En terme de mélange des couches, on fait difficilement pire.

C'est très intéressant de pouvoir confronter nos deux opinions sur le sujet, car je me rends compte que le problème vient au final plus de la mentalité qu'on peut avoir que de notre notion de propreté du code. On est d'accord sur les principes finaux à savoir :

être compatible partout
coder efficacement (donc rapidement)
rester homogène
…

mais que notre désaccord vient plutôt du moyen de parvenir à ces principes finaux.

26/02/2015, 18h09
sekaijin

Dans le monde industriel ce qui prime c'est l'efficacité. efficacité dans le dev dans la maintenance et dans l'usage.

On se moque des petite fleur et des oiseaux est des beaux effets on réserve ça au IHM pour le client (internet et encore on voit que certaine boite sont pas douées pour ça)

lorsqu'on affiche un grille de donnée on veut une grille et si dans l'entreprise on à 1000 grille dans 100 appli on veut qu'elle aient toutes la même apparence et le même comportement.

il suffit de regarder l'usage d'excel. Un étudiant, un commercial, un chercheur qui présente une grille faite avec excel y mets de la couleur du style pour rendre la présentation sexy attrayante mais dans 90% des cas Excel sert à manipuler des données et les seul effet de style sont là pour aider à comprendre du coup c'est peut-être moche mais c'est toujours pareil toujours efficace.

Quant à la définition de traitement et présentation que tu fais (dans ton exemple) tu est très loin du compte
tout cela n'est que de la présentation. le datastore est un lien entre la couche de présentation est son cache de donnée à présenter. tout comme l'index. cela n'a absolument rien à voir avec un traitement. pour cela il y a des classes pour le métier. il y a des contrôleurs pour le contrôle, pour la persistance il y a les proxy etc. le datastore est un cache de donne destiné à la présentation.

si ton appli ne fait que piocher des données dans un datastore et que du coup pour toi ce simple cache est la partie traitement tu ampute de 70% le code de mes applications.
dans une application on ne fait pas que lire écrire et stocker des données. on les traite on les transforme on en crée on calcule on déduit on induit etc.
les processus métier sont bien plus complexe que simplement afficher et enregistrer des données.

Je comprends mieux tes propos effectivement tu prends ExtJS pour un truc qui fait de l'IHM et pas des appli.

si indiquer à une vue où se trouve le cache des données qu'elle doit afficher c'est faire du traitement je n'ose imaginer ce qu'est que faire un bilan comptable, une charge de travail, un décalage de planning, un calcul de résistance.

dans l'industrie les application ont du code métier qui n'a absolument rien à voir avec une quelconque vue.

dans ExtJs on trouve des DataStore des Models des Proxys des Contrôleurs et des Classe métier pure.
tout cela peut fonctionner sans une seule vue.

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.

Quant à la persistance elle est dans ExtJS déléguée au serveur via un Proxy qui agit comme un représentant local d'un service distant. encore une fois cela n'a rien à voir avec une vue.

Si avec ça tu n'arrive pas à séparer tes couches c'est que tu as un sérieux problème.

Je suis sidéré que tu considère l'index dans le cache de donnée destiné à la présentation comme un élément de traitement.

dans ExtJS la vue est en relation avec un datastore qui est son cache local de donnée
les actions dans la vue sont captées par le contrôleur qui agit sur le datastore et qui inter agit avec les classes métier.

Par défaut tu peux persister directement ton cache via un proxy de persistance
mais tu peux aussi utiliser des classes métier locale qui invoquent des services sur le serveur. et par ce biais déléguer la persistance au au serveur qui deviens invisible dans la webapp.

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.

Je ne connais personne qui va voir le code compilé par C++ pour dire que l'application n'est pas maintenable. il va dans le code source C++ et justement ExtJS permets un code clair structuré concis.

Lorsqu'un développeur se penche sur le code généré par C++ c'est pour des problèmes de performance ou pour traquer un BUG particulièrement récalcitrant. (là ExtJS à un de ses gros point faible pour les raison que tu évoque sur le code généré) en général pour le Débug on reste au niveau du langage source c'est à dire dans notre cas le code JS.
C'est un gros avantage pour la maintenance l'évolution que de n'avoir qu'un seul langage. C'est toujours très compliqué de maintenir un code qui doit mixer plusieurs langages.

Produire un logiciel en entreprise s'apparente à une chaine de fabrication d'un Airbus. les contrôles qualité se font à tous les niveaux. les méthodes de Spécifications, de conceptions, de réalisations, de tests, sont vérifiées éprouvée répétables. rien n'est laissé au hasard.

j'imagine si aujourd'hui on abandonnait tous les framework de haut niveau dans tous les domaines pour n'utiliser que les API de base de tous les systèmes.
l'informatique ferait un arrêt brutal.
aujourd'hui même les processeurs sont conçus avec des outils qui permettent au développeur (de puce) de faire abstraction des éléments de base.
Cela n'empêche pas de chercheurs des développeurs de ce pencher sur ses fondement pour eux aussi les faire évoluer.
Mais sans atelier de conception évolué jamais tout cela ne serait adopté.

quelle vision étriqué du développement web tu nous donnes là.
Je suis consterné.

Tout au long de l'évolution de l'informatique on a vu apparaitre des limites. des gens se sont penché dessus et ont proposé des modèle de développement pour lever ces limites. cela a engendrée des dizaines de modèles de programmation. (procédurale, fonctionnelle objet etc) des centaines voire des millier de modèles de conceptions. Des outils, des langage sont nés pour implémenter ces modèles. certain avec plus ou moins de bonheur. d'autre avec des atout non négligeable.

Je pense qu'il ne viendrait à aucun développeur d'aujourd'hui l'idée de dire que tout ça est à mettre à la poubelle.
Je pense que pour des cas bien bien cibler on peut remettre en cause la pertinence du choix d'utiliser tel ou tel modèle. voire d'en proposer de nouveau. Mais personne aujourd'hui mettra tout ça en cause.

ExtJs est un de ces outils qui implémente plusieurs de ces modèles (ayant fait leur preuves) et il est reconnu en entreprise pour cela.
Que tu juge personnellement que pour tes développements il n'est pas adapté je le conçois. mais le juger en omettant tant d'autres aspect du développement d'application n'a pas de sens.

Quant à la créativité en entreprise on ne la cherche pas dans la beauté de l'interface. On la cherche dans l'activité de ces usager. dans le métier qu'on va implémenter dans les applications.

J'avoue qu'en lisant ce dernier post je me demande ce qu'est pour toi une application.
Je ne dirais pas qu'ExtJS c'est un must surement pas. Mais penser que sa philosophie est une aberration ça me laisse pantois.
En lisant ce post j'ai l'impression que tu n'imagine même pas ce que peut être une application dans une entreprise.

J'espère que je me trompe.
A+JYT
27/02/2015, 10h01
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 :
http://img11.hostingpics.net/thumbs/...complexits.png
À 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.

Citation:

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.
27/02/2015, 10h23
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.
28/02/2015, 13h06
Chen norris

Citation:

[…] 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é.
28/02/2015, 15h02
sekaijin

Citation:

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

Citation:

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.

Citation:

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

Citation:

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
02/03/2015, 09h05
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.