Discussion :

[la.lune]

sentiment personnel, tant pis...

La question n'est pas question de sentiment, mais il ne faut pas qu'on v�hicule de fausses informations. Il ne faut pas oublier qu'avec le typage dynamique c'est le d�veloppeur qui souffre dans certains cas avec le typage dynamique encore faiblement, c'est cette souffrance qu'on veut �viter, on aime tous les facilit� et les bonnes syntaxes, et la bonne structure du code.

Il ne faut pas qu'en d�veloppant mon jeu je connais tous les caract�ristiques de mes objets, alors je dois passer par quelque chose de dynamique apr�s je vais me mordre les doigt apr�s en cas de bug.

Nous on veut le choix en javascript c'est �a mon objectif.

[sekaijin]

Bonjour,

Je viens de lire attentivement tes interventions.

Je suis enti�rement d'accord avec toi "nous devons avoir le choix"
HTML permet d'embarquer des scripts et il est possible d'utiliser d'autres langages que JavaScript
En 1996 j'embarquais du TCL et IE permettait d'utiliser VBS.

Mais, je ne suis pas d'accord lorsque certains dissent qu�il faut supprimer les prototypes et le typage dynamique de JS et le remplacer par des classes et du typage Satique.

EcmaScript n'est pas utilis� que dans le WEB et je ne suis pas toujours tr�s content de la fa�on don EcmaScript est int�gr� au navigateur la Partie W3C de JS est pour moi plus probl�matique que le langage.

Lorsqu�on utilise EcmaScript dans d'autres contextes que le Web, sa capacit� � faire �voluer ces objets est pertinente efficace.

Je sais que cela � un co�t et je suis le premier � dire qu'il faut utiliser la mod�lisation statique lorsque cela est pertinent.

Je pense qu'effectivement tout comme par le pass� avec le shellScript on est arriv� � des usages dans le navigateur qui ne sont plus dans le scope de d�part. Il ne s'agit plus d'�crire un petit script pour g�rer un �v�nement. Aujourd'hui on �crit de v�ritable application quasi 100% JS et l� le mod�le de programmation propos� n'est peut �tre la le meilleur.

Pour faire des IHM, la mod�lisation par classes a fait ses preuves.

Je suis personnellement confront� � la situation inverse tous les jours.
J'ai des dev fait en JAVA dans lequel je manipule des "objets" tr�s mouvants aux contours flous.

Pour y parvenir, j'ai fini par utiliser des HashMap. Du coup tous mes "objets" sont des HashMap. � quoi peut me servir le typage statique ? Je ne peux pas utiliser le polymorphisme Java puisque ce sont tous des HashMap
Je dois donc faire ce qui est le pire en java des if et switch pour d�terminer quelle m�thode statique d'un objet statique utiliser sur ma HashMap, id�alement il me faudrait pouvoir associer � ma HashMap un objet qui poss�de toutes les m�thodes le concernant. Mais ayant quelques centaines de m�thodes il me faudrait alors pr�voir toutes les combinaisons possibles. N'ayant pas connaissance avant l'ex�cution du contenu de ces "objets" je ne peux pas faire des classes pour chaque "type d'objet" que je re�ois.
Au final sur cette partie je fais du dev proc�dural en Java.

Avec Nashorn (Js dans Java8), j'ai le meilleur des deux mondes. Pour cette partie particuli�rement peu typ�e, JS est une force. Pour tout le reste les classes java font des merveilles.
Malheureusement Java8 n'est pas encore une cible pour la mise en production. Mais tous mes tests montrent qu�utiliser JS pour cette partie donne un code simple, robuste, adaptable, maintenable, �volutif, et concis.
Tout le contraire des mots que je lis dans les critiques de JavaScript. Et le code JS �tant dans le Jar Java il n'est pas modifiable par l'utilisateur donc je n'ai pas de Pb de s�curit� plus important qu'avec le reste de l'appli.

J'aimerais dans le monde web voir apparaitre plusieurs choses.
D'autres langages support�s en standard dans le navigateur pour cibler les nouveaux usages.
J'aimerais aussi pouvoir envoyer au navigateur un "lanceur d'app". Un mime type qui dirait au navigateur charge ce JS (ou un autre langage) et ex�cute-le. Je trouve tr�s con de faire une page HTML comme

Code html :

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

<html<head><script src="myapp.js"></script></head></html>

j'aimerais bien pouvoir dire au navigateur charge myapp.js et ex�cute-la. Je n'ai jamais de code HTML dans mes applis.

A+JYT

[danielhagnoul]

Bonsoir

J'ai trouv� une opinion int�ressante, malheureusement en anglais, sur l'inflation des "frameworks" et le devenir du JS

En bref (ce n'est pas une traduction du texte, juste un reflet, les opinions auxquelles j'adh�re de plus en plus) :

Oublions les m�saventures provoqu�es par les navigateurs obsol�tes et mettons � la poubelle les rustines d�velopp�es pour pallier leurs insuffisances.

En 2014, avec l'�volution des codes (HTML5, CSS3, JS ES6) et l'�volution des navigateurs dignes de ce nom, il est devenu plus int�ressant d'utiliser le JS que de s'enfermer dans le carcan d'un "framework" aussi bon soit-il.

Il faut bien distinguer une "library" (code effectuant une t�che pr�cise), qui sera toujours utile, d'un "framework" qui vous impose une mani�re de penser donc de coder.

Idem pour l'UI, les nouveaux standards permettent la cr�ation d'�l�ments r�utilisables (Web Components). Pour l'instant plusieurs techniques n�cessitent encore l'usage de "polyfils".

Quelques liens utiles :

• Object.observe
• Promises
• HTML Imports
• HTML Templates
• Custom Elements
• Shadow DOM

• Polymer
• X-Tag
• Bosonic

• Brick Download
• X-Tag Download

[SylvainPV]

Ce n'est pas qu'une question de richesse et de puissance du langage / de l'outil. Les frameworks servent surtout � fixer un cadre. Si on s'engage � suivre rigoureusement la m�thode impos�e par un framework, on �vite en th�orie plusieurs erreurs de parcours classiques. C'est aussi une mani�re d'homog�n�iser la fa�on de coder au sein d'une �quipe. Par exemple, EcmaScript 6 apporte la notation des classes. Entre class, l'op�rateur new et Object.create, �a fait trois fa�ons diff�rentes de faire la prog objet. Si on ne se fixe pas une ligne de conduite, �a peut vite devenir un sacr� bazar.

Une citation que j'ai lu je ne sais plus o� :

Les frameworks, c'est comme les pistes de skis. C'est moins fun que le hors-pistes, mais t'as plus de chances d'en sortir indemne.

[Kaamo]

Je connaissais pas Bosonic, �a a l'air cool ! Des retours ?

[Spartacusply]

Il faut bien distinguer une "library" (code effectuant une t�che pr�cise), qui sera toujours utile, d'un "framework" qui vous impose une mani�re de penser donc de coder.

Pourtant c�t� serveur, les contraintes impos�s par l'utilisation d'un framework sont a priori les m�mes et pourtant ceux-ci se sont clairement fait une place et font maintenant partie int�grante du bagage de tout "d�veloppeur web". Leurs avantages ne sont plus � prouver, le principal �tant de se concentrer sur les points sp�cifiques de notre projet plut�t que s'acharner � r��crire des fonctions r�currentes � tout d�veloppement, et dans bien des cas (il reste des cas sp�cifiques ou leur utilisation ne s'impose pas bien entendu), ceux-ci sont clairement profitables aux d�veloppeurs malgr� les inconv�nients qu'ils engendrent -car il y en a aussi bien s�r-.

Alors bien que les langages utilis�s soient diff�rent, pourquoi en serait-il diff�remment c�t� client ?

[legeek11202]

Le nombre de library existent sur le web est �norme, d�ailleurs elle repr�sente la plus grande partie de l'utilisation de Github :o (13.98% sur 144 langages)
Et c'est vrai aussi que de plus en plus de personnes ce dise d�veloppeur JS alors qu'ils importent des biblioth�ques et tape une ligne de code.

Serte les biblioth�ques sont bien dans le sens de la rapidit� d'installation et d'utilisation mais tr�s peut de gens vont voir ce qu'il se passe derri�re.

L'�crire soit m�me s'est mieux � mon gout.

[Paleo]

Je pose la question au sujet de TypeScript car il est commandit� par un acteur majeur de l'informatique et risque de s'imposer dans les normes futures du Javascript (je suppose donc que cette question correspond au sujet)

Le Javascript est tr�s complet et me satisfait parfaitement. Le javascript est un langage qui poss�de des propri�t�s tr�s int�ressantes.
Notamment l'absence de typage, qui n'est peut-�tre pas un oubli, mais la volont� de proposer un autre format de programmation que celui qui �tait r�pandu dans les ann�es 80.

Bonjour, quelques arguments en faveur de TypeScript :

* Le langage TS est un sur-ensemble de EcmaScript 5. Cela signifie que n'importe quel code ES5 est valide en TS. Les lib jQuery et autres sont alors utilisables (contrairement � Dart). Le temps d'apprentissage est r�duit.
* Le compilateur TS produit du code JS propre et ind�pendant (contrairement � Traceur qui g�n�re un code JS d�pendant d'un runtime). Dans le pire des cas, s'il fallait quitter la technologie, le code JS produit par TS serait une base de travail convenable.
* � part le typage qui est une innovation de TS, les autres �l�ments du langages sont des impl�mentations du brouillon de ES6 (voir un r�sum� ici). Il s'agit des classes, des modules (espaces de nommage), des param�tres par d�faut et de l'op�rateur "fl�che". Cela implique que le compilateur TS est destin� � �tre simplifi� et ne prendre en compte que le typage.
* Concernant le typage : il apporte un confort non n�gligeable dans l'assistance fournie par les IDE. Le m�canisme des interfaces/impl�mentations dans TS est plus souple que dans les langages typ�s classiques et s'int�gre bien dans la mani�re de penser JS. C'est � mon sens un apport consid�rable.
* TS ajoute aussi la notion d'accessibilit� dans les classes : les membres peuvent �tre d�clar�s priv�s.
* La technologie est open-source et utilisable en dehors des autres produits Microsoft (comme ce n'est pas dans les habitudes de Microsoft, mieux vaut v�rifier).

Utilisez le Playground pour tester. Je sugg�re d'y coller par exemple ce code :

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
interface HelloWorld {
	sayHello();
}
 
class MyFirstClass implements HelloWorld {
    constructor(private name: string = 'World') {
    }
    public sayHello() {
        return "Hello, " + this.name + '!';
    }
}
 
function test(obj: HelloWorld) {
	obj.sayHello();
}
 
var obj = new MyFirstClass('John');
test(obj);

Supprimez �ventuellement la d�claration "implements HelloWorld" : elle est optionnelle.

Le code dynamique est toujours possible. Par exemple ajoutez ceci qui compilera sans probl�me :

Code :

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

1
2
3
obj['otherMethod'] = function () {
	alert('Other');
};

[Invit�]

Bonjour, je ne suis qu'un enfant par rapports aux autres dev JS, n�anmoins, pour moi, Js est le futur. Je trouve Java assez aust�re, en JS, c'est super ludique. Quand au concept de ne pas re-faire la roue, il est pouss� au max avec
1. Jquery
2. Tous les plugs-ins existant.


Mon trip: Ce serait de faire dialoguer JS avec d'autres langages (JAva, C++) pour de la robotique, et en fait tout piloter � partir de JS.

Toute la bureautique peut �tre faite sur JS et les derniers navigateurs. Je ne vois pas l'int�r�t de passer sur des langages plus "perfectionn�s" pour faire de la bureautique.

J'ai pas encore fait d'h�ritage par contre, le mot "extends "manque beaucoup !

Par contre, r�aliser une constructeur en JS est super simple ! J'adore �a !

Quand � JSON, c'est un format EXCELLENT et tr�s accessible ! Bref? pour moi JS c'est l'avenir, et les autres langages ont du soucis � se faire...

[SylvainPV]

Je pense que C et C++ n'ont pas trop de soucis � se faire

Il y a des centaines de langages de programmation, avec leurs points faibles et points forts. J'adore le JS mais j'ai bien conscience de ses nombreux points faibles. Qualitativement, les nouveaux langages comme Swift ou Dart sont meilleurs. C'est normal, ils ont �t� con�us pour palier aux d�fauts des pr�c�dents. Mais ce n'est pas forc�ment la qualit� qui d�termine l'adoption d'un langage. Un tr�s bon langage peut tr�s vite tomber dans l'oubli si les plates-formes et l'outillage ne suit pas

[yahiko]

Dans les syst�mes embarqu�s o� la fiabilit� du code est indispensable, je ne pense pas qu'un langage comme JavaScript ait la moindre chance de percer.

[Paleo]

J'ai pas encore fait d'h�ritage par contre, le mot "extends "manque beaucoup !

La plupart du temps, l'h�ritage est une mauvaise pratique, �a ne fait pas de mal de s'en passer. Les interfaces et impl�mentations sont bien plus �l�gantes.

[SylvainPV]

Et l'h�ritage d'interfaces ?

Je ne pense pas que proclamer que tel concept est une mauvaise pratique soit vraiment tr�s constructif, tout d�pend de comment il est concr�tis� et � quelle situation on fait face. On peut trouver des cas qui se pr�tent mal � l'h�ritage, et d'autres qui se pr�tent mal aux interfaces. On devrait plut�t se f�liciter d'avoir un langage tr�s flexible qui peut jongler facilement entre ces paradigmes, en tout cas plus facilement qu'avec d'autres technos *kof kof* JEE *kof*

Concernant l'h�ritage, c'est faisable en JS mais c'est clair que la syntaxe est p�nible avec cette salet� d'op�rateur new. Heureusement, l'avantage quand une syntaxe ne nous pla�t pas est qu'on peut construire quelque-chose de plus plaisant autour. Et puis il y a le mot-cl� extends qui d�barque avec les classes ES2015 d'ici la fin de l'ann�e, m�me si selon moi c'est faire un autre trou dans le mur plut�t que de r�parer la porte.

[yahiko]

On devrait plut�t se f�liciter d'avoir un langage tr�s flexible qui peut jongler facilement entre ces paradigmes, en tout cas plus facilement qu'avec d'autres technos [SIZE=1]*kof kof* JEE *kof*

Esp�rons que des Java�stes ne passent pas dans le coin
Ils sont encore nombreux les bougres !

[Paleo]

Sur l'h�ritage de classes, c'�tait un avis � propos de la POO en g�n�ral et pas sp�cialement pour JavaScript.

L'h�ritage est souvent utilis� comme une technique de r�utilisation du code. Et c'est mal. L'h�ritage devrait s'en tenir � sa d�finition en UML : une sp�cialisation sur un plan fonctionnel. C'est-�-dire que la raison de l'h�ritage doit se trouver dans le sens que les objets ont et non pas dans des fonctionnalit�s en commun. Pour r�utiliser, la mani�re propre est la d�l�gation. Or les programmeurs en POO font massivement usage de l'h�ritage en tant que m�canisme de r�utilisation.

Pourquoi cette forme de r�utilisation est mauvaise ? Car l'h�ritage casse le principe d'encapsulation. Dans la pratique, une modification dans le code de la classe m�re ou dans celui de la classe enfant n�cessite que le d�veloppeur soit conscient de l'impl�mentation interne des deux classes sous peine d'effets de bord.

Il reste la sp�cialisation, et celle-ci est un cas rare en programmation. Dans mon exp�rience, dans un programme constitu� d'une centaine de classes, on peut trouver peut-�tre cinq cas o� la sp�cialisation a du sens. Or les langages incitent au contraire � un h�ritage tout azimut. Par exemple en Java les classes et les m�thodes devraient �tre "final" (h�ritage interdit) par d�faut, et c'est le contraire : si on ne pr�cise rien, tout est h�ritable. Par exemple l'accesseur "protected" devrait �tre utilis� avec parcimonie, et l'�quipe de TypeScript s'est d�p�ch�e de l'impl�menter � cause de la forte demande de la communaut�. Sans parler du mot-cl� "extends" qui signifie le contraire de "sp�cialiser" !

L'h�ritage des interfaces : il est en pratique utilis� � bon escient. Une interface est un contrat. Il faudrait vraiment �tre paresseux pour vouloir h�riter juste dans le but de r�utiliser des d�finitions. Et puis �a a des cons�quences : par exemple vous voulez h�riter quatre m�thodes d'une interface m�re, mais la cinqui�me m�thode de l'interface m�re, celle dont vous n'avez pas besoin, il faudra bien ensuite que la classe l'impl�mente pour rien, et, heureusement, m�me les d�veloppeurs les moins �l�gants r�pugnent � cela. Donc dans la pratique, l'�cueil de l'h�ritage pour r�utilisation est mieux �vit�.


Sinon je trouve ObjectModel int�ressant. Une mani�re de faire des v�rifications de types en dynamique.

[SylvainPV]

"c'est mal". Cela illustre bien l� o� je veux en venir, le bien et le mal sont des concepts absolus or rien n'est absolu, tout est relatif. L'h�ritage casse le principe d'encapsulation certes, mais la d�l�gation casse le principe de substitution, alias polymorphisme. Quel principe serait plus important qu'un autre en toutes circonstances ? De mani�re absolue, il n'y a pas de paradigme sup�rieur aux autres. Tout d�pend de la situation rencontr�e. M�me si �a ne concerne que 5% des classes d'un projet, il y aura quand m�me 5% de cas o� l'h�ritage, "c'est bien".

Apr�s je suis d'accord pour dire qu'on bourre le cr�ne des �tudiants avec de l'h�ritage � cinq niveaux de profondeur, avec les profs qui se creusent la cervelle pour trouver des exemples pertinents quand ils savent pertinemment qu'un cas similaire ne se retrouvera probablement jamais sur un vrai projet. Mais bon, si chacun pr�che pour sa paroisse, on est pas sortis de l'auberge !

[Paleo]

[�] mais la d�l�gation casse le principe de substitution, alias polymorphisme.

Dans un contexte d'h�ritage de classes, le principe de substitution n'a de sens qu'avec une sp�cialisation. On a un type g�n�ral, puis un sous-type (plus sp�cialis�) qui peut se faire passer pour le type g�n�ral :

More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping,

Mais d�s qu'un langage le propose, la mani�re habituelle et �l�gante de faire de la substitution, c'est le m�canisme d'impl�mentation des interfaces.
H� oui.
TypeScript wins! :p

[Spartacusply]

Quand on d�veloppe avec le mod�le MVC, on a bien souvent un contr�leur p�re (pourquoi pas abstrait m�me si on veut), avec des contr�leurs fils qui seront chacun une s�paration de grandes fonctionnalit�s du projet (en gros).

J'ai donc une question : est-ce un bon cas d'utilisation de l'h�ritage ? Si oui, bon ben l'utilisation de l'h�ritage c'est quand m�me vachement utile (parce que du coup �a s'applique aussi aux vues et aux mod�les) et du coup je pense que c'est plus de 5% des cas, si non, j'aimerai bien qu'on m'explique pourquoi parce que je vois pas ce qui n'est pas bien

[Paleo]

Euh, "MVC" dans quel sens ? AngularJS ?
Angular g�n�re un h�ritage de scopes/contr�leurs, c'est d'ailleurs un point qui pose probl�me parce qu'il n'est pas intuitif. Mais pour s�parer diff�rentes parties de l'interface, les directives paraissent indiqu�es, non ?

Les frameworks incitent � l'h�ritage, pas toujours � bon escient. Certes il vaut mieux programmer de la mani�re pr�vue par les concepteurs du framework, mais �a ne prouve rien.

[SylvainPV]

la mani�re habituelle et �l�gante

habituel et �l�gant sont deux crit�res totalement subjectifs