javascript - Diferencias entre Narwhal y Node.js?

rhino

Question

Soy nuevo en Node.js y he estado leyendo sobre Narwhal que es un framework basado en Rhino.

Mis preguntas:

1. Si estoy usando Node.js, ¿podría usar Narwhal y sus bibliotecas / módulos?
2. ¿No están bloqueadas las bibliotecas / módulos en Narwhal IO (por qué Node.js obtuvo esta gran popularidad)?
3. ¿Node.js es solo para crear servidores web o es para crear aplicaciones generales, al igual que Narwhal?

Answer 1

1. Si está utilizando Node o Narwhal, solo use paquetes y módulos que anuncien la compatibilidad con su motor respectivo. Actualmente hay muchos matices para escribir aplicaciones, paquetes y módulos que funcionan en ambos motores. Kris Zyp de Dojo ha hecho un gran esfuerzo para que sus paquetes funcionen en ambos sistemas y no puedo pensar en nadie más.

2. Los módulos de entrada y salida de Narwhal son bloqueantes, al igual que las bibliotecas estándar para Python, Ruby, Perl, C, Java, etc.

   Sin embargo, hay una clase de aplicaciones que no se pueden escribir eficazmente con IO bloqueante, como juegos que mantienen su estado en la memoria del servidor y comunicación con numerosos clientes. Solo la experimentación puede revelar si los threads o los bucles de eventos funcionan mejor para aplicaciones individuales. Pero, además, es difícil y peligroso escribir aplicaciones "evented" en la mayoría de los lenguajes de programación y ecosistemas de bibliotecas porque los beneficios de usar IO sin bloqueo se pueden obviar rápidamente al usar cualquier IO de bloqueo, y el bloqueo de IO se oculta con frecuencia en el capas de arquitectura, incluso tan bajas como la interfaz del sistema operativo. Nodo es emocionante porque está creando un ecosistema con IO estrictamente asíncrona, lo que lo convierte en el primer sistema en el que esta clase de aplicación es razonablemente fácil de escribir.

   Los proponentes como Doug Crockford y Mark Miller argumentan que la programación asincrónica de bucles de eventos es la forma en que deberían escribirse la mayoría de las aplicaciones porque es más fácil razonar acerca del flujo de datos, concurrencia y seguridad en estos sistemas y componer ciegamente dichos subsistemas sin comprometer la corrección o integridad.

   Sin embargo, si desea aprovechar JavaScript como un lenguaje pero no desea comprar la complejidad adicional de la programación de bucle de eventos, Narwhal está diseñado para funcionar tanto en JavaScriptCore, el rápido motor de JavaScript detrás de Safari, como en Rhino. El uso de Rhino le da acceso a App Engine de Google. Narwhal fue diseñado para darle flexibilidad de su motor JavaScript, pero no tuvo en cuenta el modelo IO de Node. Narwhal también se usa ampliamente en el ecosistema de software 280 North, para herramientas de compilación y servidores para aplicaciones Cappuccino Objective-J, como Jake y Jack.

3. Tanto Node como Narwhal se pueden usar para aplicaciones generales y servidores web. Nodo es especialmente adecuado para clientes y servidores de red. Narwhal es especialmente adecuado para los programas estilo Unix y JSGI, servidores web similares a CGI, y está diseñado para ejecutar aplicaciones JSGI en una variedad de servidores web sin alteración.

Escribir aplicaciones que funcionen tanto en Narwhal como en Node es difícil pero posible. Escribir "paquetes" que funcionen para Narwhal y Node es posible, pero debe hacerse deliberadamente. Si un paquete no anuncia que ha sido diseñado y probado tanto en Narwhal como en Node, puede apostar que solo funcionará en uno u otro.

io: los módulos que no hacen uso de subsistemas IO, como analizadores, formateadores, codificadores y decodificadores, son particularmente adecuados para compartir códigos entre Narwhal y Node.

paquetes: existen diferencias en la forma en que se distribuyen los paquetes para NPM (Node Package Manager) y Tusk (administrador de paquetes de Narwhal). Ambos usan package.json, pero las "dependencias" tienen diferentes significados en cada uno. Hay un parche próximo para Narwhal que le permite tolerar esta inconsistencia. Cuando los paquetes se instalan en Narwhal, todos comparten el mismo espacio de nombre del módulo, como Ruby. Con NPM, cada paquete tiene un subárbol del espacio de nombre del módulo con el mismo nombre que el paquete.

módulos: Node y Narwhal ambos proporcionan extensiones variables a la especificación del módulo CommonJS.

1. El nodo proporciona variables gratuitas adicionales como __dirname .
2. El nodo permite que el objeto de exportación se reasigne con module.exports = x .
3. Narwhal proporciona require.once(id, scope) para ejecutar un módulo una vez (independientemente de si se ha cargado previamente) con variables adicionales gratuitas en el alcance (a veces se denominan erróneamente "globales").
4. El nodo no proporciona el módulo module.path . module.path para el nombre de archivo del módulo actual.
5. Narwhal y Node proporcionan sistemas incompatibles para extender el cargador de módulos para manejar idiomas alternativos para módulos, como CoffeeScript y ObjectiveJ.

Answer 2

Node.js no se debe comparar con Narwhal, sino que se debe comparar con Rhino. Al igual que Rhino, Node.js es un intérprete de JavaScript.

Node.js se ajusta a la especificación CommonJS para módulos, por lo que todas las bibliotecas son compatibles con CommonJS. Parece que Narwhal también es compatible con CommonJS, lo que significa que podrían usarse en Node.

Pero primero veamos los módulos estándar de Node ya que parece que hay mucha coincidencia con Narwhal. Además, eche un vistazo a la lista de módulos de terceros disponibles para Node.js: http://github.com/ry/node/wiki/modules

Respuesta adicional:

Ah, ya veo. Narwhal es realmente como el Nodo. Dijiste que Narwhal es un marco que me echó. Ahora veo que no es así. De hecho, la página de introducción dice que puedes ejecutar frameworks como Nitro encima del intérprete de Narwhal.

La diferencia entre Narwhal y Node es básicamente que Narwhal usa una arquitectura de motor javascript conectable, mientras que Node solo usa V8. Ambos son javascript "shells" propiamente dicho (vamos a llamarlos así por ahora para evitar confusiones con el término "intérprete").

No estoy seguro de hasta qué punto se pueden tomar las bibliotecas CommonJS escritas para cualquiera de las plataformas y usarlas en la otra plataforma. Supongo que ciertamente todas las libs JS puras son compatibles. El nodo utiliza un modelo de E / S sin bloqueo, por lo que es posible que algunos módulos binarios para Narwhal no funcionen correctamente en Node.

Sin embargo, el nodo recalca la programación del estilo de devolución de llamada (para aprovechar al máximo las E / S sin bloqueo). Para un programador experimentado de JS esto no es un problema, ya que estamos acostumbrados a setTimeout() , XMLHttpRequest , etc. De hecho, como un experimentado programador de JS, prefiero el estilo de Node. Narwhal se parece demasiado a C.

Ejemplos:

Esto es lo que quiero decir con la diferente "sensación" de Node sobre Narwhal.

En Narwhal, el ejemplo para sorber un archivo es:

var fs = require("file");
var data = fs.read(myfilename); /* code stops at this point
                                 * until all data is read
                                 */
/* process data here */

En Node.js es:

var fs = require(''fs'');
fs.readFile(myfilename, function(err,data) {
    /* process data here */
});

/* readFile returns immediately and code continues
 * executing while file is being read
 */

Al igual que setTimeout , leer archivos en Node es asincrónico (su código necesita esperar a que el disco duro busque y lea datos y durante ese tiempo puede ejecutar otras partes de código).

Answer 3

Si prefiere el estilo sincrónico de Narhwal, también puede usar mi paquete Common Node , que le permite ejecutar Narwhal sincrónico, RingoJS y otros paquetes compatibles con CommonJS, así como también aplicaciones JSGI en Node.

Answer 4

Solo agregaría RingoJS a la mezcla. Es el sistema CommonJS basado en Rhino, pero en comparación con Narwhal es mucho más maduro (su autor principal ha estado desarrollando su predecesor Helma por años) y al seguir a ambos gits en su desarrollo, RingoJS parece ser mucho más activo. El desarrollo del narval parece ser lento en estos días.