Je voulais dire "comparable à du Javascript natif".
Car mon but, c'est clairement de ne plus développer en Javascript.
Je voulais dire "comparable à du Javascript natif".
Car mon but, c'est clairement de ne plus développer en Javascript.
Dart : Google sort une nouvelle version de Dart Editor
l’outil de développement pour son « JavaScript-killer » introduit une bibliothèque WebGL dédiée
Mise à jour du 15/04/2013
Google vient de publier une nouvelle version de Dart Editor.
À titre de rappel, Dart Editor est un environnement de développement open source léger, pour l’édition de code, le débogage et l’exécution d’applications Dart.
Il comprend un éditeur de code pour Dart avec coloration syntaxique, autocomplétion, etc. le SDK (kit de développement) Dart et Dartium (une version modifiée de Chrome qui dispose d’une machine virtuelle Dart pour le test des applications).
La nouvelle version de Dart Editor introduit comme fonctionnalité phare une bibliothèque dédiée pour WebGL, la technologie d’affichage 3D pour les navigateurs Web.
L’EDI propose désormais une nouvelle option pour désactiver l’activation automatique de la complétion de code. L’aperçu de l’application fonctionne dorénavant avec le nouveau moteur d’analyse. Ce nouveau moteur d’analyse apporte plusieurs améliorations de performances et une meilleure gestion de la mémoire.
En plus de ces nouveautés, des modifications ont été apportées à la plateforme, notamment la suppression de la méthode List.addLast, le déplacement des types WebGL de dart:html vers dart:web_gl, l’ajout d’un argument optionnel pour la méthode StrinkSink.writeAll et bien plus.
[ame="http://www.youtube.com/watch?v=VQLdm8BY1Ao"]Présentation de Dart Edito[/ame]
Pour rappel, Dart est un langage de programmation structuré pour le Web, basé sur les classes et optionnellement typé. Le langage est proposé comme une alternative à JavaScript.
Le compilateur dart2js serait capable de traduire du code Dart en JavaScript, qui serait plus performant que son équivalent idiomatique.
:fleche: Télécharger Dart Editor
Source : Le site du projet
Et vous ?
:fleche: Avez-vous adopté le nouveau langage de Google ?
:fleche: Pensez-vous qu'il pourra pousser JavaScript vers la sortie ?
Avez-vous adopté le nouveau langage de Google ?
non
Pensez-vous qu'il pourra pousser JavaScript vers la sortie ?
non
J'ai parcouru cette passionnante discussion, et j'y ai lu beaucoup de mal à propos de javascript. Je ne connais rien à javascript, ni au développement web en fait, mais je suis curieux de savoir pourquoi javascript a si mauvaise réputation chez les développeurs alors qu'il est tant utilisé. Quelqu'un pourrait me faire un briefing?
En faite ça dépend des développeurs, et c'est un peu la même routine ... je pourrais détester Lua et un autre l'adorer par exemple.
Ces développeurs qui n'aiment pas javascript, c'est parce qu'ils lui trouvent des lacunes. Du moins, certaines de ces lacunes n'en sont pas : ces développeurs préfèrent tel ou tel système d'autre(s) langage(s) (exemple : il y en a qui préfèrent les classes au prototypage).
D'autres fois, c'est un défaut un peu "bancal" : le JavaScript ne dispose pas nativement, à proprement parler, d'héritage comme en PHP, il faut le faire autrement (des méthodes sont indiqués en faisant une petite recherche google ...).
D'autres encore n'aiment pas la syntaxe, le typage etc ...
En bref, comme je l'ai dit, c'est plus selon le goût qu'autre chose. Le langage à aussi des vraies lacunes, mais pas autant que ça.
Edit : il faut rajouter que la plupart des développeurs javascript utilisent jQuery, pour aller plus vite, que ce soit plus pratique ... enfin bon, il y a des frameworks/librairies qui peuvent aider à "s'adapter" au langage aussi.
Pour moi javascript a mauvaise presse pour les mêmes raisons que PHP : c'est un langage grand public et permissif, ce qui fait que pas mal de "pages" javascript sont bourrées d'erreur et que ça peut être une horreur à reprendre/maintenir.
Donc ce n'est pas propre au langage (la plupart des langages de scripts sont tout aussi permissifs) mais plutôt à son succès.
S'il est si utilisé, même par les gens qui le détestent, comme moi, c'est avant tout parce que c'est le seul langage qui peux être utilisé pour exécuter du code coté client, sur tous les navigateurs, sans avoir recours à un plugin.
Après il a des avantages, comme sa relative simplicité de prise en main, son approche dynamique qui lui permet manipuler facilement le contenu d'une page Web.
Mais si on veut faire une application lourde, je ne le conseillerais vraiment pas. C'est certes faisable en Javascript, mais des langages plus structurants et performants comme le C++, Java, ... me paraissent clairement plus adaptés.
JS est très différents des autres langages donc déroutant pour beaucoup. D'une apparente simplicité au départ il se révèle ensuite déroutant, car il ne se comporte pas comme l'a prévu le développeur. Cependant, cette apparente faiblesse (voir complexité inutile) se révélera être d'une puissance redoutable pour le développeur qui est prêt a réapprendre ce qu'il croyait savoir sur la programmation. Bien sûr beaucoup vont me moinser (:aie:, mais je m'en fout, ça ne m’empêchera pas de dire la vérité), car ils ne sont pas prêts a admettre qu'un langage de script permissif et simple d'accès au départ puisse être puissant. Malheureusement pour eux, le JS devient de plus en plus omniprésent, donc ils vont être forcés à terme d'évoluer ou d’arrêter le développement (ou c'est peut-être pour ça qu'ils vont me moinser?:aie: comme toujours je préfère dire ce que je pense plutôt que d'éviter les moins, question d'intégrité). Pour répondre a ta question, c'est donc à cause d'un orgueil mal placé de certains devs que le JS a si mauvaise réputation alors qu'il est tant utilisé. Si tu t'intéresse à JS, alors j'ai un conseil, fait des tutos jusqu'au bout, pratique un minimum (disons qu'il y a une sorte de cap à franchir), et les joies du JS seront tiennes.
Piero
C'est vrai que le JS devient omniprésent, c'est vrai que c'est un langage difficile, c'est vrai que c'est un langage puissant permissif et tout ça en même et c'est tellement vrai qu'avec le temps on voit fleurir un peu partout des générateurs de JS (coffeescript, dart etc), des bibliothèques d'abstraction pour simplifier la création de classes, y'a toute une réflexion sur asm.js, je connais même un guru javascript qui m'avoue générer son JS à partir de code coffeescript, tellement plus rapide et optimisé et je le comprend, alors effectivement la mort du JS c'est pas pour demain, mais je pense qu'on écrira de moins en moins de JS directement avec le temps, un peu comme quand l'assembleur a laissé peu à peu la main à des langages haut niveau, en tout ça fait un bail que j'ai pas démarré un projet conséquent directement en JS et...qu'est ce que ça fait du bien :)Citation:
Malheureusement pour eux, le JS devient de plus en plus omniprésent, donc ils vont être forcés à terme d'évoluer ou d’arrêter le développement
Tout dépend la définition que l'on se donne de "puissant", car au premier abord, ça ne veux pas dire grand chose.
Personnellement des que quelqu'un me parle d'un langage en me disant qu'il est puissant, j'ai peur. Car en général, il entend que le langage leurs évite de réfléchir à certains problèmes par magie, ce qui finit généralement par ce traduire par des performance mauvaises, parce que la magie ça a un coût, ou des comportement déroutants, car la magie, ça a ces limites.
Bref si on veux aller dans le complexe on se retrouve a apprendre tout le comportement que la magie essayait de cacher et on fini par ce retrouver avec quelque chose d'encore plus complexe que le problème initial.
C'est le problème le plus énervant de JS. On est obligé de l'utiliser (du moins dans un navigateur) non pas parce que c'est un bon langage, mais parce que l'on a pas le choix.
Quand je fais une application classique, c'est quand même bien agréable de pouvoir choisir le langage le plus adapté. Heureusement, maintenant, il y a des langages qui compilent vers Javascript, avec même des performances supérieure à du Javascript qui aurait été fait main, ce qui en dit long sur la "puissance" du langage.
Perso ça me fait penser que dans un monde idéal, le javascript ne serait pas un langage mais un bytecode du style de celui qui est avalé par la JVM. Càd des opérations simples, moins difficiles à implémenter et à optimiser pour les browsers et des langages qui compilent vers ce bytecode commun.
Parce que de fait, c'est à cela qu'on vient avec des dart2js, des asm.js, des coffeescript et autre. Bientôt la seule vraie différence ce sera qu'au lieu de compiler vers du bytecode, on le fera vers un sous-ensemble optimisé de javascript.
+1000Citation:
Parce que de fait, c'est à cela qu'on vient avec des dart2js, des asm.js, des coffeescript et autre. Bientôt la seule vraie différence ce sera qu'au lieu de compiler vers du bytecode, on le fera vers un sous-ensemble optimisé de javascript.
Ce que je trouve puissant dans le JS, c'est ce qu'il permet de faire avec des fonctions (callbacks, closures, fonction anonymes, redéfinitions, héritages) de manière simple et nécessitant un minimum de code, le json (on a rien inventé de plus minimaliste et léger pour décrire un objet), mais surtout et c'est à mon avis la "killer feature" le fait qu'il soit event driven. C'est bien sûr super adapté aux interfaces hommes/machines, mais également à internet (Ajax) et ça permet disons de simuler très facilement le multi-threading. Enfin, et la je te rejoint, il y a de nombreuses bibliothèques facilement utilisables et il est très souple, et effectivement cette forme de puissance est dangereuse en de mauvaises mains, surtout pour un langage comme JS quand il est fait une abstraction des principes de bases, ce qui mène à des comportements déroutants. C'est ce qui arrive quand par exemple des débutants qui font 2/3 "trucs de fou" avec JQuery essaient de customiser. Mais ça n'en reste pas moins un gage de puissance si c'est bien utilisé.
Ouais, ouais, c'est un peu lent, mais bon à quoi servirai la puissance de nos pc sinon? enfin quand c'est bien codé déjà, c'est pas si lent. Pour les langages qui compilent vers JS, excuse moi d'être sceptique, mais je vois pas comment on peut faire plus efficient dans ce sens là (ah si, si on code avec les pieds) sinon c'est comme dire que du C++ peut être plus efficient que de l'assembleur.
BPiero
Dart atteindra bientôt la version 1.0
le « JavaScript-killer » de Google se prépare pour la conquête du Web
Emily Fortuna, ingénieur logiciel chez Google, a déclaré pendant la Google I/O que Dart atteindrait bientôt sa version 1.0.
Annoncé comme un langage structuré pour la programmation Web, Dart 1.0 embarquera de nombreuses fonctionnalités comme la méthode cascade pour une modification des objets facilitée ou encore des arguments nommés pour améliorer la lisibilité et la recherche. Le framework JQuery sera lui aussi inclus.
L'une des nouveautés sera aussi que, contrairement à la version précédente, Dart 1.0 sera désormais supporté par tous les navigateurs. « Nous pouvons le compiler en JavaScript, alors nous avons le soutien de n'importe quel navigateur », explique Fortuna.
Les ingénieurs de Google travaillent également sur la prochaine version de GWT (Google Web Toolkit), qui sera publiée l'année prochaine. Ray Cromwell, ingénieur de l'entreprise, explique que leur objectif est de rendre GWT plus modulable et plus rapide. Il ajoute que les deux projets évoluent de façon orthogonale, en d'autres mots, « Dart ne saurait remplacer GWT et vice-versa ».
GWT 3.0 supportera Java 7 et 8, ainsi que les applications hybrides ; GWT sera compilé avec des bibliothèques JavaScript externes. Les navigateurs mobiles modernes devraient pouvoir le supporter.
Source : keynote Google I/O
Et vous ?
:fleche: Que pensez-vous de Dart 1.0 et GWT 3.0 ?
:fleche: Avez-vous déjà utilisé des versions précédentes de ces outils ? Lequel a le plus captivé votre intérêt ?
Ca fait vraiment plaisir !!!
Je suis Dart depuis déja un moment. Les tests que j'ai effectué dessus m'ont incité à utiliser ce langage dans mes projets persos au lieu de Javascript.
Question prise en main et facilité de débuggage, c'est le jour et la nuit avec Javascript, que j'ai encore pratiqué très récemment et sur lequel j'ai pas mal peiné (quand un "for...in" te fait planter le script à la sortie de la boucle (debug (avec des alert) normal) et que tu dois corriger avec un while...)
Niveau performances, je n'ai rencontré aucun accroc et les benchs montrent des performances tout à fait correctes du dart2js.
Un langage que je vais continuer à pratiquer pour garder une alternative sympa au Javascript.
Me concernant, niveau productivité et "fun", c'est incomparable.
est-ce que gwt 3 pourra générer du code dart au lieu de javascript?
Salut à tous.
Alors, je n'ai jamais testé Dart et je fais pas mal de JS donc je ne sais pas du tout ce que ça donne.
Mais je me demande quand même, quel est l'intérêt de coder en autre chose qu'en JS si au final le compilo' met tout en JS pour être exécuté dans le navigateur ? Parce que OK, Dart est dit plus simple à coder/debugger que JS, mais au final faut rajouter au temps d'exécution du JS, le temps de compilation en JS...
D'après moi, ça perd de son intérêt quand même.
Alors, il y a plusieurs intérêts. D'une part oui le gain de productivité et de "fun" est indéniable (sauf si tu maîtrise et aime javascript).
Deuxièmement, pour les gens pas forcément experts en javascript, le code généré est quand même de qualité. Dans certains cas, il est plus performant que du natif.
Enfin, le Dart n'est pas dynamiquement compilé en Javascript au chargement de la page. C'est à la compilation (dans l'IDE) qu'il est généré en Javascript, et c'est ce Javascript qu'il faudra déployer. Le Dart ne sert vraiment qu'au développement (sauf en utilisant la machine virtuelle Dart (uniquement dans Chrome) où là il explose Javascript).
Donc, si tu es expert en Javascript, ça aura sûrement peu d'intérêt, car tu sauras sûrement optimiser mieux que Dart2JS et tu ne galèreras pas comme beaucoup. Le problème c'est que j'ai l'impression que dans notre milieu, être expert en Javascript n'est pas très courant. Donc pour la maintenabilité, ça peut être utilise aussi.
Pour moi javascript n'est pas adapté à l'industrialisation. Attention, je ne dis pas par là que ce n'est pas possible. On sera toujours capable de faire des quick-win pour que ça marche.
Cependant, pour moi, un bon langage est un langage industriel : Travail par composant (package), Objet, design pattern...
Javascript est un langage de prototypage, ce n'est pas une critique, mais pour moi, un langage type Dart est forcement meilleur et plus confortable tant pour le développeur que pour le logiciel développé (maintenabilité, code plus clair, immersion plus facile pour un tiers...)
Ce sont ces derniers point qui font que j'ai déjà commencé à coder en Dart, et que je vais quasi certainement l'utiliser dès la sortie de la 1.0.
Moi je me demande quel est l'intérêt de coder en autre chose qu'en assembleur, puisqu'au final le compilateur ou la machine virtuelle convertit tout en langage machine... ;)
Javascript est l'assembleur du web
Pour une fois je suis plutôt voir entièrement d'accord !
Je suis de l'autre côté de la barre (j'adore, j'aime JavaScript. Je le maitrise ? Je ne sais pas vraiment, personne ne m'a "testé" et puis il faut que je progresse encore plus mais bon ...)
C'est encore une fois (c'est d'ailleurs toujours le cas) une question du goût. Tu aimes, tu n'aimes pas. Du côté de la machine, on en trouve des tas, C, C++, C#, Java, Python ... donc on peut choisir. Il est vrai que côté web client, il n'y a que JavaScript. Alors trouver une alternative, pourquoi pas, mais ne dénaturez pas pour autant ce langage !
Faire de la POO en Javascript, c'est tellement long et désagréable.
j'espere vraiment que DART va prendre beaucoup de place dans les prochaines années.
Si il peut l'être, je trouve simplement que Javascript n'évolue pas assez avec sont temps et l'utilisation que l'on en fait aujourd'hui. Sont approche n'a pas changé depuis des années, hors, notre approche du web elle a beaucoup évoluée. Hier javascript servait à gérer trois onclick, aujourd'hui on développe des Web App qui concurrencent directement les applications lourdes.
Enfin, si nous collectionnons les framework, les sur couches (CoffeeScript, TypeScript et j'en passe) signifie bien que l'on cherche à résoudre des problématiques que Javascript n'est pas nativement capable de gérer. De nos jours on développe même en GWT pour réaliser des applications html/css/js.......
Il y a quelque temps j'ai codé un petit projet perso en javascript...Evoluant dans le monde merveilleux du Java, ou tout est typé, objet et immédiatement compilé...J'ai pris une sacret baffe! Il est clair que javascript est très différent...pour ma part je m'en suis rendu compte lorsque j'ai tenté de remplir un tableau avec des variables :cry:
Aujourd'hui j'ai quelques années d'expériences en développement et je suis capable de prendre du recul sur mon travail. Mais il y a quelques temps, quand j'étais encore un jeune débutant, je pense que cela aurait été bien plus compliqué. C'est pourquoi je pense que la venu de framework comme GWT et de langage comme DART sont les bien venu et vont facilité le développement d'application web.
Un langage pas objet industrialisé à mort ? Le C. Plus du tout utilisé ? Ah ah.
JavaScript n'est pas un langage objet ? Ah bon. Apprends vraiment le JS et tu verras qu'en réalité, en JS, tout est objet (bon ok, à part quelques mots-clés)
Pas de design pattern en JavaScript ? Encore une fois : ah bon ? Ici j'en compte 27 parmi les grands classiques http://addyosmani.com/resources/esse...patterns/book/
Allez, bisous ;)
Il existe aujourd'hui un nombre incalculable de langages de programmation, mais les paradigmes et les concepts qui sont mis en œuvre dans ces langages sont en nombre limités et la plupart ont été inventés entre la fin des années 50 et le début des années 70. Le fait de "ne pas évoluer avec son temps" est donc une critique que l'on pourrait adresser à n'importe quel langage.
Le fait que JavaScript ait été utilisé pour gérer "trois onclick" n'implique pas qu'il ait été développé avec cette seule ambition. En effet, JavaScript, qui devait à l'origine s'appeler LiveScript, était destiné à devenir un langage de script pour le serveur http "Netscape Entreprise Server" et si son nom contient le terme "script", ce n'est pas parce qu'il s'agit d'un langage de programmation au rabais, mais parce qu'il est destiné un environnement d'exécution particulier (en l'occurrence un navigateur). Le fait que des applications concurrençant des « applications lourdes » aient pu être réalisées, montre d’une part les progrès qu’ont fait le html et les navigateurs et, d’autre part, que JavaScript est un vrai langage de programmation.
Tous les langages de programmation ont été développés pour permettre la création d'abstractions pour que les programmeurs puissent plus facilement gérer la complexité des programmes. Les variables, les procédures, les fonctions, les modules, les classes sont autant de moyens permettant la création d'abstractions. JavaScript n'utilise ni classe ni module, mais cela ne signifie pas qu'il ne dispose pas de moyens puissant pour créer des abstraction. En JavaScript, le principal moyen d'abstraction est la fonction qui est, dans ce langage, un objet de première classe (first-class citizen) et une fermeture (closure).
Si l'on aborde JavaScript en espérant y trouver les même concepts qu'en Java ou qu'en C#, il est évident que l'on risque d'être déçu, et je pense que si ce langage a une si mauvaise réputation, ce n'est pas tant à cause de ses défauts bien connus, mais plutôt à cause de programmeurs déçus de ne pas trouver dans ce langage ce qu'ils espéraient y trouver et qui n'ont pas voulu ou pas pu faire l'effort de regarder ce qu'il avait à offrir.
Même si un autre langage remplace un jour JavaScript dans les navigateurs, il reste pour l’heure le lingua franca des navigateurs et en tant que tel, le seul langage utilisable pour réaliser la partie cliente d’une application Web, il convient donc de l’apprendre lorsque l’on se considère comme un professionnel du Web. Cela étant dit, puisque tous les langages de programmation Turin-complet sont équivalents, il es possible de compiler n’importe quel langage en JavaScript et c’est une très bonne chose que de tels compilateurs existent. Si donc vous êtes plus à l’aise avec un autre langage, utilisez-le, mais ne dénigrez pas JavaScript parce qu’il ne correspond pas à vos attentes.
« Tout le monde est un génie. Mais si vous jugez un poisson sur ses capacités à grimper à un arbre, il passera sa vie à croire qu’il est stupide » (Albert Einstein)
Le fait d'avoir recours à un framework pour développer une application dans un langage n'implique pas que le langage ne soit pas adéquat (cela n'implique pas non plus qu'il le soit). Si c'était le cas, alors ni Java, ni C++, ni la plupart des langages couramment utilisé dans l'industrie du logiciel ne le serait. Les framework, comme les langages de haut niveau, servent à améliorer la productivité en évitant à chacun d'avoir à réinventer la roue.
CoffeScript, TypScript ou GWT ne sont pas des sur-couches, ce sont simplement des langages, comme Dart, qui disposent d'un compilateur vers JavaScript. GWT, va simplement plus loin en permettant le développement de la partie cliente et de la partie serveur de l'application (car oui, il n'est sans doute pas inutile de le rappeler, une application Web est une application client-serveur dont le processus client est un client http, le plus souvent un navigateur Web étendu avec un programme en html/JavaScript), mais une fois la compilation effectué, il y a peine plus de traces du langage de développement dans le programme en JavaScript qu'il n'y en a dans un programme en langage machine.
J'ai jamais dis que le C n'étais pas utilisé ;)
Et non désolé je trouve pas que le JS soit nativement Objet.
je fais de l'objet avec javascript, mais faut être honnête, utiliser la syntaxe {} ou les "function" pour créer une classe, c'est juste profiter d'un langage qui permet tout et n'importe quoi avec les mêmes mots clés. Ce langage est bien trop permissif.
Ok les framework sont très utiles je dis pas le contraire mais TypeScript, CoffeeScript pour moi c'est des langages crées avant tout pour combler des lacunes du JS ou apporter un peut de confort au développeur.
D'où l’intérêt d’être hyper rigoureux. Ce qui finalement n'est pas un mal. Ton idée me ferait presque dire que tes outils doivent te guider ta façon de pensée, que tu dois être souple à tes outils et non adapter tes outils à ton besoin.
Il y avait, il y a encore il y a quelques années le même débat avec PHP, ça c'est un peu tassé, sauf dans les gros nids à trolls. Depuis PHP a fait connaitre sa capacité à s'industrialiser, ses tares sont connues, ses forces aussi et on continue comme ça en faisant évoluer le langage. Pourquoi pas pareil avec le JS ? Plutôt que de réinventer la roue chacun de son coté, on ferait mieux de se concentrer sur la bonne évolution. EcmaScript 6 semble être particulièrement bien partie, non ? ;)
C'est une partie du problème je pense.
JS est un langage basé sur le prototypage, mais aujourd'hui on fait de l'objet avec.
Je ne connais pas les spec de EcmaScript6, c'est possible en effet :)
Cependant l'évolution de php est, je trouve, plus dynamique que l'évolution de js.
C'est là que je vois bien le problème. Il n'y a pas fondamentalement de problème à faire de l'objet à base de prototype. c'est juste une autre manière et c'est pas "aujourd'hui on fait de l'objet avec".
Cela te gène certes mais c'est un autre débat.
Note : pas de souci pour reconnaitre tout un tas d'autres problèmes à JS pour information.
Pourquoi comparer des pommes avec des bananes ? 8O
La comparaison me semble inappropriée. Le PHP est un langage serveur, et, malgré les actuels développements dans ce sens, JavaScript est à la base un langage client. Or, dans les méthodes actuelles de développement, on préconise, à juste raison me semble-t-il, la séparation des couches afin de faciliter la maintenance. Donc on sépare aussi strictement que faire se peut la partie client de la partie serveur. Il n'est donc pas vraiment justifié de comparer le développement du PHP avec celui du JavaScript.
JavaScript est un langage qui n'a pas souvent la faveur des développeurs en général, entendons par là les développeurs en langage serveur. La syntaxe n'est pas fondamentalement très différente, mais la manière de programmer en JavaScript n'est en revanche pas franchement comparable.
Si on en revient au sujet de départ, l'initiative de Google avec Dart tend à vouloir présenter justement une manière de programmer plus proche de telle sorte que ce que les développeurs, tels que je les ai présentés plus haut, aient moins de difficultés à développer la partie client des applications sur lesquelles ils ont à travailler.
J'ajouterais un autre élément en faveur de Dart : lorsque Rasmus a créé le PHP, il était tout seul. Le développement de Dart avait Google comme socle. Je n'irai pas jusqu'à dire que Rasmus ne fait pas le poids, ne charrions pas, mais les ressources techniques de Google ne souffrent pas beaucoup de comparaisons. On ne peut, à mon sens, pas vraiment craindre de voir l'évolution de Dart tourner en bazar infâme, les développeurs de Dart disposant de ressources autrement plus lourdes que celles dont disposait Rasmus. On a par exemple beaucoup moins de chance de voir apparaitre différentes syntaxes dans le nommage des fonctions natives, certains privilégiant le « _ » (underscore) alors alors que d'autre sont en CamelCase. Et ce n'est qu'un exemple franchement mineur, même s'il présente un des défauts du PHP (qui est malgré tout mon langage de programmation au quotidien). En outre, le simple fait que Google ait lâché d'entrée de jeu un compilateur permettant de générer un code JavaScript pour pallier aux manques existants des navigateurs qui n'ont pas adopté Dart me laisse à penser que l'idée de fond qui a prévalu au soutien de ce projet est solide et posée sur des bases qui n'ont absolument rien d'un bricolage sommaire.
L'évolution de JS est moins dynamique que celle du PHP ? Je ne parierais sûrement pas ma chemise là-dessus.
My 2¢ ;)
inappropriée dis-tu ?
On sépare les couches client/serveur, je suis tout à fait d'accord. Mais les deux reste lié, quand je compare les deux, je prends plus large.
De plus, aujourd'hui avec Nodejs on fait du client ET du serveur avec Javascript.
Tout comme le propose Dart et son très très bon package IO, donc oui je me permet de comparer les langages ;)
Aujourd'hui on travail de plus en plus avec les socket, l'asynchrone et nous nous orientons vers la programmations évènementielle sur une plateforme initialement en mode déconnecté (client/server).
Les requêtes deviennent transparentes, plus de rechargement de page, le même langages côté client et serveur.
Je ne pense pas que la comparaison avec un langage serveur soit inappropriée, bien au contraire. Un langage client/server (Javascript/Nodejs, Dart...), qui propose des Api pour travailler avec des outils de cache (redis/memcache) des bases de données ou des services type LDAP ou autres, permettra justement de se dispenser d'un second langage exclusivement serveur.
Conclusion, si demain nous avons un seul et unique langage proposant des outils et Api pour travailler aussi bien côté client que serveur avec une syntaxe et une philosophie proche des langages préférés des Dev Web, je pense, en effet, que celui-ci possède un fort potentiel pour être adopté.
:mouarf::mrgreen::lefou:Citation:
Dart se prépare pour la conquête du Web
J'ai failli m'étouffer là.
Sérieusement : Je ne crois pas un seule instant à ce langage Quoique Apple à bien réussi à mettre en place un langage du même style, et par style j'entends : Un langage élitiste, dont uniquement une poignée de gourou comprennent le fonctionnement, avec un besoin boulimique d'outils propriétaire pour faire tournée le machin, je n'ai qu'un seule demande, si ce machin surpasse une bon vieux Notepad avec de l'HTML et du JS : Filez moi un coup sec derrière la nuque ! On à déjà assez avec l'Objective-C...