Discussion :

[Invit�]

mais alors pourquoi quand je code en javascript sa marche toujour et sans que j'ai a me preocupe du language en lui meme c'est ce qui gravite autour qui peut me causer probleme

je tient quand meme a rappeler que javascript tient beaucoup du language c au niveau de la syntaxe et de preciser que dernierement j'ai lu un livre sur le c (programmer en language c Delannoyer) et bas franchement j'ai vite parcouru le bouquin tellement il y a de ressemblances

[camus3]

mais alors pourquoi quand je code en javascript sa marche toujour et sans que j'ai a me preocupe du language en lui meme c'est ce qui gravite autour qui peut me causer probleme

je tient quand meme a rappeler que javascript tient beaucoup du language c et de preciser que dernierement j'ai lu un livre sur le c (programmer en language c Delannoyer) et bas franchement j'ai vite parcouru le bouquin tellement il y a de ressemblances

Douglas Crowford ( me semble t il ) a �crit un livre qui se nomme "Javascript , the good parts" , tout simplement parce que dans javascript , il y a des "bad parts", des pi�ges , erreurs silencieuses , probl�me de port�e de variables , etc , etc ...

Bien sur si tu prends toutes les pr�cautions ( namespace , etc ... ) tu n'auras aucun probl�me. Mais il faut reconnaitre qu'il y a un probl�me de design � la base.

ECMAscript 4 aurait pu r�gler certains de ses probl�mes , mais Yahoo et Microsoft ont refus� les specs.

enfin , javascript n'a pratiquement �volu� en 10 ans ( � part ajax qui vient de chez microsoft d'ailleurs).

[gwinyam]

Bien sur si tu prends toutes les pr�cautions ( namespace , etc ... ) tu n'auras aucun probl�me.

La diff�rence entre un bon codeur et un guignol, c'est quoi d�j�?

[RomainVALERI]

tout simplement parce que dans javascript , il y a des "bad parts", des pi�ges , erreurs silencieuses , probl�me de port�e de variables , etc , etc ...

Allez cite-nous un langage sans d�fauts, qui soit r�ellement utilis� en production
*prend son carnet de notes et attend*

Il me semble que le fait de "poss�der des d�fauts" ne suffit pas pour mettre JS sur la liste noire des "langages � abattre".
Et pour ce qui est de l'avenir de JS incertain sur le long terme, l� aussi, il me semble que c'est le cas de tous les langages actuellement utilis�s en production... (je pr�cise une fois de plus "utilis� en production" parce que bien s�r Lisp est �ternel tout le monde le sait mais personne ne s'en sert )

(Ca, plus le fait de citer trois fois Microsoft comme une r�f�rence dans chaque phrase, c'est de la provoc' ou quoi ? allez arr�tons ce faux d�bat sinon �a va troller )

[Invit�]

Bien sur si tu prends toutes les pr�cautions ( namespace , etc ... ) tu n'auras aucun probl�me. Mais il faut reconnaitre qu'il y a un probl�me de design � la base.

je comprend mais on revient toujour au meme probleme celui de prendre javascript a la legere

[camus3]

La diff�rence entre un bon codeur et un guignol, c'est quoi d�j�?

Le guignol est excus� quand le langage � des d�fauts de conception manifestes.

[gwinyam]

Le guignol est excus� quand le langage � des d�fauts de conception manifestes.

Ah bon? Je te cite:

Bien sur si tu prends toutes les pr�cautions ( namespace , etc ... ) tu n'auras aucun probl�me.

Traduction de toi-m�me: si tu fais gaffe un peu � ton code, ce que tout d�veloppeur est cens� faire donc, il n'a pas de probl�me.
Pas d'excuses, non, �a te contre-dirait toi-m�me.

[camus3]

il n'y a pas de contradictions , je pointe les d�fauts du langage , son manque de s�rieux qui g�n�re lui m�me ce que tu appelles un guignol.
D'ailleurs ECMASCRIPT 5 change la port�e d'une variable par d�faut, le guignol n'est pas celui qu'on croit avec ce genre de modif.
TRADUCTION : les guignols sont bien chez ECMA.

[Bovino]

Douglas Crowford ( me semble t il ) a �crit un livre qui se nomme "Javascript , the good parts" , tout simplement parce que dans javascript , il y a des "bad parts", des pi�ges , erreurs silencieuses , probl�me de port�e de variables , etc , etc ...

Douglas Crockford Livre dont il existe d'ailleurs une traduction fran�aise
Effectivement, l'auteur voit des bad parts (et m�me des awful parts) dans JavaScript. Ceci dit, il en explique aussi les raisons et surtout ne consid�re pas que cela fait pour autant de JavaScript un mauvais langage, au contraire :

Despite its popularity, few know that JavaScript is a very nice dynamic object-oriented general-purpose programming language.

Contrairement � certains je pense que son avenir est en question sur le long terme.

Ah...
Il faudrait que tu avertisses les concepteurs du HTML 5

Je pense que javascript laissera place � une alternative mieux pens�e , du style ruby ou python par exemple avec un vrai choix sur la mani�re de programmer.

Je ne suis pas s�r que ce soit demain la veille o� les navigateurs, les produits Adobe, le shell Windows et tous les environnements utilisant JavaScript impl�menteront un interpr�teur Ruby ou Python (ben oui, JavaScript, c'est pas uniquement le Web)

enfin , javascript n'a pratiquement �volu� en 10 ans

Amusant !
Il y a pourtant de nombreux codes dont on voit imm�diatement qu'ils sont plut�t anciens ! Et qui ont moins de 10 ans. Et qui justifient que les "bad parts" que tu �voquais ne disparaissent pas spontan�ment : besoin de retro compatibilit� et mauvaise connaissance du langage font que les mauvais aspects du langage demeurent. Ca ne signifie ni que le langage n'�volue pas, ni qu'il est mauvais : il est juste interpr�t� au sein d'une interface client et compil� � la vol�e.

[gwinyam]

il n'y a pas de contradictions , je pointe les d�fauts du langage , son manque de s�rieux qui g�n�re lui m�me ce que tu appelles un guignol.
D'ailleurs ECMASCRIPT 5 change la port�e d'une variable par d�faut, le guignol n'est pas celui qu'on croit avec ce genre de modif.
TRADUCTION : les guignols sont bien chez ECMA.

Il y a pourtant contradiction.

Tu me dis que si un d�veloppeur fait gaffe � ce qu'il fait alors il n'aura pas de probl�mes, sinon il aura des probl�mes. C'est bien la preuve m�me qu'il y a contradiction avec ton autre pens�e qui dit que ce d�faut est bourr� de probl�mes.

Alors oui je suis d'accord avec toi que Javascript a des d�fauts mais fait attention � ce que tu dis. Tout comme TOUT d�veloppeur devrait faire un minimum attention � ce qu'il fait.

Je ne connais aucun langage qui autorise le d�veloppeur � faire n'importe quoi et o� �a marchera quand m�me.
Il y a des langages permissifs qui autoriseront le d�veloppeur � coder n'importe comment, mais rien ne garantit que le logiciel fera ce qui est attendu.

Pour moi, pas besoin d'une alternative � Javascript. Juste besoin que le commun des d�veloppeurs acceptent que Javascript n'est pas un sous langage et qu'ils acceptent surtout de l'apprendre correctement au lieu de bidouiller comme on le voit encore trop souvent.

[Invit�]

une chose qui me fait toujour peur c'est quand je tape javascript sur google et que en premier on tombe sur L'�diteur JavaScript et la je comprend mieux pourquoi il existe toujour autant de script merdique

[gwinyam]

Ah enfin un qui dit la m�me chose^^

Javascript est encore vu comme un langage de bricolo alors que ce n'est pas le cas...

[jonoz]

J'utilise :

-> Jquery un petit peu
-> Mootools beaucoup

J'ai utilis� :

-> Dojo
-> Prototype ( + Scriptaculous )
-> Vanilla JS

J'utilise des libraries car elles me font gagner du temps, notamment pour les s�lections d'�l�ments et qu'elles me permettent d'avoir un code qui marche relativement correctement d'un browser � l'autre.

Le probl�me de Vanilla JS est que la norme (ECMAScript il me semble) n'est pas universellement respect�e (de m�me qu'en xhtml, css... c'est l'histoire du web c�t� client quoi...).

[chok371]

Je pense que javascript laissera place � une alternative mieux pens�e , du style ruby ou python par exemple avec un vrai choix sur la mani�re de programmer.

Je vois pas quel langage pourrait le remplacer et ce qu'on pourrait faire de mieux actuellement. Le vraie probl�me de Javascript ne vient pas forcement du langage lui-m�me (il a des d�fauts comme tous les autres), mais des probl�mes de compatibilit�s entres les navigateurs, surtout dans le DOM.

Je pense plut�t que ce langage a un bel avenir devant lui, car de plus en plus de navigateurs s'unifient dans l'impl�mentation du langage en respectant les normes et les standards, leurs cr�ateurs travaillent donc pour r�soudre ces probl�mes de compatibilit�.

De plus, il y a beaucoup de librairies qui peuvent apporter beaucoup d'aide dans un d�veloppement, si elles sont utilis�es efficacement.

Il faudrait que tu avertisses les concepteurs du HTML 5

Peux-tu �tre un peu plus pr�cis ?

[squelos]

La tournure que prend le JS depend simplement de ton point de vue.
Les utilisateurs qui utilisent ces frameworks appr�cient certainement ces framework, sinon ils ne s'en serviraient pas a moins de ne pas pouvoir r�aliser ce que ces framework font. A partir de la, ils vont en conclure que des frameworks fleurissent et donc que le JS est en bonne voie.
Alors que celui qui pr�f�re developper from scratch ne sera gu�re inspir� par l'apparition de framework en tout genre.

Apr�s, je pense effectivement, que les d�butants doivent absolument eviter les framework ( sinon forcement, on n'apprend pas ...).
Et concernant les profesionnels, qui se doivent d'avoir du r�sultat rapidement, et bien c'est leur choix. Effectivement, l'utilisation d'un framework peut faire gagner du temps lors du d�veloppement, mais si apr�s il faut maintenir l'application � jour, beaucoup plus de temps risque d'�tre perdu dans du deboggage � cause d'une erreur de documentation du framework ou autre probl�me d� � l'utilisation d'un framework.

[sekaijin]

merde si js est mort il faut pr�venir la banque de france le FMI
et un bon paquet de grande soci�t�s
on va enlever les yahoo et autre.
Samsung, Airbus, NEC System Technology, sony, oracle, time warner, Borland, IBM, BNP

juste quelques noms qui me viennent ce ne sont pas la des boites qui utilisent JS pour le services web ou autre bricoles
ce sont des boites qui investissent activement dans ce langage.

je ne pense pas que Js soit mort. il va �voluer �a c'est sur.
Comme toujours je vais redire que js ce n'est pas que dans les navigateurs et les erreurs de jeunesse ne sont pas pr�sente dans toutes les impl�mentation du langage.

je ne connais pas un langage qui soit exempt de d�faut
(� part Lisp il faut dire que Lisp c'est en tout est pour tout
(,) cons, car, cdr difficile de faire foireux avec si peut)

non soyons s�rieux la perfection n'existe pas.
les langages proc�duraux ont leur d�fauts et on trouve des tas de design pattern pour palier ceux-ci
les langage � base de classe ont leur d�fauts et on trouve des tas de design pattern pour palier ceux-ci
les langages � base de prototype ont leur d�fauts et on trouve des tas de design pattern pour palier ceux-cii enfin pas beaucoup
les langages fonctionnels ont leur d�fauts et on trouve des tas de design pattern pour palier ceux-ci
les langages � acteurs ont leur d�fauts et on trouve des tas de design pattern pour palier ceux-ci enfin pas beaucoup
etc.

j'en connais un bon paquet j'en utilise pas mal et il n'y a aucune solution jamais aucun langage ne prendra en compte l'univers en son entier.
Donc pour JS il est dans sa phase ascendante. on le voit appara�tre dans les infrastructure syst�me
l� ou TCL qu'on � aussi dit mort est particuli�rement actif. ce n'est qu'un exemple parmi d'autre.

Je suis bien incapable aujourd'hui de dire dans quel domaine il est utilis�.
il est con�u de telle sort que pour rendre une application scriptable il est un choix � ne pas n�glig�.
du coup il se retrouve dans des endroits insolites et insoup�onn�

A+JYT

[gwinyam]

Tu peux aussi enlever Facebook, Netvibes (bien que...), Twitter, tous les clients sociaux (Seesmic, HootSuite, ...)
Tu peux aussi enlever gmail, google docs, la recherche instantan�e google, en fait tout google m�me, hotmail, docs, wordpress,...

[pomeh]

Bonsoir � tous

Je viens de voir passer ce sujet dans mon lecteur de flus RSS seulement aujourd'hui alors qu'il a �t� cr�� depuis un petit moment, alors je suis d�sol� mais je vais reprendre quelques citations de commentaires plut�t anciens mais auquel j'ai envie de r�pondre.

Pour moi, Javascript est un langage qui parait �tre pour les "rigolos" mais qui m�riterait vraiment que plus de d�veloppeurs s'y int�ressent. Je vais essayer d'expliquer pourquoi je penses �a.

Pour le durable il vaut mieux maitriser le langage et le code afin de pouvoir apporter les modifications n�cessaires en cas de besoin.
[...]
Le framework reste ou outil de confort et de simplification du code mais ne dispense pas la maitrise des bases.

Effectivement, l'utilisation d'un framework peut faire gagner du temps lors du d�veloppement, mais si apr�s il faut maintenir l'application � jour, beaucoup plus de temps risque d'�tre perdu dans du deboggage � cause d'une erreur de documentation du framework ou autre probl�me d� � l'utilisation d'un framework.

Il vaut mieux maitriser le code, je suis d'accord. Mais rien ne t'emp�che de maitriser une ou plusieurs librairies et de maitriser tout aussi bien le code De plus, c'est bien que TU (au sens g�n�ral) maitrise ton code, mais si tu es en entreprise et que tu d�cide de changer d'entreprise (ou bien si tu te fais gentillement remerci�), tu t'en va avec la ma�trise de ta librairie et le d�veloppeur qui va prendre le relais risque d'avoir du mal � s'y retrouver (au d�but en tout cas).

Je te rejoins sur le deuxi�me point. Les librairies JS rendent le Javascript plus facilement accessible, c'est tr�s bien pour la d�mocratisation du langage, mais �a devient tellement accessible qu'on a plus besoin de conna�tre le langage pour faire du Javascript, ce qui m�ne rapidement et simplement vers du code vraiment pas beau. Il est primordial, � mon sens, d'avoir pratiqu� le Javascript "pur" afin de comprendre les fondamentaux du langage, sans quoi il peut para�tre "magique" ou "horrible" dans certains cas (magique quand �a fonctionne mais qu'on ne sais pas pourquoi, horrible quand �a ne fonctionne pas mais qu'on ne sais pas pourquoi non plus !!).

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.

Si un peu quand m�me... T'es cens� savoir dans la limite du possible si tu travaille avec 1 �l�ment ou N �l�ments... Quant � 0 �l�ment, si t'as du code qui travaille avec des collections vides, c'est g�n�ralement mauvais signe, et en cas de doute tu as un moyen simple de faire tes v�rifications

Cette librairie n'�tends pas les types primitifs de base comme Array ou String ou autre

�a, c'est plut�t une bonne chose, et est une force de jQuery ! L'approche du wrapper est bien plus souple et propre
Pour ceux que �a int�resse, un petit article expliquant ce point de vue: http://perfectionkills.com/whats-wro...nding-the-dom/

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.

C'est dommage, pas tant que �a au final. L'h�ritage c'est bien, mais Javascript propose des techniques qui permettent de s'en passer. Je vous laisse regarder cet article qui explique comment: http://javascriptweblog.wordpress.co...in-javascript/
Mais si tu tiens vraiment � faire de l'h�ritage avec Javascript, il y a quelques exemples sur le Web qui ne font pas pas plus de quelques lignes de codes et qui fonctionnent parfaitement

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.

Tout � fait d'accord, les librairies te font gagner du temps.

Mais au final, j'�cris mes objets de mani�re � ce qu'ils fonctionnent sans librairie.

C'est ce qui devrait �tre fais tout le temps �a, d�coupler au maximum son code afin de le rendre modulable. Un exemple de d�couplage, tr�s orient� jQuery mais n�anmoins int�ressant, a �t� publi� par Rebecca Murphey sur son blog.

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.

Je ne vois pas en quoi l'utilisation d'une libraire t'emp�che d'approcher �galement au plus pr�s de la demande du client. Les libraires rajoutent des fonctionnalit�s ou les harmonisent, mais �a reste du Javascript, donc si quelquechose dans la librairie ne correspond exactement � ce que tu veux, tu peux toujours la refaire


Pour terminer sur le point des librairies, je dirais qu'il est bien de savoir les utiliser de mani�re correcte. Savoir quand on peut s'en passer, savoir quand cela nous fera gagner du temps et/ou nous permettra d'assurer la long�vit� d'un projet. Parce que la grande diff�rence entre les libraires que chacun bricole de son c�t�, et les libraires tel jQuery, c'est quelles sont et resteront p�r�ne pendant encore un sacr� bout de temps. Il y a une communaut� de d�veloppeurs et d'utilisateurs derri�re tout �a, chacun am�ne ses id�es, reporte ses bugs, donne son avis etc, et on sait bien que l'union fais la force. Les projets sont document�s et r�guli�rement mis � jour, c'est important aussi. D'une mani�re g�n�rale, si tout le monde fais sa propre librairie, �a peut vite devenir compliqu� lorsque plusieurs d�veloppeurs travaillent ensemble. Ou bien m�me lorsqu'un d�veloppeur d'une libraire "perso" quitte son entreprise, il a int�r�t a avoir bien document� sa chose sinon c'est le casse-t�te assur� pour ceux qui restent (j'en ai fais les frais, et croyez-moi, la perte (en temps, et donc en argent) peut vite �tre consid�rable selon la taille du projet). Les libraires sont un gain de d�veloppement certain, mais cela n'emp�che pas de les utiliser avec parcimonie, et surtout, surtout, cel� n'emp�che pas d'apprendre le Javascript avant toute chose.
Je ne suis pas particuli�rement pour que chacun �crive sa propre librairie, car peut-�tre que ca VOUS fera gagner du temps lorsque vous developperez, mais �a en fera surrement perdre beaucoup plus lorsque vous ne serez plus l� et qu'il faudra d�bugger/maintenir la chose. L'avantage du framework sur ce point, c'est que tout le monde parle le m�me "langage" (pas au sens Javascript, au sens outil/framework), donc tout le monde peut comprendre relativement facilement le code qui a �t� �crit par un autre. Une exception � cette remarque quand m�me, lorsqu'il s'agit d'un d�veloppement vraiment sp�cifique, il peut-�tre mieux d'avoir son propre code plut�t que celui d'une librairie.



Pour moi, et pour beaucoup d'autres, l'ann�e 2010 a �t� l'ann�e du Javascript, et ce n'est pas fini. Des tas de projets ont �t� lanc�s ou propuls�s au cours de cette ann�e.
Je penses notamment � Node.js, qui permet d'amener Javascript c�t� serveur. Ce n'est pas le premier projet � faire �a, mais c'est le premier a avoir autant de succ�s. Et il est d�sormais possible et simple de cr�er un site Web / application Web uniquement gr�ce � Javascript.
Je penses ensuite aux nombreuses d�mos que l'on a vu sortir ici et l�, montrant des utilisations de HTML5 et CSS3, avec le Canvas, l'audio, la vid�o et j'en passe.
La sortie d'IE 9 et les d�mos de Microsoft pour vanter son navigateur, toutes repoussant les limites du navigateur via Javascript.
Les navigateurs d'ailleurs, qui font tous de plus en plus d'efforts pour avoir des interpr�teurs Javascript de plus en plus rapide. Les frabricants se concentrent de plus en plus sur 2 choses: le respect des standards, et la vitesse d'ex�cution du Javascript. Ce n'est pas pour rien.
La communaut� Javascript ensuite, qui essaye de redorer l'image du langage via une campagne de Google bombing-like pacifique. Il y a �galement eu plusieurs concours Javascript et de nombreuses conf�rences durant l'ann�e.
Le Web 2.0 fait naitre de partout des applications web, et non plus des simples sites web. C'est applications font pour la plupart appel au Javascript pour rendre les choses plus interactives.

Qui utilise la version HTML de Gmail ?



Liens divers concernant des applications Javascript:
http://blog.rebeccamurphey.com/on-jq...e-applications
http://blog.rebeccamurphey.com/on-rolling-your-own
Recommend Tools And Resources For JavaScript Developers: Issue 1
Building Large-Scale jQuery Applications
The Tech Behind the New Grooveshark

[gwinyam]

Je ne peux qu'applaudir
A mon avis, t'as tout couvert l�.

[dukej]

Bonsoir � tous
Si un peu quand m�me... T'es cens� savoir dans la limite du possible si tu travaille avec 1 �l�ment ou N �l�ments... Quant � 0 �l�ment, si t'as du code qui travaille avec des collections vides, c'est g�n�ralement mauvais signe, et en cas de doute tu as un moyen simple de faire tes v�rifications

Dans le cas de jquery c'est quand m�me optimis�, et m�me si tu lance un "for var i" sur un array il ne sera pas ex�cut� si ta condition de base i<array.length n'est pas valid�e.

Ensuite quand avec jquery tu fais un $('.blabla').monplugin().
Derri�re si le plugin est bien cod� et qu'il teste le length de jquery �a ira .
Et si tu fais un each sur le r�sultat, la blague magique c'est que �a reste quand m�me optimis� et la d�tection du length est faite en premier. Au pire tu auras lanc� une pile de 3 fonctions avant d'arriver au each, rien de m�chant :o. Et quand tu regardes le code de jquery :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
// A special, fast, case for the most common use of each
		} else {
			if ( isObj ) {
				for ( name in object ) {
					if ( callback.call( object[ name ], name, object[ name ] ) === false ) {
						break;
					}
				}
			} else { //c'est là qu'est fait le each quand on tape directement depuis un résultat de jquery. 
				for ( var value = object[0];
					i < length && callback.call( value, i, value ) !== false; value = object[++i] ) {}
			}
		}

C'est quand m�me optimis�