¿Cuáles son los pros y los contras de usar Coffeescript para las aplicaciones del lado del servidor Node.js?

Para nosotros, realmente no ha habido mucha estafa. Nos encanta CoffeeScript y la mayoría de los problemas con él (depuración, en su mayoría) se han resuelto. Nunca he tenido un problema de compatibilidad con una biblioteca basada en JavaScript.

En cuanto a “limitar la carrera de nuestro código”, se compila en JavaScript. Si CoffeeScript desalienta a las personas a usarlo, esa es una calle de doble sentido: hay una comunidad creciente de desarrolladores de CoffeeScript para quienes eso es una ventaja.

Sinceramente, no tengo idea de por qué tiene tanto odio: rara vez se escucha a personas de CoffeeScript que se burlan de los desarrolladores de JavaScript. Tal vez porque solíamos ser desarrolladores de JavaScript nosotros mismos. De todos modos, diferiré a la respuesta de Jashua sobre eso. 🙂

En cuanto a los profesionales, creo que hay muchos. CoffeeScript es mucho más fácil de leer y escribir y, por lo tanto, de mantener. (Esto no tiene nada que ver con la definición de una macro de teclado para “función”, por cierto. Es la legibilidad general y, por lo tanto, la mantenibilidad del código).

También es más fácil para los desarrolladores que no son gurús de JavaScript porque elimina algunos de los casos de esquina extraños (como == versus ===).

Es fácil de aprender para muchos desarrolladores, ya que muchos de los modismos son de Ruby y Python.

Es una de las comunidades de desarrolladores de más rápido crecimiento. Al igual que JavaScript, puede usar el mismo código en el navegador y en el servidor.

Podría seguir y seguir, en características específicas del lenguaje, como listas de comprensión, que eliminan casi sin ayuda la necesidad de una biblioteca como guión bajo. Pero me detendré aquí. 🙂

Algunas ideas sobre cómo construir el sitio móvil de NYTimes en un nodo usando CoffeeScript: CoffeeScript crea un código mucho más fácil de mantener: es fácil de leer, revisar, volver a visitar y escribir, y es mucho más sucinto; Puede que no parezca importante, pero con algunos desarrolladores en su equipo, es la clave. En el lado negativo, la depuración, tanto cuando el código no se compila por una razón inexplicable, como cuando las cosas se compilan pero no funcionan según lo previsto, es más difícil, donde es obvio en JavaScript simple.

También estoy de acuerdo en que CoffeeScript hace que el uso de prototipos (= clases) sea mucho más fácil y accesible.

Me gustaría resaltar una posible desventaja a largo plazo de usar ese subconjunto de un lenguaje que necesita compilarse con el “idioma principal” para ejecutarse. Debe saber que el compilador seguirá desarrollándose y manteniéndose para que su código no sea “en desuso” y necesitará codificar toda la aplicación una vez más en JS simple.

Con el gran soporte para ES6 (ES2015) en el Nodo v4 +, tendrá muchas menos razones para usar un subconjunto como CoffeeScript.

ECMAScript 2015 (ES6) | Node.js