La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix.
Les réponses multiples sont interdites pour les mêmes raisons.
Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses.
76,78 % des personnes sondées estiment que ces sondages sont ineptes.
j'utilise beaucoup Spip, et c'est il me semble Jquery qui est beaucoup utilisé, et encore ça dépends des extensions installées.
Personnellement, je n'en utilise pas, et je fais attention à ce que le site soit utilisable sans javascript, et que sinon cela ne bouffe pas trop de puissance.
le mieux pour tester la consommation de ressource CPU, c'est d'utiliser une vieille machine, genre Athlon XP à moins de 1.2GHz. (ou un truc plus lent).
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
en fait, j'ai même changé de poste il y a une semaine, pour un autre un peu plus puissant, mais surtout plus stable. Il doit y avoir un truc pas clair dans le noyau ou ailleurs qui fait que depuis 6 mois environs mes deux Athlon XP plantent au bout de quelques jours, vu que je n'ai plus ce soucis avec le nouveau (j'ai juste déplacé le disque dur).
Pour moi, 10 ans, c'est déjà beaucoup, ensuite tout dépend des usages. J'aurai bien continué à m'en servir s'il n'y avait pas ces plantages récurrents. Avec le nouveau (une récup), j'ai gagné en vitesse d'affiche des pages web et sur pas mal de petits trucs, par contre j'ai perdu l'écran virtuel ça m'agace franchement.
Les deux autres postes sont donc toujours en place, et seront utilisés comme terminaux légers, sans disque dur, avec démarrage par le réseau. Pour l'utilisation que je fais des machines je n'ai pas besoin de puissance, sauf très rarement quand j'utilise Gimp sur de très gros documents, et encore... ça me laisse le temps de réfléchir et ça m'oblige au contraire à être plus attentif.
Les petites machines (genre PIII à 700MHz) c'est pas mal, mais s'il n'y a pas au moins 512Mo de ram c'est vraiment dommage, et ne parlons pas de les utiliser en serveur à domicile à cause de la consommation d'électricité, parce que dans ce cas autant les remplacer par un eeePC, ou Sheevaplug...
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
il doit y avoir un truc pas clair dans le noyau ou ailleurs qui fait que depuis 6 mois environs mes deux Athlon XP plantent au bout de quelques jours, vu que je n'ai plus ce soucis avec le nouveau (j'ai juste déplacé le disque dur).
Problème de mémoire ? De surchauffe ? ou d'alim ?
j'ai change de kernel vers une version très récente (celle dans Unstable) d'abord sur un poste, et il a eu ces symptômes. (plantage au bout de quelques jours).
Ce n'est que bien plus tard que j'ai changé le kernel de mon poste principale, et j'ai aussi eu les mêmes problèmes.
Ces deux postes ont très peu de différences, c'est au niveau de la carte son intégrée, mais c'est vrai que ce ne sont pas exactement les mêmes cartes mères (même si la référence commerciale est la même).
Je vais bientôt pouvoir reprendre les tests, et je verrai.
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
J'utilise de plus en plus jQuery et j'ai tendance à me débarrasser de la dépendance aux autres bibliothèques. jQuery est léger et complet, et surtout correspond parfaitement aux besoins des sites dont je m'occupe. (je rajouterais juste que c'est jQuery + jQuery UI dont je fais usage.
J'utilise très rarement Javascript, et mes seules utilisation, c'est plutôt pour le look & feel. La documentation de Dojo, c'est toujours pas correct, mais on peut quand même développer assez vite: transitions sympas, module Comet_(informatique), ... . D'ailleurs, sans vouloir lancer des trolls, je préfère les applications comme [1] que le debian.org : en plus d'être beaucoup plus beau, ce genre de site est plus ergonomique...
Un bon vieux bout de papier et un crayon, y a que ça de vrai !!
Quoi que, à la réflexion, la pierre se conserve mieux que le papier.... on devrait plutôt revenir à la bonne époque de la gravure sur marbre. Ça c'était un média qu'il était bien.
Et pour les moins anti-évolution, il est possible aussi de réfléchir, et de se rendre compte que le javascript, quand il est utiliser correctement, permet de rendre un document HTML bien plus agréable à consulter.
Et si on n'est pas trop fermé, on peut se rendre compte que le web est en train de se diviser en deux fonctionnements distincts : les documents web, et les applications web.
Dans le premier cas on parle de documents hypertexte riches auxquels une couche légère et bien pensée de javascript est très appréciable pour en améliorer l'ergonomie.
Dans le deuxième cas, on est dans un contexte d'applications en ligne, et donc les contraintes sont totalement différentes de simples documents hypertextes, ce qui fait que les critères permettant de les qualifiés sont également différents. Notamment les contraintes d'accessibilité par exemple (évidemment il faut faire en sorte que les applications web soient accessibles, mais ce ne sont pas les même contraintes).
Des exemples pour distinguer les deux :
Exemples d'hypertextes : Wikipedia, les journaux en ligne, les documentations, les blogs etc.
Exemples d'applications web : les clients mail web, les messagerie instantanée web, toutes les diverses applications web style google docs ou autres etc.
Comme nous somme dans une période charnière où les applications web commencent à se distinguer des documents hypertextes, mais utilisent toujours les mêmes technologies, un amalgame est vite fait entre les deux. Mais il me semble que ce serait une erreur de condamner tout en bloque.
Dans le cadre de mon boulot, je m'occupe du développement d'un gros ERP web.
Notre choix s'est porté sur ExtJS, et franchement ça fait tout ce qu'on veut. Je gère pas exemple très bien le multi window (sur une fenetre de navigateur bien sur) et le résultat est assez sympa.
Non, c'est du 100 % développé maison ;)
Et c'est le projet qui est vraiment la plaque tournante de la société (plus de 500 salariés).
J'étais pas trop chaud au départ sur le dev PHP/ExtJS. (Je suis plutôt développeur C/C++/Delphi et éventuellement Java).
Mais au final, je trouve que les perfs et le look and feel sont assez sympa.
C'est moins "fun" à coder, c'est parfois assez lourd de devoir gérer les spécificités des navigateurs (qui a parlé de IE 6 ? ;) )
mais ça fait un truc portable, sans installation et avec une maintenance assez facile.
C'est pas un petit projet qu'on fait en claquant des doigts, on est deux à bosser dessus à temps plein.
C'est moins "fun" à coder, c'est parfois assez lourd de devoir gérer les spécificités des navigateurs (qui a parlé de IE 6 ? ;) )
mais ça fait un truc portable, sans installation et avec une maintenance assez facile.
C'est pas un petit projet qu'on fait en claquant des doigts, on est deux à bosser dessus à temps plein.
N'y a t-il pas un risque à supporter en interne un tel projet ? Est-ce qu'il ne serait pas intéressant de libérer la partie basse du code sous forme de bibliothèque pour essayer d'avoir des contributions externes ?
Bon, pour résumer l'expérience :
1/ Oui le Javascript ça pue en l'état, et ce quelque soit le framework utilisé. C'est une techno qui a été complètement victime de son succès, qui était tout à fait adaptée pour faire des manipulations simples du DOM mais qui est complètement dépassée pour faire des clients Web riche et qui rend le résultat non maintenable. Il est plus qu'urgent qu'on passe au standard ECMAScript 4 parce que là c'est bien plus agréable de développer en Flash/ActionScript 3 qui utilise ECMAScript 4 plutôt qu'en JavaScript. (Oui bon pas taper.)
2/ Il est impossible de faire du code de qualité en Javascript, car comme chaque navigateur implémente une API Javascript différente et avec des implémentations plus ou moins boguées (voire très boguées dans le cas d'IE) on est obligé de faire des workarounds du workaround, etc.
3/ GWT est séduisant, mais bon, dès qu'on commence à avoir des layouts compliqués là encore bonjour les surprises, même si ça reste plus agréable de développer en GWT qu'en JS directement ne serait-ce que parce qu'à cause de l'absence de typage de Javascript on ne peut pas faire d'API de qualité dans ce langage...
Il y a une image qui résume d'ailleurs très bien ce qu'est le développement web ici, et qui n'est pas tant exagérée qu'on pourrait le penser : http://humor.beecy.net/geeks/web-design/
Pour revenir à nos moutons :
1/ ExtJS supporte plein de widgets, oui ça c'est vrai.
2/ Il y a vraiment des composants tout faits pour tout en ExtJS.
Mais :
1/ La maintenance d'une appli en Ext est très compliquée, ne serait-ce que parce que faire un layout avec une page HTML qu'on intègre dans une fenêtre, c'est toujours plus simple que de le coder en Ext.
2/ Le nombre de mauvaises surprise est assez énorme avec Ext, surtout quand on doit faire des tests sur différents navigateurs.
- Essaie en particulier les forms qui contiennent des tab panels, et tu verras que tu as le choix entre soit avoir un rendu foireux sur les combobox et les grid panels, soit submitter des forms partiels avec des valeurs manquantes parce que les widgets n'ont pas été générés correctement.
- De même, avec Ext3 ils ont changé les types supportés par les records sans les documenter. (type='boolean' est passé en type='bool' alors que la doc affiche toujours type='boolean'...)
- De même, en Ext3 si tu oublies le paramètre forceLayout=true sur un widget bonjour les surprises.
- Si tu oublies de mettre un hideMode à 'offsets' sur un panel qui a un cardlayout au bout d'un moment, en switchant entre tes panels les boutons ne deviennent plus cliquables.
- Les fuites mémoire des navigateurs.
- Essaie de limiter le nombre de requêtes Ajax simultanées que tu peux lancer depuis un site codé en Ext, tu vas bien t'amuser. (Oui les record et les store c'est très séduisant à première vue, mais si tu as un besoin spécifique qui n'est pas couvert par ces records et stores tu galères un max...)
- Et la liste est longue.
Par contre, JQuery est beaucoup plus simple, il y a des plugins de qualité assez variable mais la lib de base reste très simple et très stable, globalement. Tu as une bien meilleure maîtrise du code HTML généré si tu utilises des fenêtres étant donné que c'est toi qui l'écris et que les workarounds des différents navigateurs sont plus faciles à intégrer de ce fait.
Il faut implémenter des workarounds avec JQuery si tu utilises les applets Java sous IE (encore lui...), mais dans l'ensemble on a assez peu de mauvaises surprise.
Bref, oui ExtJS est très séduisant. Mais quand on creuse un peu, on se rend compte que c'est très difficile de stabiliser une appli en ExtJS. Il n'y a qu'a voir Yahoo Mail nouvelle version, certes ça claque mais c'est très lourd et franchement pas stable, et ça utilise YahooUI, qui est à peu de choses près la même chose qu'ExtJS. Le problème conceptuel d'Ext est qu'ils ont essayé de faire de JS un langage objet, alors que justement ce n'en est pas un.
JQuery est bien plus basique, mais en fait on maîtrise beaucoup plus ce qu'on fait. Par exemple sur le projet sur lequel j'ai bossé on a centralisé tous les appels Ajax dans un "objet" Javascript. Bien moins de problèmes de fuites mémoire, et le framework est orienté prototype comme Javascript donc en fait ça marche mieux.
JQuery a le gros avantage d'intégrer le principe KISS (Keep It SImple Stupid) que Ext semblent avoir oublié.
Donc à choisir entre les deux, je choisirais nettement JQuery.
Par rapport à tes remarques sur Javascript et l'attente d'ECMA v4, j'ai récemment redécouvert haXe, un langage et compilateur qui pourrait t'intéresser car il est traduit vers plusieurs plate-formes et langages, dont Javascript.
Ne développant pas - encore - en haXe, je ne saurai juger de la qualité du code produit mais le langage, orienté objet, apporte un certain nombre de choses dont certaines font partie de l'ECMA v4. Pour plus de détails, je vous renvoie sur le site officiel, qui parlera bien mieux que moi des spécificités du langage :
[http://haxe.org/doc/intro]
[http://haxe.org/doc/features]
[http://haxe.org/doc/why]
... mais je ne trouve pas de bibliothèque qui m'aiderait à faire des "widget". Widget dans le sens de ce qu'on peut trouver pour 'iGoogle' & cie. Un tableau de bord sur lequel je peux ajouter des boites, que je peux déplacer, redimensionner, etc. Ça existe ou bien est-ce qu'il faut se le refaire à sa propre sauce ? ;)
J'utilise pas de lib, mais sinon la seule lib qui mérite d'être utilisée c'est base2 :
base2 is a lightweight library that irons out all the annoying differences in JavaScript implementations. It provides the additional functionality from JavaScript 1.6+ that only Mozilla browsers implement. It also adds some features from ES4. The library is only 6KB (gzipped).
# Heu... c'est intégré dans les outils que j'utilise
Posté par GG (site web personnel) . Évalué à 3.
j'utilise beaucoup Spip, et c'est il me semble Jquery qui est beaucoup utilisé, et encore ça dépends des extensions installées.
Personnellement, je n'en utilise pas, et je fais attention à ce que le site soit utilisable sans javascript, et que sinon cela ne bouffe pas trop de puissance.
le mieux pour tester la consommation de ressource CPU, c'est d'utiliser une vieille machine, genre Athlon XP à moins de 1.2GHz. (ou un truc plus lent).
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Heu... c'est intégré dans les outils que j'utilise
Posté par peikk0 . Évalué à 4.
/me regarde son PIII qui passe les années sans broncher et qui en a encore beaucoup devant lui...
[^] # Re: Heu... c'est intégré dans les outils que j'utilise
Posté par GG (site web personnel) . Évalué à 3.
en fait, j'ai même changé de poste il y a une semaine, pour un autre un peu plus puissant, mais surtout plus stable. Il doit y avoir un truc pas clair dans le noyau ou ailleurs qui fait que depuis 6 mois environs mes deux Athlon XP plantent au bout de quelques jours, vu que je n'ai plus ce soucis avec le nouveau (j'ai juste déplacé le disque dur).
Pour moi, 10 ans, c'est déjà beaucoup, ensuite tout dépend des usages. J'aurai bien continué à m'en servir s'il n'y avait pas ces plantages récurrents. Avec le nouveau (une récup), j'ai gagné en vitesse d'affiche des pages web et sur pas mal de petits trucs, par contre j'ai perdu l'écran virtuel ça m'agace franchement.
Les deux autres postes sont donc toujours en place, et seront utilisés comme terminaux légers, sans disque dur, avec démarrage par le réseau. Pour l'utilisation que je fais des machines je n'ai pas besoin de puissance, sauf très rarement quand j'utilise Gimp sur de très gros documents, et encore... ça me laisse le temps de réfléchir et ça m'oblige au contraire à être plus attentif.
Les petites machines (genre PIII à 700MHz) c'est pas mal, mais s'il n'y a pas au moins 512Mo de ram c'est vraiment dommage, et ne parlons pas de les utiliser en serveur à domicile à cause de la consommation d'électricité, parce que dans ce cas autant les remplacer par un eeePC, ou Sheevaplug...
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Heu... c'est intégré dans les outils que j'utilise
Posté par briaeros007 . Évalué à 2.
Problème de mémoire ? De surchauffe ? ou d'alim ?
Bref pas forcément la faute du software ;)
[^] # Re: Heu... c'est intégré dans les outils que j'utilise
Posté par GG (site web personnel) . Évalué à 2.
mais:
j'ai change de kernel vers une version très récente (celle dans Unstable) d'abord sur un poste, et il a eu ces symptômes. (plantage au bout de quelques jours).
Ce n'est que bien plus tard que j'ai changé le kernel de mon poste principale, et j'ai aussi eu les mêmes problèmes.
Ces deux postes ont très peu de différences, c'est au niveau de la carte son intégrée, mais c'est vrai que ce ne sont pas exactement les mêmes cartes mères (même si la référence commerciale est la même).
Je vais bientôt pouvoir reprendre les tests, et je verrai.
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Heu... c'est intégré dans les outils que j'utilise
Posté par Elfir3 . Évalué à 2.
# jQuery
Posté par Julien Humbert . Évalué à 2.
[^] # Re: jQuery
Posté par blobmaster . Évalué à 2.
http://jqueryui.com/
Allez-y, essayez le, adoptez le !
# Dojo : superficialité assumé
Posté par William Briand . Évalué à 1.
[1] [http://demos.dojotoolkit.org/demos/cropper/]
# Bein pour moi
Posté par highleaf . Évalué à -1.
[^] # Re: Bein pour moi
Posté par kursus_hc . Évalué à 5.
[^] # Re: Bein pour moi
Posté par Nicolas Deveaud . Évalué à 3.
Quoi que, à la réflexion, la pierre se conserve mieux que le papier.... on devrait plutôt revenir à la bonne époque de la gravure sur marbre. Ça c'était un média qu'il était bien.
Et pour les moins anti-évolution, il est possible aussi de réfléchir, et de se rendre compte que le javascript, quand il est utiliser correctement, permet de rendre un document HTML bien plus agréable à consulter.
Et si on n'est pas trop fermé, on peut se rendre compte que le web est en train de se diviser en deux fonctionnements distincts : les documents web, et les applications web.
Dans le premier cas on parle de documents hypertexte riches auxquels une couche légère et bien pensée de javascript est très appréciable pour en améliorer l'ergonomie.
Dans le deuxième cas, on est dans un contexte d'applications en ligne, et donc les contraintes sont totalement différentes de simples documents hypertextes, ce qui fait que les critères permettant de les qualifiés sont également différents. Notamment les contraintes d'accessibilité par exemple (évidemment il faut faire en sorte que les applications web soient accessibles, mais ce ne sont pas les même contraintes).
Des exemples pour distinguer les deux :
Exemples d'hypertextes : Wikipedia, les journaux en ligne, les documentations, les blogs etc.
Exemples d'applications web : les clients mail web, les messagerie instantanée web, toutes les diverses applications web style google docs ou autres etc.
Comme nous somme dans une période charnière où les applications web commencent à se distinguer des documents hypertextes, mais utilisent toujours les mêmes technologies, un amalgame est vite fait entre les deux. Mais il me semble que ce serait une erreur de condamner tout en bloque.
# ExtJs
Posté par Antoine Alexandre . Évalué à 2.
Notre choix s'est porté sur ExtJS, et franchement ça fait tout ce qu'on veut. Je gère pas exemple très bien le multi window (sur une fenetre de navigateur bien sur) et le résultat est assez sympa.
[^] # Re: ExtJs
Posté par Amaury . Évalué à 1.
PHPmyERP ?
... je vérifie sur le web et apparemment ça existe !
[^] # Re: ExtJs
Posté par Antoine Alexandre . Évalué à 1.
Et c'est le projet qui est vraiment la plaque tournante de la société (plus de 500 salariés).
J'étais pas trop chaud au départ sur le dev PHP/ExtJS. (Je suis plutôt développeur C/C++/Delphi et éventuellement Java).
Mais au final, je trouve que les perfs et le look and feel sont assez sympa.
C'est moins "fun" à coder, c'est parfois assez lourd de devoir gérer les spécificités des navigateurs (qui a parlé de IE 6 ? ;) )
mais ça fait un truc portable, sans installation et avec une maintenance assez facile.
C'est pas un petit projet qu'on fait en claquant des doigts, on est deux à bosser dessus à temps plein.
[^] # Re: ExtJs
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
mais ça fait un truc portable, sans installation et avec une maintenance assez facile.
Pour IE6 : http://www.ie6nomore.com/ et on n'en parle plus. Même youtube ne le supporte plus !
C'est pas un petit projet qu'on fait en claquant des doigts, on est deux à bosser dessus à temps plein.
N'y a t-il pas un risque à supporter en interne un tel projet ? Est-ce qu'il ne serait pas intéressant de libérer la partie basse du code sous forme de bibliothèque pour essayer d'avoir des contributions externes ?
[^] # Re: ExtJs
Posté par gojul . Évalué à 3.
Bon, pour résumer l'expérience :
1/ Oui le Javascript ça pue en l'état, et ce quelque soit le framework utilisé. C'est une techno qui a été complètement victime de son succès, qui était tout à fait adaptée pour faire des manipulations simples du DOM mais qui est complètement dépassée pour faire des clients Web riche et qui rend le résultat non maintenable. Il est plus qu'urgent qu'on passe au standard ECMAScript 4 parce que là c'est bien plus agréable de développer en Flash/ActionScript 3 qui utilise ECMAScript 4 plutôt qu'en JavaScript. (Oui bon pas taper.)
2/ Il est impossible de faire du code de qualité en Javascript, car comme chaque navigateur implémente une API Javascript différente et avec des implémentations plus ou moins boguées (voire très boguées dans le cas d'IE) on est obligé de faire des workarounds du workaround, etc.
3/ GWT est séduisant, mais bon, dès qu'on commence à avoir des layouts compliqués là encore bonjour les surprises, même si ça reste plus agréable de développer en GWT qu'en JS directement ne serait-ce que parce qu'à cause de l'absence de typage de Javascript on ne peut pas faire d'API de qualité dans ce langage...
Il y a une image qui résume d'ailleurs très bien ce qu'est le développement web ici, et qui n'est pas tant exagérée qu'on pourrait le penser :
http://humor.beecy.net/geeks/web-design/
Pour revenir à nos moutons :
1/ ExtJS supporte plein de widgets, oui ça c'est vrai.
2/ Il y a vraiment des composants tout faits pour tout en ExtJS.
Mais :
1/ La maintenance d'une appli en Ext est très compliquée, ne serait-ce que parce que faire un layout avec une page HTML qu'on intègre dans une fenêtre, c'est toujours plus simple que de le coder en Ext.
2/ Le nombre de mauvaises surprise est assez énorme avec Ext, surtout quand on doit faire des tests sur différents navigateurs.
- Essaie en particulier les forms qui contiennent des tab panels, et tu verras que tu as le choix entre soit avoir un rendu foireux sur les combobox et les grid panels, soit submitter des forms partiels avec des valeurs manquantes parce que les widgets n'ont pas été générés correctement.
- De même, avec Ext3 ils ont changé les types supportés par les records sans les documenter. (type='boolean' est passé en type='bool' alors que la doc affiche toujours type='boolean'...)
- De même, en Ext3 si tu oublies le paramètre forceLayout=true sur un widget bonjour les surprises.
- Si tu oublies de mettre un hideMode à 'offsets' sur un panel qui a un cardlayout au bout d'un moment, en switchant entre tes panels les boutons ne deviennent plus cliquables.
- Les fuites mémoire des navigateurs.
- Essaie de limiter le nombre de requêtes Ajax simultanées que tu peux lancer depuis un site codé en Ext, tu vas bien t'amuser. (Oui les record et les store c'est très séduisant à première vue, mais si tu as un besoin spécifique qui n'est pas couvert par ces records et stores tu galères un max...)
- Et la liste est longue.
Par contre, JQuery est beaucoup plus simple, il y a des plugins de qualité assez variable mais la lib de base reste très simple et très stable, globalement. Tu as une bien meilleure maîtrise du code HTML généré si tu utilises des fenêtres étant donné que c'est toi qui l'écris et que les workarounds des différents navigateurs sont plus faciles à intégrer de ce fait.
Il faut implémenter des workarounds avec JQuery si tu utilises les applets Java sous IE (encore lui...), mais dans l'ensemble on a assez peu de mauvaises surprise.
Bref, oui ExtJS est très séduisant. Mais quand on creuse un peu, on se rend compte que c'est très difficile de stabiliser une appli en ExtJS. Il n'y a qu'a voir Yahoo Mail nouvelle version, certes ça claque mais c'est très lourd et franchement pas stable, et ça utilise YahooUI, qui est à peu de choses près la même chose qu'ExtJS. Le problème conceptuel d'Ext est qu'ils ont essayé de faire de JS un langage objet, alors que justement ce n'en est pas un.
JQuery est bien plus basique, mais en fait on maîtrise beaucoup plus ce qu'on fait. Par exemple sur le projet sur lequel j'ai bossé on a centralisé tous les appels Ajax dans un "objet" Javascript. Bien moins de problèmes de fuites mémoire, et le framework est orienté prototype comme Javascript donc en fait ça marche mieux.
JQuery a le gros avantage d'intégrer le principe KISS (Keep It SImple Stupid) que Ext semblent avoir oublié.
Donc à choisir entre les deux, je choisirais nettement JQuery.
"-".
[^] # Re: ExtJs
Posté par Yakulu . Évalué à 1.
Ne développant pas - encore - en haXe, je ne saurai juger de la qualité du code produit mais le langage, orienté objet, apporte un certain nombre de choses dont certaines font partie de l'ECMA v4. Pour plus de détails, je vous renvoie sur le site officiel, qui parlera bien mieux que moi des spécificités du langage :
[http://haxe.org/doc/intro]
[http://haxe.org/doc/features]
[http://haxe.org/doc/why]
# jquery, mais....
Posté par Marc (site web personnel) . Évalué à 1.
# base2
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
base2 is a lightweight library that irons out all the annoying differences in JavaScript implementations. It provides the additional functionality from JavaScript 1.6+ that only Mozilla browsers implement. It also adds some features from ES4. The library is only 6KB (gzipped).
http://code.google.com/p/base2/
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# A voté
Posté par Tonton Benoit . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.