Alternatives à JavaScript


8 Answers

Compiler en Javascript

Pour l'instant, l'utilisation d'un langage qui compile en Javascript semble être le seul moyen réaliste d'atteindre toutes les plates-formes 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é à ce jour Le code machine est également dangereux s'il est écrit à la main, mais fonctionne correctement comme langage de compilation et d'exécution.)

Autant d'options

Il y a un nombre croissant de langues qui se compilent en Javascript. Une liste assez complète peut être trouvée ici:

Remarquable

J'en mentionnerai quelques-uns qui me paraissent remarquables (en négligeant sans doute des gemmes dont je ne suis pas conscient):

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

  • Elm : Haskell 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 la programmation réactive fonctionnelle comme une alternative intéressante aux modèles réactifs ou spaghetti MVC. Mais cela peut être un choc pour les programmeurs procéduraux .

  • Google Go vise la concision, la simplicité et la sécurité. Go code 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 grâce à une syntaxe de type C / Java avec une saisie optionnelle.

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

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

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

  • LiteScript 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.

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

  • LiveScript est une 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, il y a quelques facteurs à considérer :

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

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

  • A-t-il les caractéristiques 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'inversion de rappel imbriquée, y a-t-il beaucoup de réactivité, devra-t-il cibler d'autres environnements?

L'avenir...

Jeff Walker a écrit une série de posts sur le "problème Javascript", y compris pourquoi il ne pense ni TypeScript , ni Dart ni Coffeescript offrent des solutions adéquates. Il suggère quelques caractéristiques souhaitables pour un langage amélioré dans la conclusion .

Question

À l'heure actuelle, le seul langage entièrement pris en charge et le standard de facto pour la manipulation des arbres DOM dans le navigateur est JavaScript. On dirait qu'il a des problèmes de conception profonde qui en font un champ de mines de bugs et de trous de sécurité pour le novice.

Connaissez-vous des initiatives existantes ou planifiées pour introduire un langage (redessiné) de tout type (pas seulement javascript) pour la manipulation des arbres 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 (en dehors de l'interopérabilité) devrait être JavaScript la seule langue prise en charge sur la plate-forme du navigateur?

J'ai déjà utilisé jQuery et j'ai aussi lu "javascript: the good parts". En effet les suggestions sont bonnes, mais ce que je ne suis pas capable de comprendre est: pourquoi seulement javascript? Du côté serveur (votre plate-forme your-favorite-os), nous pouvons manipuler un arbre DOM avec toutes les langues, même fortran. Pourquoi le côté client (la plate-forme du navigateur) ne supporte-t-il que javascript?




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, et il sera donc extrêmement difficile d'introduire une langue différente. Nous n'avons tout simplement pas besoin d'une autre guerre de navigateur.

Cela explique pourquoi je ne connais aucun projet de passage à une langue client différente.

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




Du point de vue du client, Javascript est le seul moyen de manipuler le DOM. En termes de serveur, il y a une multitude de façons.




Jquery (encore javascript mais) ça va vraiment t'aider ils ont du support pour presque tous les navigateurs et ce n'est pas vraiment si difficile à apprendre :)




Si vous êtes prêt à restreindre vos clients / visiteurs à des navigateurs spécifiques, et peut-être disposés à les obliger à 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, du code que vous avez écrit en C #, IronPython, IronRuby, VB.NET, etc; le clone Moonlight gratuit de Silverlight, issu du projet Mono, promet d'apporter la même fonctionnalité à Linux.

En 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) peut offrir - ce qui signifie coller avec Javascript, ou éventuellement Flash (qui utilise un langage de programmation similaire, Actionscript).

L'acquisition d'un esprit d'entreprise, d'une adoption et d'une adhésion substantielle s'avère donc une lutte difficile même pour Microsoft, avec ses grands groupes d'ingénieurs et de budgets marketing et un projet de logiciel libre (pour éviter les soucis liés au 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é", vous dites: mais clairement la question de l'interopérabilité est LE biggie ici, compte tenu de ce que nous observons avec les progrès de Silverlight ...




Je ne pense pas que Javascript sera remplacé de sitôt. Pour une approche complètement différente des clients riches, vous pourriez vouloir étudier Flex, qui est une technologie basée sur Flash.




Une chose que je n'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 [insérer la langue] -sur- JavaScript (par exemple, les traducteurs qui vous permettent de convertir HotRuby , Python , C# , GWT , Obj-J/Cappuccino [similaire à Obj-C / Cocoa] ou Processing [pour Canvas] en JavaScript sur le client ou avant le déploiement [et certains dont font également partie 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 donnera une certaine flexibilité.

Personnellement, cependant, je recommande d'apprendre à aimer JavaScript. C'est un langage excellent et puissant, et assez élégant quand on le connait. Je suis confronté au dilemme opposé, en cherchant à avoir une solution JavaScript / DOM capable de répondre à tous mes besoins. / opinion non sollicitée




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 surtout des malentendus qui s'avèrent être très puissants.

Pour la manipulation DOM, regardez JQuery comme une bibliothèque côté client qui remplace la plupart de l'horrible DOM API avec des opérations qui sont pénibles à écrire sur des morceaux de code assez élégants qui sont plus faciles à écrire.




Il est vrai que Javascript était à un moment 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 coup d'oeil à jQuery . C'est facile et résume tous les problèmes.

Et il n'y a vraiment aucune alternative qui fonctionne partout. Flash vient à l'esprit, mais c'est aussi un script ECMA et c'est probablement fini pour la plupart des choses.




Related