Discussion :

[frfancha]

Justement, JS n'est PAS un langage objet "classique" (type C++ / Java / C# / autre..), l'approche est différente. Beaucoup de gens voient le JS comme un langage objet avec une syntaxe dégueu pour les classes; alors que le concept de classes n’existe tout simplement pas.

Exactement

[frfancha]

Dans la plupart des cas, oui, malheureusement.

Non pas parce que c'est un langage globalement bon (il a des aspects très mauvais et d'autres meilleurs) mais parce qu'il est

• Omniprésent
• Suffisamment éloigné des autres dans son approche pour que quelqu'un qui a seulement été formé aux langages orienté objet "classiques" fasse plus de mal que de bien en essayant de l'utiliser.

Plus 1000 ;-)

[Invité]

Je ne connais rien à Javascript mais j'ai bien ri en lisant ce commentaire sur la page originale :

Your thesis can be summarized as follows: “eat shit, millions of flies can’t be wrong”.

[SylvainPV]

Vu que quasiment tous les langages peuvent être compilés en JS, ce n'est pas tant le langage qui importe. Si le projet WebAssembly se concrétise, on va sans doute voir encore plus de diversité.

Pour ceux qui ne l'ont pas encore vu, cette vidéo donne un paysage assez comique des 20 prochaines années et de la fin de JS: https://www.destroyallsoftware.com/t...-of-javascript

[air-dex]

J'ai répondu "oui" à cause de Node.js. Node.js est principalement un interpréteur JavaScript, et ce bien avant d'être une technologie pour du Web côté serveur. De ce fait il permet à JavaScript de sortir du Web, et en particulier du Web côté client. Les modules de base de Node.js étendent également les possibilités de base du JS, lui dont les fonctions de base sont si limitées dans nos navigateurs. Des frameworks comme Electron (anciennement Atom Shell) basés sur Node.js lui permettent même d'être utilisé pour des applications classiques.

Par conséquent, connaître JS permet très souvent de faire un bout de programme utile dans un domaine de programmation donné (sauf cas particuliers genre systèmes embarqués). D'où l'utilité de le connaître. Ce sera rarement la meilleure techno, mais au pire on aura toujours JS dans sa panoplie de développeur pour pouvoir faire des choses. Après c'est sûr qu'il y a d'autres technos plus indiquées pour faire mieux, mais ces technos là vont souvent être spécifique au domaine.

Le "non" était de mise il y a quelques années, quand le JS était cantonné au Web côté client. Mais la donne a changé depuis. Les technologies autour de JS ont tellement évolué autour de lui et cela en fait désormais un langage passe-partout. Python pourrait faire la même chose que JS en mieux mais il n'est pas utilisable pour du Web côté client. Donc c'est oui pour JS.

La quantité d'alternative à javascript (typescript , coffeescript, Dart , asm , AtScript et j'en passe) est symptomatique de l'état de JS. Si le langage était si bon il n'y aurait pas besoin de passer par une alternative (qui au final génère du JS , mais abstrait tous les truc chiant de JS).
Un non initié qui débarque la dedans va vite avoir du mal à comprendre pourquoi.

C'est pourtant simple. Les bien-pensants du Web ont décidé que les plugins Web c'était le Mal (pour des raisons valables, mais ceci n'est pas le débat ici). Le problème est que le seul langage qui reste accepté pour du Web côté client est le seul qui soit interprété par les moteurs Web, et c'est JavaScript. Une solution pourrait consister à faire interpréter d'autres langages par nos moteurs Web mais personne ne cherche à le faire. Google a essayé avec Dart mais les autres ont préféré soutenir leurs solutions pas optimales.

[yoyo88]

Ce n'est pas une approche par prototype comme l'entend frfancha, c'est de l'orienté objet classique transpilé en prototype donc effectivement immonde.


Tu veux dire celle qui arrive dans ECMAScript 6 ? Car sinon le langage n'offre pas de support explicite des modules.

Ceci dit je suis d'accord, "il n'y a pas grand chose à lui reprocher" est quand même assez exagéré.

Oui ECMAScript 6 va résoudre beaucoup de problème mais le temps que ça soit réellement actif chez tous le monde, notamment au prêt du grand publique, il va avoir quelque année encore. (y'a cas voir le nombre de PC sous XP pour s'en convaincre)

Justement, JS n'est PAS un langage objet "classique" (type C++ / Java / C# / autre..), l'approche est différente. Beaucoup de gens voient le JS comme un langage objet avec une syntaxe dégueu pour les classes; alors que le concept de classes n’existe tout simplement pas.

Pas de soucie avec ce que tu dis mais pour moi c'est justement le problème. Ce n'es pas un langage objet alors que l'on cherche a faire de l’objet avec, se qui montre qu'il y a bien un problème.


[Troll] en plus même sans la notion d'objet je trouve la syntaxe degeu [/Troll]

[frfancha]

Vu que quasiment [URL="https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js"]cette vidéo donne un paysage assez comique des 20 prochaines années et de la fin de JS: https://www.destroyallsoftware.com/t...-of-javascript

Sympa, mais je ne suis pas d'accord avec la raison qu'il donne de l'essor de javascript en 2006 comme étant le livre "The good parts". Bien sûr un excellent livre, mais la vraie raison de l'essor en 2006 c'est AJAX.

[goldbergg]

L'inconvénient avec les langages comme TypeScript, c'est qu'un peux a la façon de jQuery, il incite a faire de la m#rde et surtout, a moins de s’être bien documenté, se qui avouons le peux de personne fait, on se retrouve a a ne pas savoir se qu'on code...

Le Js n'est pas de la POO par class mais par prototype et tans qu'on essayera de vouloir contourner sa, c'est sur que le langage ne sera jamais utilisé a bonne escient et correctement et bien évidement les devs qui n'on pas envie de s’embêter apprendre de nouveaux concepts passeront leurs temps a se plaindre.

Comme je l'ai dit dans mon précédent post, le JS est un langage simple (je le penses vraiment), mais uniquement a partir du moment ou l'on a chercher a le comprendre, pas a le simplifier ni a tenter de contourner ses fondements.

Pour les certaines problématique évoqué précédemment sur les namespace et l'héritage, il n'est aujourd'hui pas possible de faire de "using" en js, les deux solution sont sois de tous charger dans le html via les balise script, sois d'utilisé le DSL ou l'AJAX.

Pour créer un namespace en JS affin d'isoler différentes portions de code, c'est aussi simple que ça:

Code :

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

1
2
3
4
5
6
7
8
 
var MonNamespace = MonNamespace  || {};//Déclaration d'un namespace, la condition permet de réutiliser le namespace dans plusieurs fichier sans se soucier de l'ordre de l'inclusion des fichiers.
 
MonNamespace.UnePseudoClass = function (){//Je déclare une "class" dans mon namespace
	this.MaFonction = function(){
		console.log('Je suis dans UnePseudoClass');
	}
};

Pour simplifier l'héritage, il suffit de créer une fonction:

Code :

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

1
2
3
4
5
6
7
8
 
function inherit (base, parent){  
	function F() { this.constructor = base; }  
	parent.call(base);  
	F.prototype = parent.prototype;;  
	base.prototype = new F();  
	return base;  
};

et de l'utiliser :

Code :

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

1
2
3
4
5
6
 
MonNamespace.MaPseudoClassEnfant = function (){
	inherit(this, MonNamespace.UnePseudoClass);//On fait l"héritage
	//On pourait aussi faire sa, mais l'usage en direct du "__proto__" n'est pas conseillé.
	//this.__proto__ = new MonNamespace.UnePseudoClass();
};

et sa donne sa:

Code :

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

1
2
var monObj = new MonNamespace.MaPseudoClassEnfant();
monObj.MaFonction();//j'appel ma fonction hérité

(Code pondu a la va vite, y a surement moyen de faire mieux sans forcement pondre plus de ligne)

Fin voila, tous sa pour dire qu'il n'y a pas besoin de passer par des surcouche pour résoudre des problématiques au final pas si compliqué, sans compter que des site comme codepen et jsfidlle propose pas mal d'exemple pour toute sorte de problématique (et y a jsperf qui permet de sensibilisé sur les techno a utiliser ou pas )

Le code complet pour ceux qui veulent tester (fonctionne sur IE):

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
"use strict";
var MonNamespace = MonNamespace  || {};//Déclaration d'un namespace
 
MonNamespace.UnePseudoClass = function (){//Je déclare une "class" dans mon namespace
	this.MaFonction = function(){
		console.log('Je suis dans UnePseudoClass');
	}
};
function inherit (base, parent){  
	function F() { this.constructor = base; }  
	parent.call(base);  
	F.prototype = parent.prototype;;  
	base.prototype = new F();  
	return base;  
};
MonNamespace.MaPseudoClassEnfant = function (){
	inherit(this, MonNamespace.UnePseudoClass);//On fait l"héritage
}
var monObj = new MonNamespace.MaPseudoClassEnfant();
monObj.MaFonction();//j'appel ma fonction hérité

[maske]

Par conséquent, connaître JS permet très souvent de faire un bout de programme utile dans un domaine de programmation donné (sauf cas particuliers genre systèmes embarqués). D'où l'utilité de le connaître. Ce sera rarement la meilleure techno, mais au pire on aura toujours JS dans sa panoplie de développeur pour pouvoir faire des choses. Après c'est sûr qu'il y a d'autres technos plus indiquées pour faire mieux, mais ces technos là vont souvent être spécifique au domaine.

Le même argumentaire existe avec java (pour l'exemple) : « autant connaitre java, au pire on peut tout faire, les autres technos sont spécifiques ». Admettons, pour un débutant c'est effectivement intéressant d'avoir une boite à outils passe partout à valoriser pour ses premiers jobs (java, js, autre...). Mais on arrive souvent à être spécifique au domaine et donc à utiliser des technos « moins généralistes » (ce qui en fait est quasi tout le temps faux...).

Le même raisonnement sur le java (encore une fois j'ai rien contre le java) couplé à une demande de l'industrie a donné une recrudescence de l'enseignement du java très tôt dans les écoles/universités et parfois on voit des formations qui laissent tomber les autres langages. Les étudiants sortent sans avoir appris à penser hors de ce cadre. Conseiller à tout le monde de faire du js c'est du même niveau.

[Luckyluke34]

Justement, JS n'est PAS un langage objet "classique" (type C++ / Java / C# / autre..), l'approche est différente. Beaucoup de gens voient le JS comme un langage objet avec une syntaxe dégueu pour les classes; alors que le concept de classes n’existe tout simplement pas.

A ce sujet, je recommande Io, un petit langage très épuré qui est idéal si on veut comprendre le mécanisme des prototypes. C'est Javascript sans l'océan d'accolades et la syntaxe verbeuse, sans les comportements bizarroïdes (égalité...) et avec des concepts de concurrence et d'asynchronisme très simples déjà intégrés (acteurs, futures, coroutines...)

[AoCannaille]

le JS est un langage simple (je le penses vraiment), mais uniquement a partir du moment ou l'on a chercher a le comprendre

La mécanique quantique c'est simple, mais uniquement à partir du moment ou l'on cherche à la comprendre

Ta phrase me rappelle celle là : "Il comprend vide mais il faut lui expliquer longtemps"

je comprends bien qu'il y a un paradigme majeur dans le javascript que peu de personnes exploitent. Mais pourquoi? Ne serai-ce pas justement parce que ce paradigme est moins naturel et plus alambiqué que les autres ?
Auquel cas ce n'est plus le JS qui est compliqué, mais son pradigme principal.

Concrètement ça change quoi vis-à-vis du développeur? Il y a toujours une marche relativement grosse à franchir pour ne pas faire du travail moisi en Javascript (ou VanillaJS si vous préférez )

[SylvainPV]

je comprends bien qu'il y a un paradigme majeur dans le javascript que peu de personnes exploitent. Mais pourquoi? Ne serai-ce pas justement parce que ce paradigme est moins naturel et plus alambiqué que les autres ?

J'ai appris la POO par prototype plusieurs années après avoir pratiqué la POO par classes, surtout en Java et C#. Si on se concentre sur les différences fondamentales, sans parler de syntaxe ou de fonctions avancées, je trouve la POO par prototype plus simple car les concepts d'instance et de classe sont regroupés en un seul et même concept, celui de l'objet (prototypé). Il paraît également plus "naturel" car expose un niveau d'abstraction inférieur à celui des classes (une classe seule ne sert à rien, on utilise les instances d'une classe, tandis qu'on peut toujours utiliser un objet prototypé sans se préoccuper de savoir s'il est le prototype d'autres objets ou pas)

Pourquoi son manque de popularité ? J'ai quelques hypothèses :
- le fait qu'il ne soit pas ou très rarement enseigné en école ou dans les cours en ligne, où la POO par classe est souvent le seul paradigme enseigné en matière de POO ; au point que pour beaucoup, POO = classes
- le fait qu'il soit sous-représenté dans les langages dominants (Java, C++, C#, PHP, Python, Ruby etc... utilisent tous des classes)
- le fait que son seul représentant vraiment populaire, JavaScript, a été détourné dans sa conception originelle pour mieux coller au "style Java" (on peut remercier Sun pour ça, qui au passage a changé le nom d'origine "LiveScript") ; les constructeurs, l'opérateur instanceof et les ""classes"" ES6 témoignent encore de cet état de fait
- 20 ans de POO par classes qui ont ancré de profondes habitudes chez les développeurs, avec des réflexes et des façons de penser qui ne peuvent pas s'appliquer directement avec des prototypes. Il faut réapprendre les bases et ce n'est pas facile, beaucoup ont essayé les prototypes mais ne parvenaient pas à sortir de leurs patterns classiques, ce qui se soldait par un échec et donc une mauvaise impression de la POO par prototype.

Dans tous les cas je pense qu'il faut aller plus loin que le raisonnement "si c'est pas connu, c'est que ça doit pas être bien". Plutôt que faire des assomptions, je vous encourage à apprendre et à expérimenter d'autres paradigmes, pour voir leurs avantages et inconvénients. Cela permet de prendre du recul sur son style de développement, et de s'améliorer en tant que développeur même sans changer de techno/langage.

[frfancha]

J'ai appris la POO par prototype plusieurs années après avoir pratiqué la POO par classes, surtout en Java et C#. Si on se concentre sur les différences fondamentales, sans parler de syntaxe ou de fonctions avancées, je trouve la POO par prototype plus simple car les concepts d'instance et de classe sont regroupés en un seul et même concept, celui de l'objet (prototypé). Il paraît également plus "naturel" car expose un niveau d'abstraction inférieur à celui des classes (une classe seule ne sert à rien, on utilise les instances d'une classe, tandis qu'on peut toujours utiliser un objet prototypé sans se préoccuper de savoir s'il est le prototype d'autres objets ou pas)

Pourquoi son manque de popularité ? J'ai quelques hypothèses :
- le fait qu'il ne soit pas ou très rarement enseigné en école ou dans les cours en ligne, où la POO par classe est souvent le seul paradigme enseigné en matière de POO ; au point que pour beaucoup, POO = classes
- le fait qu'il soit sous-représenté dans les langages dominants (Java, C++, C#, PHP, Python, Ruby etc... utilisent tous des classes)
- le fait que son seul représentant vraiment populaire, JavaScript, a été détourné dans sa conception originelle pour mieux coller au "style Java" (on peut remercier Sun pour ça, qui au passage a changé le nom d'origine "LiveScript") ; les constructeurs, l'opérateur instanceof et les ""classes"" ES6 témoignent encore de cet état de fait
- 20 ans de POO par classes qui ont ancré de profondes habitudes chez les développeurs, avec des réflexes et des façons de penser qui ne peuvent pas s'appliquer directement avec des prototypes. Il faut réapprendre les bases et ce n'est pas facile, beaucoup ont essayé les prototypes mais ne parvenaient pas à sortir de leurs patterns classiques, ce qui se soldait par un échec et donc une mauvaise impression de la POO par prototype.

Dans tous les cas je pense qu'il faut aller plus loin que le raisonnement "si c'est pas connu, c'est que ça doit pas être bien". Plutôt que faire des assomptions, je vous encourage à apprendre et à expérimenter d'autres paradigmes, pour voir leurs avantages et inconvénients. Cela permet de prendre du recul sur son style de développement, et de s'améliorer en tant que développeur même sans changer de techno/langage.

Merci pour ce post plein de sagesse

[Invité]

J'ai appris la POO par prototype plusieurs années après avoir pratiqué la POO par classes, surtout en Java et C#. Si on se concentre sur les différences fondamentales, sans parler de syntaxe ou de fonctions avancées, je trouve la POO par prototype plus simple car les concepts d'instance et de classe sont regroupés en un seul et même concept, celui de l'objet (prototypé). Il paraît également plus "naturel" car expose un niveau d'abstraction inférieur à celui des classes (une classe seule ne sert à rien, on utilise les instances d'une classe, tandis qu'on peut toujours utiliser un objet prototypé sans se préoccuper de savoir s'il est le prototype d'autres objets ou pas)

Pourquoi son manque de popularité ?
....

Dans tous les cas je pense qu'il faut aller plus loin que le raisonnement "si c'est pas connu, c'est que ça doit pas être bien". Plutôt que faire des assomptions, je vous encourage à apprendre et à expérimenter d'autres paradigmes, pour voir leurs avantages et inconvénients. Cela permet de prendre du recul sur son style de développement, et de s'améliorer en tant que développeur même sans changer de techno/langage.

Sur le fond, je suis d'accord avec toi mais quand même, tu déplores que la beauté intrinsèque du modèle objet de javascript n'est pas reconnue à sa juste valeur alors que javascript a percé principalement grâce à l'opportunité "web côté client". C'est quand même un peu l'hôpital qui se fout de la charité...

[frfancha]

Sur le fond, je suis d'accord avec toi mais quand même, tu déplores que la beauté intrinsèque du modèle objet de javascript n'est pas reconnu à sa juste valeur alors que javascript a percé principalement grâce à l'opportunité "web côté client". C'est quand même un peu l'hôpital qui se fout de la charité...

Je n'ai pas compris où se trouve la contradiction que tu sembles relever?

[Invité]

Je n'ai pas compris où se trouve la contradiction que tu sembles relever?

En d'autres termes : le langage est connu parce qu'on peut l'utiliser facilement mais mochement, mais c'est dommage qu'il soit utilisé mochement mais si on ne pouvait pas l'utiliser mochement il n'aurait peut-être pas été aussi connu.
Ce qui fait beaucoup de mais pour un mois de novembre...

[Invité]

Js sans le Framework AngularJs, c'est vraiment pas terrible.
Par contre AngularJs+NoSql , c'est l'avenir pour le web, car pour le REST, il n'y a pas besoin de créer des champs comme en base de données relationelle, tout se fait automatiquement .
Js ne devrait être utilisé qu'avec le framework AngularJs. JQuery ? On ne s'en sert plus quand on passe sous Angular.

Java ? J'ai téléchargé android studio, rien que lors de la première install, ça plante déjà avec des messages d'erreur incompréhensibles et ça rame à donf.
Php ? C'était cool au début des années 2000, mais ça c'était y'a 16 ans .... Du temps des ordinosaures. Quand à Java qui date de 1994, une renault Clio de l'époque est bien différente d'une clio de 2015, et les variables typées, c'est long à écrire et désagréable, mais j'aime bien quand même, surtout quand je vois des mecs vendre des apps compilées.. Je me demande comment ils font pour créer leurs apps, vu comme ça parait archaique et difficile avec Spring par exemple de ne créer ne serait-ce qu'un bouton, mais c'est peut être moi qui exagère.

Ne pas oublier que JSON veut dire Javascript object Notation, et que tous les autres langages sont en train de suivre comme des petits moutons pour dialoguer avec Json... Sauf que c'est orginellement du Javascript... Moi je préfère l'origine.

[Iradrille]

Par contre AngularJs+NoSql , c'est l'avenir pour le web

Le NoSQL pour tout et n'importe quoi c'est vraiment à la mode.
Quand c'est justifié c'est très bien; mais comme tout il y a des compromis à faire.

Très souvent une base relationnelle fera le job aussi bien, si ce n'est mieux qu'une base NoSQL.

Le pire argument que j'ai entendu pour NoSQL (mongoDB) était : "c'est trop bien, ya pas de schémas à faire : donc pas de migrations. Pas non plus de problèmes d'ordres d'insertion dans les tables : il suffit de dupliquer les données."

Ton post me laisse penser que tu es dans le même état d'esprit. Oui, c'est lourd / chiant de faire un schéma correct. Oui, les migrations c'est pas toujours simple.

Mais derrière une base relationnelle ("classique") apporte un grand nombre d'avantages dont les 2 principaux sont :
* la cohérence des données (respect d'un schéma / transactions) -> pas besoin de vérifier les données, si elle sont dans la base elles sont valides et sous le bon format (sinon l'insertion passe pas); toute la logique de vérification des données est liée à la base et non à l'application qui l'utilise.
Les transactions permettent de s'assurer que la base est toujours dans un état valide.
On récupère toujours un état à jour des données contrairement à la majorité des bases NoSQL qui préfèrent ne pas fournir cette garantie pour permettre un meilleur scaling. Hors cette garantie est souvent plus importante que le scaling.

* l'unicité des données (en cas de schéma normalisé) -> mise à jour des données plus simple; taille réduite.

A partir du moment où on peut définir un schéma et que le volume de données n'est pas immense une base relationnelle EST la meilleure solution.

[Invité]

Concernant le message de MoumouteMasters : je ne vois pas trop le rapport avec la tournure "POO façon javascript" qu'a pris la discussion mais j'imagine que c'est plutôt en rapport avec l'article initial.

[air-dex]

Le même argumentaire existe avec java (pour l'exemple) : « autant connaitre java, au pire on peut tout faire, les autres technos sont spécifiques ». Admettons, pour un débutant c'est effectivement intéressant d'avoir une boite à outils passe partout à valoriser pour ses premiers jobs (java, js, autre...). Mais on arrive souvent à être spécifique au domaine et donc à utiliser des technos « moins généralistes » (ce qui en fait est quasi tout le temps faux...).

C'est ce que je dis. Le JS est un outil passe-partout pour tout faire. Mais dès que tu es dans un domaine et que tu veux y faire des choses plus sérieuses, alors tu passes à quelque chose de plus spécifique et qui n'est pas JS.

Java est bien trouvé pour ton exemple. Il pourrait même être cité en exemple comme JS. Mais Java est désormais un paria pour le Web côté client, les bien-pensants du Web ne voulant plus de plugins Web, dont Java et ses appliquettes côté client.

Le même raisonnement sur le java (encore une fois j'ai rien contre le java) couplé à une demande de l'industrie a donné une recrudescence de l'enseignement du java très tôt dans les écoles/universités et parfois on voit des formations qui laissent tomber les autres langages. Les étudiants sortent sans avoir appris à penser hors de ce cadre. Conseiller à tout le monde de faire du js c'est du même niveau.

Je te rejoins sur le fait qu'il n'est pas sain de se limiter dans les langages appris et par conséquent dans les philosophies qui vont avec. Java a même des circonstances aggravantes avec sa philosophie du tout objet. Mais contrairement à Java, JS est plus ouvert sur les philosophies de programmation. Il en a plusieurs parmi lequel l'impératif (comme le C) et la POO par prototypes.

Ne pas oublier que JSON veut dire Javascript object Notation, et que tous les autres langages sont en train de suivre comme des petits moutons pour dialoguer avec Json... Sauf que c'est orginellement du Javascript... Moi je préfère l'origine.

Dans JSON il y a aussi "Notation". Le JSON permet surtout de noter des données, et ce de manière moins verbeuse et plus lisible que XML. C'est à mon avis plus indiqué que le XML si tu n'as pas de vérifications à faire sur tes données (à l'aide d'un DTD pour XML par exemple). Je m'arrête là avant de m'égarer dans un débat "XML vs. JSON (vs. YAML)" qui est ici hors sujet.