¿Cuándo son mejores los marcos con hebras que los marcos basados ​​en eventos? (es decir, ¿cuándo los rieles son mejores que node.js?)

Question

Entiendo lo que es un marco de trabajo (Rails, Django, Symfony2, ...). Y entiendo qué es un marco impulsado por eventos (Node.js, EventMachine, Twisted, ...) y por qué es genial para live, chat, speed, ... Además, no parecen causar problemas en casos de uso normal. Entonces:

• ¿Cuáles son los inconvenientes de los marcos basados ​​en eventos?
• ¿Cuándo debería preferir Rails to Node.js?
• ¿Por qué no se escriben todos los servidores web nuevos con EventMachine, Twisted o Node.js?
• ¿Los famosos frameworks como Django o Rails se convertirán en eventos o morirán?

Answer 1

Entonces, ¿dónde están los inconvenientes de los marcos basados ​​en eventos?

1. familiaridad. Dado que la programación web basada en eventos es tan diferente, pasará un tiempo antes de que los programadores se sientan cómodos con ella. Cuando trabajas en una fecha límite, es más fácil usar lo que sabes, eso funciona.
2. Soporte de biblioteca. Node tiene una increíble cantidad de módulos, pero tiene un largo camino por recorrer para ponerse al día con Ruby and Python. Actualización: Node now has more published modules available than Python or Ruby.
3. Despliegue. El personal de TI está acostumbrado a los marcos roscados. Para aprovechar los marcos basados ​​en eventos, querrás ser asincrónico de arriba a abajo. Ahora mismo puede desarrollar en Node.js, pero ¿podrá implementarlo de manera efectiva o tendrá que administrar sus propios servidores?
4. Preocupaciones sin fundamento. cosas que parecen como problemas, pero no son realmente:
   • la programación dirigida por eventos es malo para aplicaciones intensivas de la CPU: La razón es que un cálculo intensivo de la CPU podría bloquear el servidor. Esto es estrictamente cierto, pero prácticamente se supera al generar otro proceso y tratarlo como E/S, por ejemplo, utilizando Node's child_process.exec.
   • La programación basada en eventos es solo para aplicaciones que requieren alta concurrencia: la razón es que la programación basada en eventos es "más difícil" que la programación de aplicaciones web tradicionales, por lo que no vale la pena hacerlo a menos que tenga una buena razón para hacerlo. Personalmente, no creo que este sea el caso: la programación orientada a eventos no es más difícil, pero es muy diferente. En algún momento, una masa crítica de programadores estará familiarizada con el enfoque impulsado por el evento y esta preocupación desaparecerá.
   • La programación basada en eventos es un desastre de devoluciones de llamada anidadas. Esto puede ser cierto cuando lo aprende por primera vez, pero finalmente descubrirá cómo estructurar su código de forma legible.
5. Documentación. La documentación para Node y sus bibliotecas de terceros es terrible, generalmente consta de nada más que README.md. Viniendo del mundo de Python, donde estamos acostumbrados a la excelente documentación, este es un gran inconveniente.Esto está mejorando lentamente (necesitamos más documentación like this).

¿Cuándo debería preferir Rails to Node.js?

• Cuando usted o su equipo simplemente prefiere Rubí más de JavaScript.
• Cuando usted o su equipo no están familiarizados con Node y necesita hacer el trabajo.
• Cuando necesite usar la funcionalidad que está en Rails, ese Nodo aún no tiene.
• Cuando necesite implementar en la infraestructura existente basada en Rails.
• Cuando tiene que convencer a la administración de que debe usar Node.js, pero no desea ser el que falle si el proyecto falla.

¿Por qué todo nuevo servidor web no se escriben con EventMachine, trenzado, o Node.js?

Ver más arriba.

¿Será famoso el marco como Django o los rieles se activan por eventos o mueren?

Django and Rails será por mucho tiempo. Hay muchas aplicaciones en esos marcos, y no hay razón para reescribirlas. Y hay un gran grupo de talentos, que a menudo es una consideración al desarrollar una nueva aplicación web.

(Pero vea this Quora answer del desarrollador principal de Django, endorsing Node).