Qué es Node.js? [cerrado]

Uso Node.js en el trabajo, y encontrar que es muy poderoso. Forzado a elegir una palabra para describir el nodo.js, yo diría "interesante" (que no es un adjetivo puramente positivo). La comunidad es vibrante y creciente. JavaScript, a pesar de sus rarezas puede ser un gran lenguaje para codificar. Y usted repensará diariamente su propia comprensión de las "mejores prácticas" y los patrones de código bien estructurado. Hay una enorme energía de ideas fluyendo hacia Node.js en este momento, y trabajar en él te expone a todos este pensamiento - gran levantamiento de pesas mental.

Nodo.js en producción es definitivamente posible, pero lejos del despliegue "llave en mano" aparentemente prometido por la documentación. Con Nodo.js v0. 6.x, " cluster "se ha integrado en la plataforma, proporcionando uno de los bloques de construcción esenciales, pero mi" producción.js " script sigue siendo ~150 líneas de lógica para manejar cosas como crear el directorio de registro, reciclar trabajadores muertos, etc. Para un servicio de producción "serio", también debe ser preparado para acelerar las conexiones entrantes y hacer todo lo que Apache hace para PHP . Para ser justos, Ruby on Rails tiene este exacto problema. Se resuelve a través de dos mecanismos complementarios: 1) Poner Ruby en Rails / Node.js detrás de un servidor web dedicado (escrito en C y probado al infierno y de vuelta) como Nginx (o Apache / Lighttd ). El servidor web puede servir eficientemente contenido estático, registro de acceso, reescribir URLs, terminar SSL , aplique reglas de acceso y administre varios subservicios. Para las solicitudes que llegan al servicio de nodo real, el servidor web proxy de la solicitud a través. 2) Usando un framework como Unicorn que administrará los procesos de trabajo, los reciclará periódicamente, etc. Todavía tengo que encontrar un Nodo.js serving framework que parece completamente horneado; puede existir, pero aún no lo he encontrado y todavía uso ~150 líneas en mi producción "laminada a mano".js".

Leer frameworks como Express lo hace parece que la práctica estándar es servir todo a través de un nodo jack-of-all-trades.servicio js ... "app.use (express.static (__dirname + '/ public'))". Para servicios y desarrollo de menor carga, probablemente esté bien. Pero tan pronto como intente poner gran carga en su servicio y lo ejecute 24/7, descubrirá rápidamente las motivaciones que empujan a los sitios grandes a tener un código C bien horneado y endurecido como Nginx al frente de su sitio y manejando todas las solicitudes de contenido estático (...hasta que configure un CDN , como Amazon CloudFront )). Para una toma algo humorística y descaradamente negativa sobre esto, ver este tipo .

Nodo.js también está encontrando cada vez más usos no relacionados con el servicio. Incluso si está utilizando algo más para servir contenido web, aún puede usar Node.js como herramienta de compilación, usando módulos npm para organizar tu código, Browserify para unirlo en un único activo, y uglify-js para reducirlo para su implementación. Para tratar con la web, JavaScript es una perfecta impedancia de coincidencia y con frecuencia que hace que sea la ruta más fácil de ataque. Por ejemplo, si desea arrastrarse a través de un montón de cargas útiles de respuesta JSON, debe usar mi módulo underscore-CLI, el cinturón de utilidad de datos estructurados.

Pros / Contras:

• Pro: Para un tipo de servidor, escribir JavaScript en el backend ha sido una "droga de puerta de enlace" para aprender patrones de interfaz de usuario modernos. Ya no temo escribir código de cliente.
• Pro: Tiende a fomentar la correcta comprobación de errores (err es devuelto por prácticamente todas las devoluciones de llamada, molestando al programador para manejarlo; también, async.js y otras bibliotecas manejan el paradigma "fail if any of these subtareas fails" mucho mejor que el código síncrono típico)
• Pro: Algunas tareas interesantes y normalmente difíciles se vuelven triviales, como obtener el estado de las tareas en vuelo, comunicarse entre trabajadores o compartir el estado de la caché
• Pro: Enorme comunidad y toneladas de grandes bibliotecas basadas en un gestor de paquetes sólido (npm)
• Con: JavaScript no tiene una biblioteca estándar. Te acostumbras tanto a importar funcionalidad que se siente raro cuando usas JSON.analizar o algún otro método de compilación que no requiera agregar un módulo npm. Esto significa que hay cinco versiones de todo. Incluso los módulos incluidos en el nodo.js "core" tiene cinco variantes más si no está satisfecho con la implementación predeterminada. Esto conduce a una rápida evolución, pero también cierto nivel de confusión.

Frente a un modelo simple de un proceso por solicitud ( LÁMPARA):

• Pro: Escalable a miles de conexiones activas. Muy rápido y muy eficiente. Para una flota web, esto podría significar una reducción de 10 VECES en el número de cajas requeridas en comparación con PHP o Ruby
• Pro: Escribir patrones paralelos es fácil. Imagine que necesita obtener tres (o N) blobs de Memcached. Haga esto en PHP ... ¿acabas de escribir el código de la ¿la primera gota, la segunda y la tercera? Vaya, eso es lento. Hay un módulo especial PECL para solucionar ese problema específico para Memcached, pero ¿qué pasa si desea obtener algunos datos de Memcached en paralelo con su consulta de base de datos? En Nodo.js, debido a que el paradigma es asincrónico, tener una solicitud web hacer varias cosas en paralelo es muy natural.
• Con: El código asíncrono es fundamentalmente más complejo que el código síncrono, y la curva de aprendizaje inicial puede ser difícil para desarrolladores sin una sólida comprensión de lo que realmente significa la ejecución concurrente. Aún así, es mucho menos difícil que escribir cualquier tipo de código multihilo con bloqueo.
• Con: Si una solicitud de uso intensivo de recursos informáticos se ejecuta durante, por ejemplo, 100 ms, se detendrá el procesamiento de otras solicitudes que se están manejando en el mismo nodo.proceso js ... AKA, cooperativa-multitarea. Esto se puede mitigar con el patrón Web Workers (girando un subproceso para tratar con el tarea costosa). Alternativamente, puede usar un gran número de nodos.los trabajadores de js y solo permiten que cada uno maneje una sola solicitud simultáneamente (todavía bastante eficiente porque no hay un proceso de reciclaje).
• Con: Ejecutar un sistema de producción es mucho más complicado que un modelo CGI como Apache + PHP, Perl, Ruby , etc. Las excepciones no controladas desactivarán todo el proceso, lo que requerirá lógica para reiniciar los trabajadores fallidos (véase cluster). Los módulos con código nativo con errores pueden bloquear el proceso. Cada vez que un trabajador muere, cualquier solicitud que estaba manejando se elimina, por lo que una API con errores puede degradar fácilmente el servicio para otras API cohostadas.

Versus escribir un servicio "real" en Java / C# / C (C? ¿En serio?)

• Pro: Haciendo asíncronos en el Nodo.js es más fácil que hacer thread-safety en cualquier otro lugar y podría decirse que proporciona un mayor beneficio. Nodo.js es, con mucho, el paradigma asíncrono menos doloroso en el que he trabajado. Con buenas bibliotecas, es solo un poco más difícil que escribir código síncrono.
• Pro: No hay errores de multihilo / bloqueo. Es cierto que invierte por adelantado en escribir código más detallado que exprese un flujo de trabajo asíncrono adecuado sin operaciones de bloqueo. Y necesita escribir algunas pruebas y hacer que la cosa funcione (es un lenguaje de scripting y los nombres de variables de digitación gorda solo se capturan en el tiempo de prueba unitaria). PERO, una vez que se pone a trabajar, la superficie de heisenbugs -- extraños problemas que sólo se manifiestan una vez en un millón de carreras that esa superficie es mucho más baja. El Nodo de escritura de impuestos.el código js está fuertemente cargado en la fase de codificación. Entonces tiendes a terminar con código estable.
• Pro: JavaScript es mucho más ligero para expresar la funcionalidad. Es difícil probar esto con palabras, pero JSON , escritura dinámica, notación lambda, herencia prototípica, módulos ligeros, lo que sea ... sólo tiende a tomar menos código para expresar las mismas ideas.
• Con: Tal vez usted realmente, realmente como servicios de codificación en Java?

Para otra perspectiva sobre JavaScript y Node.js, echa un vistazo De Java al Nodo.js, una publicación de blog sobre el nodo de aprendizaje impresiones y experiencias de un desarrollador Java.js.

Módulos Al considerar node, tenga en cuenta que su elección de bibliotecas JavaScript definirá su experiencia. La mayoría de las personas usan al menos dos, un ayudante de patrón asíncrono (Step, Futures, Async), y un módulo JavaScript sugar (Underscore.js).

Helper / JavaScript Sugar:

• Subrayado.js - usa esto. Tan sólo hazlo. Hace que tu código sea agradable y legible con cosas como _.isString () y _.isArray (). No estoy muy seguro de cómo podría escribir código seguro de otra manera. También, para una línea de comandos-fu mejorada, echa un vistazo a mi propio Underscore-CLI.

Patrón asíncrono Módulos:

• Paso - una forma muy elegante de expresar combinaciones de acciones seriales y paralelas. Mi recomendación personal. Ver mi post sobre cómo se ve el código de paso.
• Futuros - mucho más flexible (¿es eso realmente algo bueno?) manera de expresar el pedido a través de los requisitos. Puede expresar cosas como " iniciar a, b, c en paralelo. Cuando A y B finalicen, comience AB. Cuando A y C terminen, comience AC."Tal flexibilidad requiere más cuidado para evitar errores en su flujo de trabajo (como nunca llamar a la devolución de llamada, o llamarla varias veces). Ver El post de Raynos sobre el uso de futuros (este es el post que me hizo "obtener" futuros).
• Async - biblioteca más tradicional con un método para cada patrón. Comencé con esto antes de mi conversión religiosa a step y la posterior realización de que todos los patrones en Async podrían expresarse en Step con un único paradigma más legible.
• TameJS - Escrito por OkCupid, es un precompilador que agrega un nuevo lenguaje primativo "await" para escribir elegantemente flujos de trabajo seriales y paralelos. El patrón se ve increíble, pero requiere pre-compilación. Todavía estoy decidiendo esto.
• StreamlineJS - competidor de TameJS. Me inclino por Domesticar, pero puedes decidirte por ti mismo.

O para leer todo sobre las bibliotecas asíncronas, vea este panel-entrevista con los autores.

Web Marco:

• Express Gran framework Ruby on Rails-esk para organizar sitios web. Utiliza JADE como un motor de plantillas XML/HTML, lo que hace que la construcción de HTML sea mucho menos dolorosa, incluso casi elegante.
• jQuery Aunque técnicamente no es un módulo de nodo, jQuery se está convirtiendo rápidamente en un estándar de facto para la interfaz de usuario del lado del cliente. jQuery proporciona selectores tipo CSS para 'consultar' conjuntos de elementos DOM que luego se pueden operar (controladores de conjuntos, propiedades, estilos, etc). En la misma línea, el framework CSS de Twitter Bootstrap, Backbone.js para un patrón MVC, y Browserify.js para unir todos sus archivos JavaScript en un solo archivo. Todos estos módulos se están convirtiendo en estándares de facto, por lo que al menos deberías echarles un vistazo si no has oído hablar de ellos.

Pruebas:

• JSHint - Debe usar; yo no usé esto al principio que ahora parece incomprensible. JSLint agrega un montón de verificaciones básicas que obtienes con un lenguaje compilado como Java. Paréntesis no coincidentes, variables no declaradas, typeos de muchas formas y tamaños. También puedes activar varias formas de lo que yo llamo "modo anal" donde verificas el estilo de los espacios en blanco y demás, lo cual está bien si esa es tu taza de té but pero el valor real proviene de obtener retroalimentación instantánea sobre el número exacto de línea donde olvidaste un cierre")"... sin tener que ejecutar su código y golpear la línea ofensiva. "JSHint" es una variante más configurable de Douglas Crockford 's JSLint .
• Mocha competidor a los Votos que estoy empezando a preferir. Ambos marcos manejan lo básico lo suficientemente bien, pero los patrones complejos tienden a ser más fáciles de expresar en Mocha.
• Votos Votos es realmente bastante elegante. E imprime un informe encantador (spec spec) que le muestra qué casos de prueba pasaron / fallaron. Dedique 30 minutos a aprenderlo, y puede crear pruebas básicas para sus módulos con el mínimo esfuerzo.
• Zombie - Pruebas sin cabeza para HTML y JavaScript usando JSDom como un "navegador"virtual. Cosas muy poderosas. Combínalo con Replay para obtener pruebas deterministas del código en el navegador a la velocidad del rayo.
• Un comentario sobre cómo" pensar " en las pruebas:
  • Las pruebas no son opcionales. Con un lenguaje dinámico como JavaScript, hay muy pocas comprobaciones estáticas. Por ejemplo, pasar dos parámetros a un método que espera 4 no se romperá hasta que se ejecute el código. Barra bastante baja para crear errores en JavaScript. Las pruebas básicas son esenciales para compensar la brecha de verificación con los idiomas compilados.
  • Olvídese de la validación, simplemente haga que su código se ejecute. Para cada método, mi primer caso de validación es "nada se rompe", y ese es el caso que se activa más a menudo. Probar que su código se ejecuta sin lanzar atrapa el 80% de los errores y hará tanto para mejorar su confianza en el código que te encuentras regresando y agregando los casos de validación matizados que saltaste.
  • Comience poco a poco y rompa la barrera inercial. Todos somos perezosos, y presionados por el tiempo, y es fácil ver las pruebas como "trabajo extra". Así que empieza poco a poco. Write test case 0-cargue su módulo e informe de éxito. Si se fuerzan a hacer precisamente esto, entonces la barrera inercial a las pruebas se rompe. Eso es
  • Ahora evoluciona tus pruebas con tu código. No se deje intimidar por cómo se vería la prueba "correcta" de extremo a extremo con servidores simulados y todo eso. El código comienza simple y evoluciona para manejar nuevos casos; las pruebas también deberían hacerlo. A medida que agrega nuevos casos y nueva complejidad a su código, añadir casos de prueba para ejercer el nuevo código. A medida que encuentre errores, agregue verificaciones y / o nuevos casos para cubrir el código defectuoso. Cuando esté depurando y pierda la confianza en un fragmento de código, regrese y agregue pruebas para demostrar que está haciendo lo que cree que está haciendo. Capture cadenas de datos de ejemplo (de otros servicios que llame, sitios web que raspe, lo que sea) y aliméntelos a su código de análisis. Algunos casos aquí, validación mejorada allí, y usted terminará con altamente confiable codificar.

También, echa un vistazo a la lista oficial del Nodo recomendado.módulos js. Sin embargo, Github's Node Modules Wiki es mucho más completo y un buen recurso.

Para entender el nodo, es útil considerar algunas de las opciones de diseño clave:

Nodo.js es BASADO EN EVENTOS y ASÍNCRONO / SIN BLOQUEO . Eventos, como una conexión HTTP entrante disparará un Función JavaScript que hace un poco de trabajo y pone en marcha otras tareas asíncronas como conectarse a una base de datos o extraer contenido de otro servidor. Una vez que estas tareas han sido iniciadas, la función de evento termina y el nodo.js vuelve a dormir. Tan pronto como sucede algo más, como la conexión de la base de datos que se establece o el servidor externo que responde con contenido, se activan las funciones de devolución de llamada y se ejecuta más código JavaScript, lo que potencialmente inicia aún más tareas asíncronas (como una consulta de base de datos). De esta manera, Nodo.js intercalará actividades para múltiples flujos de trabajo paralelos, ejecutando cualquier actividad que esté desbloqueada en cualquier momento. Esta es la razón Node.js hace un gran trabajo gestionando miles de conexiones simultáneas.

¿Por qué no usar un proceso / hilo por conexión como todos los demás? En Nodo.js, una nueva conexión es solo una asignación de montón muy pequeña. Girar un nuevo proceso toma significativamente más memoria, un megabyte en algunas plataformas. Pero el costo real es la sobrecarga asociada con el cambio de contexto. Cuando tienes 10^6 subprocesos del núcleo, el núcleo tiene que hacer mucho trabajo para averiguar quién debe ejecutar a continuación. Se ha trabajado mucho en la construcción de un programador O(1) para Linux, pero al final, es mucho más eficiente tener un solo proceso impulsado por eventos que 10^6 procesos que compiten por el tiempo de CPU. Además, en condiciones de sobrecarga, el modelo multiproceso se comporta muy mal, hambrientos servicios críticos de administración y gestión, especialmente SSHD (lo que significa que ni siquiera puede iniciar sesión en la caja para averiguar qué tan atornillado está realmente).

Nodo.js es SINGLE THREADEDy LOCK FREE. Nodo.js, como una elección de diseño muy deliberada, solo tiene un solo hilo por proceso. Debido a esto, es fundamentalmente imposible que múltiples subprocesos accedan a los datos simultáneamente. Por lo tanto, no se necesitan cerraduras. Los hilos son duros. Muy, muy duro. Si no crees eso, no has hecho suficiente programación en hilo. Conseguir el bloqueo correcto es difícil y resulta en errores que son realmente difíciles de rastrear. La eliminación de bloqueos y subprocesos múltiples hace que una de las clases más desagradables de errores desaparezca. Esta podría ser la mayor ventaja de node.

Pero, ¿cómo aprovecho mi caja de 16 núcleos?

De dos maneras:

1. Para grandes tareas de cómputo pesadas como codificación de imágenes, Nodo.js puede encenderse procesos secundarios o enviar mensajes a procesos de trabajo adicionales. En este diseño, tendría un subproceso que administra el flujo de eventos y N procesos que realizan tareas de cómputo pesadas y mastican las otras 15 CPU.
2. Para escalar el rendimiento en un servicio web, debe ejecutar varios nodos.servidores js en una caja, una por núcleo, usando cluster (Con Nodo.js v0. 6.x, el módulo oficial "cluster" enlazado aquí reemplaza la versión de learnboost que tiene una API diferente). Estos Nodo local.js los servidores pueden competir en un socket para aceptar nuevas conexiones, equilibrando la carga entre ellos. Una vez que se acepta una conexión, se une estrechamente a uno solo de estos procesos compartidos. En teoría, esto suena mal, pero en la práctica funciona bastante bien y le permite evitar el dolor de cabeza de escribir código seguro para hilos. También, esto significa que el nodo.js obtiene una excelente afinidad de caché de CPU, utilizando más eficazmente el ancho de banda de memoria.

Nodo.js te permite hacer algo realmente poderoso cosas sin sudar. Supongamos que tienes un Nodo.programa js que hace una variedad de tareas, escucha en un puerto TCP para comandos, codifica algunas imágenes, lo que sea. Con cinco líneas de código, puede agregar un portal de administración web basado en HTTP que muestre el estado actual de las tareas activas. Esto es FÁCIL de hacer:

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end(myJavascriptObject.getSomeStatusInfo());
}).listen(1337, "127.0.0.1");

Ahora puede pulsar una URL y comprobar el estado de su proceso en ejecución. Agregue algunos botones y tendrá un "portal de administración". Si tienes una carrera Perl / Python / Ruby script, simplemente "lanzar en un portal de gestión" no es exactamente simple.

Pero no es JavaScript lento / malo / malo / spawn-of-the-devil? JavaScript tiene algunas rarezas extrañas, pero con "las partes buenas" hay un lenguaje muy poderoso allí, y en cualquier caso, JavaScript es el lenguaje en el cliente (navegador). JavaScript está aquí para quedarse; otros idiomas lo están apuntando como un IL, y el talento de clase mundial está compitiendo para producir el más avanzado Motores JavaScript. Debido al papel de JavaScript en el navegador, se está lanzando una enorme cantidad de esfuerzo de ingeniería para hacer que JavaScript sea increíblemente rápido. V8 es el último y mejor motor javascript, al menos para este mes. Sopla lejos los otros lenguajes de scripting en eficacia Y estabilidad (mirándote a ti, Ruby). Y solo va a mejorar con grandes equipos trabajando en el problema en Microsoft, Google y Mozilla, compitiendo para construir el mejor motor JavaScript (Ya no es un "intérprete" de JavaScript, ya que todos los motores modernos hacen toneladas de JIT compilando bajo el capó con interpretación solo como un respaldo para el código execute-once). Sí, a todos nos gustaría poder arreglar algunas de las opciones de lenguaje JavaScript más extrañas, pero realmente no es tan malo. Y el lenguaje es tan flexible que realmente no estás codificando JavaScript, estás codificando Step o jQuery more más que cualquier otro lenguaje, en JavaScript, las bibliotecas definen la experiencia. Construir aplicaciones web, prácticamente tienes que saber JavaScript de todos modos, por lo que codificar con él en el servidor tiene una especie de sinergia de habilidades. Me ha hecho no temer escribir código de cliente.

Además, si realmente odias JavaScript, puedes usar azúcar sintáctico como CoffeeScript. O cualquier otra cosa que cree código JavaScript, como Google Web Toolkit (GWT).

Hablando de JavaScript, ¿qué es un "cierre"? - Más o menos una forma elegante de decir eso conserva variables de ámbito léxico a través de cadenas de llamadas. ;) Así:

var myData = "foo";
database.connect( 'user:pass', function myCallback( result ) {
    database.query("SELECT * from Foo where id = " + myData);
} );
// Note that doSomethingElse() executes _BEFORE_ "database.query" which is inside a callback
doSomethingElse();

¿Ves cómo puedes usar "myData" sin hacer nada incómodo como esconderlo en un objeto? Y a diferencia de Java, la variable" myData " no tiene que ser de solo lectura. Esta poderosa característica del lenguaje hace que la programación asíncrona sea mucho menos detallada y menos dolorosa.

Escribir código asincrónico siempre va a ser más complejo que escribir un simple script de un solo hilo, pero con Nodo.js, es no es mucho más difícil y obtiene muchos beneficios además de la eficiencia y la escalabilidad a miles de conexiones simultáneas...

V8 es una implementación de JavaScript. Le permite ejecutar aplicaciones JavaScript independientes (entre otras cosas).

Nodo.js es simplemente una biblioteca escrita para V8 que hace evented I / O. Este concepto es un poco más complicado de explicar, y estoy seguro de que alguien responderá con una mejor explicación que Yo... Lo esencial es que en lugar de hacer alguna entrada o salida y esperar a que suceda, simplemente no esperar a que termine. Por ejemplo, pregunte por la última hora editada de un archivo:

// Pseudo code
stat( 'somefile' )

Eso podría tomar un par de milisegundos, o podría tomar segundos. Con evented I / O simplemente activa la solicitud y, en lugar de esperar, adjunta una devolución de llamada que se ejecuta cuando finaliza la solicitud:

// Pseudo code
stat( 'somefile', function( result ) {
  // Use the result here
} );
// ...more code here

Esto lo hace muy parecido al código JavaScript en el navegador (por ejemplo, con la funcionalidad de estilo Ajax).

Para obtener más información, debe consultar el artículo Nodo.js es realmente emocionante que fue mi introducción a la biblioteca / plataforma... Me pareció bastante bueno.

Nodo.js es una herramienta de línea de comandos de código abierto construida para el código JavaScript del lado del servidor. Usted puede descargar un tarball, compilar e instalar el código fuente. Le permite ejecutar programas JavaScript.

El JavaScript es ejecutado por el V8, un motor de JavaScript desarrollado por Google que se utiliza en el navegador Chrome. Utiliza una API JavaScript para acceder a la red y al sistema de archivos.

Es popular por su rendimiento y la capacidad de realizar en paralelo operación.

Entendiendo el nodo.js es la mejor explicación del nodo .js He encontrado hasta ahora.

Los siguientes son algunos buenos artículos sobre el tema.

• Aprendizaje de JavaScript del lado del servidor con Node.js
• Esta Vez, Aprenderás Nodo.js

Los cierres son una forma de ejecutar código en el contexto en el que se creó.

Lo que esto significa para la concurrencia es que puede definir variables, luego iniciar una función de no bloqueo E/S y enviarle una función anónima para su devolución de llamada.

Cuando la tarea está completa, la función callback se ejecutará en el contexto con las variables, este es el cierre.

La razón por la que los cierres son tan buenos para escribir aplicaciones con E / S sin bloqueo es que es muy fácil de administrar el contexto de las funciones que se ejecutan de forma asíncrona.

Dos buenos ejemplos son con respecto a cómo administrar las plantillas y usar mejoras progresivas con ellas. Solo necesita algunas piezas ligeras de código JavaScript para que funcione perfectamente.

Le recomiendo encarecidamente que vea y lea estos artículos:

• Nodo de vidrio de vídeo
• Nodo.js YUI DOM manipulation

Elija cualquier idioma e intente recordar cómo administraría sus plantillas de archivos HTML y qué tenía que hacer para actualizar una single CSS class name in your DOM structure (for instance, a user clicked on a menu item and you want that marked as "selected" and update the content of the page).

Con Nodo.js es tan simple como hacerlo en código JavaScript del lado del cliente. Obtenga su nodo DOM y aplique su clase CSS a eso. Obtenga su nodo DOM e innerHTML su contenido (necesitará algún código JavaScript adicional para hacer esto. Lea el artículo para saber más).

Otro buen ejemplo, es que puede hacer que su página web sea compatible con JavaScript activado o desactivado con la misma pieza de código. Imagine que tiene una selección de fecha realizada en JavaScript que permitiría a sus usuarios recoger cualquier fecha utilizando un calendario. Puede escribir (o usar) la misma pieza de código JavaScript para que funcione con su JavaScript activado o DESACTIVADO.

Hay una muy buena analogía del lugar de comida rápida que mejor explica el modelo de nodo impulsado por eventos.js, ver el artículo completo, Nodo.js, Consultorios Médicos y Restaurantes de Comida Rápida-Entendiendo la Programación impulsada por Eventos

Aquí está un resumen:

Si el restaurante de comida rápida siguiera un modelo tradicional basado en hilos, pedirías tu comida y esperarías en la cola hasta que la recibieras. La persona detrás de usted no sería capaz de ordenar hasta que su orden se hizo. En un modelo impulsado por eventos, usted pide su comida y luego salirse de la fila para esperar. Todos los demás son libres de ordenar.

.js está basado en eventos, pero la mayoría de los servidores web están basados en subprocesos.York explica cómo Nodo.js funciona:

• Usted utiliza su navegador web para hacer una solicitud de " / about.html" en un Nodo.servidor web js.

• El Nodo.el servidor js acepta su solicitud y llama a una función para recuperar ese archivo del disco.

• Mientras que el Nodo.servidor js está esperando a que el archivo se recupere, se servicios la siguiente solicitud web.

• Cuando se recupera el archivo, hay una función de devolución de llamada que es insertado en el Nodo.cola de servidores js.

• El Nodo.js server ejecuta esa función que en este caso sería renderiza el " / about.html " y enviarlo de vuelta a su navegador web."

Bueno, Entiendo que

• El objetivo del nodo es proporcionar una manera fácil para construir programas de red escalables.
• Node es similar en diseño e influenciado por sistemas como la Máquina de eventos de Ruby o el Twisted de Python.
• E/S evented para javascript V8.

Para mí eso significa que tenías razón en las tres suposiciones. ¡La biblioteca parece prometedora!

Además, no se olvide de mencionar que V8 de Google es MUY rápido. En realidad, convierte el código JavaScript en código máquina con el rendimiento coincidente del binario compilado. Así que junto con todas las otras grandes cosas, es increíblemente rápido.

Q: El modelo de programación está impulsado por eventos, especialmente la forma en que maneja E/S.

Correcto. Utiliza devoluciones de llamada, por lo que cualquier solicitud para acceder al sistema de archivos causaría que una solicitud se enviara al sistema de archivos y luego al nodo.js comenzaría a procesar su siguiente solicitud. Solo se preocuparía por la solicitud de E/S una vez que reciba una respuesta del sistema de archivos, momento en el que ejecutará el código de devolución de llamada. Sin embargo, es posible realizar solicitudes de E/S síncronas (es decir, bloquear peticiones). Depende del desarrollador elegir entre asíncrono (callbacks) o síncrono (en espera).

Q: Utiliza JavaScript y el analizador es V8.

Sí

P: Se puede usar fácilmente para crear aplicaciones de servidor concurrentes.

Sí, aunque tendría que codificar a mano bastante JavaScript. Podría ser mejor mirar un marco, como http://www.easynodejs.com / - que viene con documentación completa en línea y una aplicación de ejemplo.