Version imprimable
Hmmm...C'est moi où je sens sur ce forum un vent de W3C-addicts ? ^^
Enfin bon, de toute manière, la VM de DART c'est qu'un bonus pour moi. Et je serais en effet bien content si Flash (et Silverlight que j'appréciais déja beaucoup plus) et les applets Java pouvaient disparaître. Tout ça est bien trop lourd, sujet à failles de sécurité et instable je trouve.
Enfin, pour moi, y a beaucoup trop d'inertie dans le W3C. Donc je vote plutôt WHATWG, comme la plupart des navigateurs.
Web components type Polymer ou équivalent + Offline application + File API (HTML5) + Langage Objet + EDI :
Et on s'approchera enfin d'une bonne solution.
Faut-il encore que l'ensemble hormis l'EDI soit normé et supporté par les différents navigateurs.
Je pense qu'on y arrive là et qu'on peut déja utiliser ce genre d'archi au jour d'aujourd'hui. Par contre, question normalisation, faudra sûrement attendre 20 ou 30 ans pour un langage objet ^^'.Citation:
Envoyé par Graffito
Et pour l'EDI, à mon avis ce n'est possible que si elle est adaptée à certains frameworks (JQuery, Polymer ou autres). C'est compliqué de faire une EDI pour un langage. Le seul moyen est d'avoir une EDI pour un Framework défini comme par défaut pour ce langage (.NET pour C# par ex). La liberté de choix, c'est important donc je ne pense pas qu'on aura une IHM pour ça de sitôt.
La syntaxe de JQUERY est homogène avec celle de CCS, et pour le programmeur HTML / CSS / Javascript voire XML / XSL cela ne pose aucun souci.Citation:
Envoyé par Jean-Georges
J'ai l'impression qu'il y a sur ce fil un certain nombre de gens qui n'ont pas l'habitude de coder en JS, et on peut raisonnablement en conclure que Dart s'adresse à ces personnes, entre autres.
J'aimerais revenir sur ce qui a été dit (Jean-Georges, Graffito, etc.) : JavaScript est un langage objet, et il l'a toujours été. En revanche, ce n'est pas un langage à classes. Il faut savoir que les classes ne sont pas le seul paradigme de POO : le paradigme de JavaScript, c'est les prototypes.
Malheureusement, quand le paradigme « classes » est devenu populaire, les créateurs de JS ont décidé de l'introduire dans leur langage en ajoutant le mot-clé new et les constructeurs, mais sans toutefois introduire le concept entier. Au final, JS supporte les classes, mais de façon incomplète. C'est ça, à mon avis, qui embrouille tout le monde et qui donne à JS sa mauvaise réputation.
Donc le mieux quand on parle de JS, c'est d'essayer d'oublier qu'il supporte les classes, tout en gardant à l'esprit que c'est un langage objet. Souvenez-vous :
Objet != Classe
Pour revenir au sujet, Dart a préféré choisir le paradigme « classes ». C'est dommage, peut-être, mais je suppose que c'est un choix stratégique.
Franchement je sais pas pourquoi mais javascript m`a toujours saoulé! J'espère que bien de choses nous attendent avec Dart! #revolutionInformatique
Je ne suis pas d'accord. Pour moi le problème n'est pas le paradigme de Javascript, mais qu'il n'est pas compilé et debuggable à souhait.Citation:
Envoyé par Watilin
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
@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.
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 observableCitation:
Envoyé par LSMetag
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
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.Citation:
Envoyé par LSMetag
Donc j'aimerais bien savoir, sincèrement, en quoi tu trouves ça catastrophique.
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
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.Citation:
Envoyé par sekaijin
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 ?
les deux dernière version on environ 1 an d'écart. la version suivante est en cours.
A+JYT
Une autre alternative à ces frameworks est ST-JS qui transforme le code Java en JavaScript presque 1 à 1.
Il y a déjà des bridges pour HTML5, jQuery, AngularJS et Backbone.JS pour pouvoir utiliser ces libraires comme en JavaScript, le typage fort en plus (ce qui donne meilleur support de l’IDE, refactoring plus facile, partage des POJO avec le serveur, utilisation des outils d’analyse statique de code genre Findbugs, etc).
Une version pour Java 8 est en préparation pour le début de l'année prochaine pour permettre une syntaxe plus compacte notamment grâce aux expressions lambda.
A faire du 1 pour 1, ca risque surtout de pondre du mauvais JavaScript. Après ca reste la même "solution" que GWT.
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 ?
:fleche: 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.Citation:
Envoyé par Hinault Romaric
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.
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.
Quelle bonne nouvelle ! Moi qui ai misé sur Dart, je suis aux anges !