Où va-t-on avec JavaScript ? [Débat]

[le_chomeur]

Bonjour a tous , cela faisait un moment que je n'avais pas posté

Depuis quelques temps , je remarque une évolution des comportements vis a vis de JS , de plus en plus d'utilisateurs viennent ici pour comprendre / modifier des scripts existant en fonction de leur besoins, et bien souvent ces scripts sont basé sur des librairies / framework.

d'ou ma question , concrètement pensez vous continuez à coder comme nous le faisons aujourd'hui en repartant de zéro ( Spaffy si tu m'entends ) ou vous même passer a du full librairie pour vos dev , même les plus minimes ?

en apparté pour ceux qui ont commencé a s'y intéresser , vos retours sur l'html 5 / css3 et toutes les nouvelles fonctionnalités introduites par ceci au seins de javascript.

cdt,

Le_chomeur

[vermine]

Bonjour le chomeur,

J'ai toujours tendance (et peu importe le langage) à coder moi-même le plus de choses possibles, réinventant souvent des roues proposées par des bibliothèques quelconques. Outre quelques copier/coller, je préfère sincèrement réécrire un code en partant de (presque) zéro.

Voici certaines raisons :

- Je comprends mieux ce qu'il se passe. J'appréhende et j'aborde les choses de manière plus efficace.

- Je code ce dont j'ai précisément besoin. Ca diffère parfois de ce que la bibliothèque propose. J'ai une plus grande liberté du résultat que je désire atteindre, contrairement au résultat qu'on me propose d'atteindre.

- Je prends moins de temps pour adapter le fonctionnement ou bien corriger les éventuelles incohérences avec le contexte.

- Je ne charge pas inutilement du code uniquement parce que j'ai besoin d'une seule des cinquante fonctions proposées dans la bibliothèque.


Cependant, il m'arrive et il m'arrivera encore d'utiliser des bibliothèques. Je pense notamment a des effets de styles, des fonctions particulières, ou a un gain de temps.


Donc autant que faire ce peu, j'évite l'utilisation de bibliothèques mais je ne rouspète pas si je dois m'en servir.

[SpaceFrog]

Oui mon chomy je t'entends

Pour répondre à ta question, je dirais que tout dépend du besoin.
Pour celui qui ne maitrise pas le js de base, le framework peut être la solution pour le oneshot. vite fait, bien (ou mal fait) selon le framework et l'intégration).
Pour le durable il vaut mieux maitriser le langage et le code afin de pouvoir apporter les modifications nécessaires en cas de besoin.

Je vois mal un framework prendre de pas sur au autre l'heure actuelle et entrainer des modifications au niveau de javascript ou si peu.
Le framework reste ou outil de confort et de simplification du code mais ne dispense pas la maitrise des bases.

[le_chomeur]

Envoyé par SpaceFrog

Je vois mal un framework prendre de pas sur au autre l'heure actuelle et entrainer des modifications au niveau de javascript ou si peu.
Le framework reste ou outil de confort et de simplification du code mais ne dispense pas la maitrise des bases.

je te rejoins sur ce point , mais je me rend compte aujourd'hui ( et malheureusement ) que TOUS les plugin / objet / fonctions disponibles ( exemple : calendrier, menu déroulant etc ... ) sont codé a base d'un framework , ce qui me chagrine justement , quand on voit que l'on peut coder un slider en 4/5ko sans lib, et que certains le font en 2/3ko + lib de 50ko

je me dis qu'il y a un vrai soucis , maintenant comme le souligne Vermine :

Je code ce dont j'ai précisément besoin. Ça diffère parfois de ce que la bibliothèque propose. J'ai une plus grande liberté du résultat que je désire atteindre, contrairement au résultat qu'on me propose d'atteindre.

un code connu et compris sera beaucoup plus facile a maintenir qu'un copier/coller obscur qui fonctionnera jusqu'au jour X

De mon coté adepte également de réinventer le fil a couper l'eau chaude , cela me permet :

- Comprendre ce que je fais
- APPRENDRE !! a chaque fois que je retape un getElementById() ... cela me permet de connaitre quasiement toutes la syntaxe js par cœur ( si si j'vous assure j'en ai pissez des milliers de ligne en js :p )
- Faire évoluer mon code dans le temps grâce à mon apprentissage

Créons une librairie anti librairie

merci a vous deux pour vos retours d'utilisateurs expérimenté ( qui au final rejoignes totalement ma philosophie du développement => un bon développeur comprend ce qu'il fait !! )

[SpaceFrog]

un bon développeur comprend ce qu'il fait !

Le souci est qu'aujourd'hui les intégrateurs ne sont pas forcément codeurs ...

[Bovino]

Bonne initiative ce débat Chomy

Je trouve que les bibliothèques sont globalement (en tout cas pour celles que je connais) très bien finalisées et correctement optimisées.
Leur utilisation dans des projets d'envergure (niveau JavaScript s'entend) devient donc souvent utile.

En revanche, derrière le coté pratique de la syntaxe, il ne faut pas perdre de vue toute la machinerie qui est utilisée derrière chaque appel de méthode.
Faire un simple

Code :

$('identifiant');

n'est pas aussi anodin qu'un

Code :

document.getElementById('identifiant');

De ce point de vue, il me semble qu'il faut y réfléchir à deux fois avant d'utiliser une librairie et se poser les bonnes questions, en particulier, y gagne-t-on vraiment pour tel projet en utilisant la lib plus d'éventuels scripts par rapport à un développement "from scratch".
De mon point de vue (en tout cas, c'est mon choix personnel), très peu de projets y gagnent vraiment...

Ensuite, je trouve que ces librairies sont une plaie pour les débutants !
Déjà parce qu'ils n'essayent pas plus qu'avant de comprendre ce qu'ils font () et donc d'essayer d'apprendre JavaScript avant de l'utiliser, mais surtout parce qu'ils n'utilisent pas les bibliothèques pour se simplifier la syntaxe et le développement, mais pour masquer leurs lacunes du langage (voir par exemple ce post récent).
Malheureusement, j'ai de plus en plus l'impression que tout le monde veut désormais utiliser JavaScript, mais sans se donner la peine d'en apprendre les bases ! Comportement que l'utilisation abusive de frameworks facilite !

Donc pour moi, je préfère aussi, globalement, me créer mes propres fonctionnalités, pour les mêmes raisons évoquées précédemment, en axant au maximum le code sur la ré-utilisabilité.

[mekal]

d'en l'ensemble je rejoint ce que dit vermine

apparemment un framework c'est utile mais a mon avis ça ne peut pas toujours faire exactement ce que l'on veut et j'ai l'impression que ca limite le développement


concernant les nouvelles api du html5 le html5 en luis même et le css3 mon avis c'est que sa enrichit de façon phénoménale les possibilites d'un navigateurs mais aussi que sa rend plus difficile l’apprentissage du développement web coté client

pour les api (video, audio, drag and drop, file-api...etc) sa va javascript dure c'est donc une bonne nouvelle et une grosse partie devra ce faire sans framework du moins le temp d'en cree de nouvelles specifique a ces api

pour le html5 en lui meme c'est a dire ces balises et surtout la balise input a ce niveau la le javascript perd des plumes je pense au input de type date, color ou on a plus besoin de color picker et de calendrier en javascript avec quand même un désavantage celui de dépendre du designs du navigateur donc si on veut personnaliser ces éléments on devra revenir au color picker et calendrier en javascript,pour le reste des balise sa reste plus de la mise en page

le canvas sans javascript on peut rien faire avec.


le css3 ce que j'en pense c'est qu'il commence a sortir de son domaine qui se cantonais a de la mise en page est ce un bien ou un mal je ne serait que dire les élément tel l'ombrage, les bords arrondis, transforme je trouve ça super mais pour ce qui est des transitions et animation je trouve ça aussi pas mal mais on n'est plus dans le domaine de la mise en page c'est un peut comme si on avait rajouter un framework au css

pour conclure le html5 et le css3 vont a mon avis beaucoup changer la façon de developper un site

[dukej]

Les Frameworks permettent de linéariser le javascript, et régler souvent les soucis d'imcompatibilités navigateur. Ils étendent aussi en général les types primitifs en rajoutant des méthodes (sauf Jquery), cela permet de gagner du temps lors du développement de gros projets.

J'ai déjà travaillé sur des projets + ou moins conséquents avec 3 des librairies principales du marchés ainsi que du JS pur et dur (on dit vanilla JS) (que j'ai toujours préféré). Je ne parlerai pas de YUI ni de Dojo qui sont des frameworks ultracomplets que je verrais plus sur des "Applications webs" que sur un site internet grand public.

Pour résumer les 3 principales librairies, je vais commencer par la plus utilisée.
Jquery :
Pour moi c'est une lib pour noobs, sa simplicité d'écriture, et de chaînage permet de simplifier l'écriture du JS.

Code :

1
2
 
$("selector").doSomething().doSomethingAgain() etc...

Chaque fois qu'on utilise $, on récupère un wrapper, qu'on ai 0, 1 ou N éléments ce n'est pas un soucis et on a pas à s'en soucier. Dès qu'on applicque une méthode, cette dernière retourne un objet jquery (sauf les méthodes de base qui tapent sur les attributs et les méthodes qui retournes des childnodes.

On peut au final écrire :

Code :

1
2
3
4
5
 
$('#toto .menu li').click(function() {
                        alert('pouik');
                     }).over(function() {
                      }).css('border', '1px solid black');

Ceci est un exemple bateau mais qui montre le chainage.

Cette librairie n'étends pas les types primitifs de base comme Array ou String ou autre , et elle est compatible avec n'importe quelle autre lib, à partir du moment où on déclare :

Code :

Jquery.noConflict()

A partir de ce moment là il faudra remplacer $() par Jquery().

Son gros défaut :
Il n'y a rien pour proposer la possibilité de faire de la Poo simple comme la création de classes, de l'héritage (extends) ou de l'implémentation (implements). c'est dommage.

Elle intègre aussi nativement des effets graphiques.

Une lib graphique associé Jquery UI apporte tout un lots de composants, utile pour faire une applications avec une interface graphique assez chiadée.


Mootools:
Ma librairie préférée :
Elle étends les types primitifs : Element, Array, Number, String
Son $() retourne un Element étendu
Pour récupérer plusieurs élements soit on utilise $$('div .menu li')
soit on fait un $(monElement).getElements('selector').

Cette librairie propose tout ce qu'il faut pour faire de la POO.
La doc ici :
http://mootools.net/docs/core/Class/Class

On peut créer une classe qui permet de faire des AddEvent et FireEvent, ou gérer aussi les Options.
Tout ça est bien sympathique et pour de gros projets type applications je préfère utiliser mootools. Idem pour les sites webs, mootools est ma lib favorite.

Très modulaire, son le site de mootools on peut se construire son mootools et n'embarquer que ce dont on a besoin.

Mootools est séparé en 2 gros modules "Core" tout ce qui est utile pour l'utilisation de base, et "More" qui rajoute les effets et les certains objets (sliders, etc...).

Mootools est la plus légère de toutes les librairies.

Prototype :
CEtte lib est lourde et vieille, fonctionne un peu comme mootools, étends les types primitifs, mais rajoute toute une tonne de fonctions souvent bien inutiles.
Pour des effects graphiques il faut rajouter scriptaculous et là on plombe le poids de la lib.


Vanilla JS :
non ce n'est pas une librairie, c'est le terme employé pour dire "JS brut"
J'ai fait énormément de développements sans librairies, codé des effets, des libs ajax. Mais au final, on gagne un temps fou quand on développe un site avec une libraire.

Même si j'ai énormément d'expérience dans la compatibilités internavigateurs (surtout IE6 :/), au final une lib c'est le bonheur.

Mais au final, j'écris mes objets de manière à ce qu'ils fonctionnent sans librairie. Récemment j'ai écrit un objet qui fonctionnait avec jquery, toutes les méthodes de base (addevent, effet, getElement(s), etc...) étaient dans un objet qui servait de wrapper qui appelait les méthodes de la lib utilisée.
Au départ j'avais codé l'objet pour jquery. Il m'a fallut 5 minutes pour le passer sous mootools.

Dans un mois ou 2 je mettrais en ligne un wrapper universel et quelques objets écrit qui fonctionneraient avec les 2 librairies principales, mais plus si besoin.

Voili voilou bonne nuit

[gwyohm]

Bonjour,

Je suis d'accord avec le fait que pour une utilisation minimale de javascript, on n'a pas besoin de framework : si le besoin est de valider qu'un champ est renseigné, importer 50k de librairie est inutile.

Mais est-ce vraiment le cas des projets que vous gérez ? Personnellement jamais. Javascript fait partie intégrante des applications web.
Oui, ça fait plus joli quand ça bouge, quand on a des fondus, non ça n'apporte rien de plus fonctionnellement, mais c'est ce que le client (l'internaute) attend. Il vit dans le web2.0, ras la natte des sites en Times New Roman qui fait des alert quand on oublie de remplir un champ.

Les poids des librairies n'est pas à mon sens un argument essentiel. Pour plusieurs raisons :

• le navigateur le met en cache
• ces librairies sont disponibles via des CDN (il est donc possible qu'avant d'aller sur mon site l'internaute est déjà en cache les librairies que j'utilise)
• En général le poids du javascript comparé par exemple aux images est bien moindre

Le framework standardise et facilite les choses. C'est tout ce que je lui demande.
Quand je code en JAVA, je n'utilise pas 10% des classes disponibles dans la JVM. Comment la JVM est-elle codée pour chaque OS ? Je ne sais pas et ce n'est pas mon problème. Mon problème, c'est que ce que je code une fois tourne partout. Et bien c'est pareil pour le développement javascript et les subtilités des navigateurs.

Au final, je suis pour l'utilisation des librairies, mais sans oublier les fondamentaux ; pour reprendre la comparaison avec java, on ne peut pas apprendre spring sans connaitre java

PS. Je ne veux pas dévier le débat, mais dire que prototype est lourde et vieille est exagéré.
La version 1.7 vient de sortir, et on a déjà la roadmap pour la suite (j'en conviens, c'est la première fois)
Elle ajoute beaucoup de fonctions qui ne sont pas utilisées parce que méconnues parce que les gens ne lisent pas les docs (et devraient vraiment). Néanmoins elle utilise ces fonctions en interne.

[RomainVALERI]

D'une manière générale, on approche dangereusement du vieux débat "haut niveau / bas niveau".

Il y a en effet une tendance à dénigrer les développements effectués à plus haut niveau que celui qu'on pratique : le codeur en Java "pur" dénigre celui qui utilise Swing, Spring, Struts, etc. sans connaître assez bien Java, celui qui code en C considère que celui qui fait du Java ne comprend pas ce qu'il fait (gestion de la mémoire, etc.), celui qui fait de l'assembleur dira la même chose de celui qui fait du C... ^^

Pour le cas de JS, les librairies sont très utiles, apportant un plus dès que les projets prennent de l'envergure, mais je n'irai pas jusqu'à dire que c'est incontournable, loin de là. Je préfère moi aussi m'en passer quand le contexte le permet. Après, l'appréciation du contexte est propre à chacun, et puis on ne fait pas tous 4 sites à 10000€ par mois ^^
Enfin, il est rare qu'on ait réellement le choix. En reprenant un projet existant, on est souvent confronté à une librairie déjà intégrée, et même pour un projet initial, les commanditaires ont parfois (et parfois de manière totalement absurde par rapport au projet !) déjà fait ces choix pour le(s) développeur(s).

Sinon, juste ce détail qui m'a fait plaisir dans le message de gwyohm :

Envoyé par gwyohm

PS. Je ne veux pas dévier le débat, mais dire que prototype est lourde et vieille est exagéré.
La version 1.7 vient de sortir, et on a déjà la roadmap pour la suite (j'en conviens, c'est la première fois)
Elle ajoute beaucoup de fonctions qui ne sont pas utilisées parce que méconnues parce que les gens ne lisent pas les docs (et devraient vraiment). Néanmoins elle utilise ces fonctions en interne.

Moi aussi j'avais trouvé un peu dur le jugement sans appel de dukej

+1 aussi gwy pour le poids des librairies. A l'époque où j'ai débuté dans le web, je me souviens qu'on se donnait 50Ko comme maximum presque absolu pour une page, tout confondu, à part quelques rares exceptions qu'il fallait justifier. Aujourd'hui vous avez vu un peu le poids de ce qui transite sur le réseau ... ? entre les streamings, les RIA, les images, etc. je trouve un peu exagéré de dire que les quelques dizaines de Ko d'une librairie JS soient un problème (même s'il n'y avait pas la logique du cache).

[le_chomeur]

Hé bien hé bien , je vois que dans l'ensemble nous avons tous plus ou moins la même vision du développement ( même si le sujet était le js , je pense qu'on peut l'étendre a d'autre langage mais ce n'est pas le but ... )

Tous le monde s'accorde à dire que les librairies sont un GROS plus indéniable dans le cadre de projet conséquent , et une "perte" de temps et de connaissances dans le cadre de petit développement ( fonctionnalité spécifique etc ... )

Je pense qu'il est bon comme nous le faisons sur DVP , de fournir un maximum d'exemple et de source pour ces fameuses fonctionnalité ( la FAQ par exemple ) qui se rapproche des fonctionnalité de base de beaucoup de librairies.

je terminerais en remerciant les intervenants de cette discussion qui ont confirmé mes impressions actuelles sur l'évolution du dev JS

[dukej]

Je pense qu'on ne peut plus se passer de librairies même pour les développeurs pur JS chevronnés dont je fais parti.
Même pour un petit site d'un pote qui veut des effets "waouh", il n'y a pas photo, avec mootools je torche le truc rapidement et proprement.

[le_chomeur]

les devs pur js font aussi des choses propre

[dukej]

Envoyé par le_chomeur

les devs pur js font aussi des choses propre

Oui je fais aussi des choses très propres, mais je ne vais pas aller m'amuser à recoder un effet graphique (genre un tween) à la mano alors que mootools en a pleins son panier.

Réinventer la roue pour un petit projet n'a aucun intérêt. Même réinventer la roue tout court, quoi que parfois il vaut mieux la réinventer

[le_chomeur]

pas daccord , les effets graphiques sont aujourd'hui TOUS basé sur la librairie de penner ( un mec qui a créer les algorithmes en flash à la base et on été réutilisé dans les librairies js ...

exemple d'utilisation avec un effet "easeOutCubic"

http://mbox.tuxfamily.org/toggle/

très peu de lignes de code ...

[dukej]

Envoyé par le_chomeur

pas daccord , les effets graphiques sont aujourd'hui TOUS basé sur la librairie de penner ( un mec qui a créer les algorithmes en flash à la base et on été réutilisé dans les librairies js ...

exemple d'utilisation avec un effet "easeOutCubic"

http://mbox.tuxfamily.org/toggle/

très peu de lignes de code ...

/me va faire l'amour à chomy s'il continue à lui filer des trucs comme ça

[le_chomeur]

je pense que ce serait malvenu sur un forum public

mais bon j'pense que tu as compris l'idée global entre le js pur et "propre" et les librairies qui peuvent être évitées dans de nombreux cas

[sekaijin]

Déjà je pense qu'avant de parler de lib ou de pas lib il faut se poser la question de l'approche générale.

on en distingue deux.
la première (et probablement celle par laquelle on commence tous) consiste à faire du HTML et à l'enrichir de fonctions (au sens large) JS
par exemple ajouter un bouton calendrier à un textfield pour avoir une saisie plus simple.
la seconde consiste à ne pas écrire de HTML et de construire les objets dont on a besoin en javascript. dans cette approche on va ajouter un datefield au form qu'on aura crée en javascript.

ces deux approche sont pour moi fondamentalement différentes.
Dans la première la question d'une librairie ou pas se pose car si je veux juste ajouter une méthode de vérification de mon formulaire u faire apparaitre un div sur un click sur un bouton je n'ai pas besoin de grand chose.
Mais il faut reconnaitre que certaines librairies aident bien. la question va se poser lorsque l'enrichissement commence à prendre des proportion plus importantes.

Dans la deuxième approche même s'il m'est arrivé et qu'il m'arrive de façon expérimentales de partir de Zéro la question de l'usage d'un lib ne se pose même pas. il n'est pas question ici de construire un div une table ou tout autre élément HTML mais de construire des objet évolué directement.
un tableau croisé dynamique par exemple
un camembert, une barre d'outil, une grille de donnée paginée. etc.
le javascript pour y arriver est conséquent et les librairies qui travaillent dans ce sens sont suffisamment évolué et complètes pour ne pas tout réécrire. au final on écrit moins de chose qu'avec la première approche pour un résulta bien plus complet. par contre ça demande beaucoup plus d'investissement au départ.

Je voudrais répondre à ce qui a été avancé dans cette discussion concernant les librairies.
il est faut de croire qu'on va être soit-même tous seul dans son coin plus efficaces que des dizaines de développeurs qui on cherché à optimiser une librairie pendant plusieurs années. C'est une illusion. ça va être vrais sur quelques ligne mais beaucoup moins dès que le tous va prendre de l'ampleur.

obtenir précisément ce dont on a besoin est là aussi pas toujours apporté pas celui qu'on crois. qui n'a pas reculé sur une présentation super cool et vachement ergonomique devant la difficulté d'implémentation ?

Le temps d'adaptation est là encore pas toujours en faveur du fait maison. quand un développeur quitte une entreprise qui va maintenir et faire évoluer les développement qu'il a fait. souvent les doc des librairies sont beaucoup plus complètes. les compétences présentes sur le marché. les bricolage de développeurs dans leur coins sont une plaie pour les entreprises. c'est donc plus un problème de maitrise que de lib ou pas lib si on maitrise le code existant il sera facile de le faire évoluer.

le poids des librairies. là aussi on aperçois vite que les librairies bien structurées capitalisent beaucoup et que l'ajour de composant ou de nouveauté ne les gonfle pas de façon proportionnelle. à l'inverse les dev perso sont souvent ultra spécifique et donc l'ajout d'un composant d'une fonctionnalité ne permettra pas de réutiliser l'existant. là encore lorsqu'on commence à avoir une certaine quantité de chose en JS on s'aperçoit qu'avec une bonne librairie la croissance du poids n'est pas aussi rapide qu'à la main. il faut aussi noter que la plus part des librairies permettent d'optimiser la taille du code chargé. il est souvent possible de générer un fichier JS de la lib ne contenant que les composants qu'on utilise. malheureusement très souvent on ne prends pas le temps de cette optimisation. qui à déjà construit son propre paquetage JQuery ou Ext pour un projet ?


le problème qui est soulevé ici est plutôt : sans compétence sur un librairie offrant un service semblable à celui que je souhaite obtenir comment s'en sortir ?

je dirais de ma propre expérience et ce pas seulement en JS Aller voir les forums les listes de discussions les doc dédiées à la librairie. il y a fort à parier que quelqu'un à déjà rencontré le problème voire qu'il existe un composant ad-hoc ou mieux un plugin ou une évolution.

A+JYT

[dukej]

Envoyé par le_chomeur

je pense que ce serait malvenu sur un forum public

mais bon j'pense que tu as compris l'idée global entre le js pur et "propre" et les librairies qui peuvent être évitées dans de nombreux cas

Tu ne m'apprends rien , j'ai déjà codé ma propre lib

Mais bon, autant utiliser des trucs qui fonctionnent proprement et testés que des trucs qui marchent à moitié.

Je prend l'exemple d'une requête ajax. Je suis bien content d'avoir mon objet Ajax qui fait 1ko mais qui me simplifie l'écriture d'un appel et me permet de gérer certains évènements que de me faire chier à coder à la mano et me faire chier, même si je sais le faire.

[vermine]

sekaijin, je suis d'accord avec toi sur le fait qu'on ne peut pas prétendre avoir un code plus performant en l'ayant écrit tout seul dans son coin que le code de dix développeurs réfléchis (mais comme dit précédemment, ce ne sont pas toujours des développeurs).

Cependant, ces dix développeurs ont pour but de créer quelque chose d'utilisable par tous. Ce n'est pas mon cas. Ce que je crée sert à très peu de personnes et la demande est réellement spécifique. Chaque métier étant différent. Un code n'a pas toujours besoin d'être réutilisé ou appliqué ailleurs.
Non, je ne prétends pas créer des codes ultra puissants (ça, ça se saurait ), mais je pense pouvoir approcher de plus près la demande du client.