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é