Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« Le Web a besoin de plus de langages de programmation »

Le , par Hinault Romaric

25PARTAGES

3  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de frfancha
Membre éprouvé https://www.developpez.com
Le 12/06/2014 à 11:31
Citation Envoyé par Tryph Voir le message
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.
8  1 
Avatar de Tryph
Membre émérite https://www.developpez.com
Le 12/06/2014 à 11:24
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.
7  1 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 12/06/2014 à 11:37
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.
6  0 
Avatar de cGuille
Futur Membre du Club https://www.developpez.com
Le 12/06/2014 à 11:56
Citation Envoyé par Saverok Voir le message
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.
4  0 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 13/06/2014 à 18:52
Le web n'a pas besoin d'un langage de plus. En fait les standards du web ne devraient même pas contenir un langage comme JS selon moi, mais seulement fournir une base rapide sur laquelle chacun pourra bâtir n'importe quel langage.

Tout ce dont le web a besoin c'est d'un bytecode neutre et de bas-niveau, quelque chose entre l'assembleur et le bytecode Java. Les contraintes sont :
* Isolation mémoire. Si possible par la preuve plutôt que par le logiciel.
* Exposition de mécanismes de consommation des API du navigateur. Ce qui impose sans doute de définir un système de typage minimaliste que le langage devra pouvoir fournir et consommer.
* Efficacement compilable sur toute architecture matérielle, en prévoyant les évolutions matérielles à venir (très nombreux coeurs, coeurs spécialisés, différentes organisations du cache et modèles mémoires, ...)

Autant dire que PNaCl est un excellent candidat.
4  0 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 13/06/2014 à 18:59
Citation Envoyé par Kdence Voir le message
Plus difficile à maintenir? Si on code avec les pieds et que l'on est mal organisé, n'importe quel langage devient difficile à maintenir.
Bien sûr ! Un code dynamiquement typé écrit par cent personnes sur dix ans est aussi facile à maintenir qu'un code statiquement typé dès lors que tu as :
* Écrit pour chaque fonction les tests unitaires vérifiant tous les problèmes de typage pouvant survenir avec chaque argument.
* Documenté le type de chaque argument en commentaire
* Ajouté à chaque argument et variable des préfixes permettant de connaître le type attendu.
* Augmenté le budget pour faire tout ça.

Comme quoi c'est pas plus compliqué que de simplement ajouter un identifiant de type devant chaque variable, c'est sûr.

Et encore... Parce que le vrai bon codeur (celui qui "ne code pas avec les pieds", lui, a des pouvoirs psychiques. Donc il peut faire du code JS maintenable sans rien faire de tout cette liste. On le reconnaît au fait que cinq ans plus tard, quand il retombe sur son code, il s'est tellement amélioré entretemps qu'il préfère encore tout réécrire.
6  2 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 13/06/2014 à 15:08
Citation Envoyé par Kdence Voir le message
Le fait que Javascript ne soit pas typé, et de ce fait plus flexible, ne le rend en aucun cas moins puissant! Surtout que c'est faux!
En vérité, ce qu'offre Javascript, ce n'est ni un typage fort, ni un typage faible, mais un typage dynamique...
Sauf que la notion de puissance d'un langage c'est un terme foutoir qui ne veut absolument rien dire.
Parle-on de la vitesse d’exécution du code? Des capacités à construire des abstractions poussées? De faire des opérations complexes en peu de ligne de code? De la capacité de contrôler précisément l'utilisation des ressources?...
Sachant que toutes ces notions qui peuvent faire la force d'un langage sont souvent contradictoires.

Donc je ne saurais dire si JavaScript est "puissant", mais il n'est clairement pas la meilleure solution à tous les besoins que peut avoir un programmeur.

Citation Envoyé par Kdence Voir le message
Plus difficile à maintenir? Si on code avec les pieds et que l'on est mal organisé, n'importe quel langage devient difficile à maintenir.
Et si on a un coup de crayon sûr, on n'a pas besoin de règle pour tracer une ligne droite. Il n’empêche qu'avoir des outils qui vous aident à faire les choses bien c'est utile même aux meilleurs.
3  0 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 13/06/2014 à 20:35
Citation Envoyé par SylvainPV Voir le message
Un bytecode pour JavaScript a été de nombreuses fois envisagé, mais les inconvénients dépassent les avantages. Il y a cet article qui fait le tour du sujet : http://www.2ality.com/2012/01/bytecode-myth.html
Ces arguments ne tiennent pas :

* L'auteur affirme qu'aucun bytecode n'est universel. Mais ce qui vaut pour le bytecode vaut pour JS. Car si les deux sont Turing-complet, tout ne peut pas être accompli aussi rapidement que possible dans les deux langages. Pour ça il faut se rapprocher de la logique de la machine, ce qui n'est pas possible avec JS. D'où mon insistance pour un bytecode de bas niveau.

* L'auteur affirme que JS est suffisamment bon comme ça, que les compilateurs sont de plus en plus optimisés ma bonne dame... Et bien non ils ne le sont pas, l'écart avec le C est de 1:5 à 1:10 (les ratios de 1:2 mis en avant le sont après optimisation spécifique pour tel benchmark ou tel site). Et ça stagne désormais. Le jour où un algorithme saura optimiser parfaitement le JS, un algorithme saura écrire un programme tout seul depuis les spécs. Le JS ne suffit pas et ne suffira pas, il faut revenir à un niveau inférieur. Le mieux qu'on a c'est asm.js, qui est un bytecode encodé en JS ! Plus lourd tu meurs, bonjour le surcoût au chargement.

* L'auteur affirme qu'il y aurait avec un bytecode des problèmes de versions, ce qui serait moins souvent le cas avec un langage. Je trouve ça difficile à accepter et il ne fournit aucun argument.
3  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 13/06/2014 à 19:18
Citation Envoyé par Uther Voir le message
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.
Un bytecode pour JavaScript a été de nombreuses fois envisagé, mais les inconvénients dépassent les avantages. Il y a cet article qui fait le tour du sujet : http://www.2ality.com/2012/01/bytecode-myth.html

L'idée d'un subset optimisé de JavaScript n'est pas un "affreux bricolage", je trouve ça au contraire très intelligent de ne pas jeter à la corbeille le travail de normalisation effectué sur JavaScript pour une bête question de performance. Etant donné que le langage a beaucoup évolué entre ses débuts et ES6, définir des subsets du langage permettrait de pousser à la modernisation du code ou de cerner un certain paradigme de développement. Et les progrès d'asm.js sont très impressionnants, la démo Unreal Engine 4 m'a soufflé.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 13/06/2014 à 23:33
Citation Envoyé par DonQuiche Voir le message
Le web n'a pas besoin d'un langage de plus. En fait les standards du web ne devraient même pas contenir un langage comme JS selon moi, mais seulement fournir une base rapide sur laquelle chacun pourra bâtir n'importe quel langage.
C'est déjà le cas, Le W3C ne normalise absolument pas le JavaScript : c'est l'ECMA qui s'en occupe. Il définit juste des API standardisées (et typées contrairement a ce que beaucoup croient) qui sont utilisable par les langages de script.
Théoriquement rien n’empêche d'utiliser un autre langage. Dans la pratique, seul JavaScript s'est imposé et est devenu la norme de facto. Ça à ces avantages (compatibilité) et ces inconvénients (pas adapté a toutes les situations).

Citation Envoyé par DonQuiche Voir le message
Tout ce dont le web a besoin c'est d'un bytecode neutre et de bas-niveau, quelque chose entre l'assembleur et le bytecode Java. Les contraintes sont :
* Isolation mémoire. Si possible par la preuve plutôt que par le logiciel.
* Exposition de mécanismes de consommation des API du navigateur. Ce qui impose sans doute de définir un système de typage minimaliste que le langage devra pouvoir fournir et consommer.
* Efficacement compilable sur toute architecture matérielle, en prévoyant les évolutions matérielles à venir (très nombreux coeurs, coeurs spécialisés, différentes organisations du cache et modèles mémoires, ...)

Autant dire que PNaCl est un excellent candidat.
Je suis assez d'accord sur le constat, mais pas sur la conclusion. pNaCl a beau partir d'une très bonne idée, il a pour moi des défauts rédhibitoires qui font qu'il ne pourra pas être utilisé de manière standard par tous en l'état :
- Au niveau du bytecode pNaCl s'appuie sur un sous-ensemble du LLVM IR qui n'est pas normalisé et que les gens de LLVM n'envisagent pas vraiment de le faire.
- Au niveau de l'interface pNaCl se repose sur la PPAPI de Google, là encore non normalisée, qui doublonne à presque tous les niveaux les API déjà existante définies par le W3C.

Citation Envoyé par SylvainPV
Un bytecode pour JavaScript a été de nombreuses fois envisagé, mais les inconvénients dépassent les avantages. Il y a cet article qui fait le tour du sujet : http://www.2ality.com/2012/01/bytecode-myth.html
Il y a énormément de choses à redire à cet arcticle, pour faire court:
There is no single bytecode to “rule all languages” :
C'est vrai, aucun bytecode n'est parfait et capable de couvrir de manière optimale tous les langages et toutes les architecture, même les gens qui travaillent sur LLVM en conviennent. Ceci dit, si on souhaite avoir un socle commun, un bytecode bien pensé sera bien évidement bien plus efficace.
On voit bien sur ce point que LLVM est beaucoup plus efficace que la JVM. Et qui sont eux même bien plus adaptés qu'un langage, qui n'a jamais été pensé pour servir en tant que tel.
There is no common ground between browsers:
Sans objet dans le cas présent. Le but est justement de parvenir à une représentation intermédiaire(IR) bien définie, Il peut ainsi tout à fait y avoir de la place pour divers compilateurs langage->IR et des moteur interprétant et/ou compilant l'IR en AOT ou JIT

Bytecode is inflexible:
Ni plus ni moins que le Javascript

Citation Envoyé par SylvainPV
L'idée d'un subset optimisé de JavaScript n'est pas un "affreux bricolage", je trouve ça au contraire très intelligent de ne pas jeter à la corbeille le travail de normalisation effectué sur JavaScript pour une bête question de performance. Etant donné que le langage a beaucoup évolué entre ses débuts et ES6, définir des subsets du langage permettrait de pousser à la modernisation du code ou de cerner un certain paradigme de développement. Et les progrès d'asm.js sont très impressionnants, la démo Unreal Engine 4 m'a soufflé.
asm.js repose sur une idée certes fort ingénieuse et ces performance sont étonnamment bonnes quand on sait sur quoi cela repose, mais ça reste quand même du bricolage, qui n'atteindra jamais le niveau d'un bytecode bien pensé pour cela.

Citation Envoyé par SylvainPV Voir le message
ce qui m'embête le plus avec le bytecode, c'est le fait de ne plus pouvoir lire le code côté client. Renoncer à ça pour une question de performance alors qu'on voit Epic Citadel tourner à 60fps, ça me paraît être un mauvais choix.
Tu as essayé de regarder le condesource d'EpicCitadel?
Un bytecode décompilé sera certainement bien plus lisible que de l'asm.js
3  1