Une alternative typée statiquement à JavaScript sur les pages Web serait-elle pratique?

La préférence pour le typage dynamique et statique est en grande partie une question de goût, et différentes personnes les trouvent plus ou moins adaptées à différentes situations.

Ma question est, serait-il techniquement possible d'avoir une alternative de type statique à JavaScript pour l'augmentation des pages Web côté client, etc.?

Il n'y a certainement aucune raison technique pour laquelle une telle chose ne pourrait pas exister. Il n'y a rien de particulier dans le code côté client qui impose l'utilisation de langages typés dynamiquement.

Puisqu'il est très peu probable qu'une autre langue soit largement adoptée, votre meilleur pari serait de créer une version typée de JavaScript (c'est-à-dire une langue proche de java) et un préprocesseur qui la convertit en JavaScript normal.

Par exemple, votre script ressemble à ça:

<script type="text/staticjavascript">
   String foobar(int foo, String bar) {
      String result="";
      for (int i=0; i<foo; i++) {
         result += bar;
      }
      return result;
   }
</script>

et le préprocesseur vérifie que chaque variable, fonction, objet, etc. est utilisé correctement en fonction de son type, et change le script en

<script type="text/javascript">
   function foobar(foo, bar) {
      var result="";
      for (var i=0; i<foo; i++) {
         result += bar;
      }
      return result;
   }
</script>

que chaque navigateur peut gérer.

Ma question est, serait-il techniquement possible d'avoir une alternative de type statique à JavaScript pour l'augmentation des pages Web côté client, etc.?

Sûr. Le Google Web Toolkit compile statiquement typé Java JavaScript ... Pensez donc: toute la beauté et la flexibilité de Java, avec toutes les performances de JavaScript généré machine!

Sérieusement, vous pouvez le faire pour toutes sortes de langages, et beaucoup ont essayé (il existe, ou a déjà existé, des compilateurs pour C et C #). Que le résultat final soit pratique ou non dépend de ce que vous essayez d'accomplir: Google recherche une plate-forme cohérente pour développer de très grandes applications côté client et dispose de son propre moteur JavaScript pour démarrer; vous constaterez peut-être que l'adoption d'une telle bête pour les effets de survol et l'appel étrange AJAX introduit beaucoup plus de douleur que d'apprendre simplement à vivre avec un peu de code non typé ...

La plupart des avantages des langages de type statique sont réalisés au moment de la compilation. Si la langue va être interprétée sur le client, alors beaucoup de ces avantages sont perdus. Si vous les compilez sur le serveur, vous devez trouver comment les charger et les exécuter sur le client (pensez aux contrôles ActiveX). Vous pouvez opter pour une approche hybride (compiler dans une forme intermédiaire à jetons), mais vous revenez essentiellement aux applets Java.

Cela existe déjà.

ActionScript 3 (le langage de script derrière Flash et Flex) est un dialecte d'ECMAScript qui implémente des types forts, et vous pouvez l'utiliser plus ou moins de la même manière côté client que JavaScript (la différence étant que AS3 nécessite un plugin flash, et est compilé). J'essaie personnellement de m'en éloigner ces jours-ci, mais si vous êtes dans le camp "statique", faites-lui un tourbillon.

Cela répond à la question principale, et maintenant que nous avons cela, votre question secondaire devient "Flash est-il pratique?" La réponse est "oui", avec quelques "si" et "mais"

• ... si vous devez masquer votre code pour une raison quelconque.
• ... si vous voulez un très haut niveau d'interactivité (niveau jQuery passé)
• ... mais même sans HTML5, les compatibilités entre navigateurs s'améliorent beaucoup ces derniers temps.
• ... mais HTML5 arrive bientôt.
• ... mais l'un des gros avantages de la saisie / compilation statique (par opposition à l'interprétation) est la vitesse supplémentaire qu'il permet grâce aux optimisations (et Flash n'a pas vraiment une très bonne vitesse, malgré le système de saisie)

En théorie, vous pouvez coller tous les scripts sur une page de votre choix. La <script>balise a un typeattribut, après tout.

Le seul obstacle est d'obtenir suffisamment de parts de marché en termes d'implémentation dans différents navigateurs pour que cela en vaille la peine.

Alors oui, c'est peu probable à ce stade.

Serait-ce pratique? Non.

C'est possible? Oui!

Développer votre propre alternative typée statiquement à JavaScript prendrait au mieux du temps. Au pire, vous ne pourriez convaincre aucun navigateur existant d'implémenter votre langage de script client et vous devriez écrire le vôtre.

Vous trouverez peut-être votre réponse ici: /programming/86426/why-require-javascript-rather-than-supporting-a-standard-browser-virtual-machine

Remarque: À mon avis, les réponses les plus récentes sont plus pertinentes malgré leur score inférieur.

Vous pouvez utiliser des langues telles que haXe pour écrire votre code de manière statique et l'exporter en javascript. JavaScript devient très rapide, il est donc suffisant comme langage de sortie. Il est presque impossible d'essayer d'appliquer une langue typée statique en tant que norme Web. Les tentatives d'introduction de la saisie statique dans JavaScript ont échoué pour des raisons trop générales à discuter.

Serait-ce techniquement possible? Si elle doit être implémentée en Java, je dirais "très, très difficile, mais possible" sans perte de performances significative.

En fait, je suis en train d'écrire à la main un DSL de type statique en Java, et le seul moyen que j'ai trouvé pour éviter la vérification de type à l'exécution est d'utiliser des génériques et de supprimer les avertissements "non vérifiés" ... c'est-à-dire jusqu'au moment de l'implémentation tableaux multidimensionnels (les paramètres de classe doivent être connus au moment de la compilation et sont donc intrinsèquement finis, alors que les tableaux multidimensionnels représentent un nombre infini de types ...) J'essaie toujours de comprendre celui-ci, malheureusement - je suis sûr que vais rencontrer des problèmes similaires avec les classes définies par l'utilisateur.

Le fait est que je continue de trébucher sur ce genre de problèmes, mais après m'être assis dessus pendant un certain temps, je trouve une bonne solution. Donc, pour le faire et avoir les performances avantages de typage statique (pas de vérification de type d'exécution), je dirais qu'il est extrêmement difficile, mais pas impossible. Moins les performances, je dirais dur mais très possible.

Je sais que c'est une vieille question, juste pensé que mon expérience pourrait être précieuse pour quelqu'un.

Il est techniquement possible d'écrire des scripts côté client dans n'importe quel langage de script pris en charge par l'agent utilisateur (navigateur). Dans la pratique, le seul langage largement pris en charge est JavaScript / ECMAScript. Convaincre les fabricants de navigateurs d'implémenter et de prendre en charge une nouvelle langue à ce stade est peu susceptible de réussir; ainsi, si vous souhaitez utiliser un nouveau langage côté client de type statique, vous devrez soit traduire le nouveau langage en JavaScript, soit implémenter un interpréteur pour celui-ci en JavaScript.

Il y a plusieurs projets qui font déjà quelque chose comme ça; par exemple, Google Web Toolkit , comme mentionné dans l'une des autres réponses.

Étant donné que vous n'avez aucun espoir d'obtenir tous les navigateurs utilisés dans le monde réel pour prendre en charge une nouvelle langue; le langage devra être compilé en jscript.

Comme tous les exemples du Web sont en jscript, le langage devrait surtout ressembler à jscript.

Je pense qu'il y a une portée avec un «sous-ensemble» de jscript qui est vérifié par un vérificateur statique mais qui est également valide jscript. Par exemple:

• Toutes les variables doivent avoir un commentaire indiquant qu'il y a des types avant la première utilisation.
• Toutes les utilisations des variables doivent être valides avec ce qui précède.
• Les fonctions / classe ne peuvent pas être utilisées si elles n'ont pas été déclarées dans un commentaire #
• Un commentaire en haut du fichier js doit répertorier tous les autres fichiers js dont il dépend.

Le typage statique facultatif faisait partie du projet Harmony d'ECMAScript - si oui ou non cela se produira dans le côté client [basé sur navigateur] JavaScript est inconnu, je suppose. Voir ce lien Wikipedia: http://en.wikipedia.org/wiki/ECMAScript#Future_development