Dart : l’alternative de Google à JavaScript prête pour la conquête du Web

Version imprimable

Voir 40 message(s) de cette discussion en une page

13/12/2013, 16h43
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
13/12/2013, 17h18
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)

Citation:

Envoyé par Lutarez

...
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:

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

13/12/2013, 19h01
conscofd

Comme je ne savais jamais comment amorcer quelque chose en Js, j'ai adopté Dart parce qu'il avait tout simplement un main()...:oops:
13/12/2013, 19h09
Lutarez

Citation:

Envoyé par sekaijin

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 :aie:)

Citation:

Envoyé par sekaijin

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.

Citation:

Envoyé par conscofd

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

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().
13/12/2013, 20h14
sekaijin

Citation:

Envoyé par Lutarez

...
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 )
...
T'aurai un exemple de ces Frameworks ? Je suis assez curieux.

j'utilise ExtJS

pour ta première remarque
[ame="http://vimeo.com/36420727"]Building a Sencha Touch Mobile App with Sencha Designer 2 Beta on Vimeo[/ame]
[ame="http://vimeo.com/78866031"]Templates in Architect 3 on Vimeo[/ame]

A+JYT

Citation:
Envoyé par sekaijin
Fais comme moi Zero HTML
enfin presque
Code:

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.

14/12/2013, 13h11
sekaijin

Citation:

Envoyé par LSMetag

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.

Heu QUOI QUOI 8O8O8O8O
lorsque tu fais new Menu en C++ tu dois savoir ce que ça va faire en terme de dessin ??? Je n'ai absolument aucune idée de ce que fais exactement ExtJS lorsque je fais new Menu ce que je sais c'est que ça affiche un menu déroulant à l'endroit que j'ai choisi et qui réagit comme je m'y attends exactement ce que je constate sous Windows avec C++

quant au serveur je ne vois absolument pas ce qui vient faire là vu que c'est le client qui exécute le code. on pourrait penser que du coup le code côté client est lourd il n'en est rien en fait c'est même le contraire. lorsqu'on produit du HTML et qu'on veut lui attacher du js ont doit produire un code HTML qui génère un DOM puis du JS qui explore ce DOM et ensuite les fonctionnalité JS qu'on veut lui adjoindre. alors que la on instancie un objet JS qui va Produire le DOM donc plus de HTML et qu en plus va lui attacher les comportement attendu. pas besoin d'explorer le DOM vu que lorsqu'on produit un élément on lui attache tout ce dont il a besoin.
au final on a un code simple concis efficace et facile à maintenir dans un seul langage. exactement ce qu'on a si on développe un client lourd en C++ sous windows. avec en plus la portabilité de l'application et le déploiement à la volée. ce que je constate c'est que mes échange avec le serveur diminue. entre la moitié et un tier pour l'IHM de l'appli que les échanges pour les données sont réduit à de simples données JSON et que la charge serveur baisse d'environs à 60% à 70% par rapport à une web app traditionnelle (30% à 40% de gain).

A+JYT

Citation:
Envoyé par sekaijin
Fais comme moi Zero HTML
enfin presque
Code:

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>
Tout ça c'est bien gentil. Pour les webapps c'est même pas mal du tout.

Mais pour les sites internet traditionnels ça serait un cauchemar pour les différents intervenants qui ne sont pas développeurs. D'autant que ces sites changent souvent d'apparence. On ne va pas faire appel aux développeurs dès que l'apparence change alors que c'est plus du boulot du graphiste.

Avec ce principe app-all.js (comme ExtJS) comment est géré le MVC ? Même question pour le Dart. Je veux dire, la partie view de MVC, c'est du code Dart/Js ou alors ce sont des descripteurs de fichiers type XML/HTML (ou autres templates swing/smarty) ?

14/12/2013, 19h18
SylvainPV

J'aurais préféré qu'on réinvente CSS plutôt que JavaScript à choisir :P
Enfin, ça reste une bonne nouvelle pour l'innovation.

Citation:

Envoyé par sekaijin

Fais comme moi Zero HTML
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.

Je trouve que c'est un comble pour un dev qui réalise une interface qu'il ne sache même pas quelle techno est utilisée. Il y a quand même des avantages et des contraintes propres à chacune, SVG ou canvas c'est vectoriel ou bitmap, pas vraiment un choix qu'on fait à la légère.

C'est bien de se reposer sur des frameworks qui font le boulot à notre place, mais ça n'empêche pas de jeter un oeil au HTML généré pour voir si ça tient la route. Parfois, on a de mauvaises surprises avec certaines librairies UI : typiquement des tas de <div> et de <span> embriqués les uns dans les autres sur cinq niveaux, sans aucun effort porté sur l'accessibilité, la sémantique et l'indexation sur les moteurs de recherche. D'ailleurs le <body> vide sans même un <noscript> c'est une hérésie pour moi.
14/12/2013, 19h37
sekaijin

@ phili_b
Dart a ete principalement créé pour faires application pas des site Web

quant au MVC je ne vois pas le problème lorsque tu compile ton appli c++ tu as bien un exe alors que tu utilise MCV pourquoi un compilateur JS ou Dart ne pourrait-il pas faire de même.

@SylvainPV
Je maintiens que lorsqu'on fait une application on ne regarde pas le code binaire généré pour tracer une ligne lorsu'on fait un menu, une fenêtre, un panel, une grid. pourquoi devrions nous systématiquement revenir au niveau des couche basse dans les appli web ?
Je suis d'accord qu'il faut se méfier de certaine lib UI qui on tendence à surcharger le DOM.
A+JYT
14/12/2013, 20h49
SylvainPV

Ça dépend de où tu fixes la limite entre couche basse et couche haute. Entre analyser un code binaire et savoir si un composant est en SVG ou canvas, il y a un écart de taille !

D'après moi, quand le choix d'une techno peut changer significativement un aspect fonctionnel ou une méthode de développement, il est impératif que le développeur en soit conscient et fasse son choix en toute connaissance de cause. Pour reprendre ton exemple : tu veux tracer une ligne, et tu te moques de savoir si cette ligne est tracée en vectoriel ou en bitmap. Jusqu'au jour où tu testes le site sur un écran à haute densité de pixels et là, PAF, ta belle ligne est bourrée d'aliasing :aie: . Ce n'est pas pour autant que tu aurais forcément opté pour du SVG, mais au moins tu aurais pu anticiper le problème.
14/12/2013, 23h16
LSMetag

Citation:

Envoyé par sekaijin

Heu QUOI QUOI 8O8O8O8O
lorsque tu fais new Menu en C++ tu dois savoir ce que ça va faire en terme de dessin ??? Je n'ai absolument aucune idée de ce que fais exactement ExtJS lorsque je fais new Menu ce que je sais c'est que ça affiche un menu déroulant à l'endroit que j'ai choisi et qui réagit comme je m'y attends exactement ce que je constate sous Windows avec C++

quant au serveur je ne vois absolument pas ce qui vient faire là vu que c'est le client qui exécute le code. on pourrait penser que du coup le code côté client est lourd il n'en est rien en fait c'est même le contraire. lorsqu'on produit du HTML et qu'on veut lui attacher du js ont doit produire un code HTML qui génère un DOM puis du JS qui explore ce DOM et ensuite les fonctionnalité JS qu'on veut lui adjoindre. alors que la on instancie un objet JS qui va Produire le DOM donc plus de HTML et qu en plus va lui attacher les comportement attendu. pas besoin d'explorer le DOM vu que lorsqu'on produit un élément on lui attache tout ce dont il a besoin.
au final on a un code simple concis efficace et facile à maintenir dans un seul langage. exactement ce qu'on a si on développe un client lourd en C++ sous windows. avec en plus la portabilité de l'application et le déploiement à la volée. ce que je constate c'est que mes échange avec le serveur diminue. entre la moitié et un tier pour l'IHM de l'appli que les échanges pour les données sont réduit à de simples données JSON et que la charge serveur baisse d'environs à 60% à 70% par rapport à une web app traditionnelle (30% à 40% de gain).

A+JYT

Ha désolé, je parlais avec une vision ASP.NET, donc d'une appli internet client/serveur. C++ c'est pas du tout mon rayon. En .NET on a des composants serveurs qui sont interprétés ensuite en HTML + éventuellement Javascript et CSS. Donc oui, dans ce cas je dois savoir à l'avance quelles balises HTML IIS va créer pour le client pour un composant "Panel" (ce sera un Div dans ce cas) ou si l'id ne sera pas modifié par exemple, pour pouvoir adapter la CSS en conséquence voire rajouter une couche de JS derrière.

C'est pour ça que je parle de double interprétation. Côté IIS, puis côté client. Et c'est pour ça que je dis : autant tout coder en client quand c'est possible et pas sensible niveau sécurité.

Après, tu devais sûrement penser à un autre cas de figure.
16/12/2013, 10h57
frfancha

Citation:

Envoyé par LSMetag

...Et c'est pour ça que je dis : autant tout coder en client quand c'est possible...
Après, tu devais sûrement penser à un autre cas de figure.

Mais vous êtes d'accord! C'est cela qu'il t'explique depuis 10 posts.
16/12/2013, 14h59
LSMetag

Citation:

Envoyé par frfancha

Mais vous êtes d'accord! C'est cela qu'il t'explique depuis 10 posts.

Lol alors ça nous fait un beau quiproquos. Quand il parlait de zéro HTML et ne laissais que le CSS et le JS, je me disais qu'il faisait tout par serveur.

J'avais pas tilté qu'il utilisais ExtJS, que je ne connais pas du tout mais dont j'entrevois le principe maintenant.
Etre du même avis qu'un Expert Confirmé Senior, c'est quand même la classe ^^
16/12/2013, 16h04
patmaba

Pourquoi l'ECMA a créé un groupe d'évaluation de DART ?

Et Pourquoi pas pour Microsoft TypeScript ?

Qu'est ce qui a incité ECMA a faire cette évaluation ?

Comment vont-il l'évaluer ?
16/12/2013, 16h16
arfany

Pour ma part, je trouvais que Flash Builder et ActionScript est (était ?) très bien :) ...
16/12/2013, 17h07
Lutarez

Citation:

Envoyé par patmaba

Pourquoi l'ECMA a créé un groupe d'évaluation de DART ?
Et Pourquoi pas pour Microsoft TypeScript ?

Peut-être parceque Dart est la première (il me semble) des alternatives à JS a être arrivé en version 1.0 à l'heure actuelle.

De plus, le monde de l'informatique est assez vaste pour accueillir encore d'autres alternatives sans problème (en natif, c'est pas les langages qui manquent :aie:).

Citation:

Envoyé par sekaijin

j'utilise ExtJS

En effet, je n'y avais pas pensé sur le coup. J'y ai pourtant jeter un œil il n'y a pas si longtemps. Mais même si le fonctionnement théorique est intéressant, ce n'était pas du tout adapté à mes besoins, du coup...
17/12/2013, 10h10
Kaamo

Il ne faut pas confondre Dart avec TypeScript ou CoffeeScript.

Les deux derniers génèrent du JavaScript en permettant aux développeurs de s'affranchir de connaitre les inepties du JavaScript.

Dart est aussi un transpileur mais il peut également tourner en stand-alone à l'aide d'une VM Dart.

Vous ne voyez pas la finalité ? A terme, les navigateurs proposeront toujours une VM JavaScript mais également une VM Dart.

C'est là que ce nouveau comité 52 intervient. Poser les bonnes spécs et standards pour que les autres (que Google) vendeurs puissent implémenter leur propre VM Dart et pour qu'ils aient également leur mot à dire dans les directions/choix à prendre.

La vrai question c'est : Pourquoi aller vers une VM Dart (JavaScript killer/challenger) alors qu'on pourrait améliorer JavaScript ?
17/12/2013, 10h50
Lutarez

Citation:

Envoyé par Kaamo

La vrai question c'est : Pourquoi aller vers une VM Dart (JavaScript killer/challenger) alors qu'on pourrait améliorer JavaScript ?

Pourquoi avoir inventer le C et C++ alors que le Pascal ou SmallTalk existaient déjà ? L'évolution en informatique ne se fait pas que par mise à jour des technologies, mais aussi par la naissance de nouvelles.

Il suffit de faire quelques recherches sur internet pour se rendre compte que JS est loin de donner satisfaction à beaucoup de développeurs. L'évolution du JS continue en parallèle de toute façon. Dart réponds par ailleurs a un besoin différent de JS, vu qu'il se destine au web apps.

Bref, c'est pas parcequ'un nouveau langage apparaît que JS va disparaitre. Cela permettra simplement d'ouvrir davantage le développement web en offrant plus de solutions. A chacun ensuite de choisir les technologies qui conviennent mieux.

Voir 40 message(s) de cette discussion en une page