Pour le moment, le seul langage entièrement pris en charge et le standard de facto pour la manipulation de l'arborescence DOM dans le navigateur est JavaScript. Il semble qu'il présente de profonds problèmes de conception qui en font un champ de mines de bugs et de failles de sécurité pour les novices.

Connaissez-vous une initiative existante ou prévue pour introduire un meilleur langage (repensé) de tout type (pas seulement javascript) pour la manipulation de l'arborescence DOM et les requêtes HTTP dans les navigateurs de nouvelle génération? Si oui, quelle est la feuille de route pour son intégration dans, par exemple, Firefox, et si non, pour quelles raisons (en dehors de l'interopérabilité) JavaScript devrait-il être le seul langage pris en charge sur la plate-forme du navigateur?

J'ai déjà utilisé jQuery et j'ai aussi lu "javascript: les bonnes parties". En effet les suggestions sont bonnes, mais ce que je n'arrive pas à comprendre c'est: pourquoi seulement javascript? Du côté serveur (plateforme your-favorite-os), nous pouvons manipuler une arborescence DOM avec chaque langage, même fortran. Pourquoi le côté client (la plate-forme du navigateur) ne prend-il en charge que JavaScript?

Le problème avec javascript n'est pas le langage lui-même - c'est un langage parfaitement prototypé et dynamique. Si vous venez d'un milieu OO, il y a un peu de courbe d'apprentissage, mais ce n'est pas la faute du langage.

La plupart des gens supposent que Javascript est comme Java parce qu'il a une syntaxe similaire et un nom similaire, mais en fait c'est beaucoup plus comme lisp. Il est en fait assez bien adapté à la manipulation DOM.

Le vrai problème est qu'il est compilé par le navigateur, ce qui signifie qu'il fonctionne d'une manière très différente selon le client.

Non seulement le DOM réel est différent selon le navigateur, mais il y a une énorme différence dans les performances et la mise en page.

Modifier après la clarification en question

Supposons que plusieurs langues interprétées soient prises en charge - vous rencontrez toujours les mêmes problèmes. Les différents navigateurs seraient toujours bogués et auraient des DOM différents.

De plus, vous devrez avoir un interpréteur intégré au navigateur ou installé en tant que plug-in (que vous pourriez vérifier avant de servir la page) pour chaque langue. Il a fallu des siècles pour que Javascript soit cohérent.

Vous ne pouvez pas utiliser les langages compilés de la même manière - alors vous introduisez un exécutable qui ne peut pas facilement être examiné pour ce qu'il fait. De nombreux utilisateurs choisiraient de ne pas le laisser fonctionner.

OK, alors qu'en est-il d'une sorte de bac à sable pour le code compilé? Cela ressemble à des applets Java pour moi. Ou ActionScript dans Flash. Ou C # dans Silverlight.

Qu'en est-il d'une sorte de norme IL? Cela a plus de potentiel. Développez dans le langage de votre choix, puis compilez-le en IL, que le navigateur utilise ensuite JIT.

Sauf que Javascript est déjà un peu cette IL - il suffit de regarder GWT . Il vous permet d'écrire des programmes en Java, mais de les distribuer au format HTML et JS.

Modifier suite à une clarification supplémentaire en question

Javascript n'est pas, ou plutôt n'était pas, le seul langage pris en charge par les navigateurs: à l'époque sombre d'Internet Explorer, vous pouviez choisir entre Javascript ou VBScript pour s'exécuter dans IE. Techniquement, IE n'a même pas exécuté Javascript - il a exécuté JScript (principalement pour éviter d'avoir à payer Sun pour le mot java , Oracle possède toujours le nom Javascript ).

Le problème était que VBScript était la propriété de Microsoft, mais aussi qu'il n'était tout simplement pas très bon. Alors que Javascript ajoutait des fonctionnalités et obtenait des outils de débogage de premier ordre dans d'autres navigateurs (comme FireBug), VBScript restait uniquement IE et pratiquement non déboguable (les outils de développement dans IE4 / 5/6 n'existaient pas). Pendant ce temps, VBScript s'est également développé pour devenir un outil de script assez puissant dans le système d'exploitation, mais aucune de ces fonctionnalités n'était disponible dans le navigateur (et quand elles l'étaient, elles sont devenues d'énormes failles de sécurité).

Il existe encore des applications internes d'entreprise qui utilisent VBScript (et certaines s'appuient sur ces failles de sécurité), et elles exécutent toujours IE7 (elles n'ont arrêté IE6 que parce que MS l'a finalement tué).

Mettre Javascript dans son état actuel a été un cauchemar et a pris 20 ans. Il n'a toujours pas de support cohérent, avec des fonctionnalités de langage (spécifiées en 1999) toujours absentes de certains navigateurs et de nombreux shims sont nécessaires.

L'ajout d'une autre langue d'interprétation dans les navigateurs se heurte à deux problèmes majeurs:

• Faire en sorte que tous les fournisseurs de navigateurs implémentent le nouveau standard de langage - quelque chose qu'ils n'ont toujours pas réussi pour Javascript depuis 20 ans.

• Un deuxième langage dilue potentiellement le support que vous avez déjà, permettant (par exemple) à IE d'avoir un support Javascript de second ordre mais un excellent VBScript (encore une fois). Je ne veux vraiment pas écrire du code dans différentes langues pour différents navigateurs.

Il convient de noter que Javascript n'est pas «fini» - il évolue encore pour devenir meilleur dans les nouveaux navigateurs. La dernière version a des années d'avance sur les implémentations des navigateurs et ils travaillent sur la suivante.

Compiler en Javascript

Pour l'instant, utiliser un langage qui compile en Javascript semble être le seul moyen réaliste d'atteindre toutes les plateformes tout en écrivant du code plus intelligent, et cela restera probablement le cas pendant longtemps. Avec toute nouvelle offre, il y aura toujours une raison pour laquelle un ou plusieurs fournisseurs ne se précipiteront pas pour l'expédier.

(Mais je ne pense pas vraiment que ce soit un problème. Javascript a été bien optimisé pour le moment. Le code machine est également dangereux s'il est écrit à la main, mais fonctionne très bien comme cible de compilation et comme langage d'exécution.)

Tant d'options

Il existe un nombre toujours croissant de langages compilant en Javascript. Une liste assez complète peut être trouvée ici:

• Liste des langages compilés en JS sur le Wiki Coffeescript

Remarquable

J'en mentionnerai quelques-unes qui me paraissent dignes de mention (tout en négligeant sans doute quelques joyaux dont je ne suis pas au courant):

• Spider est apparu en 2016. Il prétend reprendre les meilleures idées de Go, Swift, Python, C # et CoffeeScript. Ce n'est pas un type sécurisé, mais il présente quelques caractéristiques de sécurité mineures .

• Elm : Haskell est peut-être le langage le plus intelligent de tous, et Elm est une variante de Haskell pour Javascript. Il est très sensible au type et concis, et offre une programmation réactive fonctionnelle comme une alternative intéressante aux modèles réactifs ou aux spaghettis MVC. Mais cela peut être un choc pour les programmeurs procéduraux .

• Google's Go vise la concision, la simplicité et la sécurité. Le code Go peut être compilé en Javascript par GopherJS .

• Dart était la dernière tentative de Google pour remplacer Javascript. Il propose des interfaces et des classes abstraites via une syntaxe de type C / Java avec typage optionnel.

• Haxe est comme l'ActionScript de Flash, mais il peut cibler plusieurs langages afin que votre code puisse être réutilisé dans les programmes Java, C, Flash, PHP et Javascript. Il propose des objets dynamiques et de type sécurisé.

• Opalang ajoute du sucre syntaxique à Javascript pour fournir un accès direct à la base de données , des continuations intelligentes, la vérification de type et aider à la séparation client / serveur. (Lié à NodeJS et MongoDB.)

• GorillaScript , "un langage de compilation vers JavaScript conçu pour responsabiliser l'utilisateur tout en essayant d'éviter certaines erreurs courantes." est semblable à Coffeescript mais plus complet, offrant un tas de fonctionnalités supplémentaires pour augmenter la sécurité et réduire les modèles passe-partout répétitifs.

• LiteScript se situe quelque part entre Coffeescript et GorillaScript. Il propose une syntaxe async / yield pour les rappels "en ligne" et la vérification des fautes de frappe de variables.

• TypeScript de Microsoft est un petit sur-ensemble de Javascript qui vous permet de placer des restrictions de type sur les arguments de fonction, ce qui peut attraper quelques bogues. De même BetterJS vous permet d'appliquer des restrictions, mais en Javascript pur, soit en ajoutant des appels supplémentaires, soit en spécifiant des types dans les commentaires JSDoc. Et maintenant, Facebook a proposé Flow qui effectue en plus l'inférence de type.

• LiveScript est un spin-off de Coffeescript qui était populaire pour sa brièveté mais qui ne me semble pas très lisible. Probablement pas le meilleur pour les équipes.

Comment choisir?

Lors du choix d' une langue alternative, certains facteurs doivent être pris en compte :

• Si d'autres développeurs rejoignent votre projet à l'avenir, combien de temps leur faudra-t-il pour se mettre à niveau et apprendre cette langue, ou quelles sont les chances qu'ils la connaissent déjà?

• La langue a-t-elle trop peu de fonctionnalités (le code sera toujours plein de passe-partout) ou trop de fonctionnalités (cela prendra du temps à maîtriser, et d'ici là, un code valide peut être indéchiffrable)?

• At-il les fonctionnalités dont vous avez besoin pour votre projet? (Votre projet a-t-il besoin d'une vérification de type et d'interfaces? A-t-il besoin de continuations intelligentes pour éviter l'enfer des rappels imbriqués? Y a-t-il beaucoup de réactivité? Peut-il avoir besoin de cibler d'autres environnements à l'avenir?)

L'avenir...

Jeff Walker a écrit une série d'articles de blog qui suscitent la réflexion sur «le problème de Javascript», y compris pourquoi il pense que ni TypeScript , ni Dart ni Coffeescript n'offrent des solutions adéquates. Il suggère quelques caractéristiques souhaitables pour un langage amélioré dans la conclusion .

JavaScript devrait-il être le seul langage pris en charge sur la plate-forme du navigateur?

Oui et non. Il existe une alternative appelée Dart par Google qui compile en JavaScript et, tout comme jQuery, elle essaie de rendre la manipulation DOM un peu plus facile. Il peut être amusant d'expérimenter, vérifiez-le.

• De Google voir le langage de fléchettes
• De Microsoft voir le langage TypeScript

Voir également

• Orme
• Kal

Il est vrai qu'à un moment donné, Javascript était notoirement difficile à gérer, mais la communauté de développement Web a parcouru un long chemin depuis. Au lieu de cela, je vous encourage à jeter un coup d'œil à jQuery . C'est facile et résume tous les problèmes.

Et il n'y a vraiment pas d'alternatives qui fonctionnent à tous les niveaux. Flash vient à l'esprit, mais c'est aussi le script ECMA et c'est probablement fini pour la plupart des choses.

À court terme, j'utiliserais des choses comme jQuery pour masquer les incompatibilités du navigateur. À long terme, des technologies comme Silverlight ou Adobe AIR peuvent en faire un champ de mines très différent (mais toujours un champ de mines) à l'avenir.

Doug Crockford a donné une conférence à Google détaillant les parties mauvaises et bonnes de JavaScript et son avenir. En fait, cela n'a pas beaucoup changé depuis 1999 - ce qui peut être considéré comme une bonne chose (à peu près tous les navigateurs peuvent exécuter le même code tant que vous êtes conscient de leurs limites) et Doug montre où les bonnes parties étaient pour la plupart des malentendus qui se sont révélés très puissants.

Pour la manipulation DOM, considérez JQuery comme une bibliothèque côté client qui remplace la plupart des horribles API DOM par des opérations difficiles à écrire sur des morceaux de code assez élégants et plus faciles à écrire.

Si vous pensez que JavaScript a de graves problèmes, je recommande le livre de Doug Crockford, JavaScript: The Good Parts . (Ou Google pour "Crockford JavaScript" pour trouver plusieurs présentations vidéo qu'il a faites.) Crockford esquisse un sous-ensemble sûr et un ensemble de pratiques, et répertorie spécifiquement certaines parties du langage à éviter.

Je ne suis pas au courant des projets de remplacement de JavaScript comme moyen de facto de manipuler le DOM. Alors mieux vaut apprendre à l'utiliser en toute sécurité et bien.

En termes de côté client, Javascript est le seul moyen de manipuler le DOM. En termes de côté serveur, il existe une multitude de façons.

Internet Explorer prend en charge les langages de script enfichables, bien que le seul inclus de manière fiable avec IE en plus de JScript soit VBScript.

Pour autant que je l'ai vu, il semble y avoir une sorte de biais général en faveur des langages dynamiques dans le navigateur, et JavaScript semble combler ce besoin suffisamment pour que les effets de réseau rendent toute autre langue un non-starter. Le langage est en fait assez puissant, bien que son implémentation dans les navigateurs laisse beaucoup à désirer.

Si vous êtes prêt à restreindre vos clients / visiteurs à des navigateurs spécifiques, et éventuellement à leur demander d'installer un plug-in, vous pouvez consulter MS Silverlight - un aperçu lisible est sur wikipedia . Avec Silverlight 2, vous pouvez exécuter, côté client, le code que vous avez écrit en C #, IronPython, IronRuby, VB.NET, etc. le clone gratuit Moonlight de Silverlight, issu du projet Mono, promet d'apporter les mêmes fonctionnalités à Linux.

Dans la pratique, la plupart des développeurs d'applications et de sites Web préfèrent atteindre un public plus large que Silverlight (et éventuellement Moonlight) ne peut actuellement offrir - ce qui signifie s'en tenir à Javascript, ou éventuellement à Flash (qui utilise un langage de programmation similaire, Actionscript).

Ainsi, gagner une part d'esprit, une adoption et une traction substantielles pour tout le reste s'avère être un combat difficile, même pour Microsoft avec ses grands groupes d'ingénieurs et ses budgets marketing et un projet de logiciel libre à côté (pour éventuellement apaiser les inquiétudes concernant le verrouillage propriétaire. ) - ce qui peut aider à expliquer pourquoi il y a très peu d'intérêt, par exemple de la part de la Fondation Mozilla, à pousser vers un tel objectif. "En dehors de l'interopérabilité", dites-vous: mais il est clair que la question de l'interopérabilité est LA grande ici, compte tenu de ce que nous observons avec les progrès de Silverlight ...

Comme déjà dit, vous avez Flash (ActionScript, qui est un langage dérivé de Javascript) et Silverlight / Moonlight (IronPython, IronRuby, JScript, VBScript, C #) qui peuvent fonctionner dans le navigateur via des plugins (le premier étant beaucoup plus omniprésent) .

Il existe également une autre alternative si vous aimez Ruby: HotRuby , c'est une implémentation de ruby ​​en javascript qui s'exécutera dans le navigateur. Ce n'est pas encore très mature, mais vous pouvez y jeter un œil.

Une chose que je n'ai pas vue mentionnée (oh, je vois qu'Alcides a mentionné HotRuby pendant que j'écrivais et Nosredna a mentionné GWT et Script #) et j'aimerais vous en parler, c'est qu'il existe un certain nombre d'implémentations de [insérer le langage] -on- JavaScript (par exemple, des traducteurs qui vous permettent de convertir Ruby , Python , C # , Java , Obj-J / Cappuccino [similaire à Obj-C / Cocoa] ou Processing [pour Canvas] en JavaScript sur le client ou avant le déploiement [et certains dont disposent également diverses bibliothèques d'abstraction]). Bien sûr, il y a une surcharge de performance si elle est traduite sur le client, mais si vous êtes plus à l'aise avec une autre langue, cela vous permettra une certaine flexibilité.

Personnellement, cependant, je recommande d'apprendre à aimer JavaScript. C'est un langage excellent, puissant et assez élégant une fois que vous apprenez à le connaître. Je suis confronté au dilemme opposé, à la recherche d'une solution JavaScript / DOM côté serveur capable de répondre à tous mes besoins. / avis non sollicité

Non, c'est JavaScript, mais il évoluera. La prochaine version est "JavaScript Harmony", et vous pouvez en savoir plus si vous recherchez sur Google.

De temps en temps, quelqu'un suggère de mettre un interpréteur de code d'octet dans les navigateurs aux côtés de JavaScript. Cela n'arrivera probablement pas, du moins pendant un certain temps.

J'adore JavaScript. Mais il existe d'autres solutions, notamment GWT, qui compile Java en JavaScript et Script #, qui compile C # en JavaScript.

Jquery (toujours en javascript mais) cela vous aidera vraiment, ils prennent en charge presque tous les navigateurs et ce n'est pas vraiment difficile à apprendre :)

JavaScript est la langue anglaise du Web. L'anglais s'est historiquement répandu parce qu'il avait une marine forte conquérant divers pays. Ceci est comparable aux grandes entreprises qui ont conquis le Web avec JavaScript. C'est une langue assimilée à de multiples sources européennes (grec, latin, langues germaniques, français voire quelques mots chinois et indiens). JavaScript a emprunté de nombreux concepts au fil des années à d'autres langages (structurel, OO, fonctionnel). L'anglais est parlé à différents endroits avec de légères variations de dialecte et d'accent, ce qui peut rendre la compréhension difficile. Tout comme JavaScript, différents navigateurs l'interprètent un peu différemment.

Même si l'anglais est facile à apprendre au début, il a une prononciation très incohérente et plus d'exceptions que de règles. Tout comme JavaScript, il est toujours là pour offrir une surprise.

Malgré les différents accents, JavaScript est la lingua franca du Web. Tout comme vous n'êtes peut-être pas anglais et écrivez ici en anglais, chaque navigateur Web a un certain degré de compréhension de l'anglais. IE6 est comme le gars qui dit sur son CV qu'il parle couramment, mais n'est allé qu'à un cours de deux semaines sur l'anglais comme langue étrangère.

Il y a eu des tentatives pour remplacer l'anglais comme langue principale du monde, par exemple l'espéranto. Mais tous ont échoué, car la plupart des gens sur terre parlent un peu anglais. De la même manière, il sera difficile d'introduire de meilleures alternatives à JavaScript.

Je ne pense pas que Javascript sera remplacé de si tôt. Pour une approche complètement différente des clients riches, vous voudrez peut-être étudier Flex, qui est une technologie basée sur Flash.

Peut-être que quelque chose comme haxe (voir haxe.org) pourrait vous aider. C'est un langage qui semble plus propre que JavaScript et qui peut être compilé en JavaScript, donc il peut être exécuté dans un navigateur.

Je sais que ce n'est pas une réponse directe à votre question, mais j'ai pensé que cela pourrait néanmoins vous intéresser.

Beaucoup de gens comprennent que Javascript n'est pas le meilleur et le plus joli langage qui soit. Cependant, il est actuellement pris en charge par les navigateurs, et il sera donc extrêmement difficile d'introduire une langue différente. Nous n'avons tout simplement pas besoin d'une autre guerre des navigateurs.

Cela explique pourquoi je ne connais aucun projet de basculement vers une autre langue côté client.

Mais je pense que Javascript n'est pas si mal si vous commencez à penser au modèle DOM et à comment travailler avec lui. Beaucoup de choses qui sont désordonnées avec JS sont le résultat du fonctionnement du modèle DOM.