ventajas traversing node funciona framework ejemplo desventajas como change caracteristicas javascript node.js dom v8 headless-browser

javascript - traversing - node js es un framework



¿Por qué Node.js no tiene un DOM nativo? (15)

1) ¿Qué significa que tenga un modelo de objeción de presupuesto? No hay documento para representar.

2) La mayor parte del tiempo no estás recuperando páginas. Puedes, pero la mayoría de las aplicaciones de Nodo probablemente no lo sean.

3) Sin un documento y un navegador, Javascript es solo otro lenguaje de programación. Entonces puede preguntar por qué no hay un DOM en C # o Java

Cuando descubrí que Node.js se creó utilizando el motor de JavaScript V8 , pensé:

Genial, el web scraping será más fácil ya que la página se renderizará como en el navegador, con un DOM "nativo compatible con XPath y cualquier llamada AJAX en la página ejecutada.

  1. ¿Por qué no tiene un DOM nativo cuando usa el mismo motor de JavaScript que Chrome?
  2. ¿Por qué no tiene un modo para ejecutar JavaScript en las páginas recuperadas?
  3. ¿Qué no entiendo acerca de los motores de JavaScript frente al motor en un navegador web?

¡Muchas gracias!

El Document Object Model (DOM en abreviatura) es una interfaz de programación para documentos HTML y XML y representa la página para que los programas puedan cambiar la estructura, el estilo y el contenido del documento. Más sobre este tema.

La distinción necesaria entre el lado del cliente ( navegador ) y el lado del servidor ( Node.js ) y sus principales objetivos:

  • Del lado del cliente: acceder y mostrar información de la web
  • Del lado del servidor: proporcionando formas estables y confiables de entregar información web

¿Por qué no hay DOM en Node.js por defecto?

Por defecto, Node.js no tiene acceso, ni tiene ningún conocimiento sobre el DOM real en su propio navegador. Node.js solo entrega los datos, que serán utilizados por su propio navegador para procesar y renderizar todo el sitio web, el DOM incluido. El servidor proporciona los datos a su navegador para usar y procesar. Esa es la forma prevista.

¿Por qué no quieres acceder al DOM en Node.js?

Acceder al DOM real de su navegador usando Node.js sería simplemente fuera del objetivo del servidor. La función de su propio navegador es mostrar los datos provenientes del servidor. Sin embargo, es ciertamente posible y existen múltiples soluciones en diferentes niveles de profundidades y variedades para preprocesar, manipular o cambiar el DOM mediante llamadas AJAX. Veremos qué traerán las tendencias futuras.

¿Por qué querrías acceder al DOM en Node.js?

De forma predeterminada, no debe acceder a su DOM real (al menos algunos datos) usando Node.js. El lado del cliente y el lado del servidor están separados en términos de rol, funcionalidad y responsabilidad en función de años de experiencia y conocimiento. Aunque hay varias situaciones en las que hay razones sólidas para hacerlo:

  • Recopilación de datos de uso (pruebas A / B, eficiencia UI / UX y comentarios)
  • Pruebas sin cabeza (desarrollo, automatización, raspado web)

¿Cómo se puede acceder al DOM en Node.js?

  • jsdom : implementación pura de JavaScript, buena para probar tu propio proyecto DOM / relacionado con el navegador
  • cheerio : gran solución si te gusta / a menudo usas jQuery
  • puppeteer : la propia forma de Google de proporcionar pruebas sin cabeza con Google Chrome
  • propia solución (su posible enlace de proyecto futuro aquí)

Aunque estas soluciones no proporcionan una forma de acceder al DOM real de su navegador de forma predeterminada , pero puede crear un proyecto para enviar algún tipo de datos sobre su DOM al servidor, luego usar / renderizar / manipular esa información en función de sus necesidades. .

... y sí, el web-scraping y el desarrollo web en términos de herramientas y utilidades se volvieron más sofisticados y ciertamente más fáciles en varios campos.

El DOM es el DOM, y la implementación de JavaScript es simplemente una entidad separada. DOM representa un conjunto de instalaciones que un navegador web expone al entorno de JavaScript. Sin embargo, no hay ningún requisito de que un motor de tiempo de ejecución de JavaScript particular tenga instalaciones expuestas a través del objeto global.

Lo que Node.js es es un entorno JavaScript autónomo completamente independiente de un navegador web. No existe un vínculo intrínseco entre los navegadores web y JavaScript; el DOM no es parte del lenguaje o especificación de JavaScript ni nada.

Utilizo la antigua implementación de JavaScript basada en Java de Rhino en mi servidor web basado en Java. Ese entorno tampoco tiene nada que ver con ningún DOM. Es mi propia aplicación la responsable de poblar el objeto global con instalaciones para hacer lo que necesito que sea capaz de hacer, y no es un DOM.

Tenga en cuenta que hay proyectos como jsdom si desea un DOM virtual en su proyecto Node. Debido a su propia naturaleza como una plataforma del lado del servidor, un DOM es una instalación de la que Node puede prescindir y aún tiene perfecto sentido para una amplia variedad de aplicaciones de servidor. Eso no quiere decir que un DOM no sea útil para algunas personas, pero simplemente no está en la misma categoría de servicios como control de procesos, E / S, redes, interoperabilidad de bases de datos, etc.

Puede haber alguna respuesta "oficial" a la pregunta "¿por qué?" por ahí, pero básicamente es solo el negocio de quienes mantienen Node (la Node Foundation ahora). Si un intrépido desarrollador decide que Node debe enviar de forma predeterminada un conjunto de módulos para admitir un DOM virtual, y funciona y funciona con éxito y lo hace posible, entonces el nodo tendrá un DOM.

El nodo es un entorno de tiempo de ejecución, no representa un DOM como un navegador.

Esto está relacionado: hay un nuevo proyecto (2012) llamado node-webkit que intenta agregar DOM y mucho más de Webkit a Node. ¡Apúntalo!

Javascript! = Navegador. Javascript como un idioma no está vinculado a los navegadores; node.js es simplemente una implementación de Javascript destinada a servidores, no a navegadores. Por lo tanto, no DOM.

Node.js es para la programación en el servidor . No hay DOM para representar en el servidor.

Parece que las personas han respondido ''por qué'' pero no cómo. Una respuesta rápida de cómo es que en un navegador web, un objeto de documento está expuesto (de ahí DOM, modelo de objeto de documento). En Windows, este objeto se llama objeto de documento . Puede consultar esta página y ver los métodos que expone que son para manejar documentos HTML como createElement . No uso node.js o no he hecho programación COM por un tiempo, pero me imagino que podría usar DOM en node.js simplemente llamando al objeto COM IHTMLDocument3 . Por supuesto, para otras plataformas como Mac OS X o Linux, probablemente tenga que usar algo de su API de sistema operativo. Esto debería permitirle crear fácilmente un lado del servidor de página web usando DOM, o para raspar las páginas web entrantes.

Parece que tiene una suposición errónea de que V8 y el DOM están inextricablemente relacionados, ese no es el caso. DOM funciona en realidad con Webkit, V8 no maneja el DOM, maneja llamadas Javascript al DOM. No dejes que esto te desanime, Node.js ha forjado un nicho importante en el mercado de servidores en tiempo real, pero no dejes que nadie te diga que es solo para servidores. Node hace posible construir casi cualquier cosa con JavaScript.

Es posible hacer lo que estás hablando. Por ejemplo, está la muy buena biblioteca jsdom si realmente necesita acceso al DOM, y node-htmlparser , también hay algunas bibliotecas de raspado realmente buenas que aprovechan estos como el apricot .

Porque no hay un DOM. DOM significa Document Object Model . No hay ningún documento en el nodo, por lo que no DOM para manipularlo. Eso es definitivamente una cosa del navegador.

Puede usar una biblioteca como cheerio que le proporciona una simple manipulación DOM.

Nodo es el nivel de servidor JavaScript. Es solo el lenguaje aplicado a una API básica del sistema, más parecida a C ++ o Java.

Si lees DOM como ''objetos vinculados inmediatamente accesibles desde mi script'', entonces la respuesta '' sí , pero es muy diferente del conjunto de objetos disponibles del script del documento web''. La razón principal es que el nodo es ''E / S con everencia para V8'', no ''Objetos de árbol HTML para V8''

node.js eligió no incluirlo en su biblioteca estándar. Para cualquier funcionalidad, hay una compensación inevitable entre exhaustividad, escalabilidad y capacidad de mantenimiento.

Eso no significa que no sea potencialmente útil. Existe al menos una implementación jsdom destinada a NodeJS (entre otras implementaciones de CommonJS).

PD: Al leer esta pregunta, también me preguntaba si V8 (node.js está construido sobre esto) tenía un DOM

¿Por qué cuando usa el mismo motor JS que Chrome no tiene un DOM nativo?

Pero busqué en Google y encontré la página de V8 de Google que recita lo siguiente:

JavaScript se utiliza con mayor frecuencia para las secuencias de comandos del lado del cliente en un navegador, por ejemplo, para manipular objetos Document Object Model (DOM). Sin embargo, el DOM no suele ser proporcionado por el motor de JavaScript, sino por un navegador. Lo mismo ocurre con V8: Google Chrome proporciona el DOM. Sin embargo, V8 proporciona todos los tipos de datos, operadores, objetos y funciones especificados en el estándar ECMA.

node.js usa V8 y no Google Chrome .

Del mismo modo, ¿por qué no tiene un modo para ejecutar JS en las páginas recuperadas?

También creo que realmente no lo necesitamos tan mal. Ryan Dahl creó node.js como un hombre (programador único). Tal vez ahora él (su equipo) desarrollará esto, pero yo ya estaba muy sorprendido por la cantidad de código que producía (loco). Quería crear una biblioteca fácil / eficiente sin bloqueo, en la que creo que hizo un excelente trabajo.

Pero, de nuevo, otro desarrollador creó un módulo que es bastante bueno y se desarrolló activamente (hoy) en jsdom .

¿Qué no entiendo acerca de los motores de Javascript frente al motor en un navegador web? :)

Esas son cosas diferentes, como es de esperar, claras de la cita anterior.

Respuesta 2018: principalmente por razones históricas, pero esto puede cambiar en el futuro.

Históricamente, muy poca manipulación DOM se realizó en el servidor. De forma agregada, como otras respuestas aluden, JS stdlib y DOM son bibliotecas separadas: si está utilizando un nodo, por ejemplo, un script de Unix, entonces HTMLElement y NodeList etc., no son realmente relevantes para eso.

Sin embargo, la manipulación del DOM del lado del servidor ahora es una parte muy común de la entrega de aplicaciones web . Los servidores web necesitan comprender la estructura de las páginas y, si se les solicita que rendericen un recurso como HTML, entregan contenido HTML que refleja el estado inicial de una aplicación web. Esto significa que las aplicaciones web se cargan mucho más rápido que si el servidor simplemente entrega una página de código auxiliar y los navegadores luego hacen el trabajo de completar el contenido real. Actualmente, esto se hace con JSDom y similares, pero del mismo modo en que el nodo tiene incorporados objetos de Request y Response , tener funciones DOM mantenidas como parte de stdlib ayudaría con esta tarea.