Discussion :

[Hinault Romaric]

Le Web a besoin de plus de langages de programmation pour rivaliser avec le « natif »
selon un ingénieur de Google à l’origine de Dart

Le monde du développement informatique dispose d’une pléthore de langages de programmation. Mais, si on se limite au domaine du Web, le nombre de langages de programmation disponible serait insuffisant.

C’est en substance l’idée qu’a fait passer Gilad Bracha, ingénieur chez Google et membre de l’équipe à l’origine du langage de programmation structuré pour le Web Dart.

S’exprimant lors de la conférence des développeurs QCon de New York, celui-ci a affirmé que les applications Web pourraient un jour dépasser les applications Desktop (natives) en performance, en fonctionnalités et en facilité d’utilisation si les développeurs ont plus de choix dans les langages de programmation Web qu’ils peuvent utiliser.

« Je pense que sur la plateforme Web, on peut faire des applications meilleures que les applications natives. En fin de compte, on devrait le faire. Sinon, nous serons tous dévorés par les galeries d’applications propriétaires », a déclaré Gilad Bracha.

Le premier atout du développement Web par rapport au développement natif est le fait que les applications Web peuvent s’exécuter sur plusieurs plateformes et n’ont pas besoin d’être installées. Cependant, son inconvénient majeur est le fait qu’il ne fonctionne pas en absence de connexion réseau.

Bracha estime qu’il est essentiel que les langages Web et les écosystèmes associés puissent offrir un moyen d’utiliser les applications hors connexion. Les prochains langages de programmation Web doivent également permettre de créer et effectuer facilement des tests.

Actuellement, le Web repose essentiellement sur le langage de programmation JavaScript qui est cependant, selon Bracha, déficient dans plusieurs scénarios, notamment la possibilité d’utiliser l’application hors ligne. De plus, du fait que le langage soit normalisé, son évolution est lente. « JavaScript est basé sur la norme EcmaScript, qui peut prendre des années pour être mise à jour. Il devrait être plus facile de faire ces choses », regrette celui-ci.


Il existe d’autres langages de programmation Web qui n’ont pas eu beaucoup de succès à cause de leurs faiblesses. C'est pourquoi Google a créé le langage de programmation Dart, non pas comme un remplaçant de JavaScript, mais pour offrir plus d’alternatives aux développeurs, selon Bracha.

Celui-ci a également cité quelques autres langages de programmation Web qui sont moins connus et encore au stade expérimental, mais qui sont assez prometteurs. Il s’agit notamment de Elm, un langage de programmation fonctionnelle pour la création d’interface graphique disposant d’une prévisualisation instantanée des modifications, sans que le code ne soit enregistré. Bracha a également cité Lively, Leisure et Newspeak.

Au final, Bracha estime que la concurrence est bonne pour tout le monde, et le web devrait aussi avoir son lot de langages de programmation, comme pour l’univers du développement natif.


Source : QCon


Et vous ?

Que pensez-vous de l'avis de Bracha ? Le Web a-t-il besoin de nouveaux langages de programmation ?

[Gugelhupf]

D'accord, on parle bien de langage de script exécuté coté client (navigateur) et monopole du langage JavaScript, et non pas de langage serveur...

[Tryph]

je suis pas certain de comprendre exactement ce que le monsieur reproche au manque de langage web mais comme je le comprends pour le moment, y a un truc qui cloche dans son analyse.

en fait je vois pas de quel manque il parle.
s'il veut faire des applications qui fonctionnent hors ligne, n'importe quel langage de programmation "natif" fait l'affaire. avec une connexion avec des services web, elle peuvent parfaitement utiliser des focntionalités dans le cloud.
après y a la problèmatique de l'utilisation sur n'importe quelle plateforme indiféremment, mais on dispose de Python et de Java (et d'autres?) si on veut faire du multiplateforme. ça me parait pas pire d'utiliser de genre de techno que de vouloir passer par un navigateur.
on peut arguer que quasiment tout le monde a au moins un navigateur sur son poste mais que tout le monde n'a pas une version de Python ou de Java, mais tout le monde n'a pas un navigateur récent qui dispose des dernières implémentations des standards.

bref, je suis pas certain que le tout web+navigateur soit toujours la meilleure solution.

[frfancha]

je suis pas certain de comprendre exactement ce que le monsieur...

Y a rien a comprendre c'est juste une pub pour DART par rapport à javascript.

[Saverok]

Que pensez-vous de l'avis de Bracha ? Le Web a-t-il besoin de nouveaux langages de programmation ?

Chaque langage a ses atouts et ses inconvénients
Il est donc toujours bon d'avoir le choix afin de choisir le langage le mieux adapté aux besoins

Par contre, cela implique t-il la multiplication des interpréteurs ?
Actuellement, les moteurs JS n'ont pas les mêmes perf en fonction des navigateurs
Il me semble que Dart se compile en JS donc pas trop de soucis mais en est-il des autres langages ?
Chaque navigateur devra t'il implémenter son propre interpréteur pour chaque langage ?
Si oui, seuls les gros pourront suivre (et encore) et cela tuera dans l’œuf les nouveaux projets sans compter que les perf des navigateurs en prendront un sacré coup

« Je pense que sur la plateforme Web, on peut faire des applications meilleures que les applications natives. En fin de compte, on devrait le faire. Sinon, nous serons tous dévorés par les galeries d’applications propriétaires », a déclaré Gilad Bracha.

En quoi les galeries d'applications sont elles un passage obligé ?
Cela n'existait pas avant l’avènement du mobile et on installait bien des appli sur nos PC avant ça

Côté perf, les latences du réseau seront tjrs un frein pour les applications web
De plus, les appli web ne peuvent pas accéder aux ressources matériels du device
Donc à partir du moment où l'appli a besoin d'utiliser les périphériques du genre positionnement GPS, appareil photo / webcam, micro, etc. Le passage par une appli lourde reste une voie obligatoire

[super_navide]

Je pense qu'il faut pouvoir coder en java dans une page web(avec toute les règle de sécurité qu'il faut comme pas d’accès aux fichier locaux , pas de possibilité d’exécuter des programmes locaux ), javascript c pas typé donc très difficile à maintenir et moins puissant qu'un langage typé ( lien dynamiqe à l'execution ), en plus javascript n'est Multi-thread, a l'heure des
multicoeur c un défaut de taille

[SylvainPV]

Non, le Web ne repose pas essentiellement sur JavaScript. Le Web est infiniment plus complexe que ça, et ne serait pas ce qu'il est sans la multitude de technos/langages/solutions/matériels sous-jacents. Même si l'on se concentre sur la partie cliente, le front-end, ce n'est pas JavaScript qui est essentiel mais HTML. On peut faire un site sans JavaScript, mais pas sans HTML. Je sais qu'il n'est pas forcément approprié de parler de langages de programmation pour désigner HTML, CSS ou des formats comme JSON ou encore SVG, mais ce sont ces technos et formats qui sont essentiels pour la popularité de JavaScript. Imaginez JavaScript sans les API document, sans l'objet window, sans les API HTTP de Node.js...

Je ne vois pas en quoi la pluralité des langages aiderait le Web. On a plusieurs fois décrit JavaScript comme l'assembleur du web, dans le sens où beaucoup de langages étaient transpilés en JavaScript pour un usage web. Le terme "assembleur" contraste nettement avec le côté "haut niveau" du langage, mais l'idée générale est là : un langage universel et fédérateur, normalisé par des organismes publics reconnus. On en a pas besoin de plusieurs, ça ne ferait qu’alourdir les navigateurs et diviser la communauté de développeurs web front. Si vous voulez utiliser un autre langage, libre à vous de transpiler comme le font déjà CoffeeScript, TypeScript et Dart. La transpilation en JS convient très bien, et je préfère largement l'approche de Mozilla avec asm.js que celle de Google et sa VM Dart qui tend à privatiser le Web front-end.

son inconvénient majeur est le fait qu’il ne fonctionne pas en absence de connexion réseau.

C'est faux, faire un mode semi-déconnecté est tout à fait possible pour une application web, j'ai déjà plusieurs sites à mon actif qui fonctionnent très bien en offline.

[cGuille]

Je ne comprends pas trop le rapport entre les problèmes dont il parle et le nombre de langages dispos dans le navigateur.

JavaScript serait "déficient dans […] la possibilité d’utiliser l’application hors ligne".
Aucun rapport avec le langage AMHA. C'est lié aux API proposées par les navigateurs. C'est en route (je pense à IndexedDb), et ça sera dispo à travers JS.
Pour des choses simples, on a déjà le localStorage, lui aussi disponible depuis JS.

Sur la lenteur du standard ECMA, il préfère quoi ? Pas de normalisation ? Donc chaque nav fait comme il veut et c'est le bordel ? Pourquoi un autre standard évoluerait-il plus vite ?

Ce sont les seuls arguments qu'il utilise et ils sont de mon point de vue hors-sujet.

Je ne suis pas contre proposer des langages différents, pour pouvoir écrire le code différemment selon nos goûts. Mais bon, on ne risque pas de multiplier les problèmes d'incompatibilité ?
En tout cas c'est pas en me disant que "JS ne permet pas les apps hors-lignes" ou que "la norme EcmaScript évolue trop lentement" que je serai convaincu…

[cGuille]

De plus, les appli web ne peuvent pas accéder aux ressources matériels du device
Donc à partir du moment où l'appli a besoin d'utiliser les périphériques du genre positionnement GPS, appareil photo / webcam, micro, etc. Le passage par une appli lourde reste une voie obligatoire

C'est faux : depuis HTML5, le navigateur propose des API pour accéder au device : localisation, vibreur, batterie, webcam/micro… même du calcul sur le GPU si mes souvenirs sont bons.

[Marco46]

On peut faire un site sans JavaScript, mais pas sans HTML. Je sais qu'il n'est pas forcément approprié de parler de langages de programmation pour désigner HTML, CSS ou des formats comme JSON ou encore SVG, mais ce sont ces technos et formats qui sont essentiels pour la popularité de JavaScript. Imaginez JavaScript sans les API document, sans l'objet window, sans les API HTTP de Node.js...

Un site web oui mais une appli web non. Impossible sans javascript.

C'est faux, faire un mode semi-déconnecté est tout à fait possible pour une application web, j'ai déjà plusieurs sites à mon actif qui fonctionnent très bien en offline.

Je suis d'accord c'est un problème d'architecture pas de langage. Il est tout a fait possible d'avoir un front-end autonome qui va fonctionner sans connexion.

[SylvainPV]

Le mot "appli web" ou "web app" n'a pas de définition objective, il y a une large part de subjectivité quant aux critères en fonctionnalités et expérience utilisateur attendues pour pouvoir parler de web app. J'ai vu des choses extrêmement impressionnantes en CSS ou en SVG qui n'utilisaient pas JavaScript. Par exemple ce clône de Duck hunt : https://developer.mozilla.org/en-US/...tail/duck-hunt

[Uther]

Le premier atout du développement Web par rapport au développement natif est le fait que les applications Web peuvent s’exécuter sur plusieurs plateformes et n’ont pas besoin d’être installées.
[...]
De plus, du fait que le langage soit normalisé, son évolution est lente. « JavaScript est basé sur la norme EcmaScript, qui peut prendre des années pour être mise à jour. Il devrait être plus facile de faire ces choses », regrette celui-ci.

Là, le monsieur est juste contradictoire. C'est parce que le langage est normalisé qu'il peut être déployé sur de multiple plateformes. Si on commence a introduire des langages qui ne reposent pas sur une plateforme normalisée commune, on perd immédiatement le principal avantage d'une application web.
On peut pas avoir le beurre et l'argent du beurre, ...

Que pensez-vous de l'avis de Bracha ? Le Web a-t-il besoin de nouveaux langages de programmation ?

Oui et non. De nouveaux langages coté client, certainement, Javascript a de très nombreux défauts et malgré tous les améliorations qu'il a connu ces dernières années, il n'est clairement pas la meilleure solution a tous les problèmes.

Mais de nouveaux langages qui reposent sur leur propre infrastructure supportée uniquement par leur créateur, comme ce qu'essaye de faire Dart a long terme, pitié non. Si tout le monde procède ainsi, cela conduirait à une fragmentation du web.

Pour moi l'idéal serait une vraie plateforme d'abstraction qui permettrait un recours à n’importe quel langage. Un peu comme ce que Google veux faire avec pNaCl, mais qui reposerait sur les API du Web et pas sur une technologie de plugin qui leur est propre(PPAPI) et avec une vraie normalisation supervisée par un organisme comme le W3C ou WhatWG, ... pour garantir un support par tous les acteurs.
Ça prendrait certes du temps, mais on aurait quelque-chose de vraiment efficace, équitable et pérenne. Et en attendant on peut toujours faire de la compilation vers JavaScript ce qui semble fonctionner relativement bien pour Dart et asm.js.

s'il veut faire des applications qui fonctionnent hors ligne, n'importe quel langage de programmation "natif" fait l'affaire. avec une connexion avec des services web, elle peuvent parfaitement utiliser des fonctionnalités dans le cloud.

Mais avec du natif tu perds l’installation transparente et le multi plateforme, sans installation préalable d'un framework lourd sur le client. Les navigateurs.
En effet l'idée repose sur le fait que l'on ne reste pas avec une version antédiluvienne de son navigateur, mais c'est heureusement de moins en moins le cas surtout depuis que les principaux navigateurs font des mises a jour automatiques.

Côté perf, les latences du réseau seront tjrs un frein pour les applications web
De plus, les appli web ne peuvent pas accéder aux ressources matériels du device
Donc à partir du moment où l'appli a besoin d'utiliser les périphériques du genre positionnement GPS, appareil photo / webcam, micro, etc. Le passage par une appli lourde reste une voie obligatoire

Regarde toutes les dernière API validées ou en cours de validation par le W3C, tu verras qu'il ne reste plus grand chose qui ne soit pas réalisable par des appli Web, obtenir un positionnement GPS est un très bon contre exemple car c'est possible aux appli web depuis bien longtemps maintenant.
Et l'API de cache d'application de HTML5 permet justement de faire des application Web qui peuvent persister en cache sur le client pour ne plus dépendre du réseau

Je ne vois pas en quoi la pluralité des langages aiderait le Web. On a plusieurs fois décrit JavaScript comme l'assembleur du web, dans le sens où beaucoup de langages étaient transpilés en JavaScript pour un usage web. Le terme "assembleur" contraste nettement avec le côté "haut niveau" du langage, mais l'idée générale est là : un langage universel et fédérateur, normalisé par des organismes publics reconnus. On en a pas besoin de plusieurs, ça ne ferait qu’alourdir les navigateurs et diviser la communauté de développeurs web front. Si vous voulez utiliser un autre langage, libre à vous de transpiler comme le font déjà CoffeeScript, TypeScript et Dart. La transpilation en JS convient très bien, et je préfère largement l'approche de Mozilla avec asm.js que celle de Google et sa VM Dart qui tend à privatiser le Web front-end.

Oui et non on peut certes compiler vers du Javascript, et c'est certes ce qu'il se fait de mieux actuellement, sans recourir a des plugins qui fragmentent le web. Je suis entièrement d'accord sur le fait qu'intégrer Dart au navigateur est un hérésie.
Mais recourir au JavaScript pour ça n'est clairement pas une solution propre techniquement, il n' absolument pas été conçu pour faire ce travail de manière optimale, et ca se ressent forcément sur les performances. Une solution alternative serait bienvenue, à condition bien sur qu'elle soit ouverte et normalisée.

[abriotde]

L'unité qu'offre javascript n'est pas pour déplaire. Le fait qu'il évolue lentement mais surement (au sens ou il évolue dans le bon sens), est plutôt a son avantage. Le développeur peut aisément s'adapter et utiliser tout son potentiel. Ce que l'on peut imaginer pour optimiser les performances, ce n'est pas avant tout un langage de programmation, ce serait plus un environnement. Par exemple convertir les pages HMTL/Javascript en binaire pour prendre moins de place (compressé cela existe déjà, c'est le mode deflate). Plutôt coder chaque lettre sur un octet au lieu de plusieurs (surtout en utf8). Seul les chaîne de caractères resteraient en UTF8/UTF16. On gagnerait alors en bande passante et en temps de d'exécution. On peut aussi imaginer le compiler en byte-code...

Bref ne rien changer pour l'utilisateur ni pour le développeur, mais tout optimiser pour l'ordinateur. Certes quand ceci sera fait on pourra imaginer un langage plus stricte permettant une meilleur optimisation/compilation en byte-code (Comme le Dash).

L'idée au final reviens a revenir aux applets Java...

[SylvainPV]

recourir au JavaScript pour ça n'est clairement pas une solution propre techniquement, il n' absolument pas été conçu pour faire ce travail de manière optimale, et ca se ressent forcément sur les performances. Une solution alternative serait bienvenue, à condition bien sur qu'elle soit ouverte et normalisée.

Oui je suis d'accord, je pense qu' asm.js pourrait être cette solution alternative, sans transition trop abrupte pour assurer la rétrocompatibilité.

[Uther]

Pour moi asm.js, n'est pas la solution alternative, c'est la solution actuellement disponible en espérant que le W3C oiu le WHATWG se décide a envisager une nouvelle norme plus adaptée a d'autres langages.

asm.js a le mérite de se baser sur Javascript qui est déjà normalisé et permet d'avoir un code aussi optimal que possible avec un langage qui n'est pas du tout prévu pour cela. Cela dit, ça reste un affreux bricolage, inutilement lourd a télécharger et compiler et optimiser par rapport a un bytecode qui serait prévu pour.

[Fanvan]

J'ouvre l'article, me disant qu'il y a peut-être là quelque chose d'intéressant. Le point de vue d'un des membres de l'équipe de dart sur l'écosystème web, ça peut toujours être intéressant à écouter.

Et puis en lisant qu'un employé de Google avait déclaré ça :

« Je pense que sur la plateforme Web, on peut faire des applications meilleures que les applications natives. En fin de compte, on devrait le faire. Sinon, nous serons tous dévorés par les galeries d’applications propriétaires »

Je me suis dit que je n'ai pas perdu mon temps. Au moins, j'aurais bien ri.

[Marco46]

J'ouvre l'article, me disant qu'il y a peut-être là quelque chose d'intéressant. Le point de vue d'un des membres de l'équipe de dart sur l'écosystème web, ça peut toujours être intéressant à écouter.

Et puis en lisant qu'un employé de Google avait déclaré ça :



Je me suis dit que je n'ai pas perdu mon temps. Au moins, j'aurais bien ri.

En quoi c'est drôle, il a parfaitement raison.

[hunyka]

Bonsoir,

Es ce que CoffeScript est également considéré comme un nouveau langage pour le web au même titre que Dart ?

[hunyka]

En quoi c'est drôle, il a parfaitement raison.

Dévorés par les galeries d’applications propriétaires dixit un employé de Google. Tu ne vois pas l'ironie ?

[23JFK]

En fait, le mec veut réinventer l'écosystème java/j2se/javafx/j2ee ... mais sans Oracle. ça tombe bien qu'il soit chez google parce que c'est sans doute la seule entreprise qui puisse renouveler le genre. Les autres langages auquel j'ajoute le tcl/tk n'ayant jamais réussi à s'imposer dans les navigateurs.