Discussion :

[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]

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 :

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

$('identifiant');

n'est pas aussi anodin qu'un

Code :

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

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é.

[franculo_caoulene]

Salut à tous,

Pour répondre à la question originale. Le comportement du développeur Javascript lambda n'a pas changé d'un poil en dix ans. On a tous commencé à faire du Javascript copier/coller. Ce sont les sources disponibles qui ont changés. Avant nous n'avions que des snippets à disposition, maintenant les frameworks ont pignon sur rue, ce sont donc eux qu'on copie ou utilise à mauvais escient aujourd'hui.
Je ne sais plus qui a dit ça, mais Javascript est le seul langage de programmation qu'on n'apprend pas! Si vous avez correctement appris Javascript à l'école, c'est que vous en faite, je pense, depuis moins de quatre ans (estimation à vue de nez). Ce n'est que ces dernières années que le développement Javascript s'est professionnalisé, la création des frameworks en est justement l'illustration.

Comment développer? Cela dépend du projet. Un framework est fait pour industrialiser le développement et accessoirement pour lisser les comportements entre navigateurs. Il est bon d'industrialiser le développement sur de gros projets ou sur une quantité de petits projets. Même si, pour les petits projets, on peut parfois considérer l'utilisation d'un framework comme un luxe.
J'ai déjà vu certaines personnes utiliser un framework et sa surcouche graphique uniquement pour bénéficier d'un simple effet. Alors que tout le reste des scripts de l'application était développé sans tenir compte de ces frameworks! Dans ce cas là, je me dis que c'est comme acheter une librairie entière pour pouvoir lire un livre.
D'un autre coté, pourquoi se prendre la tête à réinventer la roue si on n'a aucune contrainte de performance et si ça ne fait pas de mal au client? Un développeur expérimenté aura, très probablement, déjà ses propres snippets sous la main et ne fera peut-être au final qu'un copier/coller (la boucle est bouclée) alors pourquoi pas utiliser un framework?

Ce qui compte finalement, je pense, c'est la compréhension de Javascript et du développement web en général. Ceci permettant de faire les bons choix.

Pour répondre à la suite du débat, le développement web est peut-être le type de développement le plus ouvert au "grand public". On aura donc toujours dans le forum des développeurs lambda rendant service à une association le temps d'un week-end. On ne peut décemment pas leur demander de tout comprendre du développement web avant de poster un message. Enfin je dis ça, mais je suis le dernier à répondre à ce genre de message. Curieusement, je me trompe peut-être, dans ce forum j'ai l'impression qu'il n'y a que des gens qui posent des questions et des anciens "désabusés" pour y répondre. Il manque la tranche du milieu, celle du développeur intermédiaire qui apprend et qui veut tester ses connaissances en répondant aux questions.

PS : galerien69 si tu fais ça de façon professionnelle, tu es sur la mauvaise voie. Si c'est de façon personnelle et pour le plaisir, fait comme bon te semble.

[RomainVALERI]

Curieusement, je me trompe peut-être, dans ce forum j'ai l'impression qu'il n'y a que des gens qui posent des questions et des anciens "désabusés" pour y répondre. Il manque la tranche du milieu, celle du développeur intermédiaire qui apprend et qui veut tester ses connaissances en répondant aux questions.

Comment ?
>>> et moi alors ?!
Je passe pas mal de temps à répondre aux messages quand je le peux, et ça représente finalement assez peu parmi tous les posts que je lis. Je suis très loin d'être un "ancien" voire un spécialiste, et ma motivation à 95% est effectivement d'en profiter pour apprendre un maximum (je ne suis d'ailleurs pas le seul*, mais même si je plaisante j'ai moi aussi observé la tendance que tu décris ^^)

* edit : tiens, la preuve que je ne suis pas le seul dans ce cas ^^ juste en dessous de ce post salut vermine

[vermine]

Je ne sais plus qui a dit ça, mais Javascript est le seul langage de programmation qu'on n'apprend pas!

Peut-être, il n'empêche que ce n'est vrai que pour les gens qui ont étudié d'autres langages (je pense au C et ou au Java dans mon cas) avant de se lancer dans le Javascript. Il y a une logique à apprendre.

[sekaijin]

je pense que tous les developpeur qui on appris la POO sans jamais approcher les langage orienté objet autre que ceux à base de classe
doivent déapprendre en arrivant sur javascript.

on inculque dans les E.I. dans notions sur la POO en donnant l'impression que c'est de l'absolu alors que la POO à base de classe n'est qu'une des approche théorique de la POO

JS est un vrai langage à objet basé sur la notion de prototype
j'aimerais connaitre le nombre d'école qui enseigne cette théorie ?

que dire de langage qui implémente un mix des notion de prototype et de classe
Xlisp par exemple ou l'objet object permet de construire des objets comme javascript object est donc un prototype d'objet
mais xlisp contient aussi un objet class est est un prototype pour créer des objet classe que l'on pourra dériver et instancier la classe obtenue ainsi seront des classe au même titre qu'en java.

la théorie est bien plus vaste que la simple poo à basse de classe comme en java ou C++

A+JYT

[Watilin]

C'est marrant ce débat qui a un petit arrière-goût qui me rappelle quelque chose…

Je dois l'essentiel de mon expérience au dév web. En web j'ai vu (c'est moins vrai maitenant avec l'essor des RIA) s'affronter deux écoles : les graphistes, et les codeurs.
Les codeurs veulent une appli robuste, peu importe l'allure. Le graphiste veut du eye-candy, et code sans s'emmerder. (j'essaye de rester impartial bien que je sois du côté des codeurs ^^)

Aujourd'hui j'ai plutôt envie de dire : y'a les pisseurs de code qui te font un projet patché de partout, et les managers qui arpentent les salons d'embauche à la recherche d'experts pour réparer leurs pauvres projets.
Et parmi les experts qui reprennent ces projets, il y a ceux qui maugréent en maudissant leurs prédécesseurs, et ceux qui sont contents d'avoir du boulot. C'est une question de pragmatisme.

Pour résumer, l'existence des mauvais justifie celle des bons

Attention, je ne dis pas que le débutant est mauvais. Mais parmi les débutants, il y a ceux qui cherchent à comprendre, et ceux qui ne cherchent pas. Mon avis, c'est qu'on devrait tous chercher à devenir expert.

[SpaceFrog]

[FaridM]

Faut dire aussi que la plupart des cours sur javascript que l'on trouve (et particulièrement sur le web), sont soit dépassé, soit mauvais, beaucoup apprenne encore a faire :

Code html :

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

1
2
 
<input type="button" value="Envoyer" onclick="envoyer()" />

alors que d'après ce que j'ai compris, c'est complètement obsolète et donc à proscrire. Moi qui essaie justement d'apprendre à utiliser ce langage, j'essaie en vain de trouver des cours correcte et à jour. J'ai commencé le livre "Bien développer pour le web 2.0" et même si il est trés bon, est loin d'être complet, du coup je reste sur ma faim.

Je comprends donc les débutants qui plutôt que faire du mauvais code pleins de bidouillage pour que cela fonctionne sur tout les navigateurs, préfèrent utiliser une librairie reconnu qui marche.

PS : Vous l'aurez compris, je cherche unlivre ou tuto complet sur comment bien développez en JS (Javascript la référence n'est plus disponible).

[domi65]

Code html :

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

1
2
 
<input type="button" value="Envoyer" onclick="envoyer()" />

c'est complètement obsolète et donc à proscrire.

Pas d'accord. C'est tout à fait valable. Seulement, le javascript n'est pas séparé du HTML.

Si tu veux placer tout ton JS dans un fichier externe, alors c'est pas bon, ni si tu veux un gestionnaire plus poussé, mais ce n'est pas en soi une mauvaise pratique. Et c'est clair que c'est moins savant que document.querySelector('[type=button]').addEventListener('click',function {...}).
mais ça fonctionne très souvent pareillement, si des biblis externes ne viennent pas foutre le b*****

[melka one]

Ce que je constate c'est que lire du JavaScript devient de plus en plus imbuvable bientôt il faudra avoir fait 10 ans mini de JavaScript afin de comprendre ce que fait un code et pendant ce temps les framework et autre ce régales.

[dukej]

Salut à tous,

Pour répondre à la question originale. Le comportement du développeur Javascript lambda n'a pas changé d'un poil en dix ans. On a tous commencé à faire du Javascript copier/coller. Ce sont les sources disponibles qui ont changés. Avant nous n'avions que des snippets à disposition, maintenant les frameworks ont pignon sur rue, ce sont donc eux qu'on copie ou utilise à mauvais escient aujourd'hui.

Nan avant on avait des "scripts" à disposition, des trucs qu'on récupérait sur internet, des machins mal codés où toutes les variables étaient globales, enfin bref du super bonheur quoi

Je ne sais plus qui a dit ça, mais Javascript est le seul langage de programmation qu'on n'apprend pas! Si vous avez correctement appris Javascript à l'école, c'est que vous en faite, je pense, depuis moins de quatre ans (estimation à vue de nez). Ce n'est que ces dernières années que le développement Javascript s'est professionnalisé, la création des frameworks en est justement l'illustration.

Celui qui a dit que le javascript ne s'apprends pas qu'il viennent me voir, je lui expliquerait qu'avec le JS on peut même mettre en place des design patterns qu'on trouve souvent et comment faire de la POO avec héritage. Il changera d'avis

Comment développer? Cela dépend du projet. Un framework est fait pour industrialiser le développement et accessoirement pour lisser les comportements entre navigateurs. Il est bon d'industrialiser le développement sur de gros projets ou sur une quantité de petits projets. Même si, pour les petits projets, on peut parfois considérer l'utilisation d'un framework comme un luxe.

Industrialiser oui et non, ça permet aussi d'avoir une couche d'abstraction et de se passer de la gestion du navigateur, ne prends l'exemple tout con des events IE qui sont gérés complètement différemment que sur les autres navigateurs (attachEvent != addEventListener), sans oublier les events customs de IE comme le mouseenter et le mouseleave

J'ai déjà vu certaines personnes utiliser un framework et sa surcouche graphique uniquement pour bénéficier d'un simple effet. Alors que tout le reste des scripts de l'application était développé sans tenir compte de ces frameworks! Dans ce cas là, je me dis que c'est comme acheter une librairie entière pour pouvoir lire un livre.

On a déjà eu des ingés qui intégraient des maquettes HTML montées par mon équipe, blague du jour, l'ingé avait juste besoin de faire de l'ajax, et l'ingé avait collé prototype sur le site, :'( :'( juste pour ça :'( :'( :'(. Je lui ai refilé ma classe Ajax de 2ko qui gère les évènements and co et rulez

D'un autre coté, pourquoi se prendre la tête à réinventer la roue si on n'a aucune contrainte de performance et si ça ne fait pas de mal au client? Un développeur expérimenté aura, très probablement, déjà ses propres snippets sous la main et ne fera peut-être au final qu'un copier/coller (la boucle est bouclée) alors pourquoi pas utiliser un framework?

Bah les "snippets" et compagnie c'est beau quand tu es sur ton site perso, mais parfois faut factoriser tout ça et le framework est idéal.

Ce qui compte finalement, je pense, c'est la compréhension de Javascript et du développement web en général. Ceci permettant de faire les bons choix.

Pour répondre à la suite du débat, le développement web est peut-être le type de développement le plus ouvert au "grand public". On aura donc toujours dans le forum des développeurs lambda rendant service à une association le temps d'un week-end. On ne peut décemment pas leur demander de tout comprendre du développement web avant de poster un message. Enfin je dis ça, mais je suis le dernier à répondre à ce genre de message. Curieusement, je me trompe peut-être, dans ce forum j'ai l'impression qu'il n'y a que des gens qui posent des questions et des anciens "désabusés" pour y répondre. Il manque la tranche du milieu, celle du développeur intermédiaire qui apprend et qui veut tester ses connaissances en répondant aux questions.

Le développement web est un développement trop ouvert au public, on trouve de tout et n'importe quoi en dév, par exemple : on a déjà vu des intégrateurs HTML qui te font de la merde en CSS alors qu'ils sont payés une fortune :s, et personne ne regarde le code derrière seul le résultat visuel compte, alors que si demain tu rajoutes du contenu et que le site pète parce que le mec a tout figé en hauteur, tu es dans la merde et tu fais x2 en temps pour rattraper ses conneries car le site a déjà été dynamisé

PS : galerien69 si tu fais ça de façon professionnelle, tu es sur la mauvaise voie. Si c'est de façon personnelle et pour le plaisir, fait comme bon te semble.

+1

[dtcSearch]

Je trouve que les Librairies, en particulier jQuery et son jQueryUI, sont bien pratique car comble un vrai problème qu'on retrouve dans le Web dès lors qu'on veut faire une Application Web, le fait qu'il n'y ai pas de composante graphique pour des tâches récurrentes auquel nous sommes familiers, par exemple, saisir une date.
Le temps de développer un calendrier fonctionnant sur Internet Explorer et Firefox suffit à ce poser la question d'utiliser une librairie qui en propose sous forme de plugin.
Pourquoi plus une librairie qu'un composant dédié?
Je pense au fait que la librairie, jQuery en particulier, est un renouveau. Il est possible de faire de la RIA équivalente à du Silverlight en quelques minutes, sans que l'utilisateur est besoin de plugin, juste d'un navigateur (présent par défaut).

J'ai moi même fait du Javascript (car oui, en utilisant une librairie, j'ai plutôt l'impression de faire du jQuery que du Javascript), c'est pas bien sorcier de faire un WYSIWYG, des Drag&Drop ou encore des fenêtres modal en vanilla javascript, mais dès lors qu'on veut faire un calendrier, datagrid ou autres, c'est une autre paire de manche.

L'intérêt des librairies est faites pour moi, leurs tailles est sans importance, l'utilisations d'une URL commune en tant que source (http://www.google.com/jsapi) permet l'usage du cache sans s'en soucier. Et qui sait, peu être qu'un jour elles seront intégrées aux navigateurs (cas dans le mobile).

[druith]

Beaucoup de choses ont été dites. Je me contenterais donc de dresser deux constats :

- depuis que les frameworks sont utilisés en masse, on est passé d'effets flocons de neiges par dessus la page html ou des horloges dans un champ input à des effets réellement ergonomiques, esthétiques... et utiles !

- plus qu'en php en css/html, il m'est demandé de changer/ajouter/supprimer très souvent mes scripts JS dans les sites que je réalise. Or les frameworks sont plus rapides, certes mais surtout, je me sens beaucoup moins frustré (et donc aigri envers mon client !!) quand je dois me contenter de virer une librairie (même personnalisée) par une autre plutôt que de ne plus devoir utiliser le super-code-optimisé pondu le mois dernier.

Cette dimension de frustration n'a pas encore été abordée (ou je suis passé à côté), pourtant elle me semble très importante, plus on réalise un travail sur mesure et en langage pur, et plus l'idée de modifier ce travail est difficile à accepter. On se place dans un travail artisanal, et si c'est parfait pour un projet qui ne sera pas modifié pendant plusieurs mois / années, cela est très difficile à accepter sur des projets aux modifications et mises à jour régulières.

J'insiste sur le fait que je ne parle même pas de temps de travail ou d'optimisation du travail, juste du rapport intime que l'on entretient avec son code.

[dukej]

Beaucoup de choses ont été dites. Je me contenterais donc de dresser deux constats :

- depuis que les frameworks sont utilisés en masse, on est passé d'effets flocons de neiges par dessus la page html ou des horloges dans un champ input à des effets réellement ergonomiques, esthétiques... et utiles !

- plus qu'en php en css/html, il m'est demandé de changer/ajouter/supprimer très souvent mes scripts JS dans les sites que je réalise. Or les frameworks sont plus rapides, certes mais surtout, je me sens beaucoup moins frustré (et donc aigri envers mon client !!) quand je dois me contenter de virer une librairie (même personnalisée) par une autre plutôt que de ne plus devoir utiliser le super-code-optimisé pondu le mois dernier.

Cette dimension de frustration n'a pas encore été abordée (ou je suis passé à côté), pourtant elle me semble très importante, plus on réalise un travail sur mesure et en langage pur, et plus l'idée de modifier ce travail est difficile à accepter. On se place dans un travail artisanal, et si c'est parfait pour un projet qui ne sera pas modifier pendant plusieurs mois / années, cela est très difficile à accepter sur des projets aux modifications et mises à jour régulières.

J'insiste sur le fait que je ne parle même pas de temps de travail ou d'optimisation du travail, juste du rapport intime que l'on entretient avec son code.

Faut aussi coder de manière générique, les trucs que je code son quasiment génériques ou alors des gros morceaux sont génériques et utilisables dans n'importe quel contexte. Et là tu te fais moins chier à recoder oou modifier le code

[druith]

Faut aussi coder de manière générique, les trucs que je code son quasiment génériques ou alors des gros morceaux sont génériques et utilisables dans n'importe quel contexte. Et là tu te fais moins chier à recoder oou modifier le code

Entièrement d'accord bien entendu ,

Mais en faisant ça de façon efficace ne se retrouve-t'on pas avec un framework maison à maintenir ? Et puis est-on réellement capable de ne pas jeter un oeil "rapide" à la partie générique à chaque projet pour vérifier si par hasard on pourrait pas l'optimiser un peu... avant de réaliser qu'on est dessus depuis 3 heures au moins

Je maintiens qu'avec un framework utilisé par tout le monde ou presque on fait un peu plus le bétail : on l'utilise sans se poser de question sur le core mais au moins on est soulagé de cette dérive de toujours vouloir faire du trop bon travail damned ! le mieux est l'ennemi du bien en informatique aussi.

(je pense à un graphiste que j'avais croisé qui travaillait depuis 2 ans sur son site perso en flash parce qu'il voulait tout scripter sans utiliser l'interface, jusqu'à la typo qu'il programmait lui-même... la chose était optimisée certes mais le site n'a jamais été mis en ligne : il s'était trop impliqué à tout faire parfaitement )