Discussion :

[pomeh]

Je suis entièrement d'accord avec toi sur le fait que jQuery fais les vérifications nécessaires en interne afin de ne pas faire des traitements sur des collections vides, ce qui constitue un gain de performances.

Mais je crois que tu as toi-même résumé mon point de vue avec ces deux phrases:

Ensuite quand avec jquery tu fais un $('.blabla').monplugin().
Derrière si le plugin est bien codé et qu'il teste le length de jquery ça ira .

La subtilité là dedans se résume au "SI le plugin [...]". Si le développeur du plugin n'as pas conscience que jQuery peut retourner des objets vides, il ne fera pas cette vérification lui-même. Et ce problème existe pour pas mal de plugins...
Et puis rien ne dis que demain ça ne sera pas toi ou moi qui écrira un plugin et qui devra prendre la responsabilité de faire cette vérification là. En règle générale, si le développeur n'as pas l'habitude de faire cette vérification dans son code "quotidien", il ne la fera pas lorsque qu'il écrira ce plugin en question.

Ensuite, je suis d'accord que 3 fonctions maximum appelées comme ça pour rien car l'objet est vide ce n'est pas beaucoup. Mais lorsque tu écrit un code comme ci-dessous (qui est volontairement moche, mais qui pourrait tout à fait exister), ce ne sont plus que 3 appels de fonctions...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
// exemple inventé d'un code de plugin pour faire un effet "voir plus" / "voir moins'
jQuery.fn.cropText = function( options ) {
	var defaults = {
		duration: 100
	};
 
	var settings = jQuery.extend( defaults, options ); // appel a extend pas necessaire si l'objet est vide...
 
	jQuery('.cropTextLink', this).click(function() {
		if( jQuery(this).parent('.cropText').is(':visible') )
		{
			jQuery(this).parent('.cropText').slideUp(settings.duration);
		}
		else
		{
			jQuery(this).parent('.cropText').slideDown(settings.duration);
		}
	});
 
	jQuery( this ).slideUp(settings.duration); // pas mal de traitements sont fait dans les méthodes d'animations comme ça, ici ça ne sert a rien..
 
};

(PS: ce code rassemble tout ce qu'il ne faut PAS faire avec jQuery)

Pour rester dans le thème du sujet, je dirais qu'il faut toujours être un minimum conscient de comment les choses se déroulent en arrière-plan, du moins pour les choses que l'on utilise souvent. jQuery et les autres librairies n'ont rien de magique, elles facilitent énormément la vie du développeur mais on peut très vite en faire une mauvaise utilisation...

[dukej]

jQuery et les autres librairies n'ont rien de magique, elles facilitent énormément la vie du développeur mais on peut très vite en faire une mauvaise utilisation...

Si ma librairie est magique :o
patapay

[Oscar Hiboux]

Voilà déjà quelques bons points soulevés ici ! C'est toujours amusant de lire certains commentaires qui transpirent le vécu...

Avant de poursuivre j'aimerais rappeler que JavaScript n'est pas un langage objet comme certains l'entendent (ceux-là même sont souvent déçus, malheureusement). Protoype.js, entre autres, offre certes la possibilité de décrire des classes avec la notion d'héritage mais c'est au détriment des protections d'accès aux variables, ce qui à mon sens est bien plus important que de pouvoir hiérarchiser des objets de cette manière. Avant d'apprendre à faire des "classes" en JavaScript il vaut mieux commencer par en apprendre comment fonctionne son modèle objet car il offre des possibilités intéressantes. C'est d'ailleurs une remarque qui en recoupe d'autres faites plus tôt : avant de tout planquer dans une bibliothèque il est préférable de maîtriser un minimum le langage.

Sinon, pour en revenir à la question, j'aimerais l'aborder un p'tit peu différemment en tâchant de rester dans le sujet...

Avec l'évolution d'HTML et CSS je vois en JavaScript une sorte de catalyseur vers le "tout-web" ou le "tout-dans-mon-navigateur". En effet, on arrive aujourd'hui à faire des choses assez impensables hier ; et demain sera un jour encore plus surprenant ! JavaScript, avec pour vocation initiale de dynamiser du contenu HTML, est progressivement devenu un véritable moteur applicatif et on en parle de plus en plus pour du côté-serveur (où apparaissent certaines bibliothèques également).

Rien qu'en voyant les dernières évolutions en terme d'interpréteurs on sent nettement l'engouement de l'industrie - pour faire un parallèle avec les changements au sein de la population des développeurs. Où va-t-on véritablement avec JavaScript et les technologies qui l'accompagnent ? On le saura très bientôt car tout ça va aller de plus en plus vite (croisons les doigts pour qu'IE 9 remplace vite ses anciens).

[JFGOmega]

Le plus beau c'est que vous avez tous raison !
Effectivement je pense moi aussi que c'est mieux d'écrire son propre code ne serait ce que parce que l'ayant écrit, on le maitrise et on peut facilement le maintenir. Le problème avec les frameworks, c'est que quand ça marche c'est super, quand ca coince, la première question, c'est ou est le problème, dans mon code ?, dans le code du framework ? dans l'utilisation que j'en ai fait ?

Vous voulez connaitre mon rêve : un framework léger (très léger) dont le seul usage, et le seul but serait (tu as raison dukej) régler les soucis d'icompatibilités des navigateurs car c'est (quand on un bon niveau de coding de base) la partie ou l'on perd le plus de temps et d'énergie.

Pour le reste, je ne connais pas un seul framework utile à 100%. Dans le meilleur des cas on en utilise peut être 20% (toujours si on a un niveau de base déjà très correct) et croyez moi, j'en ai étudié quelques uns avant d'en choisir un.

Ceci dit pour ceux qui n'ont pas ce niveau de base (déjà assez élevé dans mes critères), les frameworks sont surement très utiles, est ce qu'ils permettent à ceux qui les utilisent d'améliorer leur niveau : j'en doute car ils sont quand même très techniques et très peu documentés sur l'essence même du coding.


Très bon sujet en tout cas

[ke2007]

Personnellement avant je ne comprenais pas l'utilité des frameworks, pensait que c'était un phénomène de mode et ne voyait pas l'utilité de ré-apprendre une syntaxe quand tu en connais une... (Bon j'étais fermé je l'avoue )

Mais depuis peu, je me suis mis à Mootools et je dois dire que je ne regrette pas du tout.
Et personnellement je ne me suis pas encore mis au HTML5, mais j'aime bien utilisé le javascript et finalement avec un framework tu peux faire des multitudes de choses avec un minimum de code, et ça j'aime bien

Le problème avec les frameworks, c'est que quand ça marche c'est super, quand ca coince, la première question, c'est ou est le problème, dans mon code ?, dans le code du framework ? dans l'utilisation que j'en ai fait ?

C'est le revers de la médaille malheureusement ^^

[riete]

Cette question me rassure énormément sur ma façon de travailler. Moi qui travaille dans mon coin sans utiliser des librairies alors qu'elles fleurissent de toutes part et que leur utilisation se généralise. Je me disais "tu deviens ringard mec, tu devrais peut être faire comme les autres !".

Mais je n'ai jamais pu me résigner à perdre le contrôle total (au moins en apparence) sur tous ce que je développe. Passer des heures et des heures à essayer de décortiquer des librairies, au niveau productivité n'est pas non plus une solution. Alors je ne code sûrement pas parfaitement, mais ce que je fais fonctionne et j'en contrôle les performances.
Un autre argument en défaveur de l'utilisation des Librairies est le développement d'applications mobile ou le trafic se doit d'être optimisé.

Pour répondre à la question sur HTML5, je dirais que c'est une évolution logique pour le développement Web. Je l'ai découvert il y a 1 an avec WebKit. Depuis j'ai développé une appli offline pour mobile, c'est un peu déroutant au départ, mais je trouve cela très performant. Le principale problème réside dans le choix des mobiles et des navigateurs qui les équipes. Entre les spécifications constructeurs et la réalité il y a souvent un gouffre .

[Lcf.vs]

Perso, je n'utilise jamais de frameworks, je ressens moi aussi le besoin de pleinement maîtriser ce que j'ai développé, pour un peu toutes les raisons évoquées précédemment.

De plus, je n'aime pas l'idée de devoir mettre la licence d'un autre dans un de MES projets.

[stailer]

Passer des heures et des heures à essayer de décortiquer des librairies, au niveau productivité n'est pas non plus une solution

On peut lire vraiment de tout sur ce thread... J'utilise JQuery tous les jours et je l'ai toujours pris en Minified et je n'ai jamais regardé une seule ligne de code de son fichier. Pareil sur JQuery UI , ses composants , et pareil sur ExtJS.

Toutes ces remarques montrent véritablement que vous n'avez pas toucher à ces frameworks JS ou alors tout simplement : que vous savez pas vous en servir.

Désolé mais je suis pas un Dieu de la programmation LOOIIIIIN de la ... Et pourtant j'ai jamais eu de souci. Ni même avec de multiples composants dans la même page (par exemple ValidationEngine + Jquery UI avec tabs + JQgrid avec édition temps réel et customatisation des colonnes d'édition).

[guy_lux]

J'avoue que je suis assez étonné de lire que certains préfèrent tout coder à la main !!! Après, que l'on soit plus porté sur Prototype ou JQuery, peu importe, mais vouloir réinventer la roue dans ce domaine précis est à mon avis une _pure_ folie, tout particulièrement en ce qui concerne les compatibilité entre browsers. Enfin, on pourrait aussi parler des appels AJAX, des effets visuels... avec 50 ko de lib, j'ai tout ça en (rarement plus de) 3 lignes de codes, et bon, ça va, 50Ko de JS mis en cache, de nos jours, c'est vraiment rien-du-tout.

Je suis aussi étonné que certains aient une approche "les Frameworks JS, c'est pour les débutants". Débutant ou pas, on s'en fiche. Ce qui compte, c'est "efficace ou pas". Les clients veulent du bling bling avec de l'AJAX, des fade() et des appear() en pagailles, et si je devais tout me taper à la main, mon Dieu, j'explose toutes les deadlines !!!

Je n'ose même pas imaginer mes journées de boulot sans Prototype/JQuery

[Lcf.vs]

Hey, les gars, préférer tout coder à partir de zéro, ça ne signifie pas forcément faire et refaire sans arrêt.

Bon nombre de codeurs qui ont cette préférence ont tout simplement codé leur propre bibliothèque.

[ke2007]

Hey, les gars, préférer tout coder à partir de zéro, ça ne signifie pas forcément faire et refaire sans arrêt.

Bon nombre de codeurs qui ont cette préférence ont tout simplement codé leur propre bibliothèque.

Peut être que je m'avance beaucoup, mais coder sa propre bibliothèque donne surement au final un résultat plus lourd que celui proposé par une communauté où tout les savoirs sont mélangés et où je pense que les scripts sont optimisés au maximum.

En tt cas perso, je trouve ça jouissif de pouvoir coder sans me préoccuper des différences entre navigateurs et dès qu'il y a un changement j'ai pas besoin de recoder ma lib, je fais seulement un update de mon framework

[Bovino]

Bon nombre de codeurs qui ont cette préférence ont tout simplement codé leur propre bibliothèque.

+1.

Le but n'est pas de tout refaire pour le plaisir, mais d'avoir la possibilité de n'intégrer que ce qui est utile !
Comme déjà dit (à juste titre)

Pour le reste, je ne connais pas un seul framework utile à 100%. Dans le meilleur des cas on en utilise peut être 20%

donc si tu peux te faire une lib qui te permet d'intégrer seulement la partie utile, c'est pas plus mal et souvent meilleur au niveau performances (essaye de faire un pas à pas dans Firebug pour constater le nombre d'appels de méthodes pour un script simple avec une lib).

Les clients veulent du bling bling avec de l'AJAX

Autant je peux être d'accord globalement avec tes arguments, autant AJAX est le contre exemple : un appel AJAX codé main ne prend pas plus de place qu'avec un framework et ce cas est symptomatique de l'utilisation par les débutants.
Attention, je ne dis pas que seuls les débutants utilisent les fonctions AJAX d'un framework, si un codeur expérimenté utilise un framework, il aurait tort de ne pas l'utiliser à fond, en revanche, on voit souvent des débutants n'intégrer le framework QUE pour AJAX et utiliser du code natif pour le reste.
Et c'est dans ce sens qu'il est dit que l'utilisation d'un framework est une mauvaise approche pour débuter, qu'il soit utilisé pour d'autres raisons a été largement approuvé dans ce topic (même par ceux qui n'en utilisent pas).

[RomainVALERI]

Peut être que je m'avance beaucoup, mais coder sa propre bibliothèque donne surement au final un résultat plus lourd que celui proposé par une communauté où tout les savoirs sont mélangés et où je pense que les scripts sont optimisés au maximum.

Même si ta remarque semble tenir du bon sens, je crois que ce n'est pas tout-à-fait juste.

La communauté de dev d'un framework donné a bien sûr des moyens plus importants que le développeur isolé. Cependant :

- le développeur isolé a en revanche des "spécifications" connues, limitées, et beaucoup plus simples que celles d'un framework, étant donné qu'il n'a pas à remplir toutes les fonctions généralistes et plus ou moins détaillées que propose un framework : il va à l'essentiel des besoins, au fur et à mesure de leur rencontre. Pas besoin de mettre au point, tester, ajuster et garder à jour tout une partie consacrée (par exemple) au "drag and drop" si le besoin ne se présente pas encore.

- le développeur isolé n'est, en fait, pas isolé ^^ la preuve en est nos beaux forums de developpez (entre autres)

Enfin, la nécessité de toujours suivre les évolutions du langage pour adapter en continu sa librairie perso sont, à mon avis, une meilleure "hygiène de travail" ou "hygiène intellectuelle" (si j'ose dire ) que celle consistant à donner sa confiance à un framework aveuglément, quitte à en devenir dépendant.

[crcom106]

J'ai découvert HTML et JS à une époque où lancer la compilation d'un programme en Java te laissait le temps d'aller boire un café. Et j'ai littéralement passé des nuits blanches à faire clignoter des textes ou faire des tableaux de toutes les couleurs sous NS4. C'était instantané, c'était magique !

Il y a peu, quand j'ai cherché du boulot, on m'a demandé : "
- Vous connaissez jQuery ?
- Ben, non. J'ai mes propres librairies et je code directement mes besoins en JS.
- Au revoir."

J'ai déjà utilisé prototype.js, ext.js ou encore jQuery pour faire "hello world".
Alors pourquoi, je ne les connais pas ?
- je suis trop souvent rebuté par la syntaxe de ces librairies, surtout jQuery.
- je n'aime pas la syntaxe à la JSON (Math.pow(imbrication,n))
- et comme beaucoup, je préfère vraiment maîtriser mon code
Donc, un peu comme un emballage cadeau, ben, la syntaxe ça compte !

Ces frameworks contribuent à faire évoluer le web en général. Avant on copiait un bout de code que l'on rebalancait à sa sauce sur le web. Aujourd'hui on charge une librairie qui donne à certains l'envie de créer et partager la leur. Et demain ? Peut-être quelques méga d'application web qui permettront de visualiser un astronaute sur Mars, et que les uns et les autres voudront refaire en l'améliorant
Pour moi, javascript fait partie de ces langages de haut niveau, mal fichu/imparfait qui n'évoluera que lentement, que tout le monde utilisera pour créer des outils ultra-top contribuant ainsi à sa démocratisation, sans qu'il y ait de réel pas en avant dans son évolution.

[riete]

@stailer le site que tu propose en pied de message "Revolution Sound Records" est il une réalisation de ta part ?

[stailer]

Pas du tout !

C'est parce que je fais de la musique en fait...

En perso j'ai http://www.stailer.com mais fais un peu à l'arrache. L'ergonomie est pas top.

[Kymils]

Pour ma part, je suis novice en javascript. Comme je n'ai ni le niveau, ni le temps, ni l'envie de faire puis de maintenir ma propre librairie, jQuery a été pour moi une bénédiction. Des trucs qui me paraissaient hors de portée se font sur une seule ligne. En plus la syntaxe ne me rebute pas, bien au contraire.


C'est un peu de l'industrialisation, en tout cas, je vois bien ça comme l'avenir de l'utilisation de javascript.

[sekaijin]

pour moi la question ne se pose même pas coder à la mimine est une aberration.

Non que je traite ceux qui le font de fous ou de ringard ou autre.

simplement parce que dans mon contexte ce ne peut être envisager.
je pense qu'il faut des gens qui code en js pur sans framework pour par exemple faire des choses que les framework ne font pas encore.

je pense par exemple à la lib raphael si le gus qui à commencé n'avait codé qu'avec les framework disponible il n'aurait jamais produit de dessin.

donc il en faut et gloire à ces travailleur de l'ombre.

par contre dans ma partie c'est tout autre chose. plusieurs millions de formulaire en ligne cela signifie des millions de procédure de vérification
des application développées par des équipes qui évolue des prestataires différent qui reprennent ce que d'autres ont fait etc. des application de plusieurs dizaines de milliers de lignes de code.

dans un tel contexte le code perso à la mimine c'est prohibé. on utilise des procédures industrielles qui permettent l'appropriation du code par d'autre. de valider ce qui est produit etc. le tout s'appuyant dur des librairies éprouvées. on ne réinvente pas la roue à chaque fois et on capitalise un maximum ce qui est fait.

en lisant la discussion je vois que beaucoup reproche au framework de ne pas permettre l'apprentissage du langage.

Heu je ne connais pas une lib un framework un environnement quel qu'il soit sur n'importe quel langage qui n'ai pas pour prérequis de connaitre le langage.

le premier cour de C, C++, Java, JS, PHP etc c'est Hello Word en faisant en sorte qu'on se détache le plus possible de l'environnent.

prenez un cour C et vous verrez sur ce premier cour la façon de s'y prendre et de suite une remarque.
"Nous allons utiliser la fonction printf pour que votre programme affiche le résultat attendu. ne cherchez pas à en comprendre pour le moment son fonctionnement. nous y reviendrons. sachez seulement pour le moment que cela va vous permettre de faire afficher par votre programme le message désiré."

Bref il en va toujours ainsi.
Les doc des framework considèrent toujours que vous maitrisez le langage.
et heureusement. car si on devait expliquer tout les mots qu'on utilise à chaque fois qu'on l'utilise. ce simple post quoi que déjà long ferait la taille d'un dictionnaire.

pour js c'est la même chose. les framework tentent chacun de leur côté de répondre à un besoin particulier dans un contexte particulier. il ne sont pas fait pour apprendre javascript.

pour cela il faut en passer par le B.A.BA. si ce n'était pas le cas cela signifierait qu'on peut apprendre l'anglais sans connaissance préalable juste en ayant dans ses main l'œuvre de shakespeare. les enfants seraient heureux plus besoin d'école primaire. les collégiens aussi plus de cours e langue.

Donc apprenez les bases, cherchez les libs ou les framework qui correspondent à vos besoin, au pire développez le. mais soyez conscient qu'aucun langage aucune lib aucun framework ne répondra à tous les besoin.

A+JYT

[gwinyam]

Le souci, pour rebondir sur tes propos (qui sont tout à fait en accord avec ma vision), c'est qu'on trouve encore trop de développeurs qui ne poussent même pas jusqu'à la doc du framework. Qui vont seulement jusqu'à des exemples de code, des bidouilles, des astuces, copient/collent le code et ensuite pleurent parce que ça marche pas. Les bricolos quoi.

Ce sont ces gens là qui donnent une mauvaise réputation à Javascript.

[dukej]

Le souci, pour rebondir sur tes propos (qui sont tout à fait en accord avec ma vision), c'est qu'on trouve encore trop de développeurs qui ne poussent même pas jusqu'à la doc du framework. Qui vont seulement jusqu'à des exemples de code, des bidouilles, des astuces, copient/collent le code et ensuite pleurent parce que ça marche pas. Les bricolos quoi.

Ce sont ces gens là qui donnent une mauvaise réputation à Javascript.

Quand j'ai un doute c'est doc + analyse du code source, ca permet de comprendre comment les mecs ont fait

En flex quand j'utilise un composant flex 3 par exemple je regarde directement la source du composant, la fleme d'aller chercher dans la doc