Discussion :

[la.lune]

Et qu'ainsi on puisse compiler ce qu'on veut de manière efficace. Dart -> Js, ClojureScript->js, c'est tj du js...

Ce n'est pas toujours du js il faut t'informer. A la base il n'a pas besoin de js, seulement pour combler le vide que les autres navigateurs autre que chrome ne le supportent pas encore, Google propose de compiler le code vers js.

[ivanpierre]

Ce n'est pas toujours du js il faut t'informer. A la base il n'a pas besoin de js, seulement pour combler le vide que les autres navigateurs autre que chrome ne le supportent pas encore, Google propose de compiler le code vers js.

Oui, et tout le monde va se précipiter pour ajouter le langage de Google

Re : à quand du bytecode ? Qu'on puisse faire évoluer les langages et pas avoir un autre foutu langage qu'on va encore devoir trainer comme un boulet pendant des années...

[schnee]

Si je comprends bien, ça permettrait du même coup de régler tous les problème de compatibilité entre navigateur ?
Rien que pour ça ça vaudrait la peine.

[phili_b]

Si je comprends bien, ça permettrait du même coup de régler tous les problème de compatibilité entre navigateur ?
Rien que pour ça ça vaudrait la peine.

C'est un peu mettre la charrue avant les bœufs: il faudrait d'abord que les navigateurs en question implémentent Dart en natif. Mais sinon les autres framework masquent déjà les différences de compatibilité entre navigateurs.

[Invité]

Franchement je sais pas pourquoi mais javascript m`a toujours saoulé! J'espère que bien de choses nous attendent avec Dart! #revolutionInformatique

[sekaijin]

J'avoue ne pas comprendre pas mal de réflexion

Tout se passe comme si on utilisait C++ en écrivant encore du C des années 70.
Et, on trouverait C++ vieillot.

JS est fait de deux choses.
la première c'est le langage, la deuxième c'est l'interaction avec le DOM

La première est une implémentation de EcmaScript et n'a rien à envier à d'autres langages. On peut toujours discuter des avantages du fortement type face au faiblement typé. Du typage statique face au typage dynamique. Les deux ont leurs avantages. EcmaScript est un langage à Objet (pas un langage à Classe)
Et toutes les notions d'héritage et polymorphismes sont présentes. Ce n'est pas parce que les développeurs écrivent du JS purement fonctionnel et avec des variables globales que le langage n'a pas ces capacités.

La deuxième relève du W3C l'api DOM est le standard pour les interactions entre le DOM et le langage. Là encore l'API peut être critiquable, mais elle a le mérite d'exister. Alors oui on voit des Lib comme JQuery qui propose une autre API avec le DOM. Et là encore, on voit bien trop souvent un mauvais usage de l'API. Qui est en fait une approche historique. On peut continuer à passer son temps à rechercher dans le DOM des éléments à manipuler ou utiliser pleinement les capacités de l'API DOM et du langage. Je constate que l’on continue à privilégier l'approche d'y a 10 ans, époque ou le moteur HTML était beaucoup plus performant que JS/DOM. Or aujourd'hui, ce n'est plus le cas. Là encore, on fait du C avec C++.

Je comprends tout de même l'arrivée de Dart. Le couple EcmaScript/DOM est né pour faire du Script sur le web (côté serveur). Tout comme on a le Bash et autre Shell script. Aujourd'hui lorsqu'on fait un Shell script on est bien content d'avoir un interprète, un langage dynamiquement typé, et possédant quelque structure de base. Mais on ne développe pas d'appli lourde avec. Pour ça on passe à C++, Java, etc. ce qui se passe aujourd'hui avec JS c'est qu'on veut continuer à faire du Scripting, mais aussi développer des applis avec. Lorsqu'on fait un script, on a besoin de quelques objets créés à la volée, détruits de même et rarement des structures très complexes. Alors que lorsqu'on développe une appli lourde c'est plutôt le contraire. Dart est pour moi un peu comme python ou Perl. Il tente de se situer entre le scripting type Bash et le codding genre C++. et s'il apparait aujourd'hui c'est qu'il y a un réel besoin.

Quant à remplacer le JS, je n'y crois pas du tout. Tout comme avec le Shell, on aura toujours besoin d'écrire un petit script pour ceci ou cela et on ne voudra pas mettre l'artillerie lourde pour ça.

La question, que l'on peut se poser, c'est : que manque-t-il à EcmaScript aujourd'hui ? Pour moi la réponse est simple. EcmaScript c'est comme C++ sans Standard Lib. Java sans Standard Lib. On a les types de base et il faut tout construire. D'où la multiplication des librairies sur le net.
Il y a bien quelques efforts de fait comme CommonJS, mais on ne peut que constater qu'il n'y a pas de standard.

Quant au DOM et au W3C, le virage a été pris depuis quelque temps. Pour (X)HTML jusqu'à 4 le W3C a normalisé le langage HTML et ajouté le DOM et l'API DOM. Avec (X)HTML5 ce qui est normalisé c'est le DOM et son API le langage HTML5 n'est qu'une forme sérialisée du DOM.
Cette norme permet donc d'être conforme même si on utilise d'autres formes sérialisées du DOM.
Je constate qu'on trouve une multitude de représentations textuelles du DOM, dans les Lib JS. Ce qui montre un besoin. Mais là encore rien de normalisé.

J'en conclus que plus qu'un nouveau langage JS soufre d'un manque de Standard. Lib Standard pour le langage, Représentation sérielle standard autre que HTML pour le DOM, ET probablement aussi une API moins lourde pour le DOM.

Et pour finir, je dirais qu'il faut arrêter d'enseigner dans les écoles que POO = Classes. C’est archifaux et contre productif.

A+JYT

[LSMetag]

@sekaijin

Analyse très intéressante.

Oui je suis d'accord que c'est une bêtise d'enseigner que Objet = Classe. Car je n'ai réalisé que récemment que le prototypage était aussi une forme d'Objet.
Mais j'ai malheureusement réalisé que c'était un problème de compétence des profs, pas à une simplification volontaire.

Tu dis qu'on utilise une approche d'il y a 10 ans avec JS. J'aimerais connaître l'actuelle.

Oui, le besoin a évolué depuis quelques années. On utilise maintenant plus massivement JS, principalement à cause de l'Ajax et de l'évolution des performances des machines et navigateurs Web. On fait beaucoup plus de client riche.

C'est clair qu'utiliser Dart ou JQuery pour un "onclick" sur un peu de DOM c'est sortir l'artillerie lourde pour pas grand chose et contre productif.

Mais j'ai vu par exemple un Diablo-Like entièrement développé en Javascript. On met maintenant Office ou Visual Studio sur Internet (sans parler de Google Doc), et donc là l'utilisation de Javascript est intensive. L'utilisation de JQuery ou Dart devient justifiée.

Alors oui, on peut débattre du typage fort/faible, prototypage vs classes,...

Je préfère le compilé à l'interprété, mais contrairement à PHP pour qui ça ne me gêne pas, la gestion des erreurs et du debuggage sous JS est catastrophique. Et à mon avis, c'est ça le problème principal.

ECMascript est normé W3C et c'est un autre problème. Ca évolue beaucoup trop lentement par rapport au besoin.

[sekaijin]

...
Tu dis qu'on utilise une approche d'il y a 10 ans avec JS. J'aimerais connaître l'actuelle.
...

Mais j'ai vu par exemple un Diablo-Like entièrement développé en Javascript. On met maintenant Office ou Visual Studio sur Internet (sans parler de Google Doc), et donc là l'utilisation de Javascript est intensive. L'utilisation de JQuery ou Dart devient justifiée.
....

ECMascript est normé W3C et c'est un autre problème. Ca évolue beaucoup trop lentement par rapport au besoin.

Lorsqu'on fait une appli java ou c++ on ne dessine pas des rectangles pour afficher un menu. il y a bien longtemps qu'on a abandonné l'idée de mettre du code dans l'IHM. on crée un objet menu qui lui va dessiner le menu, et on utilise le patern observable
On peut très bien faire la même chose pour les appli riche. Utiliser un objet menu qui va générer le DOM adéquat.

Je suis d'accord que lorsqu'on fais des appli comme Office 360 avoir des outils comme Dart SproutCore etc. ne sont pas dépourvus de sens. et je comprends qu'après GWT Google ait sentit le besoin d'un langage plus adapté.

Pour Info Ecmascript est normé par l'IEEE norme Ecma-262 Ecma-327 Ecma-357 Ecma-402
Le W3C normalise le DOM
L'API DOM vers divers langages et donc le binding EcmaScript
C'est pour ça qu'on retrouve JavaScript (on devrait dire EcmaScript) dans actionScript, node.js Jscript etc.
C'est une confusion courante qui et souvent source d'erreur.

A+JYT

[Watilin]

la gestion des erreurs et du debuggage sous JS est catastrophique.

Est-ce que tu peux nous sortir des exemples à ce propos ? JS possède les throw, les try/catch et même les finally ; on peut créer ses propres « types » d'erreurs (je ne dis pas « classes ») et les faire hériter. De plus, aujourd'hui on a un débogueur JS natif sous Firefox, Chrome et Opera.

Donc j'aimerais bien savoir, sincèrement, en quoi tu trouves ça catastrophique.

[sekaijin]

quant au debogueur pas à pas ça fait un bail qu'il en existe déjà avec IE 5 et avant Microsoft en livrait un : MSE*.exe
MSE.exe était un éditeur debogueur intégré qui est sortit en 2000 soit 13 ans.

pour les IDE il en existe beaucoup et multiplateforme des gratuits et des payant
Ils font comme pour de nombreux autre langage de l'assistance au dev, et signalent les erreurs. certains sont capable de gérer des frameworks.

quant au langage lui-même je ne comprends pas pourquoi typer dynamiquement serait pire que statiquement.
Je ne conpte pas les Cast Exception que je vois dans les logs.
pour moi je ne vois pas de différence entre l'utilisation de "instanceOf" et la vérification de la présense d'une méthode dans un objet JS.
Les classes ne résoue pas tout. Oui les classes apportent des solutions dans certaines circonstances. mais apporte aussi des contraintes inutiles dans d'autres.

A+JYT

[LSMetag]

Lorsqu'on fait une appli java ou c++ on ne dessine pas des rectangles pour afficher un menu. il y a bien longtemps qu'on a abandonné l'idée de mettre du code dans l'IHM. on crée un objet menu qui lui va dessiner le menu, et on utilise le patern observable
On peut très bien faire la même chose pour les appli riche. Utiliser un objet menu qui va générer le DOM adéquat.

Je suis d'accord que lorsqu'on fais des appli comme Office 360 avoir des outils comme Dart SproutCore etc. ne sont pas dépourvus de sens. et je comprends qu'après GWT Google ait sentit le besoin d'un langage plus adapté.

Merci pour toutes ces infos. Je viens de regarder le pattern Observable, que je ne connaissais que de nom. C'est intéressant. Le truc, c'est qu'il faut aussi penser en matière client et serveur. Si l'on peut utiliser la machine du client pour éviter de surcharger le serveur (et des échanges réseau ralentissant le tout). Avec un RE-ADSL 512k comme chez mes parents c'est pas forcément viable.

Quand je parle de la gestion des bugs, je ne parle pas de la gestion d'exceptions que l'on connaît, je parle des erreurs qui ont lieu à l'exécution pour des trucs que l'on ne connaît pas forcément. J'aime bien avoir les warning et erreurs d'affichés à l'écran comme en PHP.
J'ai essayer de débugguer le JS avec le debuggueur de Firefox, ça n'a pas trop fonctionné sur un projet à base de Websphere Portal avec des .js disséminés partout et appelés par des JSP. Après peut-être que les outils ont évolué depuis.

En éditeur Javascript intéressant j'ai vu Aptana. C'est vrai qu'il aide bien pour le Javascript. En fait j'avoue avoir été dégouté par Eclipse (RAD de IBM pour être précis) sur des projets Maven...

Merci pour la clarification concernant la norme EcmaScript. Quelle est la fréquence de mises à jour de la norme ?

[Hinault Romaric]

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

Après plus de deux ans de développement, Google avait dévoilé le mois dernier la version 1.0 de Dart, son langage de programmation structuré pour le Web.

Dart se positionne comme une alternative au langage JavaScript, en s’appuyant sur la flexibilité qui a fait son succès, mais en proposant en plus un typage fort et optionnel.

L’Ecma, l’organisme en charge de la normalisation de JavaScript (dans le cadre du standard EcmaScript), vient d’annoncer qu’il avait créé un comité chargé de superviser la création d’une norme pour Dart.

Le comité technique TC52 aura pour mission d’élaborer des normes pour le langage et les bibliothèques Dart, créer des suites de tests pour vérifier la conformité avec les normes et superviser le développement futur de Dart.

Pour rappel, au sein de l’Ecma, existent plusieurs autres comités similaires, qui se chargent d’établir des normes pour les langages JavaScript, C# ou encore Eiffel.

Pour l’instant, Dart est pris en charge uniquement par Chrome, le navigateur de Google. Les autres éditeurs de navigateurs sont réticents à l'intégration d’un support du langage. Une normalisation de Dart pourrait être favorable à une meilleure adoption de celui-ci par l’industrie et les développeurs.


Source : blog Chromium


Et vous ?

La normalisation de Dart permettra-t-elle de doper l'adoption du langage ?

[Logan Mauzaize]

La normalisation de Dart permettra-t-elle de doper l'adoption du langage ?

Le risque c'est que chaque fabricant de navigateur développe son moteur (comme JavaScript ou Java) de manière +/- volontairement merdique pour couler la technologie.
C'est un peu l'histoire du JavaScript ou de la VM Microsoft.

Ceci dit cela a l'air d'avoir bien fonctionné pour C# alors pourquoi pas ? Ca aura au moins le mérite d'être rassurant pour ceux qui souhaite investir.

[tralloc]

Il est clair que la normalisation est LE déclencheur de l'intégration dans différents environnements. Web ou autre.
Et qui dit intégration dit possibilité de commencer des développement à partir de cela, donc cela ouvre la porte à l'adoption.

[LSMetag]

Quelle bonne nouvelle ! Moi qui ai misé sur Dart, je suis aux anges !

[Traroth2]

C'est une excellente idée. Si ça pouvait devenir un plan pour remplacer Javascript, en unifiant Dart, Typescript et CoffeeScript, ça serait parfait.

Edit : peu de chances d'arriver, vu le descriptif des objectifs du groupe de travail.

http://www.ecma-international.org/memento/TC52.htm

[Lutarez]

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)

[sekaijin]

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

Fais comme moi Zero HTML
enfin presque

Code html :

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

1
2
3
4
5
6
7
8
9
<html>
<head>
    <title>mon titre</title>
 
    <link rel="stylesheet" type="text/css" href="resources/css/app-all.css">
    <script type="text/javascript" src="app-all.js"></script>
</head>
<body />
</html>

du coup comme en java c++ etc j'instancie des objet graphique menu panel grid etc et je me moque bien que l'objet utilise html svg canevas ou je ne sais quoi pour dessiner l'interface.

qui se soucie de savoir si lorsqu'il utilise un objet menu dans un appli windows écrite en C++ ce que le code utilise pour dessiner le menu ?
à par dans les moteur de rendu de jeux vidéo ou pour des besoin spécifique on utilise des objets et le reste on s'en fout.

aujourd'hui avec certain framework on travaille ainsi. et le fait que ce soit du HTML ou autre chose qui est généré n'a plus d'importance.

A+JYT

[Lutarez]

Fais comme moi Zero HTML

HTML en soit ne me pose pas de problème, c'est simplement que j'en ai marre de tout vouloir lui faire faire alors qu'il n'est pas prévu pour ça à la base.
Je dirai donc pas non à une alternative qui ose aborder les choses différemment. Par exemple, ces "derniers temps", le responsive design est à la mode. Si cela venait à réellement devenir une "norme", je ne serais heureux de voir arriver une nouvelle technologie qui simplifierai la mise en place de ce type d'interface.

Bon, je relativise aussi mes propos car je ne serai heureux en dev web que le jour où je pourrai designer une webapp comme je designerai une application lourde ( rahlàlà la bonne "vieille" époque du natif )

aujourd'hui avec certain framework on travaille ainsi. et le fait que ce soit du HTML ou autre chose qui est généré n'a plus d'importance.

T'aurai un exemple de ces Frameworks ? Je suis assez curieux.

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

Tout dépend de ce que tu souhaites faire. Dans les contextes habituels où le JS est utilisé, l'équivalent d'un main() n'a aucune signification.
En web par exemple, on peut considérer le code suivant comme un main (avec JQuery, parceque je suis nul en JS :p):
Code javascript :
Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3

$(document).ready(function(){ // Ton code JS ici )};

Grosso modo, le code sera exécuté lorsque la page sera "prête" (donc totalement chargée), ce qui correspond plus ou moins à une main().

[LSMetag]

Fais comme moi Zero HTML
enfin presque

Code html :

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

1
2
3
4
5
6
7
8
9
<html>
<head>
    <title>mon titre</title>
 
    <link rel="stylesheet" type="text/css" href="resources/css/app-all.css">
    <script type="text/javascript" src="app-all.js"></script>
</head>
<body />
</html>

du coup comme en java c++ etc j'instancie des objet graphique menu panel grid etc et je me moque bien que l'objet utilise html svg canevas ou je ne sais quoi pour dessiner l'interface.

qui se soucie de savoir si lorsqu'il utilise un objet menu dans un appli windows écrite en C++ ce que le code utilise pour dessiner le menu ?
à par dans les moteur de rendu de jeux vidéo ou pour des besoin spécifique on utilise des objets et le reste on s'en fout.

aujourd'hui avec certain framework on travaille ainsi. et le fait que ce soit du HTML ou autre chose qui est généré n'a plus d'importance.

A+JYT

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.