Alternatives à JavaScript
Pour le moment, le seul langage entièrement pris en charge, et la norme de facto pour la manipulation de l'arborescence DOM dans le navigateur, est JavaScript. Il semble y avoir des problèmes de conception profonds qui en font un champ de mines d'insectes et de failles de sécurité pour le novice.
Connaissez-vous une initiative existante ou planifiée visant à introduire un meilleur langage (remanié) de tout type (pas uniquement javascript) pour la manipulation de l'arborescence DOM et les requêtes HTTP dans les navigateurs de la prochaine 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 (hormis l'interopérabilité) le JavaScript devrait-il être la seule langue prise en charge sur la plate-forme du navigateur?
J'ai déjà utilisé jQuery et j'ai également lu "javascript: the good parts". En effet, les suggestions sont bonnes, mais ce que je ne suis pas capable de comprendre est: pourquoi seulement du javascript? Sur le côté serveur (votre plate-forme os-favorite), nous pouvons manipuler une arborescence DOM avec toutes les langues, même fortran. Pourquoi le côté client (la plate-forme du navigateur) ne prend-il en charge que le 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), la courbe d'apprentissage est un peu longue, mais ce n'est pas la faute de la langue.
La plupart des gens supposent que Javascript est semblable à Java car il a une syntaxe et un nom similaires, mais en réalité, il ressemble beaucoup plus à LISP. Il est en fait assez bien adapté à la manipulation DOM.
Le vrai problème, c'est qu'il est compilé par le navigateur, ce qui signifie que cela fonctionne de manière très différente selon les clients.
Non seulement le DOM réel varie-t-il en fonction du navigateur, mais il existe une différence énorme en termes de performances et de présentation.
Modifier la clarification suivante dans la question
Supposons que plusieurs langages interprétés ont été pris en charge - vous avez toujours les mêmes problèmes. Les différents navigateurs seraient toujours buggés et auraient différents DOM.
De plus, vous devrez avoir un interprète intégré au navigateur ou installé de manière ou d'autre comme plug-in (à vérifier avant de servir la page) pour chaque langue. Il a fallu des siècles pour que le Javascript soit conforme.
Vous ne pouvez pas utiliser les langages compilés de la même manière. Vous introduisez ensuite un exécutable difficile à analyser. Beaucoup d'utilisateurs choisiraient de ne pas le laisser fonctionner.
OK, alors qu'en est-il d'une sorte de sandbox pour le code compilé? Cela ressemble à Java m'applique. 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 la langue de votre choix, puis compilez-le en langage IL, que le navigateur puis en JIT.
Sauf que, javascript est déjà un peu comme ça - il suffit de regarder GWT . Il vous permet d’écrire des programmes en Java, mais de les distribuer au format HTML et JS.
Éditer après la clarification suivante
Javascript n'est pas, ou plutôt n'était pas, le seul langage pris en charge par les navigateurs: à l'époque sombres d'Internet Explorer, vous pouviez choisir entre JavaScript ou VBScript pour s'exécuter dans IE. Techniquement IE ne fonctionnait même pas en Javascript - il fonctionnait JScript (principalement pour éviter de 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 qu’il n’était tout simplement pas très bon. Tandis que Javascript ajoutait des fonctionnalités et obtenait des outils de débogage de premier ordre dans d'autres navigateurs (comme FireBug), VBScript restait réservé à IE et pratiquement non débogable (les outils de développement dans IE4/5/6 n'existaient pas). Dans le même temps, VBScript a également évolué 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 (elles étaient alors devenues d’énormes failles de sécurité).
Certaines applications internes à l'entreprise utilisent encore VBScript (certaines s'appuient sur ces failles de sécurité) et utilisent encore IE7 (elles n'ont arrêté IE6 que parce que MS l'a finalement tué).
Obtenir du Javascript à 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 manquantes dans certains navigateurs et beaucoup de shims sont nécessaires.
L'ajout d'une autre langue d'interprétation dans les navigateurs pose deux problèmes majeurs:
Amener tous les éditeurs de navigateurs à mettre en œuvre la nouvelle norme de langage - un problème qu’ils n’avaient toujours pas géré pour Javascript depuis 20 ans.
Une deuxième langue peut potentiellement diluer le support que vous avez déjà, permettant (par exemple) IE d'avoir un support Javascript de seconde qualité mais un excellent VBScript (encore). Je ne veux vraiment pas écrire de code dans différentes langues pour différents navigateurs.
Il convient de noter que Javascript n'est pas "fini" - il évolue toujours 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 le moment, utiliser un langage qui compile sur 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é. 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 croissant de langues compilées 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 citerai quelques-unes que je pense méritent d'être notées (tout en négligeant sans doute des joyaux que je ne connais pas):
Spider est apparu en 2016. Il prétend prendre les meilleures idées de Go, Swift, Python, C # et CoffeeScript. Ce n'est pas typé, mais il a quelques mineures caractéristiques de sécurité .
Elm : Haskell est peut-être le langage le plus intelligent , et Elm est une variante de Haskell pour Javascript. Il est hautement typographique et concis et offre la programmation réactive fonctionnelle comme une alternative intéressante aux modèles réactifs ou aux spaghettis MVC. Mais cela peut être assez un choc pour les programmeurs procéduraux .
Le Go de Google 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 offre des interfaces et des classes abstraites via une syntaxe de type C/Java avec typage facultatif.
Haxe est semblable au code ActionScript de Flash, mais il peut cibler plusieurs langues afin que votre code puisse être réutilisé en Java, C, Flash, PHP et programmes Javascript. Il offre des objets dynamiques et sans danger pour le type.
Opalang ajoute du sucre syntaxique à Javascript pour fournir un accès direct à la base de données , des suites intelligentes, la vérification de type et une assistance pour la séparation client/serveur . (Lié à NodeJS et MongoDB.)
GorillaScript , "un langage de compilation conçu pour habiliter l'utilisateur tout en essayant d'éviter certaines erreurs courantes." s'apparente à Coffeescript, mais est plus complet et fournit une tas de fonctionnalités supplémentaires pour augmenter la sécurité et réduire les motifs répétitifs passe-partout.
LiteScript se situe quelque part entre Coffeescript et GorillaScript. Il offre une syntaxe asynchrone/rendement pour les rappels "en ligne" et la vérification des fautes de frappe variables.
TypeScript de Microsoft est un petit sur-ensemble de Javascript qui vous permet d'imposer des restrictions de type aux arguments de fonction, ce qui pourrait permettre de détecter quelques bogues. De même, BetterJS vous permet d'appliquer des restrictions, mais en Javascript pur, en ajoutant des appels supplémentaires ou en spécifiant des types dans les commentaires JSDoc. Et maintenant, Facebook a proposé Flow , qui effectue en plus une inférence de type.
LiveScript est une retombée 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?
Lorsque choisit une autre langue, 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 familiariser avec cette langue et apprendre cette langue ou quelles sont les chances qu'ils la sachent déjà?
La langue a-t-elle trop peu de fonctionnalités (le code sera-t-il toujours plein)? Ou trop de fonctionnalités (il faudra beaucoup de temps pour les maîtriser et, dans l'intervalle, un code valide pourrait être indéchiffrable)?
At-il les fonctionnalités dont vous avez besoin pour votre projet? (Votre projet a-t-il besoin de vérifications de type et d'interfaces? A-t-il besoin de suites intelligentes pour éviter les rappels imbriqués? Y a-t-il beaucoup de réactivité? Devrait-il cibler d'autres environnements à l'avenir?)
L'avenir...
Jeff Walker a écrit ne série inspirante de billets de blog sur "le problème de Javascript", y compris pourquoi il ne pense ni TypeScript , ni Dart ni Coffeescript offre des solutions adéquates. Il suggère quelques caractéristiques souhaitables pour une langue améliorée dans la conclusion .
javaScript devrait-il être la seule langue prise en charge sur la plate-forme de navigateur?
Oui et non. Il existe une alternative appelée Dart by Google qui compile en JavaScript et qui, tout comme jQuery, essaie de faciliter un peu la manipulation DOM. Il peut être amusant d’expérimenter.
- De Google voir Le langage Dart
- De Microsoft voir TypeScript
Voir également
Il est vrai que Javascript était notoirement difficile à gérer à un moment donné, mais la communauté du développement Web a parcouru un long chemin depuis. Au lieu de cela, je vous encourage à regarder jQuery . C'est facile et résume tous les problèmes.
Et il n'y a pas vraiment d'alternative qui fonctionne à tous les niveaux. Flash me vient à l’esprit, mais c’est aussi le script ECMA et c’est probablement trop fatal pour la plupart des choses.
À court terme, j'utiliserais des éléments comme jQuery pour masquer les incompatibilités du navigateur. À long terme, des technologies telles que Silverlight ou Adobe AIR pourraient faire de ce champ minier un site très différent (mais toujours un champ minier) à l’avenir.
Doug Crockford a donné une conversation à Google détaillant les mauvaises et les bonnes parties de JavaScript et de son avenir. En réalité, il 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 connaissez leurs limites) et Doug montre où les bonnes parties Ce sont surtout des malentendus qui se révèlent très puissants.
Pour la manipulation DOM, considérez JQuery comme une bibliothèque côté client qui remplace la plupart de la terrible API DOM par des opérations difficiles à écrire dans des éléments de code assez élégants et plus faciles à écrire.
Si vous pensez que JavaScript a des problèmes profonds, je vous 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 réalisées.) 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 en tant que moyen de facto de manipulation du DOM. Alors mieux apprendre à l'utiliser en toute sécurité et bien.
En termes de client, Javascript est le seul moyen de manipuler le DOM. En termes de serveur, il existe une multitude de façons.
Si vous souhaitez limiter vos clients/visiteurs à certains navigateurs et éventuellement leur demander d'installer un plug-in, vous pouvez consulter MS Silverlight - une vue d'ensemble lisible est allumée - Wikipédia . 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.
En pratique, la plupart des développeurs d'applications et de sites Web préfèrent toucher des publics plus larges que ne le peuvent actuellement Silverlight (et finalement Moonlight), ce qui signifie rester fidèle à Javascript ou éventuellement à Flash (qui utilise un langage de programmation similaire, Actionscript).
Donc, gagner beaucoup de mentalité, d’adoption et de traction pour tout le reste est un combat difficile, même pour Microsoft avec ses grands groupes d’ingénieurs et ses budgets marketing et un projet de logiciel libre sur le côté ( peut-être que les inquiétudes sur le lock-in de propriété soient dissipées) - 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, dans la poursuite de cet objectif. "En dehors de l'interopérabilité", dites-vous: mais le problème de l'interopérabilité est clairement LE plus gros problème ici, compte tenu de ce que nous observons des progrès réalisés par Silverlight ...
Internet Explorer prend en charge les langages de script enfichables, bien que le seul langage inclus de manière fiable avec IE) à côté de JScript soit VBScript.
D'après ce que j'ai vu, il semble exister un biais général en faveur des langages dynamiques dans le navigateur, et JavaScript semble combler suffisamment ce besoin pour que les effets de réseau fassent de tout autre langage un non-initiateur. Le langage est en fait assez puissant, bien que son implémentation dans les navigateurs laisse beaucoup à désirer.
Comme déjà dit, vous avez Flash (ActionScript, un langage dérivé de Javascript) et Silverlight/Moonlight (IronPython, IronRuby, JScript, VBScript, C #) qui peuvent s'exécuter dans le navigateur via des plugins (le premier étant beaucoup plus répandu) .
Il existe également une autre alternative si vous aimez Ruby: HotRuby , c’est une implémentation Ruby en javascript qui fonctionnera dans le navigateur. Elle n’est pas encore très mature, mais vous peut y jeter un coup d'oeil.
Une chose que je n’ai pas vue mentionnée (oh, je vois Alcides qui a mentionné HotRuby pendant que j’écrivais et Nosredna a mentionné GWT et Script #) et que j’aimerais rejeter, car il existe plusieurs implémentations de [insert language] -on- JavaScript (par exemple, les traducteurs qui vous permettent de convertir Ruby , Python , C # , Java , Obj-J/Cappuccino [similaire à Obj-C/Cocoa] ou traitement [pour Canvas] en JavaScript sur le client ou avant le déploiement [et dont certains comportent également diverses bibliothèques d'abstraction] ). Bien sûr, si le logiciel est traduit sur le client, il y a un surcoût lié aux performances, mais si vous êtes plus à l'aise avec une autre langue, cela vous laissera une certaine souplesse.
Personnellement, cependant, je recommande d'apprendre à aimer JavaScript. C'est un excellent langage puissant et élégant quand vous le connaissez. Je suis confronté au dilemme opposé, cherchant une solution JavaScript/DOM côté serveur capable de répondre à tous mes besoins./avis non sollicité
JavaScript est la langue anglaise du web. Anglais historiquement répandu parce qu'il avait une forte marine conquérant divers pays. Ceci est comparable aux grandes entreprises qui ont conquis le Web avec JavaScript. C'est une langue imbriquée dans de nombreuses sources européennes (grec, latin, germanique, français et quelques mots chinois et indiens). Le JavaScript a emprunté beaucoup de concepts au fil des ans à d’autres langages (structurel, OO, fonctionnel). L'anglais est parlé dans des endroits différents 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.
Bien que l'anglais soit facile à apprendre au début, sa prononciation est très incohérente et il y a 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 que vous écrivez ici en anglais, chaque navigateur Web possède un certain degré de compréhension de l'anglais. IE6 est comme le gars qui dit sur son CV qu'il parle couramment, mais qui n'a suivi 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. Espéranto. Mais tous ont échoué, car la plupart des habitants de la planète parlent un peu anglais. De la même manière, il sera difficile d'introduire de meilleures alternatives au JavaScript.
Non, JavaScript c'est ça, mais ça va évoluer. La prochaine version est "Harmonie JavaScript" et vous pouvez en apprendre plus si vous utilisez Google.
De temps en temps, quelqu'un suggère de placer un interpréteur de code octet dans les navigateurs, parallèlement à JavaScript. Cela n'arrivera probablement pas, du moins pendant un moment.
J'aime le JavaScript. Mais il existe d'autres solutions, notamment GWT, qui compile Java pour JavaScript et Script #, qui compile C # en JavaScript.
Jquery (toujours en javascript mais), il vous aidera vraiment à prendre en charge presque tous les navigateurs et ce n’est pas si difficile à apprendre :)
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 explorer Flex, 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 le JavaScript et qui peut être compilé en JavaScript, de sorte qu'il puisse ê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 être intéressant pour vous, néanmoins.
Beaucoup de gens comprennent que Javascript n'est pas la meilleure et la plus belle langue de tous les temps. Cependant, il est actuellement supporté par les navigateurs, il sera donc extrêmement difficile d’introduire un langage différent. Nous n'avons simplement pas besoin d'une autre guerre des navigateurs.
Cela explique pourquoi je ne connais aucun projet de passer à un langage client différent.
Mais je pense que le Javascript n'est pas si mauvais si vous commencez à penser au modèle DOM et à comment travailler avec. Beaucoup de choses qui sont en désordre avec JS sont le résultat du fonctionnement du modèle DOM.