Discussion :

[Washmid]

A propos des applications lourdes, il y a depuis quelque temps des commerciaux développeurs qui semblent essayer de faire croire que oui, on peut faire des supers applications client lourd en javascript/HTML comme avec java/c#.

Petit exemple avec un commercial développeur de "15 ans d'expérience" :

http://blogs.msdn.com/b/dorischen/ar...-amp-tips.aspx

Conséquence, un de mes responsable a récemment sorti qu'on devait envisager de porter une de nos appli (500 000 lignes de code) en full javascript pour windows 8

Tout ça pour dire que certains ne font vraiment pas la différence entre grosse appli et petit script, dont on peut comprendre qu'ils reprochent à javascript ce genre de choses

[Voyvode]

Oui. Le C n'en a pas non plus et pleins d'autres langages très utiles et très utilisés n'utilisent pas les classes.

Sans blague ? Merci pour l'info…

javascript a des classes , pas au sens java mais ce sont des classes quand même , smalltalk ( dont java s'inspire ) n'a pas non plus de classes à la java.

Smalltalk a des classes. Elles sont clairement considérées comme des objets à la différence de Java, ça n'en fait pas pour autant un langage basé prototype. Objective-C a cette particularité aussi par exemple.

Les classes ne sont qu'un moyen parmi d'autres pour faire de la programmation objet. Mais le problème est que la majorité des gens faisant du Javascript ne savent pas utiliser les prototypes..

Ta réponse est intéressante. En fait c'est plutôt ça qui me surprend, j'ai l'impression qu'une part non négligeable de frameworks essaye de proposer des classes alors que JavaScript est basé prototype.

[Paul TOTH]

A propos des applications lourdes, il y a depuis quelque temps des commerciaux développeurs qui semblent essayer de faire croire que oui, on peut faire des supers applications client lourd en javascript/HTML comme avec java/c#.

Petit exemple avec un commercial développeur de "15 ans d'expérience" :

http://blogs.msdn.com/b/dorischen/ar...-amp-tips.aspx

Conséquence, un de mes responsable a récemment sorti qu'on devait envisager de porter une de nos appli (500 000 lignes de code) en full javascript pour windows 8

Tout ça pour dire que certains ne font vraiment pas la différence entre grosse appli et petit script, dont on peut comprendre qu'ils reprochent à javascript ce genre de choses

mais bien sur qu'on peut faire des applications lourdes en HTML5/JS, très lourdes même

fut une époque ou Java/C# étaient critiqués de la même façon en disant qu'il n'était pas possible de porter une application de 500 000 lignes de C ou C++ dans ces langages.

en fait il y a deux points de vue, celui du technicien/développeur qui considère l'outil et son fonctionnement face au but à atteindre, et le dirigeant/commercial qui regarde la portée du produit: si Microsoft me dit que l'avenir c'est JS/HTML5, qu'est-ce que je vais m'enquiquiner avec l'avis d'un développeur qui ne veux manifestement pas se mettre à la page et garder son environnement de travail obsolète ?

Heureusement, j'ai des fois des clients qui veulent des solutions, et non des technologies, dès lors je peux librement choisir mon environnement de travail avec pour seule contrainte d'offrir au client un produit qui répond à ses attentes...et là ce n'est pas souvent du HTML/JS (ni même du C# ou Java d'ailleurs )

[Niark13]

Moi je suis plus dans l’idée que typage statique ou dynamique je m’en fiche, par contre je préfère carrément un typage fort (ça élimine quand même pas mal d’erreurs à la con, sournoises et qui peuvent être difficile à trouver).

+10000

J'ai beaucoup de plaisir à travailler en Python, qui bien que dynamique, a un typage fort qui interdit pas mal de ce que l'on voit dans les WAT*de JS.

Quand je vois les sommes faramineuses qui sont investies à la fois pour rendre JS plus rapide et pour développer des alternatives qui compilent vers JS (coffeescript, dart, typescript…), je me dis que l'avenir de JS est plus comme environnement d'exécution que comme langage de programmation.

[wirenth]

Il y a encore des gens pour se lancer dans des flame war à propos de "leur" langage... ça me fait toujours marrer les types qui disent "je suis developpeur JS" ou "je suis développeur C++", etc... Parce que tu connais qu'un langage et tu l'utilises pour tout et n'importe quoi ? Mon menuisier ne m'a jamais dit "je suis menuisier marteau, parce que je peux tout faire avec, même si c'est pas idéal".

Quant au JavaScript, oui il contient de très nombreux pièges. Mais c'est pas grave parce que JavaScript is Web Assembly Language and that's OK

[xelab]

Quant au JavaScript, oui il contient de très nombreux pièges. Mais c'est pas grave parce que JavaScript is Web Assembly Language and that's OK

Je trouve cette comparaison assez facile et rapide. Quand je code en Java ou C++, je n'ai absolument pas besoin de connaître l'assembleur. Par contre si je code dans un langage qui compile du javascript, j'ai intérêt à connaître un minimum le fonctionnement du javascript (qui est quand même un langage de haut niveau) sous peine de ne parfois rien comprendre au résultat et aux éventuels bugs.

[getz85]

Pour ceux qui ne connaissent pas: http://wtfjs.com/

Il y a de sacrés pépites quand même, je doute qu'on puisse trouver des exemples aussi aberrants dans d'autres langages (parce que son exemple sur Java est complètement idiot )

[Orwel]

Le C est un bon exemple : selon le point de vue que l’on adopte il est soit faiblement typé, soir fortement. Par contre, il est indubitablement statiquement typé.

Quelque explication, s'il vous plaît. Pour moi, le C est un langage fortement typé (1 variable / 1 type) avec la possibilité d'interprété les données avec un typage dynamique (1 donnée / plein de variable avec des types différents).

La variable indique l'interprétation de la donnée, mais avec la magie du C on peut attribuer moult variable sur une même donnée.

Le typage faible c'est une variable qui peut bouffer n'importe quoi et faire n'importe quoi sans se plaindre. Ce qui est parfait pour des scripts.

Les WAT sont une forme de critique du langage, mais tournée avec humour. Si on accepte la critique, elle peut aider à progresser; mais il ne fait jamais la dénigrer purement comme cela est présenté dans l'article.

[Bovino]

getz85, malheureusement, les exemples que je vois sur la première page ne démontrent qu'une chose : ceux qui les postent ne connaissent pas JavaScript...

Si je prends l'exemple

Code :

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

"Why am I a " + typeof + ""; // "Why am I a number"

typeof étant un opérateur, ce qui suit doit être l'opérande et + "" est un opérande valide puisque le + en préfixe est un opérateur de transtypage en nombre, donc une chaine vide transtypée en nombre (console.log(+"")) donne 0 et typeof 0 est bien un number. Il n'y a rien là de spectaculaire et tout cela est parfaitement décrit par ECMA262.

Bref, qu'on aime ou qu'on aime pas le typage dynamique, c'est un fait que JavaScript est un langage à typage dynamique et il faut le prendre en compte. Le corollaire, c'est que toute opération doit retourner un résultat et que si les paramètres de l'opération sont incompatibles, il faut les transtyper selon des règles. Or ces règles existent et il n'y a pas de surprise avec JavaScript si l'on connait ces règles.

[Kaamo]

Le typage faible/dynamique vient du fait que Javascript n'avait pas de gestionnaire d'erreur dans la v1 du langage. (comprendre les blocs try {} catch() {} finally {} ). Du coup, plutôt que de jeter une exception (impossible à l'époque!) les variables sont implicitement converties et c'est aussi pourquoi JS échoue silencieusement. (Source : un tweet de Brendan Eich).

Bien que le typage faible ait ses inconvénients (conversion implicite en chaine de caractère : '5' + 6 === '56') il a ses points forts quand il s'agit de traduire implicitement en booléen. A chaque fois que JS s'attend à un booléen (par exemple dans un if) toutes les valeurs peuvent être utilisées, elles sont automatiquement converties en true ou false. Il faut avouer que le typage faible/dynamique dans ce sens nous arrange pas mal.
Ces valeurs sont interprétées à false : undefined, null, false, -0, +0, NaN, ''. Toutes les autres à true. Tout le monde en abuse de ce typage faible, et ne s'en plaint pas pour autant.

Une bonne pratique serait d'utiliser Boolean(), Number() et String() pour convertir une donnée vers le type attendu. Ainsi, les variables auront bien le type que l'on souhaite ! Exemple très simple, loin d'être complet, mais c'est pour montrer les possibilités de maitriser le typage de JS. Il faut aller plus loin que dans certains langages mais cette souplesse, si elle est maitrisée, n'est plus une contrainte mais une force.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
function gestionVariables(mesInfos){
  var prenom = String(mesInfos.monPrenom);
  var age = Number(mesInfos.monAge);
  var loveJS = Boolean(mesInfos.loveJS);
 
  if (isNaN(age))
    throw "Type non valide pour l'âge !";
 
  console.log("Je m'appelle " + prenom + ", j'ai " + age + " ans et " + (loveJS ? "j'aime =)" : "j'aime pas =(") + " le Javascript !");
}
 
// Exemple 1 : Type non valide pour l'âge !
try {
  gestionVariables({ monPrenom: 'Toto', monAge:'blabla', loveJS: false});
} catch(e) {
  console.log(e);
}
 
// Exemple 2 : Je m'appelle Toto, j'ai 25 ans et j'aime =) le Javascript !
try {
  gestionVariables({ monPrenom: 'Toto', monAge: '25', loveJS: true});
} catch(e) {
  console.log(e);
}

[anykeyh]

Non mais le vrai "wat" dans javascript, c'est l'objet date :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
var dayInWeek = new  Date().getDay(); // Why?! x_x
var dayInMonth = new Date().getDate(); //Wat? 
var year = new Date().getYear(); //113? WAT?
 
var month = new Date().getMonth() + 1; // +1?! WAT?!
 
var now = new Date();
var now2 = new Date(now.getTime());
 
if (now != now2) { alert('WAT... ;_;?') }
 
if (now >= now2) { alert('WAT WAT WAT?!'); }

Je vous évite la gestion des fuseaux horaire avec "ce truc"
ça pourrait être risible ça ne coutait pas des millions d'euros chaque années en baisse de productivité...

Quand une personne me dit "mais non javascript c'est pas mal", je le questionne sur l'objet date, ça calme d'un coup.

[TNT89]

ceux qui les postent ne connaissent pas JavaScript...

Ca en reste néanmoins un problème : je ne connais pas (que très peu) JS, et je suis incapable par un quelconque raisonnement logique "naturel" de formuler le résultat sans le tester...

Je conçois que la plupart ne sont pas des morceaux de codes sains et courants. Par contre, l'interprétation des strings en int ou la comparaison des arrays semblent extrêmement scabreuses. Je suis persuadé que j'en ferai les frais très rapidement.

(Cela dit, ils ont aussi de bonnes lacunes en Mathématiques et en précision des formats flottants... cf "negative zero equal but not equal" et "magic increasing number"...)

[Bovino]

Code :

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

if (now != now2) { alert('WAT... ;_;?') }

Euh... fail...

Dans quel langage une instance d'un objet est égale à une autre instance ???

[anykeyh]

Code :

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

if (now != now2) { alert('WAT... ;_;?') }

Euh... fail...

Dans quel langage une instance d'un objet est égale à une autre instance ???

c#, c++, ruby, python, tout les langages qui reimplementent les opérateurs. Et optionnellement une grande partie des langages de scripts modernes.

D'ailleurs date1 > date2 fonctionne, va comprendre ils ont implémenté les opérateurs less_than, greater_than mais pas equals. Dans ce cas autant rien implémenter, non? ;-)

[rannik]

Tant de passion pour un langage qui a eu Lisp comme nourrice et Java comme couturière ...

Les seuls vrais erreurs du langage sont les choix marketing et stylistique, le reste n'a aucun intérêt tant il suffit de changer de point de vue et d'usage pour trouver des choses imbuvables dans TOUS les langages.

Et la grosse blague Javascript n'a pas de classes, il faudrait un peu se renseigner sur la programmation par prototype avant de sortir ce genre d'ânerie en 2013.

[Kaamo]

@anykeyh

Pour vérifier si deux dates sont égales : dt1.getTime() === dt2.getTime()
Ou aller voir la FAQ Javascript : Comment comparer deux dates ?

[anykeyh]

@anykeyh

Pour vérifier si deux dates sont égales : dt1.getTime() === dt2.getTime()
Ou aller voir la FAQ Javascript : Comment comparer deux dates ?

Bien sur, je sais, je pointe juste des choses qui m'hérissent les poils

En fait le problème de javascript, c'est que c'est un langage "opportuniste", comme php, je m'explique (et désolé si je prend des raccourcis):

D'un coté on a des langages de "recherches", partant d'un postulat ou d'une philosophie.
Par exemple, java la philosophie de depart c'est "write once run everywhere", et un code clair et facilement maintenable (pas de surcharge d'opérateurs, typage fort, contrat d'interfaces etc...)

Haskell le postulat c'est "lazy evaluation" et "lambda calcul"

Ruby c'est "tout est objet", "on veut faire lisp en plus lisible et plus clair"

On peut en trouver tout un tas de langages qui ont été développés car les auteurs on voulu travailler sur une nouvelle philosophie.
Et les applications technique sont venues après.

À l'inverse, on a des langages developpé pour une application: javascript a été developpé par netscape, pour animer les pages web. Bref la philosophie ici c'est "on fait un truc qui anime les pages web".
Idem pour PHP, "on fait un truc coté serveur pour gerer les formulaires et l'affichage de page dynamique".

Après coup, faut pas s'étonner que beaucoup de monde tapent sur ces langages; même hors du champ de l'informatique, dans tout les domaines c'est la même chose. En archi, une barre HLM c'est purement fonctionnel, comme javascript ou PHP quoi.

[sedryk]

<HS>

En archi, une barre HLM c'est purement fonctionnel.

Heureusement qu'on est sur une forum d'info parce que v'la le beau gros troll à 2 balles...
</HS>

[Bovino]

Ruby c'est "tout est objet", "on veut faire lisp en plus lisible et plus clair"

Ben justement, on peut dire la même chose de JavaScript...

Et précisément, même si j'admets m'être un peu enflammé tout à l'heure (), c'est bien ce qui justifie que

Code :

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

1
2
3
4
5
var d1 = new Date();
var d2 = new Date(d1.getTime();
var d3 = d1;
console.log(d1 == d2);  // false
console.log(d1 == d3);  // true

Car l'opérateur new crée une nouvelle instance qui est un objet différent, et non pas une nouvelle référence sur le même objet.

[niarkyzator]

C'est peut-être ça le soucis du Javascript en fait.
C'est normalement super simple d'utilisation et pas prise de tête, mais d'un autre coté, sans la norme ECMA262 sous les yeux tu n'est pas toujours capable de prédire le comportement d'un test d'inégalité, du coup ça devient super pointu.