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 )