¿Es CoffeeScript una base sólida sobre la cual codificar las porciones JS de una aplicación web RIA?

Proyectos como CoffeeScript, Objective J y GWT son una nueva tendencia interesante.

Google, los maestros de JavaScript, tienen su propio Google Web Toolkit (GWT) donde codifican en Java y se compila en JavaScript. Generan archivos JS separados para cada navegador para reducir el tamaño de descarga y el código puede optimizarse en gran medida.

Durante la presentación de Google Wave, hablaron sobre lo increíble que era GWT, cómo les permitió pensar de manera diferente sobre lo que es posible en los navegadores. Google Wave es una aplicación terrible, con errores de tiempo de espera de secuencia de comandos constante y bajo rendimiento general. Eso no es bueno, pero la versión más reciente de Google Documents podría estar codificada con GWT, así como otras aplicaciones que se lanzan y se usan ampliamente.

La demostración de Google Quake 2 fue portada desde Java con la ayuda de GWT.

Estos lenguajes además de JavaScript vienen con nuevos problemas, pero CoffeeScript debería tener el menor de ellos. Si una empresa como Google toma estos riesgos, otros desarrolladores también deberían hacerlo.

Si hay algo serio a lo que temer, es una falta de comunidad en torno a CoffeeScript, no hay suficientes proyectos que lo usen, pocas bibliotecas lo atienden. Entonces, si no lo usamos, lo perderemos.

He jugado con un proyecto personal en Node.js + CoffeeScript y ha sido divertido trabajar con él. Viniendo de un fondo Ruby, Javascript siempre me ha molestado, al menos hasta que leí Javascript: The Good Parts .

Una cosa importante del uso de CoffeeScript sobre el uso de Javascript sin formato es que CoffeeScript dificulta la escritura de JavaScript incorrecto (aunque aún puede escribir CoffeeScript incorrecto).

Mi razón para elegir CoffeeScript sobre el otro lote actual de lenguajes que compila JS ( https://github.com/jashkenas/cof …) tiene que ver con Parsec CoffeeScript. Parsec aún no ha terminado, pero admitirá macros dentro de la distancia de lanzamiento de Lisp. Podré usar el tipo de metaprogramación estática a la que me acostumbré con Ruby, y algo más. Teniendo en cuenta la importancia que tendrá Javascript en los próximos años (la respuesta de Ho-Sheng Hsiao a ¿Cuáles son los marcos de aplicaciones web más amigables para el futuro para seleccionar? En 2020, mirando hacia atrás, cuáles habrán sido las opciones correctas para lenguajes de programación, bases de datos, y la estrategia de alojamiento? ¿Qué habrá durado y qué fue solo una exageración?), espero hacer mucho CoffeeScript en el futuro.

Lo bueno de CoffeeScript es que genera JavaScript legible. Si más tarde decidió dejar de escribir en CoffeeScript, podría tomar el código que generó y comenzar a trabajar con eso directamente.

Solía ​​trabajar con el Sr. Ashkenas y sospecho que hay un futuro brillante para CoffeeScript.