IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Dart 1.2 améliore l'expérience du développeur
Google publie une nouvelle itération de son alternatif à JavaScript

Le , par Hinault Romaric
167 commentaires

372PARTAGES

0  1 
À la suite de Microsoft qui a publié la Release Candidate de TypeScript 1.0, Google a dévoilé une nouvelle itération de son langage Dart.

TypeScript et Dart ont en commun de vouloir corriger les faiblesses de JavaScript. Alors que TypeScript est une sorte de « super JavaScript » entièrement compatible avec celui-ci, Dart est un langage alternatif proposé par Google, avec pour objectif inavoué la mise à la retraite du langage de Script.

La nouvelle version du langage de programmation structuré pour le Web rend plus facile le débogage des applications. Les points d’arrêt peuvent maintenant être fixés sur des affectations de variables locales. Le débogueur a été optimisé et élimine certains effets secondaires liés à son utilisation.

La bibliothèque de base de Dart continue à évoluer, avec un accent sur les performances. Le débit du module WebSocket a augmenté d’un facteur de quinze depuis la version 1.0. La vitesse des primitives asynchrones de base a également été améliorée de 10 %.


L’environnement de développement Dart Editor introduit un meilleur support d’Angular (navigation, recherche et ré-factorisation). Dart 1.2 apporte également des correctifs de bugs, des améliorations de performances et des améliorations pour la machine virtuelle Dart, le compilateur, les bibliothèques et les outils.

Dart a été adopté en décembre dernier par l’Ecma, qui a mis sur pied un comité pour superviser la création d’une norme pour le langage, afin de favoriser son adoption par l’industrie, notamment les éditeurs de navigateur.

Télécharger Dart v1.2

Source : Notes de version

Et vous ?

Entre Dart et TypeScript ? Quelle approche vous semble la meilleure pour combler les faiblesses de JavaScript ?

Une erreur dans cette actualité ? Signalez-nous-la !

167 commentaires
Commenter Signaler un problème
Lutarez
Avatar de Lutarez
Membre chevronné https://www.developpez.com
Le 27/02/2014 à 14:03
Citation Envoyé par sekaijin Voir le message
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 
anthyme
Avatar de anthyme
Membre éprouvé https://www.developpez.com
Le 27/02/2014 à 14:44
Citation Envoyé par sekaijin  Voir le message
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
Avatar de Electron56
Membre à l'essai https://www.developpez.com
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 
DonQuiche
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 27/02/2014 à 19:54
Citation Envoyé par sekaijin Voir le message
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
Avatar de javan00b
Membre actif https://www.developpez.com
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 
tomlev
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 27/03/2015 à 16:11
Citation Envoyé par Hinault Romaric Voir le message
Tiens, j'ai l'impression d'avoir déjà vu ça quelque part... ça ressemble étrangement à ce que propose C# 5
2  0 
Vlozer
Avatar de Vlozer
Membre habitué https://www.developpez.com
Le 27/02/2014 à 23:55
Personnellement après avoir essayé les deux, je porte beaucoup plus d'espoir en dart qu'en TypeScript, meme si dans l'immediat, j'espere que l'un ou l'autre prendra le dessus sur le js brut...

Je ne connais pas le javascript... En tout cas tout juste assez pour faire le cake sur des page web avec JQuery, mais j'ai énormément de mal a apprécier ce langage... Ok, à chaque fois que j'ai eu à l'utiliser, j'ai souvent été surpris de élégances de certaines de ses syntaxes, mais le constat et là: si je n'ai aucun problèmes pour lire du javascript, je dois sans arrêt plus ou moins "réapprendre le langage" pour en ecrire... La faute selon moi à un certain manque de rigueur/ une trop forte flexibilité dans l'ecriture (et je dis pas ça forcement pour le typage dynamique, les signature de fonction à rallonge ou encore les fonctions anonymes imbriquées sans fin)...

Pour tout dire, je n'ai pas eu la chance d'avoir pu suivre les étapes de l'evolutions du js, pourtant, j'ai l'impression de subir le poids de son age à chaque utilisation...
Et cela dès l'apprentissage... Je me souviens qu'il y a encore quelque années, on nous donnait un alert('Hello world!'); en guise de première instruction... C'est assez représentatif du problème du js je trouve... Et c'est ce qui me donne cette impression que le js est construit sur des fondations instables...

C'est peut etre une impression complètement fausse.... Mais c'est qui me donne envie de miser sur le Dart (qui part de 0) plutot que sur Typescript qui se content d'etre simplement une surcouche des-dites fondations.
Dart voit beaucoup plus loin, pour moi ca n'a pas vraiment de sens de le comparer avec TS, car il ne s'agit pas ici de simplement typer le js (d'ailleurs en production, le dart ne fait aucune verif) mais il s'agit surtout de penser directement le langage pour comment il sera utiliser demain (scalable, concurent)...
Et à ce titre, j'estime que Dart evoluera plus rapidement que Typescript/Javascript en plus d’implémenter nativement l’interprétation de certaines features qui ne seront qu'émulées en js...

Et puis, sans vouloir stigmatiser Microsoft, je fais plus confiance à Google pour promouvoir une technologie web open source...
1  0 
youtpout978
Avatar de youtpout978
Expert confirmé https://www.developpez.com
Le 28/02/2014 à 11:44
Je pense qu'il y a la place pour plusieurs concurrents, côté serveur on a le choix d'une infinité de langage alors que côté client on est cantonné au JS.
Si on peut avoir plusieurs solution capable de cohabiter pourquoi pas au lieu d'avoir le monopole d'un seul langage.
1  0 
anthyme
Avatar de anthyme
Membre éprouvé https://www.developpez.com
Le 28/02/2014 à 12:08
Bon je precise deja je suis plus c# que java, mais j'ai fait pas mal de dev JS et typescript aussi.

Citation Envoyé par sekaijin Voir le message
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.
et tu n'a pas le choix si tu vérifie pas tu part dans les choux.

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.
Tu peux fermer les yeux mais si tu vérifie pas un jour ça te tombe dessus.

jutilise plusieurs normes qui définissent dans leur dommaine une représentation d'un ensemble d'objets. je fait appel à plusieurs fournisseurs qui propose chacun une implémentation d'une des normes. mais moi je manipule des objets dans l'ensemble de ces normes
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.
Ecoute pour moi ce n'est pas de la POO ni même de la bonne programation, il y a des pattern pour ca Adapter ou Bridge.
Différentes implémentations de domaines complètements différents n’empêche pas une abstraction avec un contrat spécifique, si ce n'est "pas possible" c'est juste qu'il y a une erreur de conception.
Ces casts, test d'instance, switch de comportements sont justes des anti patterns.

Citation Envoyé par sekaijin Voir le message
avec un typage dynamique on transmute son objet. on lui attache la méthode de son chox à la volée.
Et bien je préfère mille fois l'encapsulation.

Citation Envoyé par sekaijin Voir le message
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 ?
Ces questions nous avancent pas beaucoup ... Pourquoi les derniers langages qui sortent ajoutent le concept de classe ?

Citation Envoyé par sekaijin Voir le message
Parfoit les classes bien rigides sont des contraintes trop fortes.
Je n'ai pas dit toujours, j'ai dit parfois.
[...]
efficacité des classes 30 x 100 lignes de code java face à 3 lignes de js.
au final en java avec un 10aine de lignes de code et en jouant avec l'introspection on passe outre les protect private et autre artifice des classes java et on fait le vrai boulot soit le smême trois lignes qu'en JS. mais pour y arriver il faut casser le principe même des classe.

J'ai vu des truc monstrueux dans ma carrière.
[...]
En effet les langages dynamiques sont naturellement plus doués pour le mapping d'objets à signature similaire. Mais on peut totalement le faire avec la majorité des langages typés soit en réflexion soit avec des lib éprouvés pour cela.

Code : Sélectionner tout 
OrderDto dto = Mapper.Map<Order, OrderDto>(order);
Même pas besoin de boucle :p

Citation Envoyé par sekaijin Voir le message
et il y a des absurdité partout en javascript dans 90% des développements. voici que l'ontrouve.
[...]
Si on réfléchi comme en java i faudrait dériver la classe Element pour cet élément là. pour avoir un élément qui porte CES methode là et pas d'autres.
C'est sur que si on fasait ça en java on aurait plus de 60% des classe qui n'auraient qu'une seul objet.
Il suffit de ne pas penser classe mais prototype et ojet dynamique pour comprendre que l'objet de la classe Element peut recevoir toutes les méthodes tous les attributs dont il a besoin.
Je n'ai pas bien compris ton cas, en tout cas en C# on a les méthodes d'extension qui permettent de rajouter une méthode à une classe existante, pourtant on est sur un langage typé.
1  0 
sekaijin
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 28/02/2014 à 15:47
Bon je crois que ça commence à troller fort.

je vais arrêter. car lorsqu'on dis
le fait que js soit différent ne le rend ni meilleur ni moin bon qu'un autre et qu'on interprète ça
ainsi :
Citation Envoyé par la.lune Voir le message
Mais pourquoi pas Changer en mieux?


Tu veux supprimer le terme faiblaisses comme si JavaScript est parfait il n a aucune de faiblesse? .
Là je jette l'éponge
1  0 
Commenter Signaler un problème