¿Cómo hace frente un programador a los lenguajes estáticos a la falta de herramientas Javascript?

He programado casi exclusivamente en lenguajes compilados, particularmente Java, durante la mayor parte de mi carrera. Una de mis cosas favoritas sobre Java es lo productivo que puede ser y el poco código que realmente tiene que escribir cuando usa herramientas como Eclipse.

Usted puede:

• Refactorice fácil y automáticamente sus métodos y clases
• Ver instantáneamente todos los lugares donde se invoca un método o se usa una constante (Abrir jerarquía de llamadas / Mostrar referencias)
• La escritura estática significa que puede usar la finalización de código para mostrar todos los parámetros / funciones disponibles en un objeto
• Control-clic en el nombre de una función / miembro / clase para ir directamente a su definición

Todas estas instalaciones me hacen sentir que el IDE es mi mejor amigo. Escribir código Java y particularmente comprender los programas de otras personas se vuelve mucho más fácil.

Sin embargo, se me pide cada vez más que use Javascript, y mi experiencia hasta ahora ha sido bastante negativa.

En particular:

• No hay forma inmediata de encontrar el punto de entrada de una función (que no sea una búsqueda de texto sin formato, que luego puede resultar en búsquedas posteriores de métodos más arriba en la jerarquía de llamadas, después de dos o tres de los cuales ha olvidado dónde comenzó)

• Los parámetros se pasan a las funciones, sin forma de saber qué propiedades y funciones están disponibles en ese parámetro (aparte de ejecutar realmente el programa, navegar hasta el punto en el que se llama la función y usar console.logs para generar todas las propiedades disponible)

• El uso común de funciones anónimas como devoluciones de llamada, que con frecuencia conduce a un espagueti de rutas de código confusas, que no puede navegar rápidamente.

• Y claro, JSLint detecta algunos errores antes del tiempo de ejecución, pero incluso eso no es tan útil como tener líneas onduladas rojas debajo de su código directamente en el navegador.

El resultado es que prácticamente necesitas tener todo el programa en tu cabeza en todo momento. Esto aumenta enormemente la carga cognitiva para escribir programas complejos. Y todas estas cosas adicionales de las que preocuparse dejan menos espacio en mi cerebro para la creatividad y la resolución de problemas.

Claro, es más rápido simplemente juntar un objeto en lugar de escribir una definición de clase formal completa. Pero aunque los programas pueden ser un poco más fáciles y rápidos de escribir, en mi experiencia son mucho más difíciles de leer y depurar.

Mi pregunta es, ¿cómo enfrentan otros programadores estos problemas? Es evidente que Javascript está creciendo en popularidad, y los blogs que leo tratan sobre cuán productivas son las personas con él, en lugar de tratar desesperadamente de encontrar soluciones a estos problemas.

GWT le permite escribir código para un entorno Javascript en Java, pero no parece ser tan ampliamente utilizado como yo esperaría; la gente parece preferir Javascript para programas complejos.

¿Qué me estoy perdiendo?

Las bondades basadas en IDE no están disponibles * en un lenguaje dinámico como javascript. Tienes que aprender a prescindir de ellos. Tendrá que reemplazar el soporte de herramientas con un mejor diseño.

Use un patrón de módulo , ya sea a mano o con una herramienta como requirejs . Mantenga los módulos pequeños, para que pueda razonar sobre ellos fácilmente.

No defina tantos tipos : use objetos anónimos creados cerca del punto de llamada. Luego puede mirar a la persona que llama y al que llama y saber qué está pasando.

Intente evitar acoplar su código al DOM : intente limitar la cantidad de manipulación de DOM que realiza en su código. Si puede pasar selectores o colecciones jQuery, hágalo en lugar de que su código conozca la estructura de la página.

* _{Si está utilizando una biblioteca popular, puede obtener un autocompletado falso, pero es más como "mostrar todos los métodos jquery" que como "qué propiedades tiene este objeto". Ahorra escribir, pero no ofrece ninguna garantía de corrección.}

Me gustaría agregar una respuesta a esta pregunta, ya que últimamente he estado avanzando a través de algunos Java buenos, malos pero en su mayoría feos, y tengo una gran cantidad de generalizaciones brutas sobre desarrolladores Java y Java vs.JS y Desarrolladores JS que en realidad podrían estar basados ​​en algo vagamente parecido a una verdad útil.

Hay IDEs pero puede ser útil entender por qué no ha habido muchos

He estado probando Webstorm ahora que me siento atraído por el desarrollo de Node y no es lo suficientemente malo como para que lo haya comprado, pero todavía tiendo a abrir archivos js en Scite con más frecuencia que WS. La razón de esto es que puede hacer mucho más con mucho menos en JS, pero también porque el trabajo de la interfaz de usuario proporciona comentarios inmediatos, las herramientas de desarrollo del navegador (Chrome y Firebug en particular) son realmente excelentes y (teniendo en cuenta los contextos que no son del navegador ) volver a ejecutar el código alterado es rápido y fácil sin un paso de compilación.

Otra cosa de la que estoy bastante convencido es que los IDEs básicamente crean su propia demanda al habilitar un código descuidado que realmente no puede permitirse en JavaScript. ¿Quieres aprender cómo nos gestionamos en JS? Puede ser útil comenzar tratando de escribir algo no trivial en Java sin un IDE y prestar mucha atención a las cosas que debe comenzar a hacer y pensar para poder mantener / modificar ese código sin mover un IDE adelante. En mi opinión, esas mismas cosas siguen siendo críticas para escribir código mantenible, ya sea que tenga un IDE o no. Si tuviera que escribir un plan de estudios de programación de 4 años, no le permitiría tocar un IDE durante los primeros dos años con el interés de no torcer las herramientas y las dependencias.

Estructura

Los desarrolladores JS experimentados que trabajan con aplicaciones complejas pueden estructurar su código y lo hacen. De hecho, es algo en lo que tendemos a tener que ser mejores con una historia temprana que carecía de IDEs para leer el código por nosotros, pero también porque los lenguajes poderosamente expresivos pueden expresar poderosamente bases de códigos de desastres completamente imposibles de mantener muy rápidamente si no codifica cuidadosamente.

De hecho, tuve una curva de aprendizaje bastante empinada para comprender nuestra base de código Java recientemente hasta que finalmente me di cuenta de que nada de eso era una POO adecuada. Las clases no eran más que paquetes de métodos poco relacionados que alteran los datos disponibles a nivel mundial en beans o DTO o getters / setters estáticos. Esa es básicamente la misma bestia vieja que se suponía que OOP reemplazaría. Así que básicamente dejé de mirar y pensar en el código. Acabo de aprender las teclas de acceso directo y rastreé a través de los problemas y todo salió mucho más suavemente. Entonces, si aún no tiene el hábito, piense mucho más sobre OOD.

Una aplicación JS bien estructurada al más alto nivel tenderá a consistir en funciones complejas (por ejemplo, jQuery) y objetos que interactúan entre sí. Yo diría que la marca de una aplicación bien estructurada y fácil de mantener en cualquier idioma es que es perfectamente legible ya sea que la esté mirando con un IDE o Notepad ++. Es una de las principales razones por las que soy muy crítico con la inyección de dependencia y la primera prueba de TDD llevada al extremo.

Y finalmente, deja ir las clases. Aprende la herencia prototípica. En realidad, es bastante elegante, fácil de implementar cuando realmente necesita herencia. Sin embargo, creo que los enfoques de composición tienden a funcionar mucho mejor en JS, y personalmente empiezo a enfermarme y tengo terrores nocturnos EXTJS cada vez que veo más de uno o dos niveles de herencia en cualquier idioma.

Principios Básicos Primero

Me refiero a las cosas centrales de las que deberían derivarse todas las otras buenas prácticas: DRY, YAGNI, el principio del menor asombro, la separación limpia de dominios problemáticos, escribir en una interfaz y escribir código legible humano son mi núcleo personal. Cualquier cosa un poco más compleja que defienda el abandono de esas prácticas debe considerarse Kool Aid en cualquier idioma, pero especialmente en un lenguaje como JavaScript, donde es muy fácil dejar un legado de código muy confuso para el próximo tipo. El acoplamiento flojo, por ejemplo, es excelente hasta que lo llevas tan lejos que ni siquiera puedes saber dónde está ocurriendo la interacción entre los objetos.

No temas teclear dinámicamente

No hay muchos tipos principales en JavaScript. En su mayor parte, las reglas de conversión dinámicas son prácticas y directas, pero vale la pena aprenderlas para que pueda aprender mejor a administrar el flujo de datos sin conversiones innecesarias y rutinas de validación sin sentido. Créeme. Los tipos estrictos son excelentes para el rendimiento y detectar problemas en la compilación, pero no lo protegen de nada.

Aprenda la mierda de las funciones y cierres de JS

Las funciones de primera clase de JS son posiblemente la razón principal por la que JS ganó el premio "Solo un lenguaje que vale la pena tocar la web del lado del cliente". Y sí, en realidad hubo competencia. También son una característica central de JS. Construimos objetos con ellos. Todo tiene un alcance para las funciones. Y tienen características útiles. Podemos examinar los parámetros a través de la palabra clave argumentos. Podemos adjuntarlos temporalmente y dispararlos en el contexto de ser métodos de otros objetos. Y hacen que los enfoques basados ​​en eventos de cosas obscenamente fáciles de implementar. En resumen, convirtieron a JS en una bestia absoluta para reducir la complejidad y adaptar diversas implementaciones de JS (pero principalmente la API DOM) directamente en la fuente.

Reevaluar patrones / prácticas antes de adoptar

Las funciones de primera clase y los tipos dinámicos hacen que muchos de los patrones de diseño más complejos sean completamente inútiles y engorrosos en JS. Sin embargo, algunos de los patrones más simples son increíblemente útiles y fáciles de implementar dada la naturaleza altamente flexible de JS. Los adaptadores y decoradores son particularmente útiles y he encontrado que los singletons son útiles para las complejas fábricas de widgets de interfaz de usuario que también actúan como gestores de eventos para los elementos de interfaz de usuario que construyen.

Siga la guía del idioma y haga más con menos

Creo que uno de los principales jefes de Java argumenta en alguna parte que la verbosidad es en realidad una característica positiva que hace que el código sea más fácil de entender para todas las partes. Bazofia. Si eso fuera cierto, la jerga legal sería más fácil de leer. Solo el escritor puede hacer que lo que ha escrito sea más fácil de entender y usted solo puede hacerlo poniéndose en el lugar del otro tipo ocasionalmente. Entonces abraza estas dos reglas. 1. Sea lo más directo y claro posible. 2. Llegar al maldito punto ya. La victoria es que el código limpio y conciso es de órdenes de magnitud más fáciles de entender y mantener que algo en lo que tienes que atravesar veinticinco capas para llegar desde el gatillo a la acción deseada real. La mayoría de los patrones que defienden ese tipo de cosas en lenguajes más estrictos son, de hecho, soluciones para limitaciones que JavaScript no tiene.

Todo es maleable y eso está bien

JS es probablemente uno de los lenguajes menos proteccionistas de uso popular. Abraza eso. Funciona bien. Por ejemplo, puede escribir objetos con variables "privadas" persistentes inaccesibles simplemente declarando variables regulares en una función de constructor y hago esto con frecuencia. Pero no es para proteger mi código o los usuarios del mismo "de sí mismos" (de todos modos, podrían reemplazarlo con su propia versión durante el tiempo de ejecución). Pero más bien es para señalar la intención porque la suposición es que el otro tipo es lo suficientemente competente como para no querer destrozar ninguna dependencia y verá que no está destinado a hacerlo directamente, tal vez por una buena razón.

No hay límites de tamaño, solo dominios problemáticos

El mayor problema que tengo con todas las bases de código Java que he visto es la abundancia de archivos de clase. En primer lugar, SOLID es solo una reiteración confusa de lo que ya debe saber sobre OOP. Una clase debe manejar un conjunto específico de problemas relacionados. No hay un problema con un método. Eso es solo tomar el viejo código de func-spaghetti C de encadenamiento solo con la adición de toda la sintaxis de clase sin sentido para arrancar. No hay límite de tamaño o método. Si tiene sentido agregar algo a una función, clase o constructor ya largo, tiene sentido. Toma jQuery. Es un conjunto completo de herramientas de longitud de biblioteca en una sola función y no hay nada de malo en eso. Si todavía necesitamos jQuery depende de un debate razonable, pero en términos de diseño,

Si Java es todo lo que sabe, incursione en algo con una sintaxis no basada en C

Cuando comencé a jugar con Python porque me gustó lo que estaba escuchando sobre Django, aprendí a separar la sintaxis del diseño del lenguaje. Como resultado, se hizo más fácil entender Java y C como una suma de sus partes de diseño de lenguaje en lugar de una suma de cosas que hacen de manera diferente con la misma sintaxis. Un buen efecto secundario es que cuanto más comprenda otros idiomas en términos de diseño, mejor comprenderá las fortalezas / debilidades del que mejor conoce a través del contraste.

Conclusión

Ahora, considerando todo eso, veamos todos los puntos problemáticos:

• No hay forma inmediata de encontrar el punto de entrada de una función (que no sea una búsqueda de texto sin formato, que luego puede resultar en búsquedas posteriores de métodos más arriba en la jerarquía de llamadas, después de dos o tres de los cuales ha olvidado dónde comenzó)

Chrome y Firebug realmente tienen seguimiento de llamadas. Pero vea también mis puntos sobre la estructura y mantener las cosas concisas y directas. Cuanto más pueda pensar en su aplicación como construcciones bien encapsuladas más grandes que interactúan entre sí, más fácil será averiguar de quién es la culpa cuando las cosas salen mal. Yo diría que esto también es cierto para Java. Tenemos constructores de funciones de clase que son perfectamente útiles para las preocupaciones tradicionales de OOP.

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

En mi código, casi nunca uso los literales de objetos {}como componentes estructurales de la aplicación, ya que no pueden tener variables internas (privadas) y prefiero reservarlas para usarlas como estructuras de datos. Eso ayuda a establecer una expectativa que mantiene la claridad de la intención. (si ve curvas, son datos, no un componente de la arquitectura de la aplicación).

• Los parámetros se pasan a las funciones, sin forma de saber qué propiedades y funciones están disponibles en ese parámetro (aparte de ejecutar realmente el programa, navegar hasta el punto en el que se llama la función y usar console.logs para generar todas las propiedades disponible)

Nuevamente, vea las herramientas modernas del navegador. Pero también, ¿por qué es tan fastidioso volver a ejecutar el programa? La recarga es algo que un desarrollador web del lado del cliente generalmente golpea cada pocos minutos porque no le cuesta absolutamente nada hacerlo. Esto es otra vez, otro punto con el que la estructura de la aplicación puede ser útil, pero es una desventaja de JS que debes ejecutar tu propia validación cuando hacer cumplir los contratos es crítico (algo que solo hago en los puntos finales expuestos a otras cosas que mi base de código no hace) 't control). En mi opinión, la compensación vale la pena los beneficios.

• El uso común de funciones anónimas como devoluciones de llamada, que con frecuencia conduce a un espagueti de rutas de código confusas, que no puede navegar rápidamente.

Sí, eso es malo en cualquier cosa no trivial. No hagas eso. Nombra tus funciones niños. También es más fácil rastrear cosas. Puede definir, evaluar (necesario para asignar) y asignar una función trivial simple en línea con:

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

Ahora Chrome tendrá un nombre para ti cuando estés rastreando llamadas. Para funciones no triviales, lo definiría fuera de la llamada. También tenga en cuenta que las funciones anónimas asignadas a una variable siguen siendo anónimas.

• Y claro, JSLint detecta algunos errores antes del tiempo de ejecución, pero incluso eso no es tan útil como tener líneas onduladas rojas debajo de su código directamente en el navegador.

Nunca toco las cosas. Crockford le ha dado algunas cosas buenas a la comunidad, pero JSLint cruza la línea en preferencias estilísticas y sugiere que ciertos elementos de JavaScript son partes malas sin una razón particularmente buena, en mi opinión. Definitivamente ignore esa cosa sobre las clases regEx y negación seguidas de * o +. Los comodines funcionan peor y puedes limitar fácilmente la repetición con {}. Además, ignore todo lo que diga sobre los constructores de funciones. Puede envolverlos fácilmente en una función de fábrica si la nueva palabra clave le molesta. CSSLint (no el de Crockford) es aún peor en el frente de los malos consejos. Siempre lleve a las personas que hablan mucho con un grano de sal. A veces juro que solo buscan establecer autoridad o generar material nuevo.

Y nuevamente, debe desaprender lo que ha aprendido con esta preocupación de tiempo de ejecución que tiene. (es común que he visto con muchos desarrolladores de Java / C #) Si ver errores en el tiempo de ejecución aún te molesta 2 años después, quiero que te sientes y recargues el spam en un navegador hasta que se hunda. no es una división de tiempo de compilación / tiempo de ejecución (bueno, no es visible de todos modos, JS se ejecuta en un JIT ahora). No solo está bien descubrir errores en tiempo de ejecución, es muy beneficioso recargar y descubrir spam de manera tan barata y fácil en cada punto de parada.

Y aprovecha esas herramientas de desarrollo de Chrome. Están integrados directamente en webkit. Haga clic derecho en Chrome. Inspeccionar elemento. Explora las pestañas. Una gran capacidad de depuración con la capacidad de alterar el código en la consola durante el tiempo de ejecución es una de las opciones más potentes pero menos obvias. Genial para probar también.

En una nota relacionada, los errores son tus amigos. Nunca escriba una declaración catch vacía. En JS no ocultamos ni enterramos errores (o al menos no debemos toser YUI / tos ). Los atendemos. Cualquier cosa menos resultará en dolor de depuración. Y si escribe una declaración catch para ocultar posibles errores en la producción, al menos silenciosamente registre el error y documente cómo acceder al registro.

Lo que estás diciendo es solo la queja común de una persona con mentalidad de Java que mira JavaScript.

Primero respondamos tu pregunta ...

... mi pregunta es, ¿cómo lidian otros programadores con estos problemas ...

Respuesta: NO lo hacen. Aprenden la filosofía de JavaScript renunciando primero al culto de Java.

Tienes que entender esta premisa ... JavaScript NO es Java. Simplemente no se trata de sintaxis, se trata más de la filosofía.

Ahora tomemos algunos de ellos ...

• Ver instantáneamente todos los lugares donde se invoca un método o se usa una constante (Abrir jerarquía de llamadas / Mostrar referencias)

  Control-clic en el nombre de una función / miembro / clase para ir directamente a su definición

  Todos estos están disponibles, solo elija un IDE decente.

• La escritura estática significa que puede usar la finalización de código para mostrar todos los parámetros / funciones disponibles en un objeto

  Este no es un problema que enfrentas . Esto es algo que requiere cambiar su perspectiva en la programación. El sistema de tipo suelto es uno de los puntos fuertes de JavaScript. Comprenda la escritura suelta y aprenda a apreciarla. Además, la finalización del código funciona muy bien con JS.

• Y claro, JSLint detecta algunos errores antes del tiempo de ejecución, pero incluso eso no es tan útil como tener líneas onduladas rojas debajo de su código directamente en el navegador.

  Firebug, la consola Chrome / Safari e incluso los IDE hacen todo eso y MÁS.

  Hay JSHint que puede hacer el ingenioso análisis estático al que están acostumbrados los programadores de Java.

• El resultado es que prácticamente necesitas tener todo el programa en tu cabeza en todo momento. Esto aumenta enormemente la carga cognitiva para escribir programas complejos.

  ¡Incorrecto! Por el contrario, JavaScript es un lenguaje de programación "ligero", y lo alienta a tener programas más simples. Como dice Doug Crockford ... te castigará si intentas escribir programas basados ​​en modelos en JavaScript.

• Si bien los programas pueden ser un poco más fáciles y rápidos de escribir, en mi experiencia son mucho más difíciles de leer y depurar.

  ¡Completamente equivocado! ¿Cómo se decide la legibilidad en función del lenguaje de programación? Los programas son legibles (o no), NO idiomas. Además, JavaScript tiene depuradores fantásticos.

Disculpe si sonaba un poco grosero, pero la verdad es que tiene que cambiar su disposición de Java para comprender JavaScript.

Solo los programadores Java "maduros" pueden apreciar JavaScript, y usted no puede dominar lo que no aprecia. Nuevamente, lo siento por ser francamente directo.

En general, es difícil tener las herramientas que mencionó para un lenguaje dinámico (a menos que el IDE sea parte del tiempo de ejecución, es decir, Smalltalk). Dicho esto, una vez que aprendes un editor de texto realmente bueno, la mayoría de los IDE se ven menos atractivos, esa es al menos mi experiencia.

Ese es el precio que pagamos por usar idiomas mal escritos. Uno solo puede preguntarse por qué esta abominación se ha vuelto tan popular. Las desventajas superan con creces las ventajas de los idiomas mal escritos.

Quizás deberíamos aplicar el principio de no cooperación a esta basura para que desaparezca.

No me gustaba javascript (y su escritura dinámica) pero he llegado a apreciar su orientación a objetos, cierres y programación funcional . Además, sus objetos globales y la eliminación de la conversión de tipo silencioso fueron un soplo de aire fresco cuando los encontré por primera vez.

Mi idea preferida para javascript es la tormenta web, ya que es fácil hacer que jQuery intellitext funcione (lástima que no sea gratis).

Además, no diría que está creciendo, ya es omnipresente.

Tus puntos específicos:

No hay forma inmediata de encontrar el punto de entrada de una función

No entiendo esto, ¿cómo podría ser más simple?

Los parámetros se pasan a las funciones, sin forma de saber qué propiedades y funciones están disponibles en ese parámetro

Si configura su ide para incluir la definición de objetos, las propiedades del objeto estarán disponibles a través de intellitext (pero es posible que haya perdido su punto aquí).

El uso común de funciones anónimas como devoluciones de llamada, que con frecuencia conduce a un espagueti de rutas de código confusas, que no puede navegar rápidamente.

Uso común ? Si no le gustan las funciones anónimas, no las use. ¿O te refieres a jQuery que los usa sustancialmente? jQuery es probablemente considerado por la mayoría de los desarrolladores web como el mayor ahorrador de tiempo en la historia del desarrollo web .

JSLint detecta algunos errores antes del tiempo de ejecución

Los atrapa a todos, puedes incluirlo en tu ide . O Webstorm lo incluye por defecto (creo).

¿Qué me estoy perdiendo?

Te estás perdiendo las dos enormes ventajas que tiene Javascript sobre Java:

• El código Javascript es aproximadamente un cuarto del tamaño del código Java equivalente.
• Nunca tendrá que esperar una compilación y reiniciar el servidor.

Yo trabajo de manera diferente en Javascript. Agrego un poco de código a la vez, tan poco como pueda probar, y actualizo el navegador y lo pruebo. Con jQuery, un par de líneas de Javascript son todo lo que necesito la mayor parte del tiempo.

He encontrado que la programación Java es relativamente improductiva , y ahora estoy escribiendo todo mi código del lado del servidor en Groovy, por las mismas dos razones.

Sé que esta pregunta es antigua, pero como programador de C ++ / C # que tenía los mismos sentimientos pero que ahora ha hecho mucho JavaScript durante los últimos 10 años, mi primera recomendación sería probar Visual Studio Code .

Por supuesto, no puede ofrecer todas las funciones que se pueden agregar con un lenguaje fuertemente tipado, pero se acerca bastante.

También puede tomar información de tipo de mecanografiado y aplicarla a JavaScript. Incluso si nunca usa el mecanografiado, puede obtener la finalización del código y la documentación en toneladas de API a medida que escribe JavaScript.

Entonces a tus preguntas

• No hay forma inmediata de encontrar el punto de entrada de una función (que no sea una búsqueda de texto sin formato, que luego puede resultar en búsquedas posteriores de métodos más arriba en la jerarquía de llamadas, después de dos o tres de los cuales ha olvidado dónde comenzó)

¿Parece mayormente resuelto en VSCode?

• Los parámetros se pasan a las funciones, sin forma de saber qué propiedades y funciones están disponibles en ese parámetro

Esto se resuelve para muchos IDEs documentando su código con comentarios de estilo JSDoc o mecanografiados. Los editores leerán los comentarios y le darán la misma terminación a la que está acostumbrado

El uso común de funciones anónimas como devoluciones de llamada, que con frecuencia conduce a un espagueti de rutas de código confusas, que no puede navegar rápidamente.

Como programador de C #, las funciones anónimas también son comunes allí y se han agregado a C ++. Creo que esto es algo a lo que solo tienes que acostumbrarte.

Además, aunque las devoluciones de llamada se han reemplazado principalmente con promesas y con asíncrono / espera y si tiene una API que usa una devolución de llamada, puede envolverla rápidamente para usar una promesa y luego usar asíncrono / esperar para que el problema desaparezca.

Y claro, JSLint detecta algunos errores antes del tiempo de ejecución, pero incluso eso no es tan útil como tener líneas onduladas rojas debajo de su código directamente en el navegador.

Obtendrás líneas onduladas en Visual Studio Code. No solo eso, sino que si activa la integración de ESLint obtendrá toneladas de advertencias y / o errores sorprendentes resaltados en su editor. Más de lo que he visto para otros idiomas en realidad. Mi experiencia es linters para C / C # / Java han sido bastante codificadas, ya que ESLint es tanto configurable como extensivamente masivo y, como tal, las bibliotecas populares pueden incluso integrarse para brindarle consejos y advertencias sobre el uso específico de la biblioteca en el editor. Algo que no he visto personalmente en otros idiomas (¿aunque tal vez sea común ahora también para otros idiomas?)

También es 2018 y ES7 es la nueva norma, por lo que obtienes class. Siempre usas el modo estricto. Nunca usas vary siempre usas consty letun montón de cosas que los programadores de C ++ / C # / Java tuvieron dificultades para acostumbrarse a desaparecer. Active la no-undefregla en ESLint y desaparecerán aún más problemas

Dicho esto, aprenda cómo thisfunciona realmente y cómo funcionan realmente las funciones y los métodos porque no es lo mismo que C ++ / C # / Java.

Mis primeros 2-3 años de JavaScript me hicieron sentir frustrado. Sin embargo, en algún momento hizo clic. Dejé de intentar forzarlo a ser C ++ / C # / Java y ahora me siento frustrado al volver cuando las cosas que tomarían 15 líneas en JavaScript tomarían 150 en esos otros idiomas.

Si te gustan los IDE y estás acostumbrado a eclipsar, mira Aptana como IDE para JavaScript. Creo que puede hacer mucho de lo que quieres. (Personalmente odio los IDEs pero esa es una conversación diferente).

En cuanto a las funciones anónimas, considero que son la característica más poderosa en JavaScript y tratar de trabajar en un lenguaje que no las tiene es bastante doloroso.

Si desea algo más que pueda compilarse en JavaScript, hay un montón de opciones, CofffeeScript, Clojure y GWT, todas me vienen a la mente, pero hay otras.

Todavía no lo he usado, pero he visto algunas demostraciones y estoy muy impresionado con Cloud 9 como IDE de JavaScript.

Puede elegir el modelo de servicio en línea o descargarlo de GitHub.

Y como evidencia de su calidad como IDE, Cloud9 fue escrito usando ... ¡Cloud9!