Devrait être évité JavaScript en faveur du GWT / WEBSHARPER ou une autre abstraction?

Mon avis pour ce que l'on vaut la peine, c'est que chaque cadre a ses avantages / contre et une équipe de projet devrait évaluer leurs affaires d'utilisation avant l'inclure une. Pour moi, tout cadre est juste un outil à utiliser pour résoudre un problème et vous devez choisir le meilleur pour le travail.

Je préfère m'en tenir aux solutions javascript pures moi-même, mais cela étant dit que je peux penser à quelques cas où GWT seraient utiles. GWT permettrait à une équipe de partager du code entre le serveur / client, réduisant la nécessité d'écrire le même code deux fois (JS et Java). Ou si quelqu'un portait un client Java à une interface utilisateur Web, il peut trouver plus facile de s'en tenir à GWT (bien sûr, cela peut encore le rendre plus difficile :-)).

Je sais que c'est une sur-simplification brute, car il y a beaucoup d'autres choses que des cadres tels que GWT offre, mais voici comment je le vois: si vous aimez JavaScript, écrivez JavaScript; Si vous ne le faites pas, utilisez GWT ou Cappuccino ou autre.

La raison pour laquelle les personnes utilisent des cadres tels que GWT ne sont pas nécessairement l'abstraction qu'elles donnent - vous pouvez avoir cela avec des cadres javascript tels que ExtJS - mais plutôt le fait qu'ils vous permettent d'écrire des applications Web dans une autre chose que JavaScript. Si j'étais un programmeur Java qui souhaitait écrire une application Web, j'utiliserais GWT parce que je n'aurais pas besoin d'apprendre une nouvelle langue.

C'est toute la préférence, vraiment. Je préfère écrire JavaScript, mais beaucoup de gens ne le font pas.

Bien, je sur une autre, je ne pense pas personnellement pas en faveur d'un style que l'abstraction de Javascript est le seul avantage que ces cadres apportent à la table. Certes, à abstraire la langue entière, il y aura des choses qui deviennent impossibles qui étaient auparavant possibles, et vice-versa. La décision d'aller avec un cadre comme GWT sur l'écriture JavaScript vanille dépend de nombreux facteurs.

Faire ce une discussion de JavaScript vs langue X est stérile que chaque langue a ses forces et ses faiblesses. Au lieu de cela, faire une analyse coûts-avantages objective sur ce qui doit être gagné ou perdu en allant avec un tel cadre, et qui ne peut être fait par vous et non la communauté SO malheureusement. P>

La question de ne pas sachant ce qui se passe sous le capot s'applique à JavaScript tout autant comme il le fait à une source traduite. Combien de personnes vous pensez savoir exactement ce qui se passe dans jQuery quand ils essaient de faire une comparaison comme $ ( « p ») == $ ( « p ») code> et revenir false code> en conséquence. Ce n'est pas une situation hypothétique et il y a plusieurs questions sur le même sujet SO. Il faut du temps pour apprendre une langue ou d'un cadre, et compte tenu de suffisamment de temps, les développeurs pourraient tout aussi bien comprendre la source compilée de ces cadres. P>

Un autre aspect lié à la question ci-dessus est de confiance. Nous construisons en permanence des abstractions de haut niveau sur des abstractions de niveau inférieur, et nous comptons sur le fait que les choses de niveau inférieur est censé fonctionner comme prévu. Quelle est la dernière fois que vous creusé dans le binaire compilé d'un programme C ++ ou Java juste pour faire en sorte que cela a fonctionné correctement? Nous ne sommes pas parce que nous faisons confiance au compilateur. P>

En outre, l'utilisation d'un tel cadre, il n'y a pas de honte à retomber à l'aide de JavaScript JSNI, par exemple. Il est tout au sujet de la résolution du problème de la meilleure manière possible avec les outils à portée de main. Il n'y a rien de sacré JavaScript ou Java ou C #, ou Ruby, etc. Ils sont tous les outils pour résoudre les problèmes, et si elle peut être un obstacle pour vous, ce pourrait être un vrai gain de temps et avantageux à quelqu'un d'autre. p>

Quant à savoir où je pense que la programmation web est dirigé, il y a beaucoup de tendances intéressantes que je pense ou plutôt l'espoir réussirez tel que JavaScript côté serveur. Il permet de résoudre des problèmes très réels pour moi au moins que nous pouvons éviter la duplication de code facilement dans une application web. Même, la logique, les validations etc. peuvent être partagés sur les côtés client et serveur. Il permet également d'écrire un simple (de) mécanisme de sérialisation ainsi la communication RPC ou RMI devient possible très facilement. Je veux dire que ce serait vraiment agréable d'être en mesure d'écrire: p>

$.ajax({
    url: "/account",
    data: { amount: 200 },
    success: function(data) {
        ..
    }
    error: function() {
        ..
    }
});

doit être évité JavaScript en faveur de X? Par tous les moyens!

Je vais commencer par un avertissement de non-responsabilité: ma réponse est très polarisée comme je suis sur l'équipe de développeurs Websharper. La raison pour laquelle je suis sur cette équipe est la première place, c'est que je me suis retrouvé un échec complet dans l'écriture de JavaScript pur, puis suggéré à ma société que nous essayons d'écrire un compilateur de notre langue préférée, F #, à JavaScript.

Pour moi, JavaScript est l'assemblage portable de la bande , remplissant le même rôle que c fait dans le reste du monde. Il est portable, largement utilisé, et il restera. Mais je ne veux pas écrire JavaScript, pas plus que je ne veux écrire Assemblée. Les raisons pour lesquelles je ne souhaite pas utiliser JavaScript comme langue comprennent:

1. Il n'y a pas d'analyse statique, il ne vérifie même pas si les fonctions sont appelées avec le bon nombre d'arguments. Typos mordons!

2. Il n'y a pas de concept de bibliothèques, espaces de noms, modules, classes, donc chaque cadre invente leur propre (une situation similaire à celle du schéma R5RS).

3. L'outillage (éditeurs de code, de débugleurs, de profilers) est plutôt médiocre et la plupart d'entre eux à cause de (1) et (2): JavaScript ne sont pas soumis à une analyse statique.

4. Il n'y a pas ou une bibliothèque standard très limitée.

5. Il existe de nombreux bords rugueux et un biais pour utiliser la mutation. JavaScript est une langue mal conçue même dans la famille non typée (je préfère le régime).

   Nous essayons de répondre à toutes ces questions dans Websharper. Par exemple, WEBSHARPER dans Visual Studio a une achèvement de code, même lorsqu'il expose les API javascript tiers, comme EXT JS. Mais que nous ayons ou si nous réussirons ou que nous échouons n'est pas vraiment le point. Le point est que cela est possible et j'espère que, très souhaitable de traiter ces problèmes.

   Pire encore si vous ne savez pas ce qui est passer sous les couvertures que vous courez le risque de conséquences involontaires. Par exemple. Comment savez-vous que GWT crée-t-il fermetures et gestion des espaces de noms correctement?

   Il s'agit simplement d'écrire le compilateur de bonne manière. Websharper, par exemple, cartes F # Lambdas à JavaScript Lambdas de manière 1-1 (en fait, il ne présente jamais de Lambda). J'accepterais peut-être votre argument si vous avez mentionné cela, par exemple, websharper n'est pas encore mature et testé suffisamment et que vous êtes donc hésitant à la faire confiance. Mais alors GWT existe depuis un certain temps et devrait produire du code correct.

   La ligne de fin de la ligne est que les langues fortement typées sont strictement meilleures que les langues non typées - vous pouvez facilement écrire un code non typique, si vous en avez besoin, mais vous avez la possibilité d'utiliser le cheereur de type, qui est le vérificateur orthographique du programmeur. . Pourquoi tu n'aurais-tu pas? Un refus de le faire semble un peu luddite pour moi.