Comment un programmeur habitué aux langages statiques fait face au manque d'outils Javascript

J'ai programmé à peu près exclusivement dans des langages compilés, en particulier Java, pendant la majeure partie de ma carrière. L'une de mes choses préférées à propos de Java est la productivité que vous pouvez être et le peu de code que vous avez réellement à écrire lorsque vous utilisez des outils comme Eclipse.

Vous pouvez:

• Refactorisez facilement et automatiquement vos méthodes et classes
• Afficher instantanément tous les endroits où une méthode est invoquée ou une constante est utilisée (Open Call Hierarchy / Show References)
• La saisie statique signifie que vous pouvez utiliser la complétion de code pour afficher tous les paramètres / fonctions disponibles sur un objet
• Contrôle-cliquez sur un nom de fonction / membre / classe pour aller directement à sa définition

Toutes ces installations me font sentir que l'IDE est mon meilleur ami. L'écriture de code Java et en particulier la compréhension des programmes des autres peuples devient beaucoup plus facile.

Cependant, je suis de plus en plus appelé à utiliser Javascript, et mon expérience jusqu'à présent a été assez négative.

En particulier:

• Aucun moyen immédiat de trouver le point d'entrée d'une fonction (autre qu'une recherche en texte brut, qui peut ensuite entraîner des recherches ultérieures de méthodes plus haut dans la hiérarchie des appels, après deux ou trois dont vous avez oublié où vous avez commencé)

• Les paramètres sont transmis aux fonctions, sans aucun moyen de savoir quelles propriétés et fonctions sont disponibles sur ce paramètre (autre que l'exécution du programme, la navigation jusqu'au point auquel la fonction est appelée et l'utilisation de console.logs pour afficher toutes les propriétés disponible)

• Utilisation courante de fonctions anonymes comme rappels, ce qui conduit souvent à un spaghetti de chemins de code déroutants, que vous ne pouvez pas parcourir rapidement.

• Et bien sûr, JSLint détecte quelques erreurs avant l'exécution, mais même ce n'est pas aussi pratique que d'avoir des lignes ondulées rouges sous votre code directement dans le navigateur.

Le résultat est que vous avez à peu près besoin d'avoir le programme entier dans votre tête à tout moment. Cela augmente considérablement la charge cognitive pour l'écriture de programmes complexes. Et toutes ces choses supplémentaires dont il faut s'inquiéter laissent moins de place dans mon cerveau pour la créativité et la résolution de problèmes.

Bien sûr, il est plus rapide de simplement assembler un objet plutôt que d'écrire une définition de classe formelle entière. Mais alors que les programmes peuvent être légèrement plus faciles et plus rapides à écrire, d'après mon expérience, ils sont beaucoup plus difficiles à lire et à déboguer.

Ma question est, comment les autres programmeurs gèrent-ils ces problèmes? Javascript gagne clairement en popularité, et les blogs que je lis parlent de la façon dont les gens sont productifs, plutôt que d'essayer désespérément de trouver des solutions à ces problèmes.

GWT vous permet d'écrire du code pour un environnement Javascript en Java à la place, mais ne semble pas être aussi largement utilisé que je m'y attendrais; les gens semblent préférer Javascript pour les programmes complexes.

Qu'est-ce que je rate?

Les subtilités basées sur l'IDE ne sont pas disponibles * dans un langage dynamique tel que javascript. Vous devez apprendre à vous en passer. Vous devrez remplacer le support d'outils par une meilleure conception.

Utilisez un modèle de module - soit à la main, soit avec un outil comme requirejs . Gardez les modules petits, afin de pouvoir les raisonner facilement.

Ne définissez pas autant de types - utilisez des objets anonymes créés à proximité du point d'appel. Ensuite, vous pouvez regarder l'appelant et l'appelé et savoir ce qui se passe.

Essayez d'éviter de coupler votre code au DOM - Essayez de limiter la quantité de manipulation DOM que vous faites dans votre code. Si vous pouvez transmettre des sélecteurs ou des collections jQuery, faites-le plutôt que de faire connaître la structure de la page à votre code.

* _{Si vous utilisez une bibliothèque populaire, vous pouvez obtenir une fausse saisie semi-automatique, mais cela ressemble plus à "afficher toutes les méthodes jquery" qu'à "quelles propriétés cet objet possède-t-il". Il enregistre la frappe, mais n'offre aucune garantie d'exactitude.}

Je voudrais ajouter une réponse à cette question car j'ai parcouru récemment du bon, du mauvais mais surtout du laid Java et j'ai une toute nouvelle charge de sur-généralisations brutes sur les développeurs Java et Java par rapport à JS et Les développeurs JS qui pourraient en fait être basés sur quelque chose ressemblant vaguement à une vérité utile.

Il y a des IDE mais il peut être utile de comprendre pourquoi il n'y en a pas eu beaucoup

J'ai essayé Webstorm maintenant que je suis attiré par le développement de Node et ce n'est pas assez mal que je l'ai acheté, mais j'ai toujours tendance à ouvrir les fichiers js dans Scite plus souvent que WS. La raison en est que vous pouvez faire beaucoup plus avec beaucoup moins dans JS, mais aussi parce que le travail de l'interface utilisateur donne un retour immédiat, les outils de développement du navigateur (Chrome et Firebug en particulier) sont en fait assez excellents, et (tenant compte des contextes non-navigateur ) la réexécution du code modifié est rapide et facile sans étape de compilation.

Une autre chose dont je suis assez convaincu est que les IDE créent essentiellement leur propre demande en activant du code bâclé que vous ne pouvez vraiment pas vous permettre en JavaScript. Vous voulez savoir comment nous gérons dans JS? Il peut être utile de commencer par essayer d'écrire quelque chose de non trivial en Java sans IDE et de porter une attention particulière aux choses que vous devez commencer à faire et à penser afin de pouvoir réellement maintenir / modifier ce code sans qu'un IDE ne bouge. vers l'avant. OMI, ces mêmes choses sont toujours essentielles à l'écriture de code maintenable, que vous ayez un IDE ou non. Si je devais écrire un programme de programmation de 4 ans, cela ne vous laisserait pas toucher à un IDE pendant les deux premières années dans le but de ne pas tordre les outils et les dépendances.

Structure

Les développeurs JS expérimentés traitant des applications complexes peuvent et peuvent structurer leur code. En fait, c'est une chose que nous avons tendance à améliorer avec une histoire ancienne qui manquait d'IDE pour lire le code pour nous, mais aussi parce que les langages puissamment expressifs peuvent exprimer très rapidement des bases de code de catastrophe complètement ingérables très rapidement si vous ne codez pas de manière réfléchie.

J'ai en fait eu une courbe d'apprentissage assez abrupte dans la compréhension de notre base de code Java récemment jusqu'à ce que je réalise finalement que rien de tout cela n'était une bonne POO. Les classes n'étaient rien de plus que des ensembles de méthodes vaguement reliées modifiant les données disponibles à l'échelle mondiale dans des beans ou des DTO ou des getters / setters statiques. C'est essentiellement la même vieille bête que OOP était censée remplacer. J'ai donc arrêté de chercher et de penser au code en gros. Je viens d'apprendre les touches de raccourci et j'ai retracé les dégâts et tout s'est bien passé. Donc, si vous n'avez pas déjà l'habitude, pensez beaucoup plus à OOD.

Une application JS bien structurée au plus haut niveau aura tendance à se composer de fonctions complexes (par exemple jQuery) et d'objets interagissant les uns avec les autres. Je dirais que la marque d'une application bien structurée et facile à entretenir dans n'importe quelle langue est qu'elle est parfaitement lisible, que vous la regardiez avec un IDE ou Notepad ++. C'est l'une des principales raisons pour lesquelles je suis très critique à l'égard de l'injection de dépendances et du TDD test-first poussé à l'extrême.

Et enfin, abandonnez les cours. Apprenez l'héritage prototypique. Il est en fait assez élégant et facile à implémenter lorsque vous avez réellement besoin d'héritage. Cependant, je trouve que les approches de compositing fonctionnent beaucoup mieux dans JS, et je commence personnellement à tomber malade et à avoir des terreurs nocturnes EXTJS chaque fois que je vois plus d'un ou deux niveaux d'héritage en cours dans n'importe quelle langue.

Principes fondamentaux d'abord

Je parle des éléments essentiels dont devraient dériver toutes les autres bonnes pratiques: DRY, YAGNI, le principe du moindre étonnement, la séparation nette des domaines problématiques, l'écriture sur une interface et l'écriture de code lisible humain sont mon noyau personnel. Tout ce qui est un peu plus complexe et qui préconise l'abandon de ces pratiques devrait être considéré comme Kool Aid dans n'importe quel langage, mais surtout un langage comme JavaScript où il est très facile de laisser un héritage de code très déroutant pour le prochain. Le couplage lâche, par exemple, est une bonne chose jusqu'à ce que vous alliez si loin que vous ne pouvez même pas dire où se produit l'interaction entre les objets.

N'ayez pas peur de la frappe dynamique

Il n'y a pas beaucoup de types de base en JavaScript. Pour la plupart, les règles de casting dynamiques sont pratiques et simples, mais cela vaut la peine de les apprendre afin que vous puissiez mieux apprendre à gérer le flux de données sans conversions inutiles et routines de validation inutiles. Croyez-moi. Les types stricts sont parfaits pour les problèmes de performances et de repérage lors de la compilation, mais ils ne vous protègent de rien.

Découvrez les fonctions et fermetures de JS

Les fonctions de première classe de JS sont sans doute la principale raison pour laquelle JS a remporté le prix «Seule langue digne de toucher le Web côté client». Et oui, il y avait effectivement de la concurrence. Ils sont également une caractéristique centrale de JS. Nous construisons des objets avec eux. Tout est limité aux fonctions. Et ils ont des fonctionnalités pratiques. Nous pouvons examiner les paramètres via le mot-clé arguments. Nous pouvons temporairement les attacher et les tirer dans le contexte d'être des méthodes d'autres objets. Et ils rendent les approches événementielles des choses obscurément faciles à mettre en œuvre. En bref, ils ont fait de JS une bête absolue pour réduire la complexité et adapter différentes implémentations de JS lui-même (mais surtout l'API DOM) directement à la source.

Réévaluer les modèles / pratiques avant d'adopter

Les fonctions de première classe et les types dynamiques rendent beaucoup de modèles de conception plus complexes complètement inutiles et encombrants dans JS. Cependant, certains des modèles les plus simples sont incroyablement utiles et faciles à mettre en œuvre étant donné la nature très flexible de JS. Les adaptateurs et les décorateurs sont particulièrement utiles et j'ai trouvé les singletons utiles pour les usines de widgets d'interface utilisateur complexes qui agissent également comme gestionnaires d'événements pour les éléments d'interface utilisateur qu'ils construisent.

Suivez l'exemple de la langue et faites plus avec moins

Je crois que l'un des honneurs de Java fait valoir quelque part que la verbosité est en fait une caractéristique positive qui rend le code plus facile à comprendre pour toutes les parties. Poudlard. Si c'était vrai, le jargon juridique serait plus facile à lire. Seul l'auteur peut rendre ce qu'ils ont écrit plus facile à comprendre et vous ne pouvez le faire qu'en vous mettant à la place de l'autre gars de temps en temps. Adoptez donc ces deux règles. 1. Soyez aussi direct et clair que possible. 2. Arrivez au point putain déjà. La victoire est que le code propre et concis est des ordres de grandeur plus faciles à comprendre et à maintenir que quelque chose où vous devez parcourir vingt-cinq couches pour passer du déclencheur à l'action réelle souhaitée. La plupart des modèles qui préconisent ce genre de chose dans des langages plus stricts sont en fait des solutions de contournement pour les limitations que JavaScript n'a pas.

Tout est malléable et ça va

JS est probablement l'un des langages les moins protectionnistes couramment utilisés. Embrassez cela. Ça fonctionne bien. Par exemple, vous pouvez écrire des objets avec des variables persistantes "privées" inaccessibles en déclarant simplement des variables régulières dans une fonction constructeur et je le fais fréquemment. Mais ce n'est pas pour protéger mon code ou ses utilisateurs "d'eux-mêmes" (ils pourraient tout de même le remplacer par leur propre version pendant l'exécution). Mais c'est plutôt pour signaler l'intention parce que l'hypothèse est que l'autre gars est suffisamment compétent pour ne pas vouloir manipuler les dépendances et verra que vous n'êtes pas censé y accéder directement, peut-être pour une bonne raison.

Il n'y a pas de limites de taille, seuls les domaines problématiques

Le plus gros problème que j'ai avec toutes les bases de code Java que j'ai vues est une surabondance de fichiers de classe. Tout d'abord, SOLID n'est qu'une réitération déroutante de ce que vous devez déjà savoir sur la POO. Une classe doit gérer un ensemble spécifique de problèmes connexes. Pas un problème avec une seule méthode. Cela ne prend que du mauvais vieux code de func-spaghetti C en chaîne uniquement avec l'ajout de toute la syntaxe de classe inutile pour démarrer. Il n'y a pas de limite de taille ou de méthode. S'il est logique d'ajouter quelque chose à une fonction ou une classe ou un constructeur déjà long, cela a du sens. Prenez jQuery. C'est un ensemble d'outils complet de la longueur d'une bibliothèque dans une seule fonction et il n'y a rien de mal à cela. Que nous ayons encore besoin de jQuery est à un débat raisonnable, mais en termes de conception,

Si Java est tout ce que vous savez, essayez quelque chose avec une syntaxe non basée sur C

Quand j'ai commencé à jouer avec Python parce que j'aimais ce que j'entendais sur Django, j'ai appris à séparer la syntaxe de la conception du langage. En conséquence, il est devenu plus facile de comprendre Java et C comme une somme de leurs parties de conception de langage plutôt que comme une somme de choses qu'ils font différemment avec la même syntaxe. Un bon effet secondaire est que plus vous comprenez les autres langues en termes de conception, mieux vous comprendrez les forces / faiblesses de celle que vous connaissez le mieux grâce au contraste.

Conclusion

Maintenant, compte tenu de tout cela, nous allons toucher tous vos problèmes:

• Aucun moyen immédiat de trouver le point d'entrée d'une fonction (autre qu'une recherche en texte brut, qui peut ensuite entraîner des recherches ultérieures de méthodes plus haut dans la hiérarchie des appels, après deux ou trois dont vous avez oublié où vous avez commencé)

Chrome et Firebug ont en fait un suivi des appels. Mais voyez aussi mes points sur la structure et la concision et la directivité. Plus vous pouvez considérer votre application comme de plus grandes constructions bien encapsulées interagissant les unes avec les autres, plus il est facile de déterminer à qui revient la faute lorsque les choses tournent mal. Je dirais que c'est vrai aussi pour Java. Nous avons des constructeurs de fonctions de classe qui sont parfaitement utilisables pour les problèmes de POO traditionnels.

function ObjectConstructor(){
    //No need for an init method.
    //Just pass in params and do stuff inside for instantiation behavior

    var privateAndPersistent = true;

    //I like to take advantage of function hoisting for a nice concise interface listing
    this.publicAndPointlessEncapsulationMurderingGetterSetter
    = publicAndPointlessEncapsulationMurderingGetterSetter;
    //Seriously though Java/C# folks, stop with the pointless getter/setters already

    function publicAndPointlessEncapsulationMurderingGetterSetter(arg){
        if(arg === undefined){
            return privateAndPersistent;
        }
        privateAndPersistent = arg;
    }

}

ObjectConstructor.staticLikeNonInstanceProperty = true;

var instance = new ObjectConstructor();//Convention is to  capitalize constructors

Dans mon code, je n'utilise presque jamais les littéraux d'objet {}comme composants d'application structurelle car ils ne peuvent pas avoir de variables internes (privées) et préfèrent plutôt les réserver pour une utilisation en tant que structures de données. Cela permet de définir une attente qui maintient la clarté de l'intention. (si vous voyez des curlies, ce sont des données, pas un composant de l'architecture de l'application).

• Les paramètres sont transmis aux fonctions, sans aucun moyen de savoir quelles propriétés et fonctions sont disponibles sur ce paramètre (autre que l'exécution du programme, la navigation jusqu'au point auquel la fonction est appelée et l'utilisation de console.logs pour afficher toutes les propriétés disponible)

Encore une fois, consultez les outils de navigation modernes. Mais aussi, pourquoi est-il si difficile de réexécuter le programme? Le rechargement est quelque chose qu'un développeur Web côté client frappe généralement toutes les quelques minutes, car cela ne vous coûte absolument rien pour le faire. C'est encore une fois, un autre point avec lequel la structure de l'application peut être utile, mais c'est un compromis de JS que vous devez exécuter votre propre validation lorsque l'application des contrats est critique (quelque chose que je fais uniquement aux points de terminaison exposés à d'autres choses que ma base de code ne fait pas). 't contrôle). OMI, le compromis vaut bien les avantages.

• Utilisation courante de fonctions anonymes comme rappels, ce qui conduit souvent à un spaghetti de chemins de code déroutants, que vous ne pouvez pas parcourir rapidement.

Ouais, c'est mauvais pour tout ce qui n'est pas trivial. Ne fais pas ça. Nommez vos fonctions enfants. Il est également plus facile de retracer les choses. Vous pouvez définir, évaluer (requis pour attribuer) et attribuer une fonction triviale simple en ligne avec:

doSomethingWithCallback( (function callBack(){}) );

Désormais, Chrome aura un nom pour vous lorsque vous effectuez le suivi des appels. Pour les fonctions non triviales, je les définirais en dehors de l'appel. Notez également que les fonctions anonoymées affectées à une variable sont toujours anonymes.

• Et bien sûr, JSLint détecte quelques erreurs avant l'exécution, mais même ce n'est pas aussi pratique que d'avoir des lignes ondulées rouges sous votre code directement dans le navigateur.

Je ne touche jamais à ça. Crockford a donné de bonnes choses à la communauté, mais JSLint franchit la ligne dans les préférences stylistiques et suggérant que certains éléments de JavaScript sont de mauvaises parties sans raison particulière, IMO. Ignorez définitivement une chose à propos des classes regEx et négation suivies de * ou +. Les caractères génériques fonctionnent moins bien et vous pouvez facilement limiter la répétition avec {}. Ignorez également tout ce qu'il dit sur les constructeurs de fonctions. Vous pouvez facilement les envelopper dans une fonction d'usine si le nouveau mot clé vous dérange. CSSLint (pas Crockford) est encore pire sur le mauvais conseil. Prenez toujours des gens qui font beaucoup de discours avec un grain de sel. Parfois, je jure qu'ils cherchent simplement à établir une autorité ou à générer de nouveaux éléments.

Et encore une fois, vous devez désapprendre ce que vous avez appris avec cette préoccupation d'exécution que vous avez. (c'est un problème courant que j'ai vu avec beaucoup de développeurs Java / C #) Si voir des erreurs au moment de l'exécution vous dérange encore 2 ans plus tard, je veux que vous vous asseyiez et que le spam se recharge dans un navigateur jusqu'à ce qu'il s'enfonce. il n'y a pas de division à la compilation / à l'exécution (enfin pas visible de toute façon - JS est exécuté sur un JIT maintenant). Il n'est pas seulement correct de découvrir des bogues au moment de l'exécution, il est extrêmement avantageux de recharger le spam aussi facilement et à moindre coût et de découvrir des bogues à chaque point d'arrêt auquel vous vous rendez.

Et lancez-vous sur ces outils de développement Chrome. Ils sont intégrés directement dans le webkit. Faites un clic droit dans Chrome. Inspecter l'élément. Explorez les onglets. Beaucoup de puissance de débogage avec la possibilité de modifier le code dans la console pendant l'exécution étant l'une des options les plus puissantes mais moins évidentes. Idéal pour les tests aussi.

Sur une note connexe, les erreurs sont vos amis. N'écrivez jamais une déclaration catch vide. Dans JS, nous ne cachons ni n'enterrons les erreurs (ou du moins nous ne devons pas tousser YUI / toux ). Nous nous occupons d'eux. Rien de moins entraînera une douleur de débogage. Et si vous écrivez une instruction catch pour masquer les erreurs potentielles dans la production, enregistrez au moins silencieusement l'erreur et documentez comment accéder au journal.

Ce que vous dites n'est que le reproche commun à une personne soucieuse de Java qui regarde JavaScript.

Répondons d'abord à votre question ...

... ma question est de savoir comment les autres programmeurs font face à ces problèmes ...

Réponse: ils ne le font PAS. Ils apprennent la philosophie JavaScript en abandonnant d'abord le culte Java.

Vous devez comprendre cette prémisse ... JavaScript n'est PAS Java. Il ne s'agit tout simplement pas de syntaxe - c'est plutôt de philosophie.

Reprenons maintenant certains d'entre eux ...

• Afficher instantanément tous les endroits où une méthode est invoquée ou une constante est utilisée (Open Call Hierarchy / Show References)

  Contrôle-cliquez sur un nom de fonction / membre / classe pour aller directement à sa définition

  Tous ces éléments sont disponibles - il suffit de choisir un IDE décent.

• La saisie statique signifie que vous pouvez utiliser la complétion de code pour afficher tous les paramètres / fonctions disponibles sur un objet

  Ce n'est pas un problème auquel vous faites face . C'est quelque chose qui nécessite de changer votre vision de la programmation. Le système de type lâche est l'une des forces de JavaScript. Comprenez la dactylographie lâche - et apprenez à l'apprécier. De plus, la complétion de code fonctionne très bien avec JS.

• Et bien sûr, JSLint détecte quelques erreurs avant l'exécution, mais même ce n'est pas aussi pratique que d'avoir des lignes ondulées rouges sous votre code directement dans le navigateur.

  Firebug, la console Chrome / Safari et même les IDE font tout cela et PLUS.

  Il existe JSHint qui peut effectuer l'analyse statique astucieuse à laquelle les programmeurs Java sont habitués.

• Le résultat est que vous avez à peu près besoin d'avoir le programme entier dans votre tête à tout moment. Cela augmente considérablement la charge cognitive pour l'écriture de programmes complexes.

  Faux! Au contraire, JavaScript est un langage de programmation "léger" - et vous encourage à avoir des programmes plus simples. Comme le dit Doug Crockford ... cela vous "punira" si vous essayez d'écrire des programmes fortement basés sur des modèles en JavaScript.

• alors que les programmes peuvent être légèrement plus faciles et plus rapides à écrire, d'après mon expérience, ils sont beaucoup plus difficiles à lire et à déboguer.

  Totalement faux! Comment décidez-vous de la lisibilité en fonction du langage de programmation? Les programmes sont lisibles (ou non) - PAS les langues. De plus, JavaScript a des débogueurs fantastiques.

Pardonnez-moi si j'ai eu l'air un peu grossier - mais la vérité est que vous devez changer votre disposition Java pour comprendre JavaScript.

Seuls les programmeurs Java "matures" peuvent apprécier JavaScript - et vous ne pouvez pas maîtriser ce que vous n'appréciez pas. Encore une fois, désolé d'être carrément franc.

En général, il est difficile d'avoir les outils que vous avez mentionnés pour un langage dynamique (sauf si l'IDE fait partie du runtime - c'est-à-dire Smalltalk). Cela dit, une fois que vous avez appris un très bon éditeur de texte, la plupart des IDE semblent moins attrayants - c'est du moins mon expérience.

C'est le prix que nous payons pour utiliser des langues mal typées. On ne peut que se demander pourquoi cette abomination est devenue si populaire. Les inconvénients l'emportent de loin sur les avantages des langues mal typées.

Peut-être devrions-nous appliquer le principe de non-coopération à ces déchets pour les faire disparaître.

Je détestais javascript (et sa frappe dynamique) mais j'ai appris à apprécier son orientation, ses fermetures et sa programmation fonctionnelle . De plus, ses objets globaux et la suppression de la conversion de type silencieuse étaient une bouffée d'air frais lorsque je les ai trouvés pour la première fois.

Mon idée préférée pour javascript est webstorm car il est facile de faire fonctionner jQuery intellitext (dommage que ce ne soit pas gratuit).

De plus, je ne dirais pas que sa croissance est déjà omniprésente.

Vos points spécifiques:

Aucun moyen immédiat de trouver le point d'entrée d'une fonction

Je ne comprends pas cela, comment pourrait-il être plus simple?

Les paramètres sont passés aux fonctions, sans aucun moyen de savoir quelles propriétés et fonctions sont disponibles sur ce paramètre

Si vous configurez votre idée pour inclure la définition des objets, les propriétés de l'objet seront disponibles via intellitext (mais j'ai peut-être manqué votre point ici).

Utilisation courante de fonctions anonymes comme rappels, ce qui conduit souvent à un spaghetti de chemins de code déroutants, que vous ne pouvez pas parcourir rapidement.

Usage courant ? Si vous n'aimez pas les fonctions anonymes, ne les utilisez pas. Ou faites-vous référence à jQuery qui les utilise considérablement? jQuery est probablement considéré par la plupart des développeurs Web comme le plus grand gain de temps de l'histoire du développement Web .

JSLint intercepte quelques erreurs avant l'exécution

Il les attrape tous, vous pouvez les inclure dans votre idée . Ou Webstorm l'inclut par défaut (je pense).

Qu'est-ce que je rate?

Il vous manque les deux énormes avantages de Javascript sur Java:

• Le code Javascript représente environ un quart de la taille du code Java équivalent.
• Vous n'avez jamais à attendre une compilation et un redémarrage du serveur.

Je travaille différemment en Javascript. J'ajoute un peu de code à la fois, aussi peu que possible, et actualise le navigateur et le teste. Avec jQuery, quelques lignes de Javascript sont tout ce dont j'ai besoin la plupart du temps.

J'ai trouvé la programmation Java relativement peu productive , et j'écris maintenant tout mon code côté serveur dans Groovy, pour les deux mêmes raisons.

Je sais que cette question est ancienne mais en tant que programmeur C ++ / C # qui a eu les mêmes sentiments mais qui a maintenant fait beaucoup de JavaScript au cours des 10 dernières années, ma première recommandation serait d' essayer Visual Studio Code .

Bien sûr, il ne peut pas offrir toutes les fonctionnalités qui peuvent être ajoutées avec un langage fortement typé, mais il se rapproche assez.

Il peut également extraire des informations de type de typescript et les appliquer à JavaScript. Même si vous n'utilisez jamais de frappe, vous pouvez obtenir du code et de la documentation sur des tonnes d'API lorsque vous tapez JavaScript.

Donc à vos questions

• Aucun moyen immédiat de trouver le point d'entrée d'une fonction (autre qu'une recherche en texte brut, qui peut ensuite entraîner des recherches ultérieures de méthodes plus haut dans la hiérarchie des appels, après deux ou trois dont vous avez oublié où vous avez commencé)

Semble principalement résolu dans VSCode?

• Les paramètres sont passés aux fonctions, sans aucun moyen de savoir quelles propriétés et fonctions sont disponibles sur ce paramètre

Ce problème est résolu pour de nombreux IDE en documentant votre code avec des commentaires de style JSDoc ou du texte dactylographié. Les éditeurs liront les commentaires et vous donneront le même achèvement auquel vous êtes habitué

Utilisation courante de fonctions anonymes comme rappels, ce qui conduit souvent à un spaghetti de chemins de code déroutants, que vous ne pouvez pas parcourir rapidement.

En tant que programmeur C #, les fonctions anonymes sont également courantes et ont été ajoutées à C ++. Je pense que c'est quelque chose auquel vous devez simplement vous habituer.

De plus, bien que les rappels aient été principalement remplacés par des promesses et par async / wait et si vous avez une API qui utilise un rappel, vous pouvez rapidement l'encapsuler pour utiliser une promesse, puis utiliser async / wait pour que ce problème disparaisse.

Et bien sûr, JSLint détecte quelques erreurs avant l'exécution, mais même ce n'est pas aussi pratique que d'avoir des lignes ondulées rouges sous votre code directement dans le navigateur.

Vous obtiendrez des lignes ondulées dans Visual Studio Code. Non seulement cela, mais si vous activez l'intégration ESLint, vous obtiendrez des tonnes d'avertissements et / ou d'erreurs incroyables mis en évidence dans votre éditeur. Plus que ce que j'ai vu pour d'autres langues en fait. Mon expérience est que les linters pour C / C # / Java ont été assez codés en dur alors qu'ESLint est à la fois massivement configurable et massivement extensible et que de telles bibliothèques populaires peuvent même s'intégrer pour vous donner des conseils et des avertissements sur l'utilisation de bibliothèques spécifiques dans l'éditeur. Quelque chose que je n'ai pas personnellement vu dans d'autres langues (bien que ce soit peut-être commun maintenant aussi pour d'autres langues?)

C'est aussi 2018 et ES7 est la nouvelle norme, donc vous obtenez class. Vous utilisez toujours le mode strict. Vous n'utilisez jamais varet utilisez toujours constet letet un tas de choses que les programmeurs C ++ / C # / Java ont eu du mal à s'habituer à disparaître. Activez la no-undefrègle dans ESLint et encore plus de problèmes disparaissent

Cela dit, apprenez comment thisfonctionne vraiment et comment les fonctions et les méthodes fonctionnent vraiment, car ce n'est pas la même chose que C ++ / C # / Java.

Mes 2-3 premières années de JavaScript m'ont frustré. À un moment donné, il a cliqué. J'ai cessé d'essayer de le forcer à devenir C ++ / C # / Java et maintenant je suis frustré de revenir en arrière quand des choses qui prendraient 15 lignes en JavaScript en prennent 150 dans ces autres langages.

Si vous aimez les IDE et êtes utilisé pour éclipser, consultez Aptana comme IDE pour JavaScript. Je pense que cela peut faire beaucoup de ce que vous voulez. (Personnellement, je déteste les IDE mais c'est une conversation différente).

Quant aux fonctions anonymes, je trouve qu'elles sont la fonctionnalité la plus puissante de JavaScript et essayer de travailler dans un langage qui ne les possède pas est à ce stade assez pénible.

Si vous voulez quelque chose d'autre qui peut être compilé en JavaScript, il y a un tas d'options, CofffeeScript, Clojure et GWT sautent tous à l'esprit mais il y en a d'autres.

Je ne l'ai pas encore utilisé moi-même mais j'ai vu quelques démos et je suis très impressionné par Cloud 9 en tant qu'IDE JavaScript.

Vous pouvez opter pour le modèle de service en ligne ou le télécharger sur GitHub.

Et comme preuve de sa qualité d'IDE, Cloud9 a été écrit en utilisant ... Cloud9!