¿Hay una buena razón para evitar node.js para aplicaciones web que no son en tiempo real?

29

He visto muchas charlas sobre lo increíble que es Node.js para las aplicaciones web en tiempo real: cosas que necesitan enchufes, Comet, comunicaciones pesadas con AJAX, etc. Sé que su modelo controlado por eventos, asíncrono y subproceso también es bueno para la concurrencia con baja sobrecarga.

También he visto los tutoriales de Node.js para aplicaciones más simples, 'tradicionales', no en tiempo real (por ejemplo, el ejemplo de blog estándar, que parece ser el 'Hola Mundo' estándar para las personas que aprenden el desarrollo de aplicaciones). Y también sé que node-static le permite servir activos estáticos.

Mi pregunta es: ¿hay alguna buena razón para evitar Node.js para aplicaciones web tradicionales, como anuncios clasificados, foros, el ejemplo de blog mencionado anteriormente o el tipo de aplicaciones CRUD que creas para aplicaciones comerciales internas? Solo porque sobresale en todas las cosas funky en tiempo real, ¿eso lo contraindica para usos más habituales?

Lo único en lo que puedo pensar, desde el principio, es la falta de bibliotecas maduras (aunque eso está cambiando).

(La razón por la que pregunto es porque estoy considerando abandonar PHP para Node.js, principalmente para superar la falta de coincidencia de impedancia de cambiar entre idiomas, pero también para poder reutilizar el código de validación y otras cosas. Mi superego me advierte que elija el la mejor herramienta para el trabajo , sin embargo, no tengo mucho tiempo para aprender quince idiomas y todas sus bibliotecas de usuarios solo para tener un arsenal completo. También es tranquilizador que Node.js me brinde una ruta de optimización más fácil que PHP / Apache en el futuro cuando tenga que empezar a pensar en el tráfico pesado).

[EDITAR] Gracias por las respuestas hasta ahora, amigos; Solo quiero ver si alguien más va a influir antes de elegir una respuesta. La respuesta de @Raynos confirma un poco lo que estoy pensando, y los enlaces de los comentaristas me sirvieron para pensar, pero quiero ver si alguien más tiene respuestas específicas de Nodo, como 'NO UTILICE NODO PARA EL PROBLEMA X '. (Además de las tareas de CPU alta; ya lo sé :-)

Paul d'Aoust
fuente
1
@ default.kramer: Gracias por el enlace, ¡realmente lo disfruté!
Zach
1
¡Guauu! Un tipo bastante obstinado, ¿eh? En el artículo de seguimiento, parece estar diciendo que, para aplicaciones de alta E / S y baja CPU, los sistemas roscados e igualados están más o menos a la par, y que el problema radica en los programadores novatos que no saben cuándo renunciar a los eventos y generar un nuevo hilo. Pero la ignorancia del programador no significa que la herramienta sea mala, ¿verdad? Estoy de acuerdo en que usar un entorno cuyo forté es bucles de eventos para tareas intensivas en CPU es un poco extraño, pero ¿es malo?
Paul d'Aoust el
1
Su odio a JavaScript también parece ser un tema importante, que me temo podría ser en parte responsable de la energía detrás de su argumento.
Paul d'Aoust
@Paul - Probablemente deberías tomarlo con un grano de sal. No sé mucho sobre Node.js; Solo pensé que era humorístico. (como la mayoría de sus escritos)
default.kramer
@ default.kramer gracias por el recordatorio; Tiendo a tomar las opiniones de las personas como evangelio. Su principal crítica válida parece ser que no debe usar Node.js para tareas intensivas en CPU. Estoy confundido acerca de su crítica de los procesos de los trabajadores; ¿Hay algún gran problema con la creación de trabajadores separados para tareas específicas?
Paul d'Aoust

Respuestas:

13

¿Hay alguna buena razón para evitar Node.js para las aplicaciones web tradicionales?

Sí, si tiene N años en la plataforma web X, entonces claramente puede desarrollar una aplicación en la plataforma X más rápido.

Si desea hacer Y y la plataforma X tiene una solución prefabricada Y que hace X, entonces hágalo.

Todas las razones genéricas de por qué debería usar una plataforma sobre otra.

¿Qué tipo de aplicaciones CRUD creas para aplicaciones comerciales internas?

Sí, hay otra plataforma que le permite escribir una aplicación genérica más rápido, me viene a la mente Ruby on Rails.

Sin embargo, eso dijo. Tengo experiencia con el nodo y no puedo afirmar que elegiría otra plataforma sobre el nodo a menos que haga una gran cantidad de características listas para usar.

Básicamente es una simple cuestión de

¿Existe una herramienta que haga todo esto por mí? No, luego elija la plataforma más conveniente para escribir la herramienta.

No hay razones sólidas por las que node.js sea una plataforma inconveniente (aparte de "odio javascript")

Raynos
fuente
Entonces, ¿cree que los principios pragmáticos como la familiaridad, la disponibilidad de bibliotecas, etc., son argumentos sólidos para una determinada plataforma, ¿eh? Esos son buenos pensamientos, y definitivamente son cosas que estoy considerando. (Estoy sorprendido de que estés abogando por soluciones listas para usar; ¡pensé que eras un tipo de persona de rol!)
Paul d'Aoust el
@ Pauld'Aoust Soy un tipo un poco listo para ti. Sin embargo, no hago nada y no tengo plazos.
Raynos
je, gracias por la advertencia. Recuerdo sus comentarios en el chat de node.js sobre el uso de bibliotecas de modelos de otras personas (Backbone.js, etc.) y me di cuenta de que estaba pasando demasiado tiempo aprendiendo Backbone.js y no lo suficiente para aprovechar (y aprender) JavaScript mecanismo de herencia prototípico. Buen consejo; Me siento mucho más relajado ahora.
Paul d'Aoust
44
-1 vago. 1) El hecho de que tenga N años de experiencia en X no significa que deba evitar Node.JS. ¿Estás proponiendo ignorancia voluntaria basada en la experiencia? ¿Y cuáles son las "razones genéricas"? 2) 'otras aplicaciones que le permiten escribir una aplicación genérica más rápido' - es puramente subjetivo. 3) 'diferente * que "* Odio * JavaScript' - también es subjetivo y no es una razón válida para evitar una tecnología floreciente. * Ortografía.
Jack Stone
@ClintNash algunas de sus razones no son diferentes a las suyas. "Recursos humanos" versus "N años de experiencia" son exactamente lo mismo. "NodeJS no es tan maduro como los marcos tradicionales" frente a "Sí, hay otra plataforma que le permite escribir una aplicación genérica más rápido, me viene a la mente ruby ​​on rails". También son lo mismo. No solo son iguales, sino que los tuyos no son más medibles (objetivos) que los suyos.
aaaaaa
6

Después de trabajar con el nodo durante algunas semanas, diría que sí, es genial. Pero no necesariamente es algo que quiera usar para reemplazar sus aplicaciones web habituales con ... ni, en mi opinión, está destinado a ser.

Recuerde, el nodo es su propio servidor. Esto introduce complejidades si desea ejecutar más que solo su aplicación node.js. es decir, si tiene más de un sitio / dominio alojado en una máquina. No es como una pila LAMP, donde puede tener una docena de aplicaciones PHP para media docena de dominios diferentes que se ejecutan en el mismo servidor (en el puerto 80, al menos). Hay marcos para el nodo que probablemente lo hacen posible, pero eso agrega complejidad que simplemente no necesita si se adhiere a las plataformas web tradicionales. (Por supuesto, también puede configurar proxies colocando un servidor web frente al nodo, pero eso de alguna manera anula el beneficio de usar el nodo).

OMI, Node es perfecto para trabajar en conjunto con un servidor web tradicional. La forma en que tengo las cosas organizadas ahora es servir las imágenes estáticas html / js / vía apache, y manejar las necesidades de datos 'en tiempo real' mediante un sondeo largo a la aplicación de nodo.

Gran maestro B
fuente
Vale la pena considerar la facilidad de uso de +1 para configurar varios hosts.
Paul d'Aoust
Es bastante simple colocar aplicaciones de nodo detrás de un servidor Apache httpd o nginx y enrutar solicitudes con la firma URI de esa aplicación al puerto (o puertos) del nodo.
TomG
+1: la noción de node.js como proxy del lado del servidor ('junto con el servidor web tradicional') ganó fuerza a principios de este año y vale la pena analizarla, especialmente si tiene una gran arquitectura tradicional para administrar. Es un patrón de diseño que parece tener sentido para la empresa. Pero, vale la pena señalar: esta no es una razón para EVITAR Node.js, sino una razón para usarlo para un propósito específico.
Jack Stone
44
-1: poner un proxy (como nginx) delante del nodo es un caso de uso perfecto y en realidad es mucho más seguro y eficaz en algunos casos que no tener uno en absoluto. No vence a ningún beneficio de nodo. Tiendo a ejecutar mis aplicaciones de nodo en sockets de dominio Unix, y luego hago que nginx actúe como un guardián.
Scott Anderson
3

Una buena razón para tener dudas acerca de los nodos no es técnica: es genial y sorprendente en lo que hace.

Son negocios y específicamente capital humano, es decir, programadores que lo saben, cuánto cuestan y su disponibilidad. No es tan difícil de aprender, pero como con cualquier tecnología más nueva, el número de personas que lo conocen bien (o quieren) es una subestimación de los grupos más grandes de trabajadores.

Michael Durrant
fuente
así que piensas que no hay mucho en contra de usar Node en lugar de pilas de aplicaciones más tradicionales; los problemas tienen más que ver con las preocupaciones del mundo real?
Paul d'Aoust
+1. Recursos humanos, y la falta de voluntad de algunos para aprender JavaScript, es una verdad incómoda. Esta respuesta lo dice bien. Pero, evitar Nodo "porque la gente odia JavaScript" tampoco es la progresión lógica. ¿Dónde estaríamos técnicamente si evitáramos toda innovación que alguien más odiara? En ninguna parte. El desafío con el nodo es A) Obtener nuevo talento, o B) Educar el talento tradicional en nuevo talento. Hasta ese punto, estamos viendo escuelas de código JavaScript en todas partes desde la previsión de John Resig en la fundación de Khan Academy. En resumen, este es el camino de las cosas. +1. Bien dicho
Jack Stone
3

Esta es una muy buena pregunta que debemos hacernos para avanzar demasiado en el estado del arte.

Tenía mucha curiosidad por saber (como Paul d'Aoust) dónde existen las limitaciones de Node.JS. Lamentablemente, muchas respuestas están COMPLETAS de sesgos subjetivos y razones temporalmente relevantes.

Me pregunté: ¿PODEMOS FILTRAR BIAS SUBJETIVAS Y OBTENER RESPUESTAS SÓLIDAS A ESTA PREGUNTA RELEVANTE?

Los puntos restantes parecen ser:

1. NodeJS no es tan maduro como los marcos tradicionales. Como sugiere Paul d'Aoust, esta es solo una razón temporalmente relevante, no para evitarla por completo, sino para su revisión y diligencia debida. Se espera que hagamos nuestra tarea como profesionales de la web, y es nuestro trabajo determinar el mejor ajuste de la tecnología para la organización, sus necesidades, su futuro, el equipo (y no nosotros). La madurez es una necesidad de aclaración y un juicio de apetito por el riesgo, pero no de evasión.

2. NodeJS como servidor proxy. Una sugerencia sabia, de discusión previa, que vale la pena revisar y considerar. Es la noción de usar Node en correlación con las tecnologías existentes como un patrón de diseño de proxy de interfaz front-end. Pero también, no es una razón para EVITAR el uso del nodo, sino una razón para evitar usarlo como un reemplazo completo. En lugar de optar por un enfoque corolario

3. Nodo de depuración. En una conversación con los desarrolladores del Nodo central en Joyent, hay muchas complicaciones en torno a la depuración y el rastreo de la causa raíz de los problemas resultantes del núcleo (basado en la ejecución de un solo hilo y la incapacidad de ver en los hilos del pasado). Vale la pena considerarlo y evaluarlo, pero (de nuevo) probablemente no sea aversión por el uso común, solo casos extremos que pueden empujar el sobre. Tal vez sus necesidades específicas caerían en esta categoría y tal vez no.

4. Recursos humanos. Esta es la mejor razón para EVITAR el uso de JS en esta página y, en mi humilde opinión, es una verdad cruda e inconveniente. Se plantea la pregunta: ¿ tiene su empresa los profesionales talentosos adecuados a la mano para ver el proyecto a través del ciclo de vida completo? Si no, no hay duda de que debe evitar NodeJS. O, en su lugar, considere A) localizar el talento correcto, o B) Educar el talento existente.

Quejas: Mi observación de las quejas en JavaScript es que muchas resultan más del Error del usuario que de fallas consistentes del lenguaje. Hemos desacreditado muchos reclamos contra "The Hate JavaScript Diatribe" y continuaremos desacreditando muchos más. Problemas como: la documentación no es lo suficientemente buena, no es lo suficientemente sexy, pero a la gente no le gusta, es cáncer, es el demonio o es demasiado "propensa a los errores tipográficos" (-Crichardson), son subjetivos y quejas sesgadas que deben ser eliminadas para la toma de decisiones corporativas precisas.

Al final, la respuesta correcta puede ser: no hay buenas razones para EVITAR NodeJS . Quizás es por eso que está experimentando un rápido crecimiento, adopción y contribución. Pero para todos nosotros, tal vez la respuesta aquí es continuar evaluando, investigando y entendiendo mejor NodeJS, y buscando aversiones concretas. En la búsqueda de estar abiertos a comprender exactamente dónde Node.JS es inmaduro, encontramos exactamente dónde necesitamos mejorarlo. Y eso es una bendición.

Buena pregunta. Por mi parte, sigo siendo curioso de que alguien mencione una mejor razón para evitar NodeJS, que estas.

Jack Stone
fuente
-1

¿Hay algún beneficio de usar el nodo sobre X para aplicaciones que no son en tiempo real?

  • Escalado : el nodo tiene un buen rendimiento, pero otras plataformas también; PHP, Ruby, Python y Java todos escalan. Puede encontrar GRANDES nombres con millones de usuarios que los están utilizando.
  • Un lenguaje para frontend y backend : es una broma, al igual que "Escribe una vez ejecutado en cualquier lugar" de Java
  • Caliente y sexy : el único punto válido. ¡Pero a nadie le importa que su sitio web esté usando tecnología vanguardista!

Beneficio de usar X sobre Nodo para aplicaciones que no son en tiempo real:

  • Mejor práctica : debido a que Node es nuevo, tiene menos mejores prácticas que otras plataformas, especialmente para aplicaciones web CRUD.
  • Lenguaje Javascript : a la gente no le gusta Javascript. Mientras Node.js está activo, Javascript no lo está. Esta es la razón por la cual las personas crearon Coffeescript para evitar escribir Javascript incluso para el lado del cliente.
  • Velocidad de desarrollo : los marcos antiguos y aburridos, incluidos, entre otros, Rails y Django, están bien probados y mejorados durante muchos años para los sitios web de CRUD. Si bien puede implementar aplicaciones similares en Node, es más fácil hacerlo en el marco de trabajo de su abuelo.
  • Estabilidad : los marcos web de Node están mejorando a un ritmo más rápido. Significa que están cambiando y tendrán más incompatibilidad de API en el futuro cercano.
  • Bibliotecas y herramientas : las tecnologías más antiguas con más usuarios tienen más bibliotecas y herramientas.

Mi respuesta definitivamente no será válida en 2015. En 2014, omita Node para aplicaciones web que no sean en tiempo real, pero esté atento.

Cada marco web tiene un punto fuerte. Serás feliz mientras lo usas para ese punto. Las aplicaciones web que no son en tiempo real no son el punto fuerte de los marcos web de Node.

Hossein
fuente
2
-1. Estoy de acuerdo en que esta respuesta no será válida en 2015. Pero eso también es motivo de rechazo. En esencia, las decisiones de hoy SON las decisiones de mañana. Anula los 8 puntos anteriores, si podemos ver que solo son temporalmente relevantes. 1) Escalado: las escalas de Walmart Mobile no son una razón para evitar Nodo. 2) Isomorphic JS no es broma. No es un motivo 3) servidor sexy? La mayoría de los usuarios solo conocen ux. 4) La mejor práctica es subjetiva, 5) ¿No está de moda? -subjetivo 6) ¿Más fácil? -subjetivo. 7) La estabilidad es un punto temporalmente relevante. 8) NPM proyectado para pasar Maven en 2014. No hay razones aquí. Voto a favor.
Jack Stone
-1

Node.js es una plataforma muy popular y tiene muchas características interesantes, bla, bla, bla, pero el uso de una herramienta es una preferencia personal. Le di a Node.js cuatro veces y no estaba contento con eso. Aquí están mis razones. Tenga en cuenta que algunas de esas razones están desactualizadas o simplemente son personales: P

  • Preferí diferentes idiomas / sintaxis (me gusta Python, Scala, mi idioma favorito es Prolog, así que sí).
  • La calidad de la documentación para frameworks y bibliotecas que utilicé no es tan buena para las bibliotecas Java, Scala y Python.
  • Los diseñadores de los nodejs están bastante obsesionados con las devoluciones de llamada en lugar del modelo de evento, el observador o los futuros.
  • Hay soluciones listas para lo que quiero hacer en Ruby, Python, Java desarrollado en 2005, solo necesito editar el archivo de configuración.
David Sergey
fuente
2
-1 - Puntos subjetivos. "Sintaxis preferida", "Documentación no tan buena", "Devolución de llamada obsesiva" y "Ya se hizo en mi idioma" - son todos vagos y subjetivos. Hemos escuchado esto antes. Están desacreditados. No hay razón para evitar Node.JS aquí. Voto a favor.
Jack Stone
1
Todos los puntos son mi preferencia personal, que dije abiertamente. Además, ¿cómo desacreditar la preferencia personal?
David Sergey
-9

HTTP no tiene estado, por lo que en realidad no existe una aplicación web que no sea en tiempo real y, por lo tanto, no hay razón para que no pueda usar el nodo para todo.

Dicho esto, el nodo es más adecuado para un tipo particular de arquitectura de aplicación. PHP es archivos html que contienen un poco de código. El nodo es un código que opcionalmente contiene un poco de html.

Esto significa que si su aplicación tiene formularios html estándar sin ningún script del lado del cliente, PHP será más fácil. Node tiene herramientas de plantillas, pero obviamente no es tan maduro como algo como PHP.

Si tiene muchos scripts del lado del cliente y guarda los datos con ajax, terminará con un cliente estático html que llama a funciones en el servidor. Esto es exactamente en qué nodo es bueno. Si bien no es la forma en que generalmente se crean las aplicaciones CRUD, puede producir algo bastante bueno con el marco adecuado.

Tom Clarkson
fuente
Punto tomado sobre HTTP sin estado y tiempo real-ish; Sin embargo, estoy más interesado en las preocupaciones pragmáticas sobre la definición típica de tiempo real: grandes volúmenes de solicitudes de bajo peso. Parece un poco exagerado girar una nueva instancia de PHP solo para arrojar tres o cuatro líneas de JSON a veces. ¿Estoy en lo cierto o solo estoy sufriendo el síndrome del loro?
Paul d'Aoust el
Si no está cargando PHP, está cargando javascript, y hay varios tipos de almacenamiento en caché involucrados, por lo que la diferencia no será suficiente para preocuparse. La gran diferencia está en el estilo de codificación y, por lo tanto, en el mantenimiento: ambas plataformas pueden generar HTML o JSON, pero PHP fue diseñado para personas acostumbradas a editar archivos html estáticos, mientras que el nodo fue diseñado para personas acostumbradas a la programación moderna de JavaScript.
Tom Clarkson el
Sé que tengo que cargar un intérprete en algún momento, pero veo un beneficio de tener una instancia del intérprete ejecutándose todo el tiempo (para aplicaciones con poca CPU, por supuesto) como en Node.js en lugar de hacer que los intérpretes giren arriba y termina con cada solicitud, como en PHP.
Paul d'Aoust el
Sí, y también esperaría que js tuviera un mejor rendimiento en un nivel de solicitud individual dada la cantidad de competencia en ese espacio recientemente. Sin embargo, creo que es una parte relativamente menor de la diferencia: con el nodo tiene control directo y exactamente la cantidad de código necesaria para atender la solicitud, mientras que cualquier sistema basado en plantillas que asume que está sirviendo páginas agregará una sobrecarga innecesaria y complejidad en otros escenarios
Tom Clarkson el