Juste un gros + 1 à ugo-sans-h ! J'aurais pas dit mieux !
C'est pour ça que je suis en train d'utiliser Dart pour mon CV, pour le faire découvrir au monde de l'entreprise.
Version imprimable
Juste un gros + 1 à ugo-sans-h ! J'aurais pas dit mieux !
C'est pour ça que je suis en train d'utiliser Dart pour mon CV, pour le faire découvrir au monde de l'entreprise.
On peut ne pas aimer js, mais on peut aussi éviter d'écrire des bêtises. Son implémentation repose sur Ecmascript. Ecmascript n'est pas là pour faire du remplissage de papier, c'est une norme, versionnée, sur laquelle repose les différentes versions de Javascript. Combien de langage peuvent se pré-valoir d'être normé ? Le problème de JS vient des interpréteurs intégrés dans les navigateurs, et surtout de l'historique lié à IE6 (merci Microsoft, au moins vouis avez retenu la leçon avec IE10/11)
Jquery n'est pas du js non plus et si les gens se formaient correctement au JS on aurait moins de soucis. Ca ne sert à rien d'utiliser systématiquement $() alors que document.querySelector/All fait pareil (à condition que sa cible d'utilisateur repose sur des navigateurs récents, mais pas tant que ça)
Typescript n'est pas un langage, mais tout comme coffeescript, une surcouche permettant d'écrire du code à compiler en js avant la mep (de manière manuelle ou auto). Ils ont leur propre implémentation d'un modèle objet sous Javascript, à chacun ses particularités.
Je ne suis pas contre Dart, j'aime ce qui est nouveau, mais quid de Dart sous FF, Opera, IE, ou du mobile ? Comme le dit Ugo-sansH il faut que la VM soit développée pour chaque navigateur dans chaque version d'OS. C'est pas gagné et du coup en attendant il faut dans tous les cas compiler en js pour être sur que ça marche partout, c'est dommage. On se retrouve alors avec une énième surcouche comme type/coffee script
Ce que je trouve étrange c'est qu'il n'y est aucun plugin navigateur permettant de disposer de la Machine Virtuelle sous FF ou Chrome. A moins que je ne l'ai tout simplement pas trouvé ?
On est d'accord sur le fait que JS soit normé. Et encore, Microsoft a créé son JScript avec sa propre norme.Citation:
Envoyé par rebolon
Le problème, c'est qu'on se retrouve avec les mêmes soucis que ce qu'on peut constater avec le W3C. 10 ans pour chaque version de la norme (je ne parle pas des sous-version qui n'ajoutent presque rien), donc quelque chose qui quelque part n'est pas très propice à l'innovation ou la mode du moment.
Un autre problème dont vous avez parlé, le non respect des normes par chaque navigateur pendant un certain nombre d'années, qui en ont dégouté pas mal du JS.
Les Fans du paradigme objet et du compilé dont je fais partie n'apprécient pas la plupart du temps Javascript. Car contrairement aux langages compilés, on a rien qui nous dit avant l'exécution qu'il y a une erreur. On n'a aucun garde fou qui nous dit "ça va donner ça si vous le mettez dans cette variable" dont le type et la conversion sont implicites. Et à l'exécution, souvent l'erreur est représentée par la non exécution de la totalité (ou d'une partie quand on est chanceux) du script, avec juste un point d'exclamation dans la console et un message d'erreur ne correspondant souvent pas du tout au problème. Difficile également de parcourir le code Javascript pas à pas pour trouver l'erreur, sauf avec des "Alert". Ajoutez à ça les différentes interprétations des navigateurs...
Donc je maintiens qu'il faut être pratiquement expert en JS pour maîtriser et vraiment l'apprécier à sa juste valeur. On n'a pas d'IDE pour nous aider (ou si peu). Les problèmes rencontrés ne sont jamais typiques et résolvables facilement à l'aide de forums. A l'aide de Frameworks comme JQuery, on obtient au final une syntaxe moins verbeuse, un même résultat quel que soit le navigateur, et certaines briques déjà toutes faites.
Les experts en Javascript ça ne court pas les rues, surtout quand on leur demande d'être en même temps experts en J2EE ou .NET.
Ces Framework et le Dart2JS sont moins performants que du natif, mais ils permettent aux développeurs de niveau au moins intermédiaire d'être productifs et de ne pas plancher une demi-journée pour débugguer le moindre petit script. Et je ne parle même pas de la maintenabilité.
Quelque part ça m'est égal qu'on doive compiler Dart en JS. Au contraire, si ça permet de valoriser JS. Ce qui compte c'est que la conversion soit vraiment fiable. Les performances de Dart2JS sont tout à fait honorables d'ailleurs.
Donc la VM pour moi, c'est la cerise sur le gâteau.
Je suis prêt à parier que c'est purement commercial.Citation:
Envoyé par Driktheviking
Vous avez vu comment Google abuse pour imposer Chrome ? Il est souvent installé avec d'autres logiciels si on ne prend pas soin de décocher la petite case peu visible, on a des pubs à la TV, dans la rue,...
J'ai vu aussi que la VM était toujours en développement.
Firefox est open source et ne va pas facilement faire confiance à un big brother comme Google. On voit ce qui s'est passé avec le h264. Au mieux, la VM, créée par Google ou par un développeur lambda en licence open source, sera téléchargeable et traitée comme le plugin Flash ou Java.
Microsoft est, tout comme Google, une société à but lucratif. Et ce n'est pas du tout le grand amour entre les 2.
Même chose pour Apple avec Safari. Apple étant encore plus fermé et big brother que Microsoft ou Google.
Bonjour je dois apprendre un language client pour une petite appli graphique. Je venais d'arrêter mon choix sur jquery, mais en lisant ceci j'hésite. Dart va-t-il être supporte sur ie et mobile ?
Cdt
Est-ce que tu VEUX apprendre un langage ou est-ce que tu DOIS l'apprendre ?Citation:
Envoyé par laurent1133
Cette nuance est très importante :
JQuery est une bibliothèque Javascript très utilisée, même dans le monde professionnel. Tu trouveras toujours du boulot dessus. Elle est assez mature (déja la version 2.0). Tu dois néanmoins connaître un minimum Javascript pou l'utiliser. Pour IE (version 9 minimum pour les nouvelles versions de JQuery) et mobile aucun problème.
Dart, c'est un peu un pari. C'est un autre langage que Javascript. Il te plaira peut-être plus si tu n'aimes pas Javascript, mais ce sera probablement à toi d'essayer de l'imposer. Il vient à peine de sortir et les entreprises ont toujours un train de retard, niveau technologie, surtout parce que souvent elles attendent que les autres aient essuyé les plâtres. Normalement le code généré est compatible tout navigateur, avec IE version 9 minimum.
Donc d'un point de vue avenir professionnel, Javascript et JQuery.
D'un point de vue étudiant ou passionné de POO, je dirais Dart, notamment pour essayer de le propager. Il ne faut pas oublier que l'avenir de Dart n'est pas défini puisqu'il vient de sortir. Cette techno peut très bien finir aux oubliettes comme elle peut finir par supplanter JS. Donc commencer un projet pro dessus est un pari risqué. Mais prouver qu'elle est très bonne et le faire savoir avec de vraies créations est également une option.
Je fais partie de la catégorie des passionnés téméraires ;)
Il manque à Dart (comme à JavaScript) quelques fonctionnalités fondamentales :
- des composants intégrés d'IHM type TextBox, Label, ComboBox, Grid ,... avec gestion d'events,
- un environnement pour concevoir des formulaires avec ces composants,
- une gestion intégrée de bibliothèque permettant d'enregistrer comme des cookies (si l'utilisateur l'accepte) de librairies de procédures et de ne refaire leur téléchargement qu'en cas de modification,
- de donner la possibilité d'utiliser un répertoire local (bac à sable) pour stocker/utiliser des données sur le PC.
Ok c 'est trés clair merci.
Ce que vous dites là est vrai et faux. oui Dart est comme TypeScript, GWT et CoffeeScript pour les navigateur qui ne le supportent pas encore qui nécessite de le compiler en Js. Mais Dart tout court sous Chrome est plus performant avec son VM que js avec le moteur V8. Le compilateur Dar2js est là pour introduire les developpeur à Dart et attendre que les autres navigateur le support.Citation:
Envoyé par Watilin
Les langages c'est comme ça, une firme le développe s'il est bon les autres le supporte, c'est ce qui a fait de javascript ce qu'il est.
Il ne faut pas toujours comparer Dart, aux autres, Dart c'est une toute nouvelle expérience.
Dart est un langage de programmation dont le code est transformé en JS, ce n'est pas une librairie JS. Et ce que tu décris, probablement avec extJs en tête, c'est le rôle d'une librairie.Citation:
Envoyé par Graffito
L'interet d'un nouveau langage est aussi de définir en standard (en mode natif ou avec les librairies fournies avec le langage) des fonctionnalités et un comportement plus évolués.Citation:
Dart est un langage de programmation dont le code est transformé en JS, ce n'est pas une librairie JS. Et ce que tu décris, probablement avec extJs en tête, c'est le rôle d'une librairie.
Et qu'ainsi on puisse compiler ce qu'on veut de manière efficace. Dart -> Js, ClojureScript->js, c'est tj du js... :)
Quand à du Google Dart comme natif... encore dix ans de programmeurs qui vont se foutre de notre gueule... ;)
:no: 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.Citation:
Envoyé par ivanpierre
Vous êtes vous bien renseigné ?Citation:
Envoyé par Graffito
- Dart supporte le projet Polymer qui justement est là pour travailler par composants.
- Il y a des bibliothèques, vu que Dart intègre un gestion "pub" qui permet d'importer des plugins externes dans ses projets ("Dice" par exemple est sympa)
- Pour le bac à sable, je n'en sais rien.
Mais gardez en tête que le but premier de Dart, c'est d'offrir une alternative à Javascript pour le développeur. Comme Javascript, il dispose d'un ensemble déja conséquent de librairies considérant le fait qu'il vient de sortir.
Et pour les navigateurs Google, pour le moment, il offre quand même des performances 130% plus élevées que du JS natif, avec possibilités améliorées de débuggage (même en Dart2js).
Connaissez-vous une IDE Javascript disposant d'une IHM permettant de manipuler le DOM à sa guise et de créer ses composants ? Moi j'aimerais la connaître.
Les textbox et consort, c'est des éditeurs style Dreamweaver qui les créent et c'est de l'HTML de prime abord, pas du Javascript. J'imagine que vous devez vouloir que Dart Editor ressemble à Visual Studio ou NetBeans ?
Dart est un langage client comme Javascript, vient à peine de sortir et on lui demande déja ce qu'on n'a pas réussi à faire en 20 ans de JS.
Oui, et tout le monde va se précipiter pour ajouter le langage de Google :DCitation:
Envoyé par la.lune
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... :D
Je ne pense pas qu'on puisse se contenter d'aborder Dart seulement sous l'angle de sa qualité technique ou du confort du développeur.
...Citation:
Envoyé par LSMetag
Le but de Google c'est quoi ?Citation:
Envoyé par LSMetag
Déjà aujourd'hui, un nombre croissant de sites web ne fonctionnent plus correctement sans les cdn jquery, mootools, angular que tout le monde nous enjoint d'utiliser. Un bête filtre 'anti-google' et un paquet de site n'est même plus praticable...
Mais à part pour générer des graphs coté client & dérouler des "autocomplete" javascript et ses librairies sont devenus superflus dans les interfaces depuis css3 et html5 ou devraient l'être ne serait-ce que pour des raisons d'accessibilité ou le référencement naturel.
Non le gros "plus" du javascript c'est la simplicité de mise en oeuvre du "tracking"... mais sur ce point javascript a des limitations : les échanges d'infos sont lisibles par l'utilisateur et l'accès aux favoris, historiques, mots de passe du navigateur est souvent impossible...
Quid de DART ? avez-vous des infos là dessus ?
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.
8OCitation:
Envoyé par schnee
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.
Bon déja je me corrige. Quand je parle de librairies externes, je parle de librairies faites par des tiers pour Dart. Ca marche comme avec Maven, avec un fichier yaml de dépendances.Citation:
Envoyé par fbrgn
Après oui, la plupart maintenant ne peuvent plus se passer de librairies pour justement rester productifs avec Javascript. Ceux qui les utilisent juste pour de l'autocomplétion ou ce genre de babioles ne sont pas très futés. Ils divisent leurs performances alors que le coder à la main, ce n'est pas la mort. Me concernant, je m'intéresse à Angular parce que je suis très orienté architecture (donc MVC + binding ça me botte). Après, quelle idée aussi de les mettre sur Google. Il faut le stocker sur un serveur à soi ou lié au site du créateur.
J'avoue que comme je n'ai pas encore cherché à utiliser la VM Dart, je n'ai aucune idée de son fonctionnement. Donc pour le référencement de scripts, j'avoue que ça me semble compliqué. Je sais qu'habituellement, c'est le référencement des pages résultat en HTML qui est fait. Donc vu que Dart utilise aussi le DOM, ça devrait fonctionner pareil. Par contre, ce que je sais, c'est que la communauté est fortement mise à contribution :
https://groups.google.com/a/dartlang...#!forum/vm-dev
Accéder aux mots de passe utilisateurs, favoris et autres ? Mais vous n'y pensez pas ???? Heureusement qu'on ne peut pas !!!!
Pour la sécurité, je pense qu'il faut savoir manier intelligemment la programmation client et serveur, et créer des architectures sécurisées prenant en compte ce qu'on veut que le client puisse voir ou non, comme pour JS. Les utilisateurs, ici, ont des compétences techniques, sont vigilants et regarderont forcément avec WireShark ou autre les accès réseau quand on essaiera d'interroger un serveur depuis Dart ou d'utiliser leur base de données IndexedDB (une base No-SQL qui a l'air tout à fait suffisante pour le commun des gens).
Je n'ai pas la science infuse mais je suis plutôt confiant pour une fois vis à vis de Google.
Google et consorts encouragent des pratiques (stockage en clair de données sur serveur par ex, cookies,...) auxquelles je n'adhère pas. Avec tout langage on peut faire des bêtises. C'est aux développeurs d'être vigilants. J'enverrai toujours des données cryptées par les soins de l'utilisateur final à la base de données, en faisant en sorte que même moi je ne puisse pas les décrypter.
Ce n'est pas spécifique à Dart. La plupart des frameworks Javascript comme JQuery permettent une abstraction du résultat (le même pour tous navigateurs).Citation:
Envoyé par schnee
Concernant Dart s'il a l'avantage de générer un bon JavaScript, il pourra peut-être faire sa place et finalement on finira peut-être par l'utiliser uniquement à travers sa VM mais j'en doute. En tout cas pas plus que Flash, Silverlight ou autres. Car il est peu probable que le W3C en fasse un standard du Web.
Si on fait du JavaScript, c'est bien parce que c'est un langage supporté par tous les navigateurs.
Il sera curieux de voir comment il se fait une place face à Ceylon. Ce dernier pouvant également être utilisé avec un environnement Java. Ce qui en fait un langage capable de fonctionner potentiellement sur tous les clients (navigateurs) et au moins deux poids lourds côté serveurs : l'écosystème Java et Node.js.
Les deux langages ayant connu leurs sorties officielles "au même moment", il sera intéressant de vérifier leur progression dans le classement TIOBE (ou autres).
HTML5 ou Web Components ? Sans compter les jeux de composants ...Citation:
Envoyé par Graffito
S'agissant au final d'un éditeur WYSIWYG pour HTML5, il faut voir ce qui est déjà supporté par les éditeurs actuels.Citation:
Envoyé par Graffito
HTTP et Offline application ?Citation:
Envoyé par Graffito
File API (HTML5) ?Citation:
Envoyé par Graffito
Il ne faut pas oublier que JavaScript fonctionne dans un navigateur et est complètement lié aux technologies HTML5 et CSS3.
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 !