Diferencias entre Narwhal y Node.js?

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 utilizar Narwhal y es bibliotecas/módulos?
2. ¿No están bloqueadas las bibliotecas/módulos en Narwhal IO (por qué Node.js obtuvo esta enorme popularidad)?
3. ¿Está Node.js solo para crear servidores web o para crear aplicaciones generales, al igual que Narwhal?

Answer 1

1. Si usa Node o Narwhal, solo use paquetes y módulos que promocionen 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, y así sucesivamente.

   Sin embargo, existe una clase de aplicaciones que no se pueden escribir eficazmente con bloqueo IO, 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.

   defensores como Doug Crockford y Mark Miller sostienen que la programación de bucles de eventos asíncronos es la forma la mayoría de aplicaciones deben ser escritas porque es más fácil de razonar sobre el flujo de datos, concurrencia, y la seguridad en estos sistemas y componer ciegamente estos subsistemas sin comprometer la corrección o integridad.

   Sin embargo, si desea aprovechar JavaScript como idioma 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, y también 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 pueden usarse 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 los subsistemas IO, como analizadores, formateadores, codificadores y decodificadores, son especialmente adecuados para compartir código entre ambos Narwhal y el Nodo.

paquetes: Existen diferencias en la forma en que se organizan 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 diferentes para el CommonJS module specification.

1. El nodo proporciona variables libres 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 CommonJS 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, en su lugar, se debe comparar con Rhino. Al igual que Rhino, Node.js es un intérprete de JavaScript.

Node.js se ajustan a la especificación CommonJS para los 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 mire los módulos estándar de Node, ya que parece que hay mucha coincidencia con Narwhal. También, echar un vistazo a la lista de módulos de 3 ª parte para Node.js:

---

respuesta adicional:

Ah, ahora 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 cuán lejos 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 siente demasiado como C.

---

Ejemplos:

Esto es lo que quiero decir con los diferentes "sensación" del nodo 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, la lectura de archivos en el Nodo es asíncrona (código de su necesidad esperar a que el disco duro busque y lea datos durante los cuales puede ejecutar otras partes de código).

Answer 3

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 durante 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.

Answer 4

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