¿Deberías aprender CoffeeScript?

Me imagino que represento a una gran parte de la comunidad de desarrollo web. Estoy muy intrigado por CoffeeScript; incluso aprendí la sintaxis y la usé en algunas demostraciones. Sin embargo, todavía no he dado el paso y lo he utilizado en un proyecto real. Todo se reduce a esta única pregunta para mí: ¿CoffeeScript es algo en lo que realmente vale la pena invertir tiempo y esfuerzo en aprender?

No estaba seguro, así que recopilé una lista de preguntas frecuentes (junto con algunas de las mías) y le pedí consejo a algunos maestros de la industria, a ambos lados de la valla.

El panel

Jeremy Ashkenas - El creador de CoffeeScript.

• @jashkenas
• Inicio de CoffeeScript
• Nube de documentos

Brendan Eich

• El creador de JavaScript y cofundador de Mozilla.
• @brendaneich
• Mozilla

John-David Dalton

• "Soy un manipulador de JavaScript obstinado, solucionador de errores y corredor de referencia. Tengo una licenciatura en Diseño Instruccional Multimedia, una esposa increíble y un cachorro".
• @jdalton
• FuseJS
• Benchmark.js
• uxebu Bio

Dave Ward

• "Soy un desarrollador de software que se enfoca en ASP.NET, jQuery y usabilidad de aplicaciones web".
• @encosia

Marco Chomut

• "Soy un científico informático extraordinario que vive en el área de Washington, DC. Me especializo en desarrollo web y móvil, y me encanta trabajar con Django y Android".
• @pewpewarrows

Trevor Burnham

• "Desarrollador web y autor".
• @trevorburnham
• El libro CoffeeScript

James Padolsey

• "Soy, de profesión, un desarrollador de JS con amplia experiencia en el desarrollo de aplicaciones de interfaz adoptando técnicas nuevas y geniales JS/HTML5/CSS3 mientras empleo una variedad de marcos".
• @padolsey
• Libro de cocina de jQuery
• uxebu Bio

Nathan Smith

• "Trabajo como desarrollador de experiencias de usuario en Pure Charity".
• @nathansmith
• 960.gs

Ryan Florence

• "Soy un desarrollador web de interfaz de Salt Lake City, Utah, y he estado creando sitios web desde principios de los 90".
• @ryanflorence
• Estructura
• Varios proyectos

Oscar Godson

• Soy Ingeniero de Software en Yammer.
• @oscargodson
• API de BatchGeo

Alex MacCaw

• Trabajo en Twitter. Desarrollador Ruby/JavaScript, autor y emprendedor de O'Reilly.
• @maccman
• Pequeño libro sobre CoffeeScript
• Aplicaciones web JavaScript (libro)
• Columna vertebral

1 - Quizás la pregunta más común: si soy un desarrollador de JavaScript razonablemente sólido, ¿existe algún incentivo real para que aprenda CoffeeScript?

Jeremy Ashkenas

Si. CoffeeScript no es un lenguaje completamente nuevo y extraño. Existe para permitir que los desarrolladores de JavaScript "razonablemente sólidos" escriban el mismo código que iban a escribir en primer lugar, de una manera más legible y fluida. La idea básica es escribir lo que quieres decir, en lugar de escribir dentro de los límites del accidente histórico. Por ejemplo, si quiero recorrer cada elemento de una lista, en CoffeeScript, puedo escribir lo que quiero decir:

1

    for item in list

2

      process item

Mientras que en JavaScript, oculto parcialmente mi intención, escribiendo:

1

    for (var i = 0, l = list.length; i < l; i++) {

2

      var item = list[i];

3

      process(item);

4

    }

CoffeeScript permite que los desarrolladores de JavaScript "razonablemente sólidos" logren lo último simplemente escribiendo lo primero.

• La capacidad de escribir código que funcione en versiones antiguas de Internet Explorer sin tener que comprometer o ajustar
• No tener que preocuparse por los errores de JavaScript, como las comas finales y la inserción automática de punto y coma
• Semántica limpia donde cada construcción del lenguaje se puede usar como parte de una expresión más grande
• y una gran cantidad de funciones adicionales enumeradas en CoffeeScript.org

James Padolsey

Si te sientes cómodo con JavaScript y puedes crear API expresivas que se adapten bien a tus necesidades, no creo que exista un incentivo suficiente para aprender CoffeeScript. Ampliar horizontes y aprender nuevos paradigmas y patrones de programación siempre es bueno, pero si estás aprendiendo CoffeeScript para que eventualmente puedas reemplazar tu necesidad de JavaScript, entonces hay otras cosas a considerar.

John-David Dalton

Si eres bueno con JS, no creo que haya ningún incentivo real para aprender CoffeeScript. Cosas como globales filtradas accidentalmente, fallos de declaraciones de cambio y otros errores potenciales de JS pueden ser manejados por linters/editores de texto JS y no requieren un paso de compilación/Node.js. Azúcar de clase es tan básico que cualquier desarrollador de JS puede, si es necesario, simularlo en un puñado de líneas. Sucede que me gusta el doble es igual a ==, y los fallos de las declaraciones de cambio, y sé cuál es la mejor manera de escribir mi JS.

Tener que cumplir con las reglas de otra persona sobre lo que sienten que es apropiado no encaja bien conmigo.

Además, no olvides que CoffeeScript no está exento de sus propias verrugas.

• Caso contra CoffeeScript
• Que "Demonios" CoffeeScript
• Problemas de CoffeeScript

Dave Ward

Exponerse continuamente a nuevas perspectivas y tecnologías es una parte fundamental para mantenerse relevante en nuestro campo.

Absolutamente. Exponerse continuamente a nuevas perspectivas y tecnologías es una parte fundamental para mantenerse relevante en nuestro campo, y CoffeeScript es sin duda un gran candidato para eso en el espacio de JavaScript. Incluso si finalmente decides que CoffeeScript no te atrae, poder escribir un poco de CoffeeScript debería ser un requisito previo para tomar una decisión informada de cualquier manera.

Nathan Smith

He estado usando CoffeeScript durante algunos meses, como parte de mi trabajo como desarrollador de interfaz en un equipo de Rieles. No sé si diría que hay un "incentivo" para aprender CoffeeScript si ya conoces JavaScript. No estoy seguro de que se obtenga un aumento de velocidad increíble, porque en realidad no existe la "mejor" herramienta para un trabajo, solo una con la que estás más familiarizado para realizar una tarea determinada.

Aunque disfruto de la sensación de comodidad de JavaScript (como un par de zapatos bien metidos), también hay muchas cosas que me gustan en CoffeeScript: la sintaxis "a menos que", por ejemplo. Yo compararía el uso de CoffeeScript con tener una conversación con un amigo que se especializó en inglés, corrigiendo su gramática todo el tiempo. Es genial si quieres esa guía, pero a veces solo quiero "mantenerlo informal" y hablar jerga, sin preocuparme por lo que eso traducirá.

Nota: suspendí el juicio hasta después de leer el libro de Trevor Burnham sobre CoffeeScript. Ahora que sé más al respecto, estoy bien usando CS cuando estoy en un equipo que ya lo usa, pero sigo prefiriendo JS para mis propios proyectos.

Ryan Florence

Absolutamente. CoffeeScript está influyendo en las decisiones de TC-39 (como libre de parentesis, sintaxis de clases, sintaxis de flechas, etc.). Es probable que las futuras versiones de JavaScript se parezcan mucho a CoffeeScript. Decidí aprenderlo después de escuchar a Brendan mencionar su influencia durante su charla en TXJS.

Si hay algo que aprender sobre CoffeeScript es que es _Sólo JavaScript™_. Lo considero parte de nuestra comunidad y realmente disfruté aprendiéndolo y usándolo. No se siente como un idioma diferente cuando lo usas.

Brendan Eich

(Limitando mi respuesta a responder a los comentarios de Ryan Florence sobre TC39, excepto en mi párrafo final).

La influencia de CoffeeScript en TC39 en la práctica se debe principalmente a que escribo y propongo hombres de paja. Ninguno se ha quedado todavía. Voy a cambiar las herramientas sin par para ser más como CoffeeScript en el sentido de que las nuevas líneas serán más significativas en los encabezados de las declaraciones (esto resuelve algunos casos difíciles y desagradables que identificó Waldemar Horwat, ver es-discutir). Pero sin estructura de bloques basada en sangrías.

La sintaxis de la función de flecha valió la pena, pero no lo lograrás. Las lambdas de bloque están en mejor forma pero aún no están "in". Como dijo Jeremy, “Para que conste, yo también prefiero [lambdas de bloque] si las flechas en JS necesitarán rizos para delimitar los bloques. Rizos o flechas, no ambos".

Que JS y CoffeeScript sean formalmente coexpresivos, tengan la misma semántica, es enorme. Sí, esto significa que podría haber escrito JS. Pero la productividad y la belleza (a los ojos de algunos espectadores) son importantes; la sintaxis importa.

Oscar Godson

En resumen, no. Los incentivos para CoffeeScript son incentivos, en mi opinión, que son para desarrolladores que no entienden completamente el lenguaje. Por ejemplo, para... en bucles y globales con fugas y sin entender "esto" completamente. Si comprendes esas cosas, no cometes esos errores en primer lugar, y si lo haces, sabrás cuál es el problema de inmediato y cómo solucionarlo. Tener un lenguaje transpilado completo para corregir errores comunes parece una exageración.

Marco Chomut

Por curiosidad profesional, siempre debes explorar nuevos lenguajes, tecnologías, bibliotecas y marcos.

Hay algunos enfoques diferentes para responder a esta pregunta. En primer lugar, por curiosidad profesional, siempre debes explorar nuevos lenguajes, tecnologías, bibliotecas y marcos. Lo peor que te puede pasar como desarrollador es quedarte estancado en una rutina. Si el primer idioma que aprendiste fue COBOL, ColdFusion o PHP, y ese sigue siendo el alcance de tu conocimiento cinco años después, solo estás pidiendo volverte obsoleto. Por otra parte, es igualmente peor saltar al nuevo sabor del mes cada vez que aparece algo ligeramente interesante en tu lector de noticias o en tu cuenta de Twitter. Ten una curiosidad sana mientras mantienes un escepticismo razonable.

Volviendo al tema, si tu y tus compañeros de trabajo ya están bien versados ​​en restringirse a las "partes buenas" de JavaScript, y son dolorosamente conscientes de sus idiosincrasias, CoffeeScript probablemente no les ofrecerá mucho. Es un enfoque más similar al de Ruby o Python a la sintaxis del lenguaje que hace todo lo posible para evitar que tu o tu equipo se disparen en el pie. Pero no es para todos.

Trevor Burnham

Obviamente, tengo un interés financiero en esta pregunta (mi libro fue publicado por PragProg en mayo), por lo que puede tomar mis palabras con un grano de sal. Pero sí, creo que vale la pena dedicar tiempo a aprender CoffeeScript. No se necesita mucho esfuerzo para aprender; CoffeeScript es básicamente la suma de unas pocas docenas de azúcares sintácticos sobre JavaScript. Y la recompensa es que puedes escribir un código más hermoso, cuando lo desees. Por ejemplo, algunos JavaScripters usan CoffeeScript solo para sus pruebas unitarias.

Algunas personas se quejan de tener que usar un compilador además de JavaScript, pero algunas de las fallas de JavaScript, como la creación global automática cuando se omite la palabra clave var (ver aquí), requieren más o menos el uso de otras herramientas o del modo estricto. CoffeeScript es una de esas herramientas y se encuentra fácilmente entre las más populares.

Alex MacCaw

Mis programas CoffeeScript terminan siendo aproximadamente la mitad de la longitud de la fuente equivalente escrita en JavaScript.

Absolutamente; de hecho, diría que hay un incentivo aún mayor para aprender CoffeeScript si eres un desarrollador de JavaScript sólido. CoffeeScript ciertamente requiere algo de dominio de JavaScript, no hay forma de evitarlo. El conocimiento de JavaScript es un requisito previo, especialmente cuando se trata de depurar.

Sin embargo, para los buenos desarrolladores de JavaScript, CoffeeScript ofrece muchas ventajas, como corregir errores comunes relacionados con las variables globales, el punto y coma y las comparaciones de igualdad. Francamente, incluso los mejores desarrolladores de JavaScript cometen este tipo de errores simples de vez en cuando.

La otra gran ventaja que CoffeeScript me ofrece sobre JavaScript es el azúcar sintáctico, como declaraciones de funciones más cortas, comprensiones y una simple abstracción de clases. Mis programas CoffeeScript terminan siendo aproximadamente la mitad de la longitud de la fuente equivalente escrita en JavaScript, con el doble de claridad.

2 - ¿CoffeeScript está dirigido a desarrolladores de JavaScript? ¿O es para desarrolladores que prefieren otros idiomas, como Ruby, y aún no han aprendido los entresijos de JS?

Jeremy Ashkenas

La idea central de CoffeeScript es expresar la semántica de JavaScript en una sintaxis tan legible y mínima como podamos encontrar.

CoffeeScript está dirigido a desarrolladores de JavaScript. Sin duda, toma prestadas ideas de otros lenguajes dinámicos, incluidos Python, Ruby y Perl. Pero en última instancia, la idea central de CoffeeScript es expresar la semántica de JavaScript en una sintaxis tan legible y mínima como podamos encontrar.

John-David Dalton

Me parece que los desarrolladores que prefieren lenguajes como Ruby gravitan más hacia CoffeeScript que los que no lo hacen. Aunque, es común encontrar desarrolladores que tengan opiniones de amor / odio al respecto en cualquier grupo.

Nathan Smith

Creo que CoffeeScript está dirigido a personas que entienden JavaScript, pero para quienes no es su lenguaje preferido. De lo contrario, (obviamente) preferirían simplemente escribir JS. Si uno conoce los entresijos de JS al comenzar con CS, es esencial si se quiere aprovechar al máximo el uso de CS.

Oscar Godson

Trabajo en Yammer con muchos ingenieros superiores de JavaScript; ninguno lo usa. Me di cuenta de que los amigos que lo usan y están extremadamente felices son personas de Rieles. Por ejemplo, en Posterous, lo usan pero no tienen ingenieros de JavaScript reales. Tenemos gente de Rails aquí, pero solo hacen Rails, no JavaScript.

Ryan Florence

Tendría que remitirme a Jeremy por eso, pero creo que atrae principalmente a los Rubyists que descubren que pasan la mayor parte del día en JavaScript. El conocimiento de CoffeeScript no sustituye al conocimiento de JavaScript. El alcance es algo diferente; aparte de eso, es solo una sintaxis más limpia.

Marco Chomut

Definitivamente diría que se dirige tanto a los desarrolladores de JavaScript existentes como a los que provienen de otros lenguajes dinámicos que son algo nuevos en el mundo web de interfaz. Personalmente lo descubrí después de tener una cantidad decente de experiencia JS "cruda", y fue refrescante trabajar con lo que imagino que sería un lenguaje moderno del lado del cliente. Si bien es solo mi enfoque personal para aprender cosas, no creo que me hubiera sumergido directamente en CoffeeScript sin ningún conocimiento previo del lenguaje en el que se construyó.

Es importante tener siempre al menos una comprensión rudimentaria de cualquier "caja negra" de abstracción que exista en tu caja de herramientas.

Trevor Burnham

Si eres alguien a quien le gusta JavaScript pero quieres escribir un código más expresivo, CoffeeScript será la opción obvia.

El objetivo de CoffeeScript es permanecer lo más cerca posible del JavaScript subyacente mientras se mejora la sintaxis del lenguaje. Eso lo hace muy diferente de, digamos, Dart o GWT, o algo que reordena el código como TameJS. Así que creo que si eres alguien a quien le gusta JavaScript pero quieres escribir un código más expresivo, CoffeeScript será la opción obvia.

Obviamente, es desproporcionadamente popular en el mundo Ruby, ya que ha tomado prestados muchos Ruby-isms como postfix if/less y tiene un evangelista extremadamente prominente en dhh, pero también es bastante popular en el mundo Node.js, lo que dice mucho.

Alex MacCaw

He usado JavaScript durante años y escribí el libro de O'Reilly sobre aplicaciones web JavaScript. Creo que se podría decir que he aprendido los "entresijos" del idioma. Dicho esto, personalmente planeo no volver a escribir JavaScript simple, no porque no me guste el lenguaje, sino porque me encanta escribir en CoffeeScript.

CoffeeScript es para personas que entienden y respetan profundamente JavaScript.

3 - Cuando se anunció Dart, gran parte de la comunidad de JS lo recibió con calumnias inmediatas. Aunque no es un lenguaje completamente diferente, lo mismo es parcialmente cierto para CoffeeScript. ¿Algunos desarrolladores simplemente tienen miedo de aprender algo nuevo o están justificadas sus críticas?

Jeremy Ashkenas

Con el lanzamiento de Dart, la comunidad de desarrollo web se enfrentó al peligro de que Google forzara un nuevo lenguaje no estándar en un navegador web de envío.

Dart es una historia diferente. Con el lanzamiento de Dart, la comunidad de desarrollo web se enfrentó al peligro de que Google forzara un nuevo lenguaje no estándar en un navegador web de envío. Como bien sabemos en la web, una vez que envías algo en un navegador, tiende a estar ahí para siempre. Además, Dart se retira del dinamismo de JavaScript y, en cambio, existe como un lenguaje algo estático, donde los tipos se pueden verificar en tiempo de compilación, pero se borran en tiempo de ejecución. La comunidad de JavaScript percibió esto como un gesto cínico para hacer que los desarrolladores de Java se sientan más como en casa en Dart, pudiendo escribir tipos que parecen similares a los tipos de Java, aunque se tratan como comentarios cuando se ejecuta el programa. No solo los desarrolladores de JavaScript desconfían del impulso de Dart, los implementadores de navegadores también desconfían.

Ahora, tomemos el caso de CoffeeScript. CoffeeScript se ha sentido amenazador para un número sorprendente de desarrolladores de JavaScript, de una manera que otros lenguajes no. No escuchas a los programadores de JS preocuparse por otros lenguajes nuevos como Clojure o Scala, o incluso lenguajes de compilación en JS como GWT o Objective-J en cualquier cosa que se acerque al mismo volumen.

Ten en cuenta que no estoy hablando de personas que simplemente eligen continuar usando JavaScript; yo también sigo usando JavaScript para muchos proyectos. Me refiero a la temible retórica de "No usaré tu biblioteca porque la escribiste en CoffeeScript", o "CoffeeScript te hace olvidar cómo escribir en JavaScript".

CoffeeScript se siente amenazador para los desarrolladores de JavaScript precisamente porque está muy cerca de JavaScript.

Debido a que la semántica es la misma, cada programa CoffeeScript es completamente interoperable con JavaScript y viceversa. Es posible que ya estés utilizando una biblioteca escrita en CoffeeScript sin siquiera saberlo (como Zombie.js, Riak-JS o xml2js). Además, CoffeeScript se está utilizando, actualmente es el decimotercer lenguaje más popular en GitHub.

Como desarrollador de JavaScript, enfrentar esta situación, donde hay una alternativa totalmente compatible a JavaScript, con el mismo perfil de rendimiento, te obliga a responder la pregunta: "¿por qué no haz probado CoffeeScript todavía?" Muchas de las publicaciones que estamos viendo son desarrolladores que justifican su respuesta a esa pregunta por sí mismos. Si no hubiera probado CoffeeScript todavía, probablemente estaría escribiendo el mismo tipo de publicaciones.

James Padolsey

La verdadera batalla es crear API limpias, intuitivas y fáciles de mantener.

Dart es un poco diferente. Uno, ¡es de Google! es decir, ese monopolio masivo del que se supone que debemos tener cuidado. Más allá de los diversos problemas políticos, Dart no parece aportar nada más que una sintaxis más al estilo de Java, que a muchos desarrolladores no les gusta mucho, incluido yo mismo. Prefiero ceñirme a las API/lenguajes más expresivos que tengo a mi disposición. Sin embargo, cuando se trata de CoffeeScript, soy cauteloso porque en realidad es solo JavaScript, pero con una sintaxis completamente diferente. JavaScript es lo suficientemente maleable para que pueda crear las API y la funcionalidad que necesito. No me importa mucho el azúcar de conveniencia a menos que realmente mejore mi capacidad para escribir un buen código. Algunas de las características de CoffeeScript, como la asignación de desestructuración y el operador existencial, son realmente impresionantes, pero para ser honesto, son solo una dulzura menor, y se puede obtener una funcionalidad similar en JavaScript (¡consulta JS 1.7 para la asignación de desestructuración también!), Aunque con un poco más de verbosidad. La verdadera batalla es crear API limpias, intuitivas y fáciles de mantener. CoffeeScript no te ayudará mucho en eso. Como dije, es azúcar.

John-David Dalton

No creo que sea tener miedo a algo nuevo. Para mí, al menos, se trata más de no querer sobre-diseñar y tener más control sobre mi JS.

Dave Ward

Es difícil hablar por los demás, pero no tengo la impresión de que muchos desarrolladores de JavaScript estén evitando CoffeeScript porque evitan cosas nuevas. En todo caso, creo que la mayoría de los desarrolladores que conocen CoffeeScript probablemente estén en el extremo de la curva de los primeros en adoptar.

En particular, creo que la renuencia a agregar el paso de compilación de CoffeeScript en el desarrollo del lado del cliente está objetivamente justificada, no relacionada con ninguna inversión previa en el aprendizaje de JavaScript.

Nathan Smith

Con cualquier nueva tecnología potencialmente disruptiva, aquellos que han apostado por la forma actual de hacer las cosas tienden a pasar por las cinco "etapas del duelo".

Esta fue mi experiencia, de todos modos...

1. Negación: "Nunca usaré CoffeeScript". (o dart)
2. Ira: "¡Ojalá la gente se callara ya!"
3. Negociación: "Está bien, supongo que tiene * algunas * partes buenas".
4. Depresión: "No puedo creer que tenga que aprender esto".
5. Aceptación: *Encogimiento de hombros* ~ "Utilice la mejor herramienta para el trabajo".

Dicho esto, hay algunas justificaciones para las críticas a CoffeeScript (y Dart). Sin embargo, mientras CoffeeScript intenta adherirse al "espíritu" de JavaScript (código conciso, etc.), el objetivo final de Dart es lograr que los desarrolladores escriban un lenguaje completamente diferente (preferiblemente interpretado en la máquina virtual de un navegador, en lugar de precompilarlo JS). Dart es más parecido a Java que a JavaScript.

La crítica más válida contra cualquier lenguaje que intente suplantar a JavaScript es que JS tiene la base de instalación más grande del mundo de cualquier lenguaje en tiempo de ejecución (en navegadores de escritorio, servidores y dispositivos móviles). Puede que no sea perfecto, pero en lo que respecta a la distribución, "simplemente funciona".

Brendan Eich ya ha expresado su interés en ver aspectos de CS incorporados en futuras versiones de ECMAScript. Por el contrario, Dart ha recibido críticas más duras no solo de los desarrolladores de JS, sino también de la comunidad de WebKit.

Oscar Godson

Si y no. Tiendo a ser más crítico con las cosas antes de probarlas, pero probé CoffeeScript para ver de qué se trataba todo el bombo. Fue agradable, pero no vale la pena. ¿Por qué tener un lenguaje compilado para *solo* ayudarlo con las verrugas JS comunes y hacer que JS sea más "bonito"? Eso es lo que me desanima. Sin embargo, los ingenieros de JavaScript tienden a ser elitistas, estoy de acuerdo con eso, pero en este caso creo que es por una buena razón. La razón es que no escribas un idioma totalmente diferente para arreglar algunas verrugas al respecto.

Ryan Florence

[...] Estamos tan cansados ​​de la fragmentación.

CoffeeScript y Dart ni siquiera son comparables. Dart tiene como objetivo reemplazar JavaScript, CoffeeScript no es más que una buena capa de pintura. Puedes utilizar CoffeeScript y aún "apostar siempre por JS". Creo que los desarrolladores de interfaz están felices de aprender cosas nuevas (nuestro entorno siempre está roto, tendrías que querer aprender cosas para sobrevivir), estamos tan cansados ​​de la fragmentación. Está completamente justificado asustarse si ves que se acerca "ActiveX 2.0". CoffeeScript no es una amenaza para JavaScript.

Marco Chomut

Creo que ambas reacciones estaban igualmente justificadas (aunque cuando Google está involucrado, la gente siempre tiende a exagerar sus opiniones de una forma u otra por cualquier motivo). CoffeeScript fue una reinvención de JavaScript de las comunidades Ruby y Python. Dart fue una reinvención de un subconjunto de la comunidad Java. Dejando a un lado los prejuicios del lenguaje, honestamente no creo que ya Java-fying sea un lenguaje dinámico y (posiblemente) detallado con un enfoque correcto.

Probablemente no ayudó que la comunidad JavaScript ya fuera alérgica a la idea de Dart incluso antes de que fuera anunciado, debido al conjunto de correspondencia "filtrada" que lo rodea.

Trevor Burnham

Por supuesto, algunas de las críticas a CoffeeScript están justificadas. Quiero decir, "un espacio en blanco significativo es malo" es poco convincente, pero "divide a la comunidad" es de fiar. Hay algo que decir acerca de que JS es una lengua franca. Pero observa errores de JS muy comunes, como olvidar una coma en un objeto literal de varias líneas (o agregar una extra al final de la última línea), y hace que toda la aplicación se bloquee... para un cierto tipo de programador (incluido yo mismo), no tener que lidiar con eso es un gran soplo de aire fresco.

Creo que CoffeeScript y JS van a coexistir pacíficamente en el futuro previsible, y habrá enemigos, y eso está bien. Así es como sabes que es un lenguaje de programación real.

Alex MacCaw

CoffeeScript no pretende reemplazar JavaScript, o abstraerlo, sino mejorarlo.

Como han mencionado otros, Dart es una bestia completamente diferente a CoffeeScript, y muchas de las críticas dirigidas a Dart estaban relacionadas con los detalles de implementación y el enfoque de Google, en lugar de solo la existencia de otro lenguaje. Francamente, CoffeeScript es un lenguaje completamente diferente a Dart.

Google adoptó un enfoque de jardín amurallado para Dart, y tengo la impresión de que realmente no buscaron inspiración fuera de los confines de su empresa. Si esto se debió a algún tipo de síndrome No inventado aquí, o al hecho de que necesitaban un lenguaje que atrajera a sus desarrolladores de Java, no estoy seguro. Sin embargo, Dart me parece algo muy específico para las necesidades de Google, en lugar de algo aplicable en general.

CoffeeScript no pretende reemplazar JavaScript, o abstraerlo, sino mejorarlo. Entonces, no solo los idiomas son completamente diferentes, sino que los motivos detrás de ellos son muy diferentes. Por lo tanto, es difícil comparar las críticas entre los dos.

4 - ¿Es justo asumir que, si estás en contra de la idea de CoffeeScript, es probable que también estés en contra de los preprocesadores de CSS, como Sass y Less? ¿O ves una distinción específica entre los dos (como yo)?

James Padolsey

Nunca he usado Sass o Less, así que no puedo comentar. Diré que la idea general es la misma en el sentido de que todos aumentan ligeramente el nivel de abstracción, lo que te permite acceder rápidamente a la funcionalidad sin tener que escribir la alternativa detallada. Diré que lo que me impide elegir CoffeeScript es muy diferente de lo que me impide elegir un preprocesador CSS.

John-David Dalton

No trabajo mucho con CSS y no he usado un preprocesador de CSS, pero puedo comprender la necesidad de administrar el grupo de prefijos de proveedores. Tampoco me siento tan cómodo con CSS como con JS.

Nathan Smith

No creo que sea una suposición del todo precisa. Si bien puede haber algunos que estén en contra de todo el preprocesamiento del código del lado del cliente, con Sass (y Compass) obtienes una capa encima de CSS que es muy "cercana al metal" en términos de sintaxis. Uno de los beneficios de Compass es la capacidad de escribir una línea que se transforma en varias líneas de código con prefijo del proveedor. No es necesario memorizar diferentes variaciones del mismo estilo que, en última instancia, quedarán obsoletas cuando se acuerde un estándar. Ejemplo de Sass (con Compass):

1

#foobar

2

  +background(linear-gradient(#fff, #ccc))

Eso se lee claramente y es algo similar a lo que podría convertirse en el estándar en CSS.

CoffeeScript, por otro lado, agrega una nueva capa sintáctica que busca ser un alejamiento de JavaScript, incorporando modismos de otros lenguajes que no son nativos de JS.

Sass agrega variables, matemáticas de colores y una gran cantidad de cosas que no se pueden hacer solo con CSS. Mientras que CoffeeScript proporciona un enfoque alternativo a lo que JavaScript ya es perfectamente capaz de hacer. Creo que es por eso que estamos teniendo esta discusión: algunos ven valor en eso. Otros no lo hacen.

Oscar Godson

Personalmente, no tengo nada en contra de los preprocesadores CSS porque agregan funcionalidad. No los uso porque soy un purista, podría decirse, pero ahorran tiempo con menos escritura, especialmente para las personas que hacen mucha codificación CSS. Tampoco tienen como objetivo arreglar cosas "rotas", solo extenderlo. No lo uso y no me veo usándolo nunca para cosas personales, pero no me opongo a usarlo.

Ryan Florence

Hay una distinción. SASS, Less, Stylus, etc., aportan algo a CSS que aún no tiene.

Hay una distinción. SASS, Less, Stylus, etc., aportan algo a CSS que aún no tiene: lógica-eso convierte tu CSS en una aplicación. CoffeeScript no aporta nada "nuevo" a JavaScript de la misma manera, por lo que es tan discutible. No usar un preprocesador CSS ni siquiera es discutible para algo que no sea trivial.

Marco Chomut

CoffeeScript proporciona una sintaxis más limpia...

Voy a tener que estar de acuerdo con las otras respuestas aquí en que los "equivalentes" CSS de CoffeeScript, como SASS o Less, a menudo se juzgan de manera bastante diferente. Para mí, SASS es siempre un valor predeterminado en cualquier proyecto nuevo en el que trabajo, mientras que CoffeeScript sigue siendo discutible. CoffeeScript proporciona una sintaxis más limpia, hace todo lo posible para mantener a un desarrollador protegido de las partes malas de JavaScript y le permite evitar la herencia basada en prototipos con su estructura de clases incorporada. SASS, por otro lado, ofrece una gran cantidad de características (muy necesarias) para CSS que de otro modo no podría tener. Variables, funciones, mixins, la lista sigue y sigue. CoffeeScript realmente no ofrece ninguna de estas meta-características a JavaScript, y en realidad se reduce al azúcar sintáctico.

Trevor Burnham

Sinceramente, me sorprende que la gente siga usando Sass/SCSS.

Sass es un ejemplo interesante porque atravesó una gran división en sí mismo: originalmente, era una alternativa completamente significativa a los espacios en blanco a CSS y, por supuesto, a algunas personas les encantó y otras lo odiaron. Ahora viene en dos versiones: la sintaxis "Sass Classic", que significa espacios en blanco, y el superconjunto CSS SCSS. Ambos son fastidiosamente estrictos; el compilador "Sass Classic" te gritará si usas tanto como un punto y coma. Luego apareció TJ Holowaychuk y creó Stylus, que te permite usar sintaxis significativa de espacios en blanco y sintaxis de llaves... ¡en el mismo archivo! Es una solución mucho más elegante y, sinceramente, me sorprende que la gente siga usando Sass/SCSS.

Lo que no quiere decir que CoffeeScript debería comenzar a aceptar llaves (habría algunos casos ambiguos). Mi punto es que los preprocesadores de CSS no se tratan realmente de una sintaxis más limpia/tersa como lo es CoffeeScript. (La sintaxis SCSS es más popular que Sass Classic, probablemente porque los diseñadores pueden seguir usando los fragmentos de CSS a los que están acostumbrados sin ejecutarlos a través de un convertidor). Se trata de hacer las cosas de una manera totalmente diferente. CSS no es realmente un lenguaje; Los preprocesadores CSS (con sus variables y funciones) son.

CSS *es* un idioma. Simplemente no es un lenguaje de "programación". Sin embargo, veo su punto, los preprocesadores permiten la programación funcional declarativa.

Alex MacCaw

Bueno, no creo que ese sea necesariamente el caso. Personalmente disfruto Less y Stylus, tanto como disfruto CoffeeScript. Sin embargo, no soy un fanático de las abstracciones HTML como HAML y Jade. Evalúo cada tecnología de forma independiente. No estoy a favor ni en contra de los preprocesadores en general.

5 - Una crítica frecuente de CoffeeScript es que, si todo el mundo lo usa, podemos llegar a un punto en el que nadie recuerde (ni haya aprendido nunca) cómo escribir JavaScript real. ¿Es esta una preocupación valida?

Jeremy Ashkenas

No, CoffeeScript expone un subconjunto de la semántica de JavaScript. Si aprendes a escribir CoffeeScript, casi por definición, sabrás cómo escribir JavaScript. El aprendizaje no es un juego de suma cero. Aprender un idioma o dialecto no te impide conocer a otros.

De hecho, así como a las personas que se sienten cómodas hablando varios idiomas les resulta fácil aprender más; Los programadores que conocen más de un dialecto de JavaScript pueden aprender mejor nuevos conceptos y modismos.

John-David Dalton

No. Como CoffeeScript se compila en JS, los desarrolladores todavía tienen que lidiar con JS durante la depuración, por el momento, y aún pueden usar JS a través de la sintaxis de incrustación admitida.

- http://jashkenas.github.com/coffee-script/#embedded - https://bugs.webkit.org/show_bug.cgi?id=30933 - https://bugzilla.mozilla.org/show_bug.cgi?id=618650

Dave Ward

Varias herramientas y marcos se han "compilado" en HTML durante casi todo el tiempo que HTML ha existido.

No, no creo que sea probable.

Varias herramientas y marcos han estado "compilando" en HTML durante casi tanto tiempo como ha existido HTML, sin embargo, el conocimiento (y la apreciación) del marcado HTML generado solo ha aumentado durante ese tiempo. Con la mayoría de las abstracciones, inevitablemente se encuentra lidiando con casos extremos que lo obligan a aprender más profundamente sobre la tecnología subyacente. En todo caso, una simple abstracción sobre algo más desalentador a menudo proporciona una vía de acceso atractiva para los nuevos desarrolladores, lo que eventualmente los lleva a aprender más sobre el tema abstraído de lo que de otro modo se habrían sentido cómodos.

Nathan Smith

Si CoffeeScript se vuelve "convencional", más personas se interesarán en el lenguaje JavaScript en sí.

De hecho, creo (espero) que tal vez sea cierto lo contrario. Creo que si CoffeeScript se vuelve "convencional", más personas se interesarán en el lenguaje JavaScript en sí. He conocido a bastantes diseñadores a los que no les importaba JavaScript en absoluto, pero aprendieron a cortar y pegar fragmentos de jQuery. En poco tiempo, dicen "Hombre, realmente necesito aprender JavaScript".

Así como jQuery encendió el interés en JS entre los diseñadores con sus selectores "lee como CSS", creo que quizás CoffeeScript será esa "droga de entrada" a una mayor comprensión de JS, excepto para los Rubyists. De cualquier manera, aquellos que ya conocen JS tienen una ventaja.

Oscar Godson

¿Has estado en StackOverflow recientemente? Intente hacer una pregunta sobre JavaScript. Una vez pregunté sobre hacer un análisis de fechas (para obtener el próximo miércoles) y alguien me envió un complemento de jQuery completo. Terminó siendo una línea y el complemento jQuery obtuvo la mayor cantidad de votos en comparación con la respuesta correcta de una línea. Esto ha sucedido con jQuery, donde la gente simplemente usa jQuery y nunca se molesta en aprender JavaScript. En Twitter escuché a alguien preguntando sobre las sesiones de cookies y alguien sugirió que usaran jQuery e incluyeran un complemento $.cookie. Me preocupa que CoffeeScript termine así, donde la gente incluirá esto para aplicaciones simples o cuando realmente no quieran entender JS.

Ryan Florence

No puedes escribir CoffeeScript sin conocer JavaScript. Estás depurando JavaScript. Estás usando bibliotecas de terceros que son JavaScript. No puedes evitarlo (el gran defecto de usar CoffeeScript para aplicaciones del mundo real). Entonces no, no es un argumento válido para estar en contra de CoffeeScript.

El hecho de que este argumento sea defectuoso es un argumento sólido para no usar CoffeeScript. Si no puedes romper con JavaScript, ¿cuál es el punto?

Marco Chomut

Se hicieron argumentos similares en la época en que jQuery se estaba volviendo bastante popular. No creo que fuera una preocupación válida entonces, y no creo que lo sea ahora. Aprender CoffeeScript también requerirá que en algún momento te abroches y aprendas el JavaScript subyacente. Esto no es realmente algo que puedas evitar, hasta que llegue el día (si es que llega) en que los navegadores lo analicen y ejecuten de forma nativa. Te encontrarás con algún error o interacción que te obligará a entender en qué se está traduciendo.

Trevor Burnham

No debes utilizar CoffeeScript sin conocer JavaScript.

Lo que dijo Ryan.

No debes usar CoffeeScript sin saber JavaScript, aunque puedes aprender ambos al mismo tiempo. Quiero decir, debe haber un millón de personas que usan JavaScript sin conocer realmente JavaScript. Muchos de ellos tienen otros lenguajes primarios, y nunca les gustará JavaScript tanto como Ruby, PHP o Java, por lo que solo aprenden lo que necesitan para salir adelante. Ese es el tipo de público al que está dirigido principalmente mi libro. Es como "Oye, aprendamos este nuevo lenguaje de moda y, a lo largo del camino, llenaremos los vacíos en nuestro conocimiento de JavaScript".

Alex MacCaw

Al contrario, es todo lo opuesto. No creo que esta sea una preocupación válida. Como han dicho los demás, el conocimiento de JavaScript es un requisito para escribir CoffeeScript. Por lo tanto, al escribir CoffeeScript, creo que tu conocimiento de JavaScript debería, en todo caso, mejorar.

El JavaScript generado por el compilador CoffeeScript es de primera categoría, y al navegar a través de él, ciertamente aprenderás algunos trucos.

Sin embargo, estoy completamente en desacuerdo con que el hecho de que no pueda romper con JavaScript sea un argumento para no usar CoffeeScript. CoffeeScript es un subconjunto ligero curado del lenguaje, que mejora su sintaxis y solo presenta las 'partes buenas'. En otras palabras, creo que es una mejora.

6 - Un argumento a favor de CoffeeScript que rara vez veo presentado es que puedes convertirlo en un mejor desarrollador de JavaScript, especialmente si es algo nuevo en el lenguaje. Al igual que en Rails, el compilador incorpora una gran variedad de mejores prácticas. ¿Ves algún beneficio en ese aspecto? ¿Utilizas CoffeeScript para convertirte en un mejor desarrollador de JavaScript?

Jeremy Ashkenas

Una gran cantidad de usuarios han informado que han aprendido nuevos trucos y patrones al leer su JavaScript compilado.

Si. Una gran cantidad de usuarios han informado que han aprendido nuevos trucos y patrones al leer su JavaScript compilado.

Pero tener las mejores prácticas integradas en el compilador no beneficia principalmente a los principiantes; el beneficio es para los programadores a largo plazo que pueden aprovechar al máximo la posibilidad de tener una forma concisa y legible de expresar sus intenciones de JavaScript en el código, sin tener que hacerlo constantemente. Ten en cuenta los patrones de mejores prácticas. Una mejor práctica que puede ser aplicada y generada por un compilador es mejor que una mejor práctica que debe recordarse y escribirse manualmente cada vez.

James Padolsey

El único problema que veo al adoptar este enfoque es que en realidad no estás aprendiendo JavaScript, y hay tanta magia sucediendo que no necesariamente estarás apreciando los extremos a los que podrías tener que llegar para hacer cosas similares en JavaScript. CoffeeScript es más fácil para estas tareas.

Creo que te enseñará a convertirte en un mejor programador, pero si quieres aprender JavaScript, apréndelo puramente.

John-David Dalton

Creo que puedes tomar "te convierte en un mejor desarrollador de JS" y aplicarlo a las bibliotecas/frameworks de JS existentes. Aprendí mucho investigando y solucionando problemas en bibliotecas como Dojo, jQuery, MooTools y Prototype. El código producido por CoffeeScript es extrañamente detallado y promueve microoptimizaciones (lo cual no es necesariamente útil y no es una "mejor práctica").

No buscaría CoffeeScript o su JS compilado para mejorar mis habilidades con JS y preferiría buscar bibliotecas JS maduras y endurecidas.

Dave Ward

Si alguien quiere convertirse en un mejor desarrollador de JavaScript, existen rutas menos tortuosas. Creo que las principales cosas que hacen que JavaScript sea difícil para los principiantes son más conceptuales que sintácticas. CoffeeScript no cambia el hecho de que necesitas comprender conceptos como cierres, programación asincrónica y paso de continuación para escribir código JavaScript no trivial.

Nathan Smith

Creo que hay algo de verdad en esto. Si está comprobando constantemente qué JavaScript genera el compilador CoffeeScript, creo que hay algunas ideas que se deben obtener. Por ejemplo, declarar todas las variables al comienzo de una función, para evitar la elevación de variables.

Además, el concepto de cierres se introduce de forma automática. Esto puede parecer frustrante al principio, si solo intentas crear una variable global, directamente en línea (emitiendo algo desde el lado del servidor en HTML). Debido a esto, CoffeeScript impone buenos hábitos, como adjuntar variables explícitamente al objeto global, si eso es realmente lo que quieres hacer...

1

// Global variable in CoffeeScript

2

window.foobar = 'something'

3

4

//=====//

5

6

(function() {

7

  // CoffeeScript output.

8

  window.foobar = 'something';

9

}).call(this);

10

11

// Versus:

12

13

(function() {

14

  // Manual typo.

15

  foobar = 'something';

16

})();

Eso no quiere decir que estas lecciones no se puedan aprender aparte de usar un transpilador, pero si alguien nuevo en JavaScript buscara usar CoffeeScript como una forma de aprender acerca de los conceptos de JS, podría ser un lugar interesante para comenzar. Sin embargo, para los principiantes de JS, leer libros canónicos como "JavaScript: The Good Parts" probablemente sería más útil.

Oscar Godson

¿Cómo aprendes o te vuelves mejor en algo de lo que te han protegido? Si nunca tienes que preocuparte por las fugas de variables globales, ¿cómo lo sabrás más adelante cuando trabajes con vanilla JS? Es como darle a alguien una cámara con enfoque automático que nunca antes ha usado una cámara y luego esperar que sepa cómo usar una cámara de película y ajustar el enfoque, ISO, etc. de forma manual.

Ryan Florence

Mi JavaScript escrito a mano es bastante diferente de lo que escupe CoffeeScript.

Creo que los desarrolladores que no tienen mucha experiencia en JavaScript tienen algo que aprender de la salida del compilador. Toma los operadores ?= Y ||=, CoffeeScript les muestra cómo resolver ese problema en JavaScript.

Pero también van a tener dificultades para depurar el código que no entienden. No creo que estas personas puedan usar CoffeeScript de manera efectiva.

Mi JavaScript escrito a mano es bastante diferente de lo que bota CoffeeScript; también es más atractivo. Creo que hay más que aprender leyendo el código fuente de algunos de nuestros líderes comunitarios y bibliotecas JS establecidas que del compilador.

Marco Chomut

Si, como desarrollador, aún no estabas expuesto a las partes más finas de JavaScript (ya sea a través de JSLint de Douglas Crockford o JSHint de Anton Kovalyov), CoffeeScript definitivamente será un curso intensivo decente en el tema. Pero solo si tienes la oportunidad de comprender realmente por qué CS tomó ciertas decisiones en el idioma. Si lo apresuras y simplemente intentas sacar un prototipo funcional lo más rápido posible, solo te estás lastimando a sí mismo a largo plazo. Lo mencioné antes en una respuesta anterior, pero desconocer algunos de los mecanismos internos de sus cajas negras es muy peligroso y contraproducente.

Trevor Burnham

Parece que has estado asistiendo a mis charlas; presento este argumento todo el tiempo.

Es interesante que menciones Rails. Mucha gente aprende Ruby aprendiendo Rails. Mucha gente aprende JavaScript aprendiendo jQuery. Pero si aprendes de esa manera, no verás todo el idioma. Por el contrario, si trabajas con algo en CoffeeScript, verás los bordes. Aprenderás todo sobre this y la herencia de prototipos y typeof/instanceof e iterando a través de claves de objeto y valores de matriz, y un centenar de otras cosas sobre las que los novatos JS preguntan en Stack Overflow todos los días.

Así que sí. Veo el aprendizaje de CoffeeScript como un camino para convertirse en un experto en JavaScripter. Ciertamente no es el único, pero es divertido y gratificante.

7 - Claramente, si eres un desarrollador de Ruby, CoffeeScript te resultará infinitamente más atractivo, ya que la sintaxis es bastante similar. Para proyectos del mundo real, donde los desarrolladores tienen fechas límite, ¿CoffeeScript no es simplemente una forma de hacer el trabajo más rápidamente, con menos mezcla de idiomas? ¿Qué hay de malo en eso, en todo caso?

Jeremy Ashkenas

Algunos Rubyists dicen que CoffeeScript se parece a Ruby, los Pythonistas dicen que CoffeeScript se parece a Python, y he escuchado a Haskellers decir que CoffeeScript se parece a Haskell.

Me temo que esta es una pregunta tonta. Algunos Rubyists dicen que CoffeeScript se parece a Ruby, los Pythonistas dicen que CoffeeScript se parece a Python, y he escuchado a Haskellers decir que CoffeeScript se parece a Haskell. La verdad del asunto es que la semántica de CoffeeScript es solo semántica de JavaScript - definitivamente no hay menos "mezcla de lenguaje" involucrada.

James Padolsey

Me temo que será aceptable renunciar a la curva vital de aprendizaje de JavaScript y simplemente tener la falsa seguridad de que el código que escribes en CoffeeScript funciona exactamente como lo haría en ese-otro-idioma-que-conoces. Para un equipo con una fecha límite, definitivamente puedo ver el atractivo de tener un entorno de desarrollo más unificado. Ruby y CoffeeScript son una linda combinación, mucho más que JavaScript y Ruby. Creo que la comprensión de JavaScript es vital, especialmente en esta etapa inicial (la depuración aún puede ser una molestia).

John-David Dalton

Depende de tu configuración. CoffeeScript, como JS libs, tiene errores de una versión a otra (incluso algunos que afectan el uso de varios navegadores) que pueden hacer que el código CoffeeScript existente se rompa.

Además, la depuración aún requiere profundizar en JS sin formato y puede que no sea necesariamente una tarea fácil a medida que las aplicaciones de CoffeeScript se vuelven más complejas.

A diferencia de las bibliotecas JS que pueden vivir en CDN, el azúcar que rodea a CoffeeScript debe compilarse para cada archivo JS (a menos que se compilen juntos). Esto puede hacer que JS generado por CoffeeScript sea menos ideal para secuencias de comandos de terceros independientes. CoffeeScript agrega otro "algo" con el que el equipo tendrá que familiarizarse y dominar, lo que cuesta tiempo/dinero y podría evitarse simplemente usando JS (JS lib + linter).

Dave Ward

Como alguien que ha pasado bastante tiempo en el mundo .NET, he visto que ese argumento se usa para respaldar el desarrollo de arrastrar y soltar y algunas abstracciones particularmente con fugas sobre HTML, CSS y JavaScript. Esa experiencia me ha dejado extremadamente escéptico sobre el valor a largo plazo de centrarse en la productividad inicial a expensas de comprender su pila de desarrollo.

Nathan Smith

No diría que es una forma de evitar la "mezcla de idiomas". Aunque CoffeeScript y Ruby pueden compartir algo de azúcar sintáctico, cada uno tiene sus propias formas de lidiar con las cosas. Si bien CS sin duda les resultará familiar a los desarrolladores de Ruby, todavía hay una curva de aprendizaje.

Si estás bajo el arma en una fecha límite, decidir usar CoffeeScript probablemente no te ayudará a hacer ese trabajo antes. Al igual que con cualquier idioma nuevo, debes reservar un tiempo para familiarizarse con él, cometer errores de principiante y finalmente terminar en un lugar donde se convierte en una segunda naturaleza.

Creo que el peligro para los desarrolladores de Ruby es esperar que CoffeeScript pase por alto algunos aspectos misteriosos percibidos inherentes a JavaScript.

Si bien puedes terminar escribiendo menos caracteres generales en un archivo *.coffee, aún debes preocuparte por lo que termina en el archivo *.js. Eso viene con experiencia, no (solo) con nueva sintaxis.

Ryan Florence

Escribes en un idioma, pero depuras en otro...

En cuanto a "menos mezcla de idiomas", supongo que quieres decir que es como Ruby en todas partes de tu aplicación, eso es totalmente falso. Escribes en un idioma, pero depuras en otro idioma y tampoco Ruby, por lo que en realidad es más aleatorio.

Si la sintaxis de JavaScript lo está ralentizando, debes aprender a usar su editor de texto o aprender a escribir. No hay nada más rápido en CoffeeScript. La introducción de CoffeeScript en tu flujo de trabajo aumenta la "mezcla":

Mucha gente pasa por alto el problema de la depuración, pero el 20% del día escribimos errores, el otro 80% los arreglamos (no lo niegues). La depuración es un gran problema.

Estás depurando un código que no escribiste. Tienes que averiguar qué está haciendo el compilador y luego averiguar por qué el código no está haciendo lo que querías. Luego tienes que ir a tu CoffeeScript y descubrir cómo solucionarlo en una sintaxis diferente. Por lo general, no es tan malo, pero cuando se utilizan algunas de las características más sofisticadas de CoffeeScript, puede parecer realmente un "código de máquina". Una línea en CoffeeScript puede convertirse en varias líneas de cosas que parecen locas (ver aquí), que, nuevamente, no escribiste, así que tienes que averiguar por qué se ve de esa manera y luego por qué está roto.

Este "barajar" de ida y vuelta es un paso extraño que lo ralentiza porque no es _tu_ código lo que estás viendo. Descubrí que volví a hacer mucho console.log en mi código en lugar de usar puntos de interrupción y expresiones de observación, etc., lo cual es una vergüenza total y más lento. Pero es la forma más rápida para mí de "barajar" entre el JavaScript que estoy depurando y el CoffeeScript que estoy escribiendo.

Trevor Burnham

¿CoffeeScript hará el trabajo más rápidamente? Ciertamente, algunos profesionales destacados de JavaScript/Ruby han llegado a esa conclusión por sí mismos.

Los rubyists son ciertamente más fáciles de vender en CoffeeScript que, digamos, los programadores de Java. Pero las preguntas más comunes que recibo de Rubyists son del tipo "Espera, ¿por qué necesitamos un lenguaje separado? ¿Por qué no podemos simplemente compilar Ruby en JS?" Y trato de explicarles que, bueno, compilar "a = b" de Ruby en JS requeriría que verifiques si b es una función, y si es así, ejecutarla y devolver su valor... y compilar "x = y + 1" requeriría que inicies una biblioteca BigDecimal, porque todos los números de Ruby son de precisión infinita... y así sucesivamente. Esa gente tiene que aprender que, mira, cuando estás en el navegador, estás en el terreno de JavaScript y tienes que hacer las paces con él. Podría ser peor. Se podría escribir estáticamente.

¿CoffeeScript hará el trabajo más rápidamente? Ciertamente, algunos profesionales destacados de JavaScript/Ruby (como Sam Stephenson de 37signals, creador de Prototype.js) han llegado a esa conclusión por sí mismos. Obviamente, depende de muchos factores... a veces lo que necesitas es una nueva perspectiva, y un nuevo idioma puede darte eso.

Alex MacCaw

CoffeeScript no es inherentemente Rubyish.

Esa es una pregunta bastante importante, y no creo que esa suposición sea necesariamente válida. CoffeeScript no es intrínsecamente Rubyish, al igual que no es intrínsecamente Pythonist. Toma prestadas características de ambos lenguajes, pero en última instancia, sus esquemas están inspirados en JavaScript. El objetivo de CoffeeScript no es abstraer JavaScript para los desarrolladores que no quieren aprenderlo, como el ahora desaparecido RJS. Como tal, no ayuda con la mezcla de idiomas.

8 - Muchos podrían argumentar que CoffeeScript permite un código más hermoso y fácil de mantener. Por ejemplo, crear una clase en CS es considerablemente más intuitivo y legible que lo que podríamos escribir con JavaScript simple.

No es sorprendente que muchos prefieran el más limpio y más corto:

1

class MyClass

2

  constructor: ->

3

    alert 'constructor'

4

5

  doSomething: ->

6

    alert 'doing something'

7

8

c = new MyClass()

9

c.doSomething()

Por encima...

1

var MyClass = (function() {

2

  function MyClass() {

3

    alert('constructor');

4

  }

5

6

  MyClass.prototype.doSomething = function() {

7

    alert('doing something');

8

  };

9

10

  return MyClass;

11

})();

12

13

c = new MyClass();

14

c.doSomething();

Mi pregunta es: ¿la legibilidad de CoffeeScript por sí sola garantiza su uso?

Jeremy Ashkenas

Puedes escribir código ilegible en cualquier idioma.

Puedes escribir código ilegible en cualquier lenguaje... pero sí, uno de los principales enfoques de CoffeeScript es la legibilidad: expresar conceptos y patrones de JavaScript de la manera más mínima y legible que podamos encontrar.

Tu ejemplo de "clase" es bueno. Si deseas crear muchos objetos que compartan métodos comunes en JavaScript, no es fácil de lograr. Hay muchas formas de romper el objeto "prototipo" mientras intentas configurar la cadena del prototipo. Te quedas escribiendo un texto repetitivo ilegible cada vez que desees encadenar dos prototipos, o usando una biblioteca auxiliar que te oculta la orientación básica del objeto. Las clases de CoffeeScript son una forma sencilla de definir las funciones de su constructor junto con sus propiedades prototípicas y su cadena de prototipos. El efecto secundario es la legibilidad de simplemente escribir lo que quieres decir:

1

    class Square extends Shape

...en lugar de media docena de líneas de código de manipulación de prototipos en JavaScript:

1

    function Square() {

2

      ...

3

    };

4

    var tempConstructor = function(){

5

      this.constructor = Square;    

6

    };

7

    tempConstructor.prototype = Shape.prototype;

8

    Square.prototype = new tempConstructor;

James Padolsey

Naturalmente, como he trabajado más con JavaScript, es más legible para mí que CoffeeScript.

Ese no es el JavaScript que escribiría, pero veo tu punto. CoffeeScript puede tener una gran legibilidad y la mayor parte del código CS que he visto es a la vez conciso y expresivo, pero no creo que esto se traduzca necesariamente en "más intuitivo". Naturalmente, como he trabajado más con JavaScript, es más legible para mí que CoffeeScript. Una vez más, esto parece tener que ver con el gusto y está muy influenciado por la exposición previa al lenguaje. Una persona Ruby probablemente entendería el código CoffeeScript antes que JavaScript, pero sería lo opuesto para, digamos, un desarrollador PHP o Java, donde las palabras clave juegan un papel central en la definición de clases y funciones. En CoffeeScript tienes operadores muy mínimos y expresivos que no siempre son tan claros.

John-David Dalton

No. Los desarrolladores tienen opiniones diferentes sobre lo que consideran legible. CoffeeScript es similar a las bibliotecas JS en que todas agregan azúcar sintáctica y cada desarrollador/equipo tiene sus propias preferencias (MooTools, jQuery, Dojo, CoffeeScript, CoffeeScript + libs, etc.).

Dave Ward

Si deseas azúcar sintáctico alrededor de la estructuración de tu código, existen bibliotecas de JavaScript para ayudar con eso sin requerir el paso de compilación molesto.

Si deseas azúcar sintáctico alrededor de la estructuración de tu código, existen bibliotecas de JavaScript para ayudar con eso sin requerir el paso de compilación molesto.

Teniendo en cuenta esta pregunta en el contexto general de las demás, el desarrollador que aún no comprende JavaScript necesita más que un análogo algo similar a la implementación de la herencia clásica de su lenguaje del lado del servidor. Creo que poner la pseudo-palabra clave "clase" frente a un desarrollador que proviene de un lenguaje típico orientado a objetos puede incluso ser perjudicial a largo plazo.

Nathan Smith

La "legibilidad" es subjetiva. Creo que has tocado algo con el ejemplo de "clase". Para los desarrolladores que provienen de una experiencia de programación clásica (C #, Ruby, etc.), CoffeeScript probablemente se sienta como un soplo de aire fresco. Para mí, habiendo aprendido JavaScript como mi primer lenguaje de programación "real", pensar en términos de clases me parece extraño.

En mi opinión, la combinación perfecta de CS y JS se agregaría var de forma automática y sin necesidad de escribir paréntesis o llaves innecesarias. Sin embargo, podrías prescindir return automático al final de cada función.

Tampoco soy un fanático de cómo CS secuestra el for in para convertirse en un bucle i++, requiriendo en cambio que escribas for of para poder iterar a través de los objetos (cuando *.length no está presente).

Oscar Godson

Esto puede deberse a que JavaScript no es un lenguaje basado en clases. Es un prototipo y eso asusta a la gente que no está acostumbrada. Los desarrolladores de PHP o Rails vienen a JS y no saben cómo usarlo correctamente. Así que inventan trucos para que funcione e incluso se parezca a otros idiomas. Ésta no es la respuesta. Si necesitas usar clases, puedes escribir un mini-lib y hacerlo limpio como:

1

var Ninja = Person.extend({

2

  init: function(){

3

    this._super( false );

4

  },

5

  dance: function(){

6

    // Call the inherited version of dance()

7

    return this._super();

8

  },

9

  swingSword: function(){

10

    return true;

11

  }});

12

13

// via http://ejohn.org/blog/simple-javascript-inheritance/

La única diferencia real es que no hay paréntesis. De hecho, me gusta la idea de Brendan Eich de JS sin paran, pero me gusta la idea de que se integre y no cambie por completo el idioma.

Ryan Florence

Reviso el código de gerrit de mi equipo todos los días. Algunos JavaScript, algunos CoffeeScript. Me cuesta tanto seguir lo que intentan hacer en una sintaxis frente a la otra. Quizás sea más legible verbalmente a veces, pero eso todavía tiene que hacerlo más comprensible para mí. Toma esta línea, por ejemplo:

1

scores = (student["assignment_#{@assignment.id}"].score for own idx, student of @gradebook.students when student["assignment_#{@assignment.id}"]?.score?)

Son 160 columnas de código legible verbalmente directamente de nuestra aplicación, pero no tengo idea de lo que está haciendo. La parte divertida es que terminas depurando cosas como esta.

Hay algunos aspectos de CoffeeScript que son menos legibles.

La flecha gruesa => une el contexto a la función, lo que suena muy bien, pero fomenta el anidamiento profundo, un anti-patrón.

Combina eso con espacios en blanco significativos en varias líneas de código y tendrás un lío. El código no estructurado con devoluciones de llamada y muchas if else es extremadamente difícil de seguir: no hay corchetes de cierre sobre los que colocar el cursor y ver dónde estoy con mi editor de texto. Algunos dicen: "No escribas código así". No escribo todo el código con el que trabajo.

Además, no todas las API tienen funciones como último argumento de su firma, por lo que terminas con algunas comas flotando al principio de las líneas, lo que se ve realmente extraño al lado del resto del aspecto generalmente atractivo de CoffeeScript.

Por otro lado, he notado que la sintaxis de la clase toca una cuerda lógica en personas que no son expertos en JavaScript, pero sí en algún otro idioma(s). De repente, te das cuenta de que puedes escribir código interfaz modular en lugar de encadenar jQuery al olvido. Personalmente, no uso la class ni escribo JavaScript de la forma en que lo hizo en el ejemplo, pero creo que es una sintaxis útil para los buenos programadores menos familiarizados con JavaScript.

Trevor Burnham

En lo que respecta a la legibilidad, no hay sustituto para una buena documentación. Miro la fuente anotada de Backbone.js y pienso, "Wow". Sería quizás un 30% menos de líneas si estuviera escrito en CoffeeScript, pero solo sería un poco más fácil de entender.

Creo que la mayor ventaja está en la capacidad de escritura. No se trata solo de menos pulsaciones de teclas (la escritura rara vez es un cuello de botella para la codificación); es menos en lo que pensar. Un modismo común de Node.js es escribir:

1

  if (err) throw err;

...en la parte superior de las devoluciones de llamada. Podría guardar eso como un fragmento, supongo, pero prefiero simplemente ingresar el equivalente de CoffeeScript.

Solo se necesitan menos ciclos cerebrales. De esa manera, puedo concentrarme más en el núcleo de la devolución de llamada.

Alex MacCaw

Claro, esa es una buena razón para aprender CoffeeScript, o cualquier lenguaje de alto nivel. La legibilidad es una parte crucial para desarrollar, mantener y ampliar código en cualquier idioma. CoffeeScript lleva esto un paso más allá al usar espacios en blanco, lo que significa que el código mal formateado simplemente no se compilará.

Por supuesto que es posible escribir código desagradable en cualquier lenguaje, pero definitivamente creo que CoffeeScript tiene una belleza estética heredada, tanto en el lenguaje como en la comunidad; mucho más que el JavaScript tradicional.

Argumentos finales

Jeremy Ashkenas

Me gustaría presentar mi objeción general a la forma en que se enmarcan estas preguntas. Crean un falso drama donde no es necesario que exista. CoffeeScript es un pequeño y divertido lenguaje que intenta empujar JavaScript en una dirección determinada: cuán mínima y legible podemos encontrar una sintaxis para expresar las famosas partes buenas de JavaScript. Si lo disfrutas, es genial; si no lo haces, también es genial: JavaScript es un lenguaje maravilloso. Debido a que CoffeeScript y JavaScript comparten semántica, siempre se llevarán bien. Personalmente, escribo mucho de ambos.

Notas del entrevistador: Absolutamente. Nunca fue mi intención crear una guerra de llamas, cuando, en última instancia, estamos tratando con herramientas útiles. ¡Eso nunca puede ser algo malo! Dicho esto, las preguntas que he proporcionado son las que encontré más frecuentes en Twitter, blogs y redes sociales. Incluso si son infundados, es importante reconocer que se les está preguntando y discutirlos. :)

Ryan Florencia

Creo que CoffeeScript es una excelente opción para aficionados y operaciones unipersonales. En un equipo, lo desaconsejaría si aún no está en el camino.

Trevor Burnham

Lo que dijo Ryan. Aprende JavaScript. Es un idioma asombroso. Pero no es mi idioma favorito, porque existe CoffeeScript.

John-David Dalton

+1 a la nota al margen de Ryan Florence.

Nathan Smith

No creo que nadie pueda negar que Jeremy Ashkenas ha creado algo extraordinario. El hecho de que todos estemos hablando de eso es un testimonio de eso. Yo animaría a cualquiera que se haya opuesto al uso de CoffeeScript a que al menos lo intente. Habiéndolo hecho yo mismo, sigo prefiriendo JavaScript, pero al menos ahora puedo apreciar por qué es atractivo para los demás.

Más recursos de CoffeeScript

Una pregunta para los lectores

Ahora que algunos de los mejores en el negocio han ofrecido sus propias opiniones, me gustaría saber de ti en los comentarios. Si bien la mayoría de estas preguntas fueron cortesía de las redes sociales y las publicaciones de blogs, esta última pregunta es una de las que personalmente me interesó más conocer la respuesta.

Una de mis únicas preocupaciones con el uso de CoffeeScript es que la depuración del JavaScript generado podría ser una gran preocupación. ¿Has encontrado que este es el caso?

¡Házmelo saber a continuación!