Discussion :

[gwinyam]

Microsoft fait la même chose avec son .Net. Sauf que Microsoft souffre d'une mauvaise réputation historique (justifiée ou non, là n'est pas la question) et que son utilisation sur les systèmes libres Unix/Linux est plus que laborieuse. Mais maintenant, difficile de développer pour Windows en se passant de .Net et ça sera de plus en plus vrai.

On en revient à la guerre des langages qui estompe la guerre des OS.

[tomlev]

Le fait qu'ils aient leur propre langage leur assure la main mise technologique dessus. Ils pourront le faire évoluer bien plus vite qu'un langage gérée par une communauté hétérogène aux besoins différents.

Tout a fait d'accord. Ca peut gêner certains qu'un langage soit entièrement contrôlé par une entreprise, mais le fait est que l'évolution du langage est beaucoup plus rapide dans ces conditions. L'exemple flagrant est C# vs Java ou C++ : Microsoft sort tous les 2 ou 3 ans une nouvelle version de C# avec des évolutions majeures, alors que la les évolutions de Java sont soumises à un processus communautaire assez laborieux qui freine largement l'évolution du langage ; idem pour C++ : ça fait des années qu'on parle de la norme C++0x, et la spécification finale vient seulement de sortir.

Le processus communautaire a bien sûr ses avantages, il prend sans doute mieux en compte les attentes des développeurs... mais ça se fait au prix d'une évolution ralentie.

[Uther]

En y repensant chacune d'elle fait plus solution pour déploiement d'application lourde que script pour dynamiser une page. Au final les possibilités d'évolution à ce niveau sont très limité si on ne veut pas réinventer le web dans la foulé.
Plus que le nouveau langage, la popularité Dart va dépendre de son API qui devra être pensé pour booster la créativité. Donc une archi très permissive mais pas trop..

C'est bien le but! Comme on le disait, Javascript a été conçu comme un langage de script simple et flexible pour apporter quelque interactions limitées au pages web, ce en quoi il remplit assez bien son rôle.

Le problème c'est qu'aujourd'hui, on a de plus en plus à faire a des applications complexes (du type gmail) avec des pages entièrement dynamiques se reposant presque exclusivement sur du code javascript. Html 5 et les technologies qui gravitent autour ne font que renforcer cette tendance.
Dans ce cadre là, un langage fortement typé et un modèle d'objet par classe n'est vraiment pas un luxe.

[rt15]

Mais maintenant, difficile de développer pour Windows en se passant de .Net et ça sera de plus en plus vrai.

Ce n'est pas le sujet de ce thread, mais sera en fait de plus en plus faux.

.NET est en quelque sorte une surcouche (Non exhaustive, cf P/Invoke pas mal utilisée) de Win32 tout aussi optionnelle que java. Hors WP7, rien n'empêche de développer en C/C++ natif, en Delphi ou autre, en s'appuyant sur le win32 ou en s'aidant d'une surcouche (MFC, QT, GTK, VCL...).

Ce qui aurait pu tout changer, c'est que M$ commence à exposer des API de Windows uniquement en .NET, un peu à la WPF. Mais justement ce n'est pas du tout la direction prise : WinRT, la nouvelle API proposée pour Windows 8, est native et basée sur COM.

M$ a donc arrêté de promouvoir uniquement le .NET, et introduit de nouveau "first class citizens" : C++ (natif) et javascript (lol).

[gwinyam]

Ah bah au temps pour moi alors^^

Et pourquoi "lol" sur JS ? tentative de troll ?

[camus3]

M$ a donc arrêté de promouvoir uniquement le .NET, et introduit de nouveau "first class citizens" : C++ (natif) et javascript (lol).

en fait il y a un conflit interne entre le pole "dev" ( wpf / dotnet) et le pole "windows". Microsoft semble se recentrer sur windows , il est probable que les technos style silverlight, wpf voir .net disparaissent au profit WinRT.
Quand à javascript sur métro , c'est juste du marketing , aucun dev sérieux ne va utiliser javascript pour faire du client lourd.

[gwinyam]

Quand à javascript sur métro , c'est juste du marketing , aucun dev sérieux ne va utiliser javascript pour faire du client lourd.

ça me rappelle un truc que j'ai vu une fois : PHP-GTK

[rt15]

Et pourquoi "lol" sur JS ? tentative de troll ?

C'est juste amusant de voire d'un côté google qui semble vouloir se débarrasser d'un mauvais javascript en le remplaçant par Dart et de l'autre M$ qui étend le javascript aux application desktop sous windows comme si c'était un langage d'avenir.

Bref, les deux géants ne sont pas tout à fait d'accord !

[camus3]

ça me rappelle un truc que j'ai vu une fois : PHP-GTK

quand tu as C# à coté qui finalement est bien plus simple à apprendre et possède la majorité des "bons cotés" de javascript ( closures , lambdas , etc ... ) , pour moi il n'y a pas photo.
Seul XAML est plus compliqué à apprendre que HTML , mais c'est le coup de la souplesse accrue de XAML.

enfin le HTML5 metro n'est pas standard , puisque tu ne peux pas executer une application metro en dehors de metro ( l'api n'est pas standard ). C'est donc du marketing.

Quand à php-gtk il est mort aujourd'hui , mais tu peux toujours faire du DotNet avec le core PHP si tu veux.

Enfin il existe jsc sur window , qui te permet déja de développer des applis dotnet avec ecmascript 4 ( jamais standardisé , la même chose qu'actionscript donc "contient" ecmascript 3.5 ).

Ecmascript 4 est le plus grand échec d'ecma ( pour des raisons purement "politiques" ) et javascript serait incontesté aujourd'hui si la spec eut été validé.

[ernestrenan]

Ok je disais que j'aimais le javascript : j'ai changé d'avis. Mon code ne générait pas exactement le comportement attendu alors j'ai ajouter des 'alert' dans le code pour bien dérouler l'ordre des événements (ils étaient bons) et le code s'est mis à faire ce que je voulais. Alors j'ai enlever les alert pour vois et tout marche bien. Maintenant javascript me fait flipper.

[gwinyam]

C'est que t'as forcément changé quelque chose. Encore une fois, et ça concerne aussi JavaScript, la machine ne fait que ce que tu lui demandes.

[Robin56]

Ok je disais que j'aimais le javascript : j'ai changé d'avis. Mon code ne générait pas exactement le comportement attendu alors j'ai ajouter des 'alert' dans le code pour bien dérouler l'ordre des événements (ils étaient bons) et le code s'est mis à faire ce que je voulais. Alors j'ai enlever les alert pour vois et tout marche bien. Maintenant javascript me fait flipper.

Faut croire qu'il s'auto-corrige. Javascript est en avance sur son temps en fait. Je me demande comment Dart va contrer ça.

[Code62]

*bump*

Pour info: Google a publié une page de "synonymes", montrant côte à côte du code javascript (y compris quelques codes jQuery) et l'équivalent en Dart: http://synonym.dartlang.org/

[_skip]

J'ai joué un peu pour ma part avec le mini-compilateur-interpréteur sur la page d'accueil. Franchement je trouve cela très prometteur, on voit clairement que ça force un certain respect des types et que la "compilation" détecte un grand nombre de mauvaises utilisations ce qui est d'ores et déjà bon signe pour la productivité et la maintenance. A terme, Dart aura aussi sans doute la possibilité d'encapsuler un bon nombre de petites différences d'implémentation JS entre les navigateurs ce qui augmente encore son intérêt.

Ceux qui comme moi trouvent que javascript est un langage chiant et inmaintenable plus adapté pour faire du bricolage que de réelles applications pourront peut être sérieusement considérer Dart dans quelques temps.

Perso je suis ceci de près.

[Hinault Romaric]

Dartium : Google publie une préversion de Chrome avec la machine virtuelle Dart
son langage structuré pour le Web

Mise à jour du 17/02/2012, par Hinault Romaric

Google vient de publier une préversion ( technical preview) pour les développeurs de Dartium, un navigateur à base de Chrome qui introduit la machine virtuelle Dart.

Dart est présenté par Google comme un langage de programmation structuré pour le Web, basé sur les classes et optionnellement typé.

L’objectif inavoué de Google est de mettre JavaScript à la retraite en proposant un langage qui offre la même flexibilité que celui-ci, mais qui se distingue par son typage fort et optionnel.

Dart s'exécute soit sur une machine virtuelle native du côté serveur ou sur un moteur JavaScript classique à l'aide d'un compilateur qui convertit le code en JavaScript compatible avec Chrome, Safari 5+ et Firefox 4+, etc.

Cette préversion permettra d’exécuter des programmes Dart directement sur la machine virtuelle Dart incluse dans le navigateur Chrome, en évitant une étape de compilation séparée pour convertir le code.

Google à l’intention après plusieurs tests de la VM Dart, de l’inclure dans les futures versions de son navigateur Chrome.

Pour l’instant, le langage bénéficie uniquement du support de Google, et aucun constructeur de navigateur n’a encore indiqué son intention de supporter Dark. La firme espère néanmoins atteindre un certain stade de maturité avec Dart avant de le soumettre à un processus de normalisation.

Dartium est disponible pour les ordinateurs Mac et Linux. Une version pour Windows sera disponible dans les jours à venir.

Télécharger Dartium

Source : Google

[camus3]

J'ai joué un peu pour ma part avec le mini-compilateur-interpréteur sur la page d'accueil. Franchement je trouve cela très prometteur, on voit clairement que ça force un certain respect des types et que la "compilation" détecte un grand nombre de mauvaises utilisations ce qui est d'ores et déjà bon signe pour la productivité et la maintenance. A terme, Dart aura aussi sans doute la possibilité d'encapsuler un bon nombre de petites différences d'implémentation JS entre les navigateurs ce qui augmente encore son intérêt.

Ceux qui comme moi trouvent que javascript est un langage chiant et inmaintenable plus adapté pour faire du bricolage que de réelles applications pourront peut être sérieusement considérer Dart dans quelques temps.

Perso je suis ceci de près.

Après avoir longtemps testé Dart , même si c'est une solution intéressante , i l il existe plusieurs problèmes ( tel que la nom compatibilité avec les librairies javascript existantes ).

Etant forcé de faire du javascript , j'ai plutôt choisit d'utiliser Coffeescript , qui lui permet d'utiliser jQuery , etc ... sans problèmes.

Coffeescript est à mon avis un meilleurs compromis entre la necessité d'utiliser javascript et le besoin du dev javascript de fonctions plus avancées , comme la simplification de définition des classes , la correction de certaines erreurs de jeunesse de javascript , etc ...

Enfin , coffeescript fonctionne partout.

[Code62]

Coffeescript est à mon avis un meilleurs compromis entre la necessité d'utiliser javascript et (...)

Coffeescript est un compromis entre...
Pas un "meilleur compromis", vu que Dart n'est pas du tout un compromis avec la nécessité de faire du javascript...

La nécessité à laquelle Dart s'efforce de répondre c'est celle d'avoir un langage de script pour des interfaces web dynamique.
La non-compatibilité avec les librairies javascript existante - le fait de ne pas faire de compromis avec javascript - lui permet de réellement s'affranchir des lourdeurs de javascript, pas seulement du point de vue du développeur, mais aussi du point de vue du moteur...

[abriotde]

Google propose une solution à un problème de fond. Javascript ne permet pas de bien coder un gros programme. Il ne gère pas les type les constantes, les variables ont une portée infinie... mais il est multi-plateform (surtout avec le html) et souple. Alors il plait aux développeurs autant qu'il est haït par eux. L'idée est d'avoir un langage adapté aux grosse application manipulant aussi simplement les objets DOM de HTML. Dart entre dans ce cadre.

Javascript a été conçu vite fait pour donner un tout petit peu d’intelligence côté client. On est largement en dehors de ses spécification avec des framework comme JQuery. Dart n'est pas tellement plus qu'une évolution importante et nécessaire de javascript.

Exps :

Code :

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

1
2
3
4
5
6
 
var absolu=3;
if(absolu==3){var abs=6;}
function truc(){
  alert(abs);
}

Ce programme fonctionne et affiche 6. Ce n'est pas normal. C'est impossible a débugger (dans un grand projet). Déjà après le if la variable "abs" ne devrait pas être accessible (C'est le cas seulement en PHP) mais alors dans une fonction c'est du n'importe quoi.

Imaginez une variable

[Invité]

Code :

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

1
2
3
4
5
var absolu=3;
if(absolu==3){var abs=6;}
function truc(){
  alert(abs);
}

de la facon dont tu l'ecrit on est dans le contexte global il est donc tout a fait normale que l'on puisse avoir accès a abs

si on de cette facon il n'y a aucuns soucis car abs se trouve dans un contexte local

Code :

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

1
2
3
4
5
6
7
8
9
10
11
var absolu=3;
 
function ff(){	
if(absolu==3){var abs=6;}
}
 
function truc(){
  alert(abs);
}
 
onload=ff

[camus3]

Coffeescript est un compromis entre...
Pas un "meilleur compromis", vu que Dart n'est pas du tout un compromis avec la nécessité de faire du javascript...

La nécessité à laquelle Dart s'efforce de répondre c'est celle d'avoir un langage de script pour des interfaces web dynamique.
La non-compatibilité avec les librairies javascript existante - le fait de ne pas faire de compromis avec javascript - lui permet de réellement s'affranchir des lourdeurs de javascript, pas seulement du point de vue du développeur, mais aussi du point de vue du moteur...

Sauf que pour faire du Dart , il faut de toute façon comprendre comment fonctionne javascript, puisque Dart ne sera jamais intégré en natif autre part que dans Chrome.

Utiliser un compilateur n’empêche pas d'avoir des bugs à l’exécution,et même si du débugging pourra être fait dans Chrome en natif, il n'est pas 100% certain qu'un script Dart compilé vers javascript qui fonctionne dans Chrome fonctionnera correctement dans tout les autres navigateurs.

Donc utiliser Dart est un compromis , comme toute solution qui compile vers javascript.

Personnellement , je trouve que la solution Coffeescript a un meilleurs ratio avantages / inconvénients que Dart, puisque Coffeescript n'est qu'une nouvelle syntaxe et n'introduit pas de nouvelles fonctionnalitées, tout en corrigeant certain problèmes grossiers de javascript , et en simplifiant la création de classes et de sous classes. Mais coffeescript ne crée pas 2 mondes incompatibles l'un avec l'autre comme le fait Dart.

De plus , avec la multiplication de l'utilisation de javascript comme moteur de scripts dans des applications ( NodeJs , tout les produits adobe , plusieurs bases nosql , etc ... ) , ne pas pouvoir interroger une API javascript directement avec Dart est un sérieux problème. Ni Coffeescript ni Haxe n'ont cette lacune.