Question

À l'heure actuelle, la seule langue entièrement pris en charge, et la norme de facto pour la manipulation d'arbre DOM dans le navigateur est JavaScript. On dirait qu'il a de profondes problèmes de conception qui en font un champ de mines de bugs et failles de sécurité pour les novices.

Savez-vous de toute initiative existante ou prévu d'introduire une meilleure (redessinée) langue de toute nature (non seulement javascript) pour la manipulation d'arbre 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, disons, Firefox, et si non, pour quelles raisons (à l'exception de l'interopérabilité) devrait être le seul JavaScript langue prise en charge sur la plate-forme de navigateur?

Je l'ai déjà utilisé jQuery et je l'ai lu aussi « javascript: les bonnes parties ». En effet, les suggestions sont bonnes, mais ce que je ne suis pas en mesure de comprendre: pourquoi ne javascript? Sur le côté serveur (plate-forme de votre-os-favori), on peut manipuler un arbre DOM avec toutes les langues, même Fortran. Pourquoi le côté client (la plate-forme de navigateur) ne supporte que javascript?

Était-ce utile?

La solution

Le problème avec javascript est pas la langue elle-même - c'est un très bon prototypé et langage dynamique. Si vous venez d'un arrière-plan OO il y a un peu d'une courbe d'apprentissage, mais ce n'est pas la faute de la langue.

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

Le vrai problème est qu'il est compilé par le navigateur, et cela signifie qu'il fonctionne d'une manière très différente en fonction du client.

Non seulement le DOM réel différent en fonction du navigateur, mais il y a une énorme différence dans la performance et la mise en page.


Modifier après la clarification en question

Supposons que plusieurs langues prises en charge ont été interprétées - vous avez toujours les mêmes problèmes. Les différents navigateurs seraient encore buggé et ont des DOMs.

De plus, vous devez avoir un interprète intégré dans le navigateur ou en quelque sorte installé comme un bouchon dans (que vous pouvez vérifier avant vous serviez afficher la page) pour chaque langue. Il a fallu une éternité pour obtenir Javascript cohérent.

Vous ne pouvez pas utiliser les langages compilés de la même manière - alors vous introduisez un exécutable qui pour ce qu'il fait ne peut pas être facilement scruté. Beaucoup d'utilisateurs choisissent de ne pas le laisser courir.

OK, alors qu'en est-il une sorte de bac à sable pour le code compilé? Sonne comme Java Applets pour moi. Ou ActionScript dans Flash. Ou C # dans Silverlight.

Qu'en est-il une sorte de norme IL? Cela a plus de potentiel. Développer dans la langue que vous voulez, puis le compiler à l'IL, que le navigateur puis JIT.

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


Modifier la suite des éclaircissements en question

Javascript est pas, ou plutôt n'a pas été la seule langue prise en charge par les navigateurs: retour dans les âges sombres d'Internet Explorer, vous pouvez choisir entre Javascript ou VBScript pour exécuter dans IE. Techniquement IE n'a pas couru même Javascript - il a couru JScript (principalement pour éviter d'avoir à payer pour Sun le mot java , Oracle possède encore le nom Javascript ).

Le problème était que VBScript était la propriété de Microsoft, mais aussi que ce n'était pas très bon. Alors que Javascript est l'ajout de fonctionnalités et d'obtenir des outils de débogage de haut débit dans d'autres navigateurs (comme Firebug) VBScript est resté IE seule et à peu près non débogable (outils de dev dans IE4 / 5/6 étaient inexistant). Pendant ce temps VBScript a également élargi pour devenir un outil de script assez puissant dans le système d'exploitation, mais aucune de ces fonctionnalités étaient disponibles dans le navigateur (et quand ils étaient ils sont devenus des failles de sécurité massives).

Il y a encore des applications internes des entreprises là-bas qui utilisent VBScript (et certains comptent sur ces failles de sécurité), et ils sont toujours en cours d'exécution IE7 (ils ne se sont arrêtés parce que IE6 MS finalement tué au large).

Obtenir Javascript à son état actuel a été un cauchemar et a pris 20 ans. Il n'a toujours pas un soutien constant, avec des caractéristiques linguistiques (spécifiées en 1999) manque encore de certains navigateurs et beaucoup de cales étant nécessaire.

Ajout d'une autre langue pour l'interprétation dans les navigateurs est confronté à deux problèmes majeurs:

  • Obtenir tous les fournisseurs de navigateur pour mettre en œuvre la nouvelle norme linguistique -.

    quelque chose qu'ils ont toujours pas réussi pour Javascript dans 20 ans
  • Une langue seconde potentiellement diluent le soutien que vous avez déjà, ce qui permet (par exemple) IE à avoir des taux de soutien, mais Javascript grand VBScript (encore une fois). Je ne veux vraiment pas être un code écrit dans des langues différentes pour les différents navigateurs.

Il ne devrait pas êtreed que Javascript est pas « fini » - elle évolue encore devenir meilleur dans les nouveaux navigateurs. dernière version est ans avant des implémentations des navigateurs et ils travaillent sur la suivante.

Autres conseils

Compiler à Javascript

Pour l'instant, en utilisant un langage qui compile à Javascript semble être le seul moyen réaliste d'atteindre toutes les plates-formes en écrivant un code plus intelligent, et cela restera probablement le cas depuis longtemps. Avec une 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 c'est un problème. Javascript est bien optimisé maintenant. Code de la machine est également dangereuse si elle est écrite à la main, mais fonctionne très bien comme cible de la compilation et la langue d'exécution.)

Donc beaucoup d'options

Il y a une piscine sans cesse croissant de langues qui compilent à Javascript. Une liste assez complète se trouve ici:

Noteworthy

Je vais citer quelques je pense sont à noter (sans doute en négligeant des pierres précieuses que je ne connais):

  • est apparu en 2016. Il prétend prendre les meilleures idées de Go, Swift, Python, C # et CoffeeScript. Il n'est pas Typesafe, mais il a une certaine sécurité rel="noreferrer"> href="http://spiderlang.org/#code-safety" mineur .

  • Elm : Haskell peut être le plus intelligent langue de tous et Elm est une variante de Haskell pour Javascript. Il est très type courant et concis et offres Programmation réactive fonctionnelle comme une alternative propre à réactif des modèles ou des spaghettis MVC. Mais il peut être tout à fait un choc pour les programmeurs de procédure .

  • Le href="http://golang.org/" Google Go vise à la concision, la simplicité et la sécurité. Code Go peut être compilé Javascript par GopherJS .

  • Dart a été plus tard tentative de Google pour remplacer Javascript. Il offre des interfaces et des classes abstraites par une syntaxe C / Java comme avec la saisie en option.

  • Haxe est comme ActionScript de Flash, mais il peut cibler plusieurs langues afin votre code peut être réutilisé en Java, C, flash, PHP et programmes Javascript. Il offre le type de sécurité et des objets dynamiques.

  • Opalang ajoute du sucre syntaxique Javascript pour fournir accès directe à la base , intelligent continuations, vérification de type et d'aider à la séparation client / serveur. (Liée à NodeJS et MongoDB.)

  • GorillaScript , "une compilation-to JavaScript langage conçu pour donner à 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 accroître la sécurité et réduire les motifs boilerplate répétitifs.

  • LiteScript se situe quelque part inbetween coffeescript et GorillaScript. Il offre la syntaxe async / rendement pour "callbacks inline", et la vérification des fautes de frappe variable.

  • tapuscrit est un petit Javascript de surensemble vous permet de placer des restrictions de type-sur des arguments de fonction , ce qui pourrait attraper quelques bugs. De même BetterJS vous permet d'appliquer des restrictions, mais dans le plus pur Javascript, que ce soit en ajoutant des appels supplémentaires ou en spécifiant les types dans les commentaires de jsdoc. Et maintenant Facebook a offert Flux qui effectue en outre l'inférence de type.

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

Comment choisir?

choisir une autre langue, il y a des facteurs à considérer :

  • Si d'autres développeurs se joindre à votre projet à l'avenir, combien de temps leur faut-il se lever à la vitesse et d'apprendre cette langue, ou quelles sont les chances qu'ils le savent déjà?

  • Est-ce que la langue ont aussi quelques fonctionnalités (le code sera toujours pleine de passe-partout) ou trop de fonctionnalités (il faudra beaucoup de temps à maîtriser, et jusque-là un code valide peut être indéchiffrable)?

  • At-il les fonctionnalités dont vous avez besoin pour votre projet? (Votre projet doit vérification de type et les interfaces? Est-il besoin continuations intelligent pour éviter l'enfer de rappel imbriqué? Est-ce qu'il ya beaucoup de réactivité? Serait-il nécessaire de cibler d'autres environnements dans le futur?)

L'avenir ...

Jeff Walker a écrit une série qui suscite la réflexion des messages de blog a propos de « problème Javascript », y compris pourquoi il pense que ni tapuscrit , ni Dart ni coffeescript offrent des solutions adéquates. Il suggère quelques caractéristiques souhaitables pour une langue améliorée dans la conclusion .

  

doit être la seule langue JavaScript pris en charge sur la plate-forme de navigateur?

Oui et non. Il y a une alternative là appelé Dart par Google qui ne compile JavaScript et jQuery comme il essaie de faire la manipulation du DOM un peu plus facile. Il peut être amusant d'expérimenter, vérifier.

Voir aussi

Il est vrai que Javascript était à un point notoirement difficile à traiter, mais la communauté de développement web a parcouru un long chemin depuis. Au lieu de cela, je vous encourage à jeter un oeil à jQuery . Il est facile et fait abstraction de tous les différents problèmes.

Et il y a vraiment pas d'autres solutions qui fonctionnent dans tous les domaines. Flash vient à l'esprit, mais qui est aussi le script ECMA et il tue probablement plus pour la plupart des choses.

À court terme, je voudrais utiliser des choses comme jQuery pour cacher les incompatibilités du navigateur. À long terme, des technologies telles que Silverlight ou Adobe AIR peuvent 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 bonnes et mauvaises parties de JavaScript et de son avenir. Il a en fait pas beaucoup changé du tout depuis 1999 - ce qui peut être dit être une bonne chose (à peu près tous les navigateurs peuvent exécuter le même code aussi longtemps que vous êtes au courant de leurs limites) et Doug montre où les bonnes pièces étaient pour la plupart des malentendus qui se révèlent être très puissant.

Pour DOM manipuluation, regardez JQuery comme une bibliothèque côté client qui remplace la plupart des API DOM terrible avec des opérations qui sont une douleur à écrire à des bits assez élégants de code qui sont plus faciles à écrire.

Si vous pensez que JavaScript a des problèmes profonds, 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 fait.) Crockford esquisse un sous-ensemble sûr et un ensemble de pratiques et énumère spécifiquement certaines parties de la langue pour éviter.

Je ne suis pas au courant des plans pour remplacer JavaScript comme de facto moyen de manipuler le DOM. Alors mieux apprendre à l'utiliser de manière sûre et bien.

En termes de Javascript côté client est la seule façon de manipuler le DOM. En termes de côté serveur, il y a une multitude de façons.

Internet Explorer prend en charge les langages de script connectables, bien que la seule manière fiable inclus avec IE en plus JScript est VBScript.

Pour autant que je l'ai vu, il semble y avoir une sorte de parti pris général vers des langages dynamiques dans le navigateur, et JavaScript semble répondre à ce besoin assez nettement que les effets de réseau font une autre langue non-démarreur. Le langage est en fait assez puissant, bien que sa mise en œuvre dans les navigateurs laisse beaucoup à désirer.

Une chose que je ne l'ai pas vu mentionné (oh, je vois Alcides mentionné HotRuby pendant que j'écrivais et Nosredna mentionné GWT et Script #) et voudrais jeter il y a un certain nombre d'implémentations de [langue] -sur-JavaScript (par exemple, les traducteurs qui vous permettent de convertir Ruby , Python , C # , Java , Obj-J / Cappuccino [similaire à Obj-C / Cocoa] ou traitement [pour Toile] pour JavaScript soit sur le client ou avant le déploiement [et dont certaines disposent également diverses bibliothèques d'abstraction]). Bien sûr, il y a une surcharge de performance si elle est en cours de traduction sur le client, mais si vous êtes plus à l'aise avec une autre langue, il vous permettra une certaine flexibilité.

Personnellement, cependant, je vous recommande d'apprendre à aimer JavaScript. Il est un excellent langage puissant et assez élégant une fois que vous obtenez de le savoir. Je suis face au dilemme opposé, ronge son frein pour avoir un côté serveur capable solution JavaScript / DOM qui répond à tous mes besoins. / Avis non sollicité

Non. JavaScript est, mais il évoluera. La prochaine version est « JavaScript Harmony », et vous pouvez en savoir plus si vous Google que.

Maintenant, puis quelqu'un suggère de mettre un interpréteur de code octet dans les navigateurs à côté JavaScript. Probablement ne se produira pas, au moins pendant un certain temps.

Je suis d'aimer JavaScript. Mais il y a d'autres solutions, y compris GWT, qui compile Java et JavaScript Script #, qui compile C # JavaScript.

Jquery (encore javascript mais) il va vraiment vous aider ils ont le soutien de presque tous les navigateurs et il est pas vraiment difficile à apprendre:)

JavaScript est la langue anglaise de la bande. Anglais historiquement se propager parce qu'il y avait une forte marine conquérir divers pays. Ceci est comparable aux grandes entreprises qui ont conquis le web avec JavaScript. Il est une langue mis à mal ensemble à partir de plusieurs sources européennes (grec, latin, langues germaniques, français même quelques mots chinois et indiens). JavaScript a emprunté beaucoup de concepts tout au long des années d'autres langues (structure, OO, fonctionnelle). L'anglais est parlé dans des endroits différents avec de légères variations dans le dialecte et l'accent, qui peut rendre la compréhension difficile. Tout comme JavaScript a différents navigateurs interprétant un peu différemment.

Même si l'anglais est facile à apprendre au départ, il a prononciation très inconsistant 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 pourriez ne pas être en anglais et écrire ici en anglais, chaque navigateur Web a un certain degré de compréhension en anglais. IE6 est comme le gars qui dit sur son curriculum vitae qu'il parle couramment, mais seulement est allé à un cours de deux semaines sur l'anglais comme langue étrangère.

Il y a eu des tentatives de supplanter l'anglais comme les mondes de langue principale, par exemple Espéranto. Mais tous ont échoué, parce que 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é dans un proche avenir. Pour une approche complètement différente pour les clients riches, vous voudrez peut-être enquêter sur Flex, qui est une technologie basée sur Flash.

Peut-être quelque chose comme haxe (voir haxe.org) pourrait vous aider. Il est une langue qui semble plus propre que JavaScript et peut être compilé en JavaScript, il peut être exécuté à l'intérieur d'un navigateur.

Je sais que ce n'est pas une réponse directe à votre question, mais je pensais que ce serait peut-être intéressant pour vous, quand même.

Beaucoup de gens comprennent que Javascript est pas le meilleur et jamais la langue de la plus jolie. Cependant, il est actuellement pris en charge par les navigateurs, et donc il sera extrêmement difficile d'introduire une autre langue. Nous avons tout simplement ne pas besoin d'une autre guerre du navigateur.

Ceci explique pourquoi je ne connais pas l'intention de passer à une autre langue côté client.

Mais je pense que Javascript est pas si mal si vous commencez à penser à modèle DOM et comment peut-on travailler avec elle. Beaucoup de choses qui sont en désordre avec JS sont le résultat de la façon dont fonctionne le modèle DOM.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top