Pourquoi JavaScript n'est-il pas utilisé pour le développement d'applications classiques (logiciels compilés)? [fermé]

Au cours de mes années de développement Web avec JavaScript, je conclus que c'est un langage incroyablement puissant et que vous pouvez faire des choses incroyables avec lui.

Il offre un riche ensemble de fonctionnalités, telles que:

• Typage dynamique
• Fonctions de première classe
• Fonctions imbriquées
• Fermetures
• Fonctions comme méthodes
• Fonctionne comme constructeur d'objet
• Basé sur un prototype
• Basé sur des objets (presque tout est un objet)
• Regex
• Littéraux de tableau et d'objets

Il me semble que presque tout peut être réalisé avec ce type de langage, vous pouvez également émuler la programmation OO, car il offre une grande liberté et de nombreux styles de codage différents.

Avec plus de fonctionnalités personnalisées orientées logiciel (E / S, FileSystem, périphériques d'entrée, etc.), je pense que ce sera génial de développer des applications avec.

Cependant, pour autant que je sache, il n'est utilisé que dans le développement Web ou dans les logiciels existants en tant que langage de script.

Ce n'est que récemment, peut-être grâce au moteur V8, qu'il a été davantage utilisé pour d'autres types de tâches (voir node.js par exemple).

Pourquoi jusqu'à présent, il n'est relégué qu'au développement Web? Qu'est-ce qui l'éloigne du développement logiciel?

Récemment, node.js a fait avancer le développement côté serveur. Il est donc désormais possible d'écrire du JavaScript pour le développement.

C'est vrai. Dans l'histoire, il n'a pas été utilisé comme langage de développement. Mais bon, même l'écriture de scripts en environnement client (User Agents) est un type de développement. N'est-ce pas?

La principale raison pour laquelle j'ai entendu et lu dans de nombreux blogs, c'est que les gens ne connaissaient pas son pouvoir et son caractère unique jusqu'à ces dernières années . Ce qui a rendu cela possible, c'est peut-être que d'autres langues faisaient assez bien leur travail, et personne n'a jamais pensé à faire quelque chose de parallèle.

D' ici :

Notez que je fonde tous mes arguments sur des cas d'utilisation réels. Les contre-arguments qui ne peuvent pas être sauvegardés avec un exemple d'utilisation dans des applications réelles, complètes, intéressantes et utiles ne sont pas valides. J'ai vu les petites "démos de langage" que tout le monde a, j'ai vu les articles de blog détaillant comment les prototypes et la frappe dynamique rendent un petit exemple trivial quelques lignes plus court qu'en C #, mais ceux-ci ne sont tout simplement pas pertinents aux problèmes que vous rencontrez pour écrire du vrai code plutôt que des micro-démos et des jouets. Voici donc mes reproches avec JS:

a) Magie «ceci». C'est ça, sauf quand c'est ça. JavaScript vous pousse à utiliser des fonctions anonymes partout, sauf qu'elles finissent toujours par perdre le contexte approprié pour la variable 'this', donc vous finissez par avoir du code maladroit comme "var _this = this" partout et ensuite en utilisant cela à l'intérieur de vos rappels ou d'autres fonctions. Certains jours, je jure que le nombre de fonctions que j'arrive à écrire et qui n'utilisent pas un «ceci» renommé sont en fait plus petites que le nombre qui le fait.

b) 1 + "1" - 1 = 10. Aussi, "1" + 0 = "10". Oui, cela a en fait causé des bogues pour nos applications, où les données qui devraient être un nombre ont été chargées à partir d'un fichier JSON en tant que chaîne en raison d'un bogue dans une autre application, et le résultat n'était pas bon. Tout notre code de chargement a dû être mis à jour pour ajouter une tonne de conversions de type partout. Quand j'ai besoin que quelque chose soit un nombre, je veux vraiment que ce soit un nombre, pas une chaîne ou un objet ou null ou autre chose. Lua, qui est très similaire à JavaScript à bien des égards, a résolu ce problème en n'étant pas suffisamment retardé pour utiliser le même opérateur pour l'ajout et la concaténation de chaînes.

c) Variables globales par défaut. Donc, même si vous prenez l'argument selon lequel la saisie dynamique est simplement "plus facile" parce que vous n'avez pas à penser aux déclarations de variables, JavaScript jette cet argument par la fenêtre en vous faisant mettre 'var' devant de nouveaux identifiants partout . Et puis il vous visse silencieusement si vous oubliez.

d) Prototypes au lieu de classes. Il existe très peu d'applications JavaScript à grande échelle dans le monde réel qui ne se connectent pas à leur propre système de classe pour contourner l'inutilité inhérente des prototypes dans l'architecture des grandes applications. Ces mêmes applications font un usage minimal des prototypes pour étendre les types JavaScript de base, et uniquement parce que JS était si mal conçu que même les deux types intégrés intéressants qu'il contient manquent de la moitié des fonctionnalités que vous attendez d'eux.

e) Impossibilité de créer des types de valeur de passage. C'est un problème fréquent dans à peu près tous les langages en dehors de C ++ / D, en fait. Pour ceux qui utilisent JavaScript pour écrire des applications WebGL, jetez un œil à toutes les bibliothèques d'algèbre linéaire pour JavaScript. Dans les applications 3D, vous utilisez presque plus souvent des vecteurs que des scalaires. Imaginez que chaque entier de votre application soit passé par référence, de sorte que "a = 1; b = a; b ++" rende a et b égaux à 2. Chaque petit vecteur à trois composants est un objet complet complet. Ils sont passés par référence (la source de près de la moitié des bogues de notre jeu WebGL jusqu'à présent, en fait). Ils existent en grande quantité, sont alloués en tas et récupérés, ce qui met une pression intense sur le GC, ce qui peut entraîner et fait des pauses dans les jeux WebGL même simples, à moins que le développeur ne passe par des cercles ridiculement compliqués pour éviter de créer de nouveaux vecteurs à tous les endroits où il est logique de créer de nouveaux vecteurs. Vous ne pouvez pas avoir de surcharge d'opérateur, vous avez donc des expressions très grandes et laides pour effectuer des opérations de base. L'accès aux composants individuels est lent. Les objets ne sont pas nativement compressés et sont donc incroyablement lents à pousser dans un tampon de vertex, sauf si vous les implémentez en tant qu'instances Float32Array, ce qui confond la merde des optimiseurs de V8 et SpiderMonkey actuellement. Ai-je mentionné qu'ils sont adoptés par référence? L'accès aux composants individuels est lent. Les objets ne sont pas nativement compressés et sont donc incroyablement lents à pousser dans un tampon de vertex, sauf si vous les implémentez en tant qu'instances Float32Array, ce qui confond la merde des optimiseurs de V8 et SpiderMonkey actuellement. Ai-je mentionné qu'ils sont adoptés par référence? L'accès aux composants individuels est lent. Les objets ne sont pas nativement compressés et sont donc incroyablement lents à pousser dans un tampon de vertex, sauf si vous les implémentez en tant qu'instances Float32Array, ce qui confond la merde des optimiseurs de V8 et SpiderMonkey actuellement. Ai-je mentionné qu'ils sont adoptés par référence?

f) Aucune fonctionnalité intégrée n'inclut ni ne nécessite de fonctionnalité. Sérieusement, toujours. Les bibliothèques tierces existent mais presque toutes ont une sorte de bogue ou une autre, dont la moindre n'est pas un problème de mise en cache déroutant dans au moins Chrome, ce qui rend le développement réel pénible.

g) Typage dynamique. Oui, je suis prêt à commencer cet argument. Vous commencez à le remarquer le plus souvent à la seconde où vous arrêtez d'écrire de petites applications Web ou pages Web et commencez à écrire de grandes applications où vous avez réellement des données qui persistent plus longtemps qu'un simple clic de souris ou un cycle de demande / réponse: ajoutez le mauvais type d'objet à un tableau à traiter plus tard et à obtenir un plantage plus tard à partir d'une méthode ou d'un membre manquant dans un bit de code complètement différent de celui où se trouvait l'erreur réelle. Des moments de plaisir. Oui, Java rend le typage statique mauvais. Non, Java / C # / C ++ ne sont pas le seul et unique moyen de faire du typage statique. L'inférence de type, la liaison d'interface implicite, etc. vous offrent tous les avantages «faciles à gérer et peu de frappes» de la frappe dynamique sans tous les bogues. Le deuxième langage Web le plus populaire - ActionScript 3 - est typé statiquement, en fait, bien qu'il soit par ailleurs identique à JS / ECMAScript. En passant, je reçois plus de plantages des applications Python sur mon bureau Fedora que des applications C / C ++ (en fait, aucune des applications C / C ++ sur mon bureau ne plante, maintenant que j'y pense). Exceptions des membres manquants == tellement plus faciles à développer et à maintenir des applications, non?

h) Vitesse. Oui, un grand nombre de développeurs super méchants ont déployé énormément d'efforts dans les exécutions de langage pour rendre JS presque la moitié plus rapide qu'un compilateur C de bas niveau qu'un seul collège junior pourrait écrire en quelques uns. mois. Et LuaJIT est dans le même bateau que JS en termes de limitations de langage fondamentales, mais parvient malgré tout à faire mieux que chaque implémentation JavaScript. Les gens qui ne comprennent pas ce que font réellement toutes les optimisations JS dans V8 ou autresaime prétendre que le JS peut faire des choses incroyables en termes de vitesse, mais la réalité est que toutes ces optimisations sont fondamentalement juste "essayer très dur d'analyser le code pour trouver des types de variables et ensuite le compiler comme un type retardé statiquement typé le compilateur du langage le ferait. " Oh, et il y a le traçage, mais le traçage fonctionne également sur les langages typés statiquement (et fonctionne mieux en raison du manque de garde de type dans le code machine généré). Pas une seule de ces optimisations de whizbang n'a été inventée par ou pour JS, en fait; la plupart proviennent de JVM de recherche (Java is evil!) ou de langages OOP classiques (les prototypes sont géniaux!).

i) Aucun IntelliSense n'est même possible. Vous voulez voir quelles méthodes existent sur cette variable que vous avez là à la ligne 187 de foo.js dans votre éditeur de texte? Dommage. Parcourez le code jusqu'à ce que vous compreniez où il a été initialisé, puis parcourez le code pour découvrir ce que contient son prototype. Et puis j'espère qu'il n'y a pas de code qui change dynamiquement le prototype derrière votre dos. En fait, il suffit de l'exécuter dans un navigateur et de définir des points d'arrêt, car trouver quoi que ce soit d'utile sur la valeur d'une autre manière est fondamentalement impossible pour une base de code plus grande que les sites toy_web_app.html que les apologistes JavaScript utilisent pour glorifier la facilité et la simplicité de JavaScript. Certains éditeurs de code s'efforcent vraiment de faire mieux, et réussissent presque un peu pour les cas très simples, parfois, une fois.

j) Aucun avantage. JavaScript n'est même pas spécial par rapport à d'autres langages typés dynamiquement. Il n'est pas capable de faire quoi que ce soit d'intéressant du tout qui ne peut pas être fait par Lua, Python, Ruby, etc. Aucune des implémentations JS n'est plus rapide que LuaJIT ou PyPy ou diverses autres implémentations JIT avancées d'autres dynamiques les langues. JS n'a pas de côté positif par rapport à d'autres langues couramment disponibles. Oh, sauf qu'il s'exécute nativement dans un navigateur Web sans plugin. C'est la seule raison au monde pour laquelle il est si populaire. En fait, c'est la seule raison pour laquelle cet événement existe. Si quelqu'un il y a 10 ans venait de penser, "diable, laissons tomber une langue existante bien conçue et bien établie dans notre navigateur et demandons aux autres gars de faire de même au lieu de faire en sorte que tout le monde utilise ce petit hackjob loufoque que NetScape a proposé ", le Web serait bien différent (meilleur) aujourd'hui. Imaginez simplement l'avenir si Chrome déposait Python dans Chrome comme langue prise en charge. Ou imaginez ceci: Google dépose C / C ++ dans Chrome en tant que langue prise en charge (http://code.google.com/p/nativeclient/).

Pourquoi?

JavaScript, la langue la plus mal comprise

Nous étions dans les âges sombres et sommes toujours pour la communauté de développement général d'accepter que JavaScript est un langage puissant et polyvalent. Ce n'est tout simplement pas courant.

La seule avancée récente est que node.js est devenu un buzz et les gens commencent à accepter que javascript ait d'autres utilisations.

J'ai gardé un œil sur le développement JS et HTML5 pour Windows 8 et la réaction de la communauté .NET était "mon dieu pourquoi?".

C'est tout simplement le fait que la plupart des développeurs non Web voient toujours JavaScript comme le langage de jouet que vous utilisez pour faire défiler les menus dans vos navigateurs.

Certes, JavaScript ne correspond pas aux "pratiques de développement modernes". Pour moi, JavaScript est toujours un langage de piratage que je craque avec vim et Internet est ma documentation. Il n'y a pas d'IDE, il n'y a pas d'outils de développement, il n'y a pas d'auto-complétion ou d '"intellisense", il n'y a pas de GUI click and drag.

Dans le monde des développeurs Java et .NET, ils sont connectés à leurs interfaces graphiques et IDE et ne pourraient pas programmer dans vim.

Votre liste ne contient rien sur l'écriture de fichiers dans le système, ce qui représente une partie importante du développement logiciel.

Les gens ne penseraient pas à utiliser JS pour créer une application car c'est le langage de script de facto pour le web, et vous utiliseriez toujours le bon outil pour le travail.

Pourquoi écrire des hectares de JS pour écrire un fichier alors qu'il s'agit d'une opération banale en Java / .NET / C / C ++?

Cela dit, comme d'autres l'ont mentionné, node.js et ses bibliothèques ont rendu les opérations côté serveur triviales et avec node.js devenant populaire, apprendre qu'il deviendra une compétence pour un CV, puisque vous pourrez maintenir / étendre / construire applications avec elle.

La plupart des langues couramment utilisées sont plus puissantes et mieux conçues que JavaScript. Toutes les fonctionnalités que vous mentionnez sont prises en charge par d'autres langages dynamiques comme Python ou Ruby qui sont globalement mieux conçus. Et certaines des fonctionnalités que vous mentionnez ne sont pas nécessairement souhaitables de toute façon - beaucoup considéreraient le typage statique avec l'inférence de type préférable au typage dynamique, si vous avez le choix.

Je ne dis pas cela pour diss JavaScript. J'aime beaucoup travailler avec JS lors du développement Web. Mais en regardant objectivement, JS a un certain nombre d'inconvénients par rapport aux autres langages:

• Nombreux défauts non corrigibles. De nombreuses erreurs ont été commises lors du développement initial de JS. Pas besoin de les énumérer ici, ils sont bien documentés. Toutes les langues ont des erreurs dans la conception initiale qui sont ensuite corrigées. La différence avec JS est que le langage a été développé et publié bien trop rapidement et ces erreurs ne peuvent jamais être corrigées en raison de l'exigence de compatibilité descendante dans les navigateurs.
• Processus extrêmement lent pour introduire des améliorations et de nouvelles fonctionnalités. Étant donné que tous les fournisseurs de navigateurs doivent être d'accord et pourraient même, pour diverses raisons politiques, vouloir ralentir le développement de la langue. Regardez C # qui est en fait un langage plus récent que JS. Lorsque C # a été introduit, il n'avait pas par exemple. des fermetures ou des fonctions d'ordre supérieur comme JS, mais après plusieurs itérations, il a maintenant tout cela et en plus des fonctionnalités comme Linq et la syntaxe asynchrone que les développeurs JavaScript ne peuvent qu'envier.
• Bibliothèque standard appauvrie. Les langages modernes comme Python, Ruby ou tout ce qui est basé sur Java ou .net ont des bibliothèques standard étendues pour presque tout ce dont vous pourriez avoir besoin. Dans JS, vous ne pouvez même pas lire un fichier sans bibliothèques tierces. Vous mentionnez Regex, mais toutes les langues modernes ont cela et mille autres choses.
• D'autres langues ont rattrapé les quelques avantages JavaScript. Des fonctionnalités telles que les fermetures et les fonctions de première classe étaient puissantes par rapport aux langages statiques maladroits comme Java il y a dix ans, mais les langages dynamiques et fonctionnels ont depuis longtemps ces fonctionnalités, et même Java, un langage assez conservateur, l'a ajouté dans Java 8.

La seule fonctionnalité qui distingue vraiment JavaScript des autres langages modernes est l'héritage basé sur un prototype (par opposition à basé sur une classe), et l'avantage de ce modèle est douteux car tout le monde l'utilise pour émuler l'héritage basé sur une classe de toute façon.

Il n'y a tout simplement aucune raison de choisir JavaScript si vous avez la possibilité de choisir une autre langue moderne. La seule raison serait que c'était la seule langue que vous connaissez.