O� va-t-on avec JavaScript ?

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

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. :P

Oui mon chomy je t'entends :mouarf:

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.

Citation:

---

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 :aie:

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

Citation:

---

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 :aie:

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 !! )

Citation:

---

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

---

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

Bonne initiative ce d�bat Chomy :ccool:

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 (:cry:) 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�.

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

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" :D
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 :D bonne nuit

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.

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 :

Citation:

---

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 ... ? 8O 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).

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 :)

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.

les devs pur js font aussi des choses propre ;)

Citation:

---

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 :D

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

Citation:

---

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

:oops: 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

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

Citation:

---

Envoy� par le_chomeur

:oops: 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 :aie:, j'ai d�j� cod� ma propre lib :aie:

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.

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 :P), mais je pense pouvoir approcher de plus pr�s la demande du client. ;)