Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
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
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)
Fais comme moi Zero HTMLEnvoyé par Lutarez
enfin presquedu 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.
Code html : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
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
Comme je ne savais jamais comment amorcer quelque chose en Js, j'ai adopté Dart parce qu'il avait tout simplement un main()...
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)
T'aurai un exemple de ces Frameworks ? Je suis assez curieux.
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.Comme je ne savais jamais comment amorcer quelque chose en Js, j'ai adopté Dart parce qu'il avait tout simplement un main()...
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$(document).ready(function(){ // Ton code JS ici )};
2
3
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().
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
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
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
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) ?
J'aurais préféré qu'on réinvente CSS plutôt que JavaScript à choisir
Enfin, ça reste une bonne nouvelle pour l'innovation.
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.
@ 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
Ç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
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.Heu QUOI QUOI
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
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.
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 ^^
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 ?
Pour ma part, je trouvais que Flash Builder et ActionScript est (était ?) très bien...
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
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...
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 ?
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.
Répondre avec citation
Partager