Tenemos una base de código JavaScript algo grande y hace aproximadamente un mes decidimos probar CoffeeScript. Uno de nuestros desarrolladores comenzó migrando uno de nuestros módulos de JS a CS usando http://js2coffee.org/ . Esta herramienta fue bastante útil y tardó unas dos o tres horas en portar unas 1000 líneas de JavaScript. Algunas observaciones que hemos notado en ese punto:
El código resultante de CoffeeScript era bastante legible.
Lo compilamos de nuevo a JavaScript y fue bastante fácil de navegar y depurar. Mientras estábamos portando ese módulo, otro desarrollador de nuestro equipo encontró un error en él. Estos dos desarrolladores corrigieron ese error en nuestro antiguo código JavaScript y en el nuevo código JavaScript que salió del compilador CS. Trabajaron de forma independiente y les llevó aproximadamente la misma cantidad de tiempo (15-20 minutos).
Debido al hecho de que era un puerto, el código resultante no usaba funciones específicas de Coffee que fueran apropiadas o deseables. Si escribiéramos en CoffeeScript desde cero, el código sería más idiomático. Debido a eso más tarde, decidimos que no portaremos el código existente.
En general, la legibilidad de la función más corta y el objeto más pequeño aumentó en cierta medida. Sin embargo, para métodos más largos ese no era el caso en absoluto. Los mayores ahorros de hinchazón provienen ->y son explícitos return, pero aparte de eso, nuestro código no se había vuelto significativamente más corto o más simple. Algunas piezas de sintaxis parecían bastante confusas, especialmente los literales de objetos. CS omite llaves entre las definiciones de los miembros y combina con "todo es una expresión" e implícito returnque hizo que algunos bits de código fueran bastante difíciles de leer.
Aquí está JavaScript:
var rabbitGenerator = {
makeRabbit: function(rabbitName, growCarrots) {
if (growCarrots) {
carrots.growMore(10);
} else {
carrots.ensureSupply();
}
return {
name: rabbitName,
height: 0,
actions: {
jump: function (height) {
this.height += height;
},
eatCarrot: function () {
// etc
}
}
};
},
// more members
}
Y así es como se vería el código correspondiente de CoffeeScript:
rabbitGenerator =
makeRabbit: (rabbitName, growCarrots) ->
if growCarrots
carrots.growMore 10
else
carrots.ensureSupply()
name: rabbitName // (*)
height: 0
actions:
jump: (height) ->
@height += height
eatCarrot: ->
Como es ahora, es bastante difícil darse cuenta de que la declaración de retorno comienza en la (*)línea. En nuestro proyecto, dependemos en gran medida de los literales de objetos: los pasamos como parámetros de función y los devolvemos de otras funciones. En muchos casos, estos objetos tienden a ser bastante complejos: con miembros de diferentes tipos y varios niveles de anidamiento. En nuestro caso, la sensación general era que el código CoffeeScript era realmente más difícil de leer que el código JavaScript simple.
Aunque la depuración de CoffeeScript resultó ser más fácil de lo que esperábamos, la experiencia de edición se ha degradado bastante. No pudimos encontrar un buen editor / IDE para este idioma. No hemos estandarizado el editor / IDE para el código del lado del cliente para nuestro proyecto y, de hecho, todos utilizamos diferentes herramientas. De hecho, todos en un equipo están de acuerdo en que cuando cambian a CoffeeScript obtienen un soporte bastante pobre de su herramienta. Los complementos IDE y editor están en una forma muy temprana y, en algunos casos, ni siquiera nos pueden dar un resaltado de sintaxis adecuado o soporte de sangría. No hablamos de fragmentos de código o refactorización. Usamos WebStorm, Eclipse, NetBeans, VisualStudio, Notepad ++ y SublimeText2.
Hablando de herramientas, debo mencionar que el compilador CoffeScript viene como un paquete Node JS. Somos una tienda primaria de Java / .NET, por lo que todos están desarrollando en cajas de Windows. Hasta hace poco, el soporte de Windows era casi inexistente en Node. No pudimos hacer que el compilador CoffeeScript se ejecutara en Windows, así que por el momento decidimos seguir con las <script type="text/coffeescript">etiquetas y el compilador sobre la marcha basado en el navegador.
El compilador es bastante rápido y no aumenta mucho el tiempo de inicio. La desventaja es que el JavaScript resultante se evaledita y es un poco difícil colocar puntos de interrupción en las herramientas de desarrollo de los navegadores (especialmente en IE8). Si tenemos dificultades con la depuración, precompilamos el código CoffeeScript con la misma herramienta de migración que mencioné anteriormente, pero aún así no es muy conveniente.
Otras promesas de CoffeeScript, como la varinserción automática o la gestión semitransparente de thiscon el operador de flecha gruesa ( =>) resultaron no proporcionar tanta ganancia como esperábamos. Ya usamos JSLint como parte de nuestro proceso de compilación y escribimos código en un ES3 x ES5-Strictsubconjunto del lenguaje. De todos modos, el hecho de que Coffee produzca el mismo tipo de código "limpio" es algo bueno . ¡Ojalá todos los marcos del lado del servidor produjeran marcas válidas de HTML5 y CSS3 también!
Dicho esto, no diría que CoffeeScript ahorra mucho tiempo al poner varpalabras clave para mí. Desaparecidos vars son fácilmente capturados por JSLint y son fácilmente corregibles. Además, una vez que te corrigen por un tiempo, de todas formas comienzas a escribir JavaScript correctamente . Por lo tanto, no diría que el café es realmente tan útil en este sentido.
Evaluamos CoffeeScript durante aproximadamente una semana. Todos los miembros del equipo escribían código en él y compartimos nuestras experiencias entre nosotros. Escribimos un código nuevo con él y portamos un código existente cuando lo creíamos conveniente. Nuestros sentimientos sobre el idioma fueron mixtos.
En general, diría que no aceleró nuestro desarrollo, pero tampoco nos ha frenado. Algunas ganancias de velocidad debido a menos tipeo y menos superficie de error fueron compensadas por ralentizaciones en otras áreas, principalmente soporte de herramientas. Después de una semana , decidimos que no exigiremos el uso de CoffeeScript, pero tampoco lo prohibiremos . Dada una libre elección, en la práctica nadie la usa, al menos por ahora. De vez en cuando pienso en crear prototipos de alguna característica nueva y luego convertir el código a JavaScript antes de integrarlo con el resto del proyecto para comenzar más rápido, pero aún no he probado ese enfoque.