Discussion :

[iluvatar75]

Merci beaucoup pour ces exemples !

Mais j'ai une autre question : A quoi sert le ++ qui se trouve après la variable si on peut l'écrire simplement sous cette forme :

Code :

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

alert(j);

Car que ça soit alert(j); ou alert(j++); le résultat est pareil

Je vous montre un exemple que je ne comprends pas que j'ai récupéré sur un site (la source de mon problème):

exemple

Code :

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

1
2
3
4
5
6
7
8
var number_1 = 0;
var number_2 = 0;
 
number_1++;
++number_2;
 
alert(number_1); // Affiche 1
alert(number_2); // Affiche 1

l'exemple au-dessus n'est pas compliqué mais pourquoi le "number_1++" le résultat affiche 1

[Bovino]

L'exemple que tu donnes n'est pas significatif car les incrémentations (post ou pre) se font avant l'utilisation des variables.
Donc dans les deux cas, l'incrémentation se fera puis l'alert apparaitra.
En revanche, dans l'exemple d'andry.aime ou le mien, tu vois bien que dans un cas, il y a d'abord incrémentation puis affichage alors que dans l'autre c'est le contraire.

[andry.aime]

Je ne sais pas si tu as testé les codes proposés mais Bovino l'a expliqué:

Code :

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

1
2
3
4
5
var i = 0, j = 0;
alert(++i); // affiche 1, car on incrémente la variable i ensuite on fait l'alert
alert(i); // affiche 1, la variable i est incrémenté avant l'alert de la ligne 2 
alert(j++); // affiche 0, car on appel alert pluis on fait l'incrémentation
alert(j); // affiche 1, la variable i est incrémenté après l'alert de la ligne 4

Je te conseille de voir un cours sur la priorité des opérateurs. Ces opérateurs ne sont pas souvent bien expliqués dans les tutoriels javascript mais regarde sur les tuto java, c++, php, ... mais ce sera bien expliqué. Les principes sont les même pour ces langages.

A+.

[Willpower]

une autre façon de voir la chose, c'est d'imaginer les "++" comme des fonctions :

Code :

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

1
2
3
4
5
FUNCTION A++(&INT){
    saveINT = INT;
    INT = INT+1;
    RETURN saveINT;
}

et

Code :

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

1
2
3
4
FUNCTION ++A(&INT){
    INT = INT+1;
    RETURN INT;
}

[vermine]

Cette question sur les opérateurs d'incrémentation a d'ailleurs fait l'objet d'un point de la FAQ.

[iluvatar75]

Alléluia !
J'ai compris !

Le lien que tu m'as donné Vermine, m'a beaucoup aidé !

Je remercie à Bovino, andry.aime, Willpower et Vermine qui ont pris le temps de me répondre !

A très bientôt !

[n2engineer5]

jquery sort en light (sans gestion de ie8 et le tralala) car le ie10 est pas mal standard now.

moi je code toujours sans librairie sur mes projets perso.s (en tout cas je n'utilise jquery que quand je veux etre lazzy)

Il y plus d'utilité à utiliser jquery-ui pour des widgets que la lib jquery de mon coté.

je code surtout en canvas et webgl en deployment multi-platformes quand c'est possible (Android est très bas présentement sur mobile coté fps ). (le jeu s'en va en javascript pas en jquery. mais quel jeu ? crysis, call of duty? euhhh non. Le old school oui! super mario kart! secret of mana! mortal combat! bomberman! castelvania et surtout final fantasy 8 ...)

voila ma vision des choses.

salut!

[scandinave]

le old school oui! super mario kart! secret of mana! mortal combat! bomberman! castelvania et surtout final fantasy 8 ...)

Pour l'instant les navigateurs ne sont pas capable d'exploiter suffisamment les cartes graphique pour permettre un jeu comme call of. On est un peu revenu 10 ans en arrière en terme de puissance disponible. Ce qui n'est pas inintéressant si l'on considère que beaucoup de développeur avait perdu de vue qu'il faut réfléchir un peu pour optimiser un programme.

Mais je suis persuadé que bientôt les navigateurs pourront exploiter une carte graphique presque aussi efficacement qu'un natif. Et la on aura des jeux avec des gros graphismes.

Finalement, on en reviens au même problème, les FAI vont devoir augmenter les débit pour que cela se développe. Parce que télécharger les ressources nécessaire à un Call of ,

[danielhagnoul]

JS n'est certainement pas le plus beau langage du monde. Venant de C++ je me souviens d'un premier contact difficile.

Un framework ne dispense pas de connaître les bases. Le plus grand mérite de jQuery est d'avoir unifié l'usage de JS sur les différents navigateurs.

L'avenir de JS, je l'ai déjà écrit il y a quelque temps, est d'incorporer le meilleur d'un framework comme jQuery et d'évoluer en utilisant une syntaxe inspirée de Python.

JS évolue en permanence, mais la plupart des gens ignorent la chose volontairement pour continuer à être compatibles avec des antiquités.

Les améliorations déjà apportées par ES5 et les améliorations en cours d'élaboration pour la sortie d'ES6 sont très importantes.

L'invention de "surcouches" ( parfois dépendantes d'un autre langage) pour compiler le résultat dans un JS réducteur par rapport aux possibilités futures du langage me semble un fameux gâchis d'effort et de matière grise.

Si cet effort avait été investi dans l'amélioration du langage, nous en serions à ES8 !

[garniture]

Coucou,
Le JS est de plus en plus utilisé, mais une question me turlupine
Pourquoi le Javascript est-il aussi populaire ?
A quel besoin ce langage répond mieu qu'un autre ?
(Ps, je ne souhaite ni lancer de débat: pro/anti javascript , ni troller c'est une question sérieuse)

[ymoreau]

Comme pour le PHP, ce n'est pas tant que le Javascript réponde mieux au besoin ciblé mais plutôt qu'il était disponible à peu près partout sans concurrence solide et est devenu "sans effort particulier" un standard incontournable. Actuellement il serait trop difficile de basculer sur autre chose sans que tous les navigateurs prennent cette décision en commun.

Cela dit ça a aussi poussé les navigateurs à optimiser leurs interpréteurs, ça a motivé des gens à développer tout un tas de frameworks/bibliothèques. Et le langage en soi reste intéressant et propose des choses alternatives, principalement son côté asynchrone. Je veux dire que même si son succès ne vient probablement pas de ses caractéristiques techniques, il en possède quand même des bonnes (coup de bol qu'on soit tombés sur Javascript plutôt qu'autre chose peut être ).

[Watilin]

(coup de bol qu'on soit tombés sur Javascript plutôt qu'autre chose peut être ).

En effet, ça aurait pu être VBScript

[sekaijin]

Bonjour.

Je ne suis pas entièrement d'accord quand je lit que JS ne c'est pas imposé grâce à ces caractéristiques techniques.

Je pense que au contraire ce sont ces caractéristiques qui on fait que JS c'est imposé.

Nous avons un peu trop tendance à juger JS par rapport au besoin d'aujourd'hui. A savoir construction d'IHM complexe, traitement plus ou moins lourd, manipulation de données structurées, etc.

Mais JS n'a pas été créé dans cette optique et là n'était pas le besoin. au départ JS est côté serveur et le besoin s'apparente plus à ce que permet sh/bash que python/C++. en effet l'usage principal d'un script (sh) c'est de positionner quelque variable appeler quelques exécutables de façon contrôlée. pas besoin de définir des structures complexe et répétitives. c'est bon pour un programme plus lourd que de devoir instancier une douzaines d'objet faire un ls -1 | tr 't' 'd'.
Mais est-ce une raison pour faire l'impasse sur les avancées dans le domaine des langages ? je pense que les ingénieurs de Netscape pensaient comme moi que non. Il ont donc cherché le meilleur modèle possible. les langage à base de classe c'est lourd c'est verbeux et ça ne réponds pas (mal) au besoin. Mais la notion d'objet est intéressante.
le monde de la théorie des langage est suffisamment vaste pour pouvoir faire son marcher et un langage à base de prototype est plutôt bienvenu. (même si aujourd'hui les développeurs ne le comprennent pas tous).

mettons nous dans le contexte nous avons des serveurs qui utilise cgi (ou dérivé) pour faire exécuter un script généralement du sh du perl ou du tcl. (php est venu juste après) le premier point à régler fut la séparation de cgi et du serveur. on a eut droit à pas mal de truc. il y a bien eu des gens pour faire ça en C ou C++ mais mise à part la compilation ça n'a rien apporté et dans le contexte mieux valais un shell qui appelle des execs C++ qu'un gros prog en compilé. plus souple à maintenir (le web est très volatile) pour quoi ni sh/bash/perl/python n'a pris l'ascendant ?
il fallait un langage qui embarque dans sa structure la capacité de s'adosser à un serveur. TCl de ce point de vu à été un bon candidat l'API C de TCL est simple légère à mettre en oeuvre et permet une interaction poussée entre le script et son hôte. Mais TCL est un langage ancien et même s'il reste très performant il ne connait pas la notion d'objet (bien qu'elle lui ai été ajouté)

bref js est techniquement un très bon compromis. l'histoire à montré que php (côté serveur) était un bon candidat.
on peut noter que la notion d'objet bien que radicalement différente entre php et JS a des similitudes. l'un est à base de classe l'autre à base de prototype. mais l'un comme l'autre on une structure d'objet construite sur une hashMap. et cela apporte beaucoup de souplesse (mais fait perdre des cheveux à certains)

Lorsque JS est passé côté client c'est une de ses caractéristique technique qui a fait son succès. le fait que JS est construit pour être adosser à une exe (le navigateur). cette caractéristique à permit très vite d'avoir accès de façon organisée (pas encore standardisé) à toutes les parties du navigateur. le navigateur lui-même, la fenêtre, la page, le document et tous les éléments qui le compose. et c'est là que pour moi JS de part ces caractéristiques techniques c'est imposé. le modèle prototype à là montré qu'il était très efficace. avec un noyau minuscule une empreinte sur le navigateur réduite JS à complètement ouvert le navigateur au script.

Il y a eut VB mais aussi bien d'autres. je pense que JS c'est imposé face à lui pour plusieurs raison. l'une d'elle est la faible empreinte dans le code de l'hote. l'autre son modèle objet très souple, et pour finir la relative concision de sont code (moins verbeux que VB)
pour ce qui ne relève pas de la technique JS a d'entré de jeu était implémentation par qui le voulait (il fallait tout de même écrire son moteur) VB est lui propriétaire. même si ce n'est pas très évident la syntaxe est simple et facile à apprendre (je parle ici de JS pas du DOM ni des objet du navigateur en gros ecmaScript) il ne nécessite pas d'outillage particulier un bête éditeur de texte.


après des années et l'évolution des besoins je lis bien trop souvent que JS à besoin de structure de classes de compilation de typage fort etc. si je reconnais que les besoin en termes d'IHM de structure de données ont changés. je ne suis pas d'accord avec ces assertions. Si vous pensez cela alors vous n'avez pas choisi le bon langage. Je pense au contraire que JS doit garder la souplesse de son modèle objet, maintenir et améliorer le transtypage. Je pense que passer du prototype aux classes de l'interprétation à la compilation (JS est déjà compilé à la volée par les moteur d’exécution) passer à un typage fort c'est la mort assurée pour JS.

Y a-t-il un nouvel espace qui se crée pour une autre technologie à côté de JS ? possible, Mais tout comme C/C++ n'a pas remplacé SH/BASH je pense que le besoin de script existera encore longtemps dans ce contexte et que ce ne sont pas les langages compilés au typage fort qui sont les mieux placé dans ce domaine.

A+JYT

[garniture]

Merci pour toutes ces explications, vous m'ouvrez le champ de reflexion.

[Lcf.vs]

après des années et l'évolution des besoins je lis bien trop souvent que JS à besoin de structure de classes de compilation de typage fort etc. si je reconnais que les besoin en termes d'IHM de structure de données ont changés. je ne suis pas d'accord avec ces assertions. Si vous pensez cela alors vous n'avez pas choisi le bon langage. Je pense au contraire que JS doit garder la souplesse de son modèle objet, maintenir et améliorer le transtypage. Je pense que passer du prototype aux classes de l'interprétation à la compilation (JS est déjà compilé à la volée par les moteur d’exécution) passer à un typage fort c'est la mort assurée pour JS.

Je partage totalement cet avis, un typage fort est un atout mais vite peut devenir trop rigide.

Pour moi, c'est la possibilité de typer qui manque, au JS... j'ai d'ailleurs développé un tokenizer dans ce sens, pour un interpréteur de pseudo-classes JS, en JS.

A mon sens, on finira par le voir arriver, ce typage... que j'espère facultatif, à l'appréciation du développeur et des besoins du projet.

[Lcf.vs]

Bonjour à tous,

Pour ceux que cela intéresse, voici mon premier outil ES6 : yld

Bonne découverte.

[imikado]

Je partage totalement cet avis, un typage fort est un atout mais vite peut devenir trop rigide.

Pour moi, c'est la possibilité de typer qui manque, au JS... j'ai d'ailleurs développé un tokenizer dans ce sens, pour un interpréteur de pseudo-classes JS, en JS.

A mon sens, on finira par le voir arriver, ce typage... que j'espère facultatif, à l'appréciation du développeur et des besoins du projet.

Javascript possède un typage fort, cf http://web.developpez.com/actu/59624...-a-l-accepter/

[Lcf.vs]

Javascript possède un typage fort, cf http://web.developpez.com/actu/59624...-a-l-accepter/

Hum, je pensais plutôt à du type hinting, etc.

L'équivalent de :

Code :

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

1
2
3
4
5
6
7
8
 
var fct;
 
fct = function fct(value) {
    if (!(value instanceof Type)) {
        throw new Error('value must be an instance of Type');
    }
};

[danielhagnoul]

Une opinion (en anglais) intéressante sur la multiplicité des bibliothèques JS : Yet Another Framework Syndrome (YAFS)

[phildes2]

Hum, je pensais plutôt à du type hinting, etc.

L'équivalent de :

Code :

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

1
2
3
4
5
6
7
8
 
var fct;
 
fct = function fct(value) {
    if (!(value instanceof Type)) {
        throw new Error('value must be an instance of Type');
    }
};

Il existe peut-être une solution simple pour reproduire cette fonctionnalité.
Par exemple, créer une variable spécifique à cette classe. La commande de vérification de type sera : if(!myTypeVar){gestion d'erreur}

Au sujet du "typage fort", ne serait-ce pas plutôt un problème d'éditeur.
Par exemple : TypeScript (que je ne recommande pas particulièrement) prend en charge les types mais produit du Javascript.
Nous pourrions en dire autant du C++ : le C++ est typé mais produit de l'assembleur (qui ne traite pas les types, je suppose.