L'Ecma, l'organisme de normalisation de JavaScript adopte Dart, un comité mis sur pied pour définir les futurs standards du langage Web de Google

Membre chevronné

Le 27/02/2014 à 14:03

Envoyé par sekaijin

le boulot est le même. au détail près que je peux dynamiquement ajouter la dite méthode à un objet alors qu'il faut redéfinir la classe et réinstancier les objets pour faire la même chose.

Justement, à titre personnel, c'est la raison majeure qui me fait détester le Javascript.

Quand je développe une application, je réfléchis en amont à l'architecture de mon code : les différentes entités, comment chaque composant va interagir, les fonctionnalités que je dois implémenter, etc. De là, et de là seulement, je serai en mesure d'écrire mon application. Ce n'est que très rarement que j'aurai besoin de modifier mon architecture. Avec du prototypage, toute cette réflexion en amont peut être réduite à néant car n'importe quoi peut s'amuser à redéfinir le comportement d'une méthode.

Pour la petite histoire, dans le cadre d'un ancien travail, j'avais réussi à détourner une IHM Siebel pour mon usage (automatisation de la saisie d'informations) en redéfinissant une fonction Javascript, juste en utilisant IE7... Je pouvais même modifier des valeurs en lecture seule !

6

2

Lutarez

Membre chevronné

Le 13/12/2013 à 17:18

Que Dart remplace ou non JS, cela n'a en réalité aucune importance. Ce qui est vraiment important, c'est d'apporter de nouvelles possibilités de développements web, avec des paradigmes différents, afin que chacun puisse adopter l'approche du développement web qu'il désire.

Je serai au ange quand ils nous trouveront également un nouveau "langage" pour concurrencer le HTML dans certains types d'applications (ex : webapp, outils internes, etc)

3

0

sekaijin

Expert éminent

Le 14/12/2013 à 19:37

@ phili_b
Dart a ete principalement créé pour faires application pas des site Web

quant au MVC je ne vois pas le problème lorsque tu compile ton appli c++ tu as bien un exe alors que tu utilise MCV pourquoi un compilateur JS ou Dart ne pourrait-il pas faire de même.

@SylvainPV
Je maintiens que lorsqu'on fait une application on ne regarde pas le code binaire généré pour tracer une ligne lorsu'on fait un menu, une fenêtre, un panel, une grid. pourquoi devrions nous systématiquement revenir au niveau des couche basse dans les appli web ?
Je suis d'accord qu'il faut se méfier de certaine lib UI qui on tendence à surcharger le DOM.
A+JYT

3

0

anthyme

Membre éprouvé

Le 27/02/2014 à 14:44

Envoyé par sekaijin

Entre Dart et TypeScript ? Quelle approche vous semble la meilleure pour combler les faiblesses de JavaScript ?
ni l'un ni l'autre

pour moi vouloir ajouter des cntrainetes fortes sur le typage n'est pas meilleur ou moins bon que le type dynamique de javascript.
je ne vois pas en quoi une classe est plus pertinant qu'un prototype.

Code javascript :

Sélectionner tout

1
2
3
4
5
6
7
foreach(Object element in myCollection) { 
  if (element instanceOf MyClass) { 
     console.log(((MyClass)element).myMethod()); 
  } else { 
     console.log("methode non supportée : " + element.toString() ) 
  } 
}

Code javascript :

Sélectionner tout

1
2
3
4
5
6
7
foreach(element in myCollection) { 
  if (element.myMethod && "function" == typeof element.myMethod) { 
     console.log(element.myMethod()); 
  } else { 
     console.log("methode non supportée : " + element); 
  } 
}

Ton exemple n'est pas bon, justement dans un langage typé avec une architecture correct on nfait pas de test d'instanceOf.
On sait partout où l'on est le type des éléments et on peut donc appeler la méthode car le compilateur nous a assuré qu'on pouvait le faire

Pour ma part je pense que typescript est plus efficace aujourd'hui pour son approche minimaliste et sa compatibilité absolue avec toutes les libs existantes. C'est le gros défaut de dart, quand il serra largement supporté et que les libs seront distribuées tant en js qu'en dart cela sera un choix du même niveau.

Il ne faut pas oublier l'objectif de typescript, être un langage "futur" du javascript, en gros on code en typescript comme on pourrait coder en ecmascript6, une fois l'ecmascript 6 arrivé on garde un code très proche.

3

0

Electron56

Membre à l'essai

Le 10/04/2014 à 17:36

Maintenant un mois que j'ai migré mon projet en dart côté serveur et dartangular côté client.

Un vrai bonheur, les possibilités qu'ils proposent donnent un confort de conception que j'ai rarement pu avoir dans pas mal de technologies. Ce que j'aurais fait en un mois auparavant je le fais maintenant en une semaine. Cela reste bien sûr un outil et le développeur fait la différence mais je ne regrette pas mon choix du tout et j'ai hâte de tester cette 1.3 ce soir.

3

0

conscofd

Nouveau membre du Club

Le 13/12/2013 à 19:01

Comme je ne savais jamais comment amorcer quelque chose en Js, j'ai adopté Dart parce qu'il avait tout simplement un main()...

2

0

sekaijin

Expert éminent

Le 14/12/2013 à 13:11

Envoyé par LSMetag

Pas bête. Mais il faut avoir une idée alors de l'interprétation par la transcription html des fameux composants serveurs.
Sans oublier que ce sera interprété niveau serveur en plus de chez le client. Si le serveur est un monstre pourquoi pas... Sinon, pas trop mon truc.

Heu QUOI QUOI

lorsque tu fais new Menu en C++ tu dois savoir ce que ça va faire en terme de dessin ??? Je n'ai absolument aucune idée de ce que fais exactement ExtJS lorsque je fais new Menu ce que je sais c'est que ça affiche un menu déroulant à l'endroit que j'ai choisi et qui réagit comme je m'y attends exactement ce que je constate sous Windows avec C++

quant au serveur je ne vois absolument pas ce qui vient faire là vu que c'est le client qui exécute le code. on pourrait penser que du coup le code côté client est lourd il n'en est rien en fait c'est même le contraire. lorsqu'on produit du HTML et qu'on veut lui attacher du js ont doit produire un code HTML qui génère un DOM puis du JS qui explore ce DOM et ensuite les fonctionnalité JS qu'on veut lui adjoindre. alors que la on instancie un objet JS qui va Produire le DOM donc plus de HTML et qu en plus va lui attacher les comportement attendu. pas besoin d'explorer le DOM vu que lorsqu'on produit un élément on lui attache tout ce dont il a besoin.
au final on a un code simple concis efficace et facile à maintenir dans un seul langage. exactement ce qu'on a si on développe un client lourd en C++ sous windows. avec en plus la portabilité de l'application et le déploiement à la volée. ce que je constate c'est que mes échange avec le serveur diminue. entre la moitié et un tier pour l'IHM de l'appli que les échanges pour les données sont réduit à de simples données JSON et que la charge serveur baisse d'environs à 60% à 70% par rapport à une web app traditionnelle (30% à 40% de gain).

A+JYT

2

0

Lutarez

Membre chevronné

Le 17/12/2013 à 10:50

Envoyé par Kaamo

La vrai question c'est : Pourquoi aller vers une VM Dart (JavaScript killer/challenger) alors qu'on pourrait améliorer JavaScript ?

Pourquoi avoir inventer le C et C++ alors que le Pascal ou SmallTalk existaient déjà ? L'évolution en informatique ne se fait pas que par mise à jour des technologies, mais aussi par la naissance de nouvelles.

Il suffit de faire quelques recherches sur internet pour se rendre compte que JS est loin de donner satisfaction à beaucoup de développeurs. L'évolution du JS continue en parallèle de toute façon. Dart réponds par ailleurs a un besoin différent de JS, vu qu'il se destine au web apps.

Bref, c'est pas parcequ'un nouveau langage apparaît que JS va disparaitre. Cela permettra simplement d'ouvrir davantage le développement web en offrant plus de solutions. A chacun ensuite de choisir les technologies qui conviennent mieux.

2

0

DonQuiche

Expert confirmé

Le 27/02/2014 à 19:54

Envoyé par sekaijin

je ne suis pas d'accord les languages supprotant l'héritage multiples sont pas légions. et lorsque tu a des objets qui sont issue de lib ou framwork tu ne peux pas les mettre dans une même collection typé c'est ainsi qu'on voit des List<Object> et autre truc car la seul classe commune est alors Object.

Je trouve en général tes avis sur les technos web très intéressants mais concernant les langages typés il est clair que tu es à côté de la plaque. Des List<Object> je n'en rencontre jamais parce qu'on n'a pas besoin de listes d'objets hétérogènes, ou alors très rarement. Et si vraiment tu as besoin de faire ça (une fois tous les cinq ans), alors le motif "adaptateur" est là pour ça.

Les seules fois où le typage statique me met inutilement des bâtons dans les roues, c'est relatif aux types paramétrés. Et encore c'est parce que je fais beaucoup de C# et que les types paramétrés y sont rudimentaires.

je ne comptes pas le nombre de CastException que je vois passé sur le SI dans des produit à plusiers centaine de milliers d'euros lorsque ce n'est pas des nombres à plus de 6 chiffre.

Là aussi je n'en rencontre jamais alors peut-être l'application a t-elle justement été conçue par quelqu'un qui, comme toi, est davantage familier des typages dynamiques et en adopte les façons de faire.
Par ailleurs s'il y a erreur sur le type de donnes attendu, mieux vaut que ça te bondisse tout de suite à la tronche avec une exception que de voir le truc accepté en douce pour créer un bug tris kilomètres plus loin.

une réalié au quotidient pas le choix la seule classe qui est capable de servir de base commune c'est Object.
certaines des lib fournissent la méthode dont j'ai bessoin d'autre pas. les classe sont final impossible de les dérivers. impossible même si on pouvait des dériver de faire en sorte que la lib produise des objets dérivés elle n'est pas là pour ça. impossible donc d'avoir un moyen d'être sur d'avoir la même méthode partout.
impossible de faire un traitement simple en parcourant les objet et en appliquant sur chacun une methode. du coup on caste on fait de s méthode utilitaire etc.
on pisse du code.

Apparemment tu parles d'un cas particulier et je te garantis qu'il est très particulier. Encore une fois peut-être auriez-vous mieux fait de faire un simple adaptateur au début.

Pourquoi tant de language lève les contrainte de classes ? pourquoi tant de language joue avec des mécanisme d'introspection ? pourquoi voit-on fleurir les injection de byteCode ?

Quoi, les besoins de métaprogrammation n'existent pas avec les langages dynamiques ? Si tu souhaites logger tous les appels pour les besoins du débogage, tu y penses très fort et ça se produit, ou alors tu mets en place une plomberie qui va modifier tes instances à la volée ?

Parfoit les classes bien rigides sont des contraintes trop fortes.
Je n'ai pas dit toujours, j'ai dit parfois.

Tout à fait. Et l'absence de contraintes n'est pas toujours une bonne chose non plus.

Par contre plus le projet est gros, plus le typage statique est utile. C'est à ce besoin que répond TypeScript.

et lors on est confromté quotidiennement à ce genre de difficultés où on fini par pondre des centaines de lignes pour 1 appel de méthode ont change de méthode de travail et on prends des outils qui ont d'autres avantages pour d'autres usages avec des façons de travailler différents.

Je pense vraiment que vous avec un très gros problème d'architecture.

biensur les nom des champs ne sont pas homogènes c'est donc des centaines de lignes à écrire. alors qu'avec un langage plus souple comme js une boucle sur tous les membres de l'objet une map qui traduit le nom du champ une autre les valeur et

Code :

Sélectionner tout

out[translateNom[membre] = translate[origValue]

en 3 ligne et une table de paramètre c'est fini pour toute les classes.
efficacité des classes 30 x 100 lignes de code java face à 3 lignes de js.

Autrement dit en JS vous implémentez un pseudo-adaptateur, alors qu'en Java vous gérez tous les cas manuellement à chaque fois. A nouveau pourquoi ne pas avoir mis en oeuvre ce motif ?

2

0

javan00b

Membre actif

Le 28/02/2014 à 1:54

Si tu veux developper en Javascript sans que sa coûte une fortune il te faut un gros stack d'une dizaine de librairie.

Ya vraiment quelqu'un qui fait des gros projets scalable en vanilla javascript de nos jours avec un budget limité ?

Faut etre serieux Dart c'est aussi bien structuré que Java, le temps de développement et la complexité sont reduit de beaucoup. C'est beaucoup mieux structuré que javascript et beaucoup + lisible pour n'importe quel programmeur qui fait de la POO sur un language qui n'a pas été architecturé en 10 jours !

C'est une question de temps, quand les gens vont s'en rendre compte et que Dart aura pris en maturité... On risque de voir beaucoup + de gens l'utiliser.

2

0

Identifiez-vous

Créer un compte

L'Ecma, l'organisme de normalisation de JavaScript adopte Dart,

Un comité mis sur pied pour définir les futurs standards du langage Web de Google

Identifiant
Mot de passe

Mot de passe oublié ?

Identifiez-vous

Créer un compte

L'Ecma, l'organisme de normalisation de JavaScript adopte Dart, Un comité mis sur pied pour définir les futurs standards du langage Web de Google

L'Ecma, l'organisme de normalisation de JavaScript adopte Dart,

Un comité mis sur pied pour définir les futurs standards du langage Web de Google