IcedCoffeeScript o jQuery diferido

Question

Recientemente, mientras trabajaba en un proyecto Backbone.JS/jQuery/CoffeeScript, me encontré en un lío de problemas de devolución de llamada y sincronización. Tenía que esperar a que se completara algo antes de continuar y me encontré en un lío de devoluciones de llamada anidadas ... que es confuso y difícil de depurar. Entonces me encontré con 2 posibles soluciones o jQuery deferredIcedCoffeeScript

IcedCoffeeScript se ve muy fácil, simplemente añadiendo await & defer. Sin embargo, me pregunto si está allí para quedarse? ¿Solo 2 preguntas aquí en StackOverflow? No se habla mucho en comparación con CoffeeScript

Otra cosa es ¿cuál es la diferencia entre los 2 métodos, que parecen hacer casi lo mismo? Excepto en IcedCoffeeScript, se parece más a código de procedimiento, y en diferido jQuery, no resuelve mi desorden de devoluciones de llamada tanto

Answer 1

Estos son muy diferentes tecnologías:

• IcedCoffeeScript es un precompilador que amplía CoffeeScript con las palabras clave await y defer que transforman el código para que pueda escribir el código en un estilo síncrono. En el JavaScript generado, await y defer producen funciones anidadas.

• jQuery diferido (también conocido como promesas) son una forma de devoluciones de llamada-escalonamiento secundarios en total: En lugar de tomar una devolución de llamada, una función asíncrona puede devolver una promesa. Luego adjuntas devoluciones de llamada a la Promesa. Es una técnica simple pero poderosa. Le dedico un capítulo en mi libro, Async JavaScript.

Cada una de estas tecnologías funciona mejor con un cierto tipo de API. await y defer esperan que una función tome una sola devolución de llamada como último argumento. Las promesas funcionan mejor cuando tienes muchas otras promesas en tu aplicación.

No existe una fórmula mágica para lidiar con el comportamiento asíncrono en JavaScript. Debe comprender las devoluciones de llamada, Promises y PubSub (también conocido como EventEmitter s) y elegir la mejor herramienta para cada trabajo. Incluso si usa IcedCoffeeScript (que es genial), todavía hay momentos en que Promises le ahorrará una gran cantidad de trabajo.

Espero que ayude. Echa un vistazo a mi libro, Async JavaScript, para obtener más información.

Answer 2

escribí un post acerca de las diferencias entre las devoluciones de llamada de eventos estándar, sub pub y deferreds, lo que podría ayudarle a cabo:

Event Emitter, Pub Sub or Deferred Promises … which should you choose?

La introducción se lee:

La respuesta obvia a la pregunta "si elige un Evento Emisor, Pub Sub o Diferido/Promesas" es que depende de lo que esté haciendo.

En este artículo voy a explorar un poco sobre cómo funciona cada patrón con (muy) implementaciones básicas, y luego veré las razones por las cuales puede elegir una sobre otra.

y el resumen es:

Emisor de sucesos es un verdadero clásico, y permite a las buenas prácticas y control sobre las cosas que suceden; Pub Sub es más flexible para eventos de componentes cruzados ; Deferred y Promises dan una forma poderosa de manejar callbacks.

Aplicando el resumen a su problema - Yo sugeriría que Deferred's y Promises probablemente lo ayuden mucho.

No sé ustedes, pero me he dado cuenta de cómo implementaría Deferred realmente me ayudó a entender las complejidades de su uso. También he incluido un código de muestra en la publicación, que al ser (extremadamente) simple, podría ayudarte cuando mires el intento más robusto de otra persona.

Answer 3

Creo que IcedCoffeeScript está aquí para quedarse.

Planeo apoyarlo indefinidamente, y soy bastante regular en parcharlo contra la línea principal. Lo uso en casi todos mis proyectos personales, y el sitio Combosaurus.com, un proyecto de OkCupid Labs a punto de llegar a la versión general, está escrito en IcedCoffeeScript.

Answer 4

Oh, definitivamente confiaría en IcedCoffeeScript. Si le gusta y usa la sintaxis de CoffeeScript, descubrirá que simplemente "se mezcla" naturalmente con ella ...

En cuanto al futuro del proyecto, tuve el mismo dilema hace un tiempo, pero parece que Maxwell Krohn está activo manteniéndolo y hay una comunidad en crecimiento y conciencia alrededor (ok, quizás no aquí en stackoverflow todavía).

Empecé a usarlo el año pasado y ahora no podía imaginarme la codificación de aplicaciones de la "vida real" sin await y defer.

Puede encontrar un breve "prototipo" sobre el elegante flujo de control asincrónico con ICS here y también escribí un 5-partes ironically-titled article on using Node.js for generic web projects here mencionando ICS.