Es un poco difícil de decir porque estas palabras no están bien definidas. En términos comunes, creo que es un poco atípico llamar a Node.js como marco, claro, pero me sería difícil discutir por qué exactamente no lo es.
Todo esto se vuelve incierto, y a menudo veo usos muy pobres del lenguaje, así que seré explícito y comenzaré desde abajo
JavaScript es un lenguaje informático, es decir, en sentido estricto, un conjunto de convenciones que nos permiten leer e interpretar un montón de texto con semántica de ejecución, una palabra elegante para "forma de interpretar el lenguaje como un conjunto de instrucciones". Las clases de programas llamados intérpretes , compiladores , transpilers , borra de , marcadores , etc., todo texto toma en y tratar de hacer algo con esta comprensión convencional de la forma de ejecutar el código.
- Los intérpretes realmente realizan la semántica de ejecución operando alguna máquina, generalmente su computadora. Puedes pensar en ellos como un hombrecito dentro de tu computadora que mueve interruptores como "imprime este personaje" según las instrucciones escritas en tu programa JavaScript.
- Los compiladores intentan convertir el texto de JavaScript en un nuevo conjunto de texto que tiene una semántica de ejecución para un idioma diferente, quizás uno con la propiedad especial de que las computadoras pueden ejecutarlo directamente.
- Los compiladores son una forma generalizada de compilador, ya que incorporan texto JavaScript y generan texto de otro idioma. La diferencia es, por lo tanto, un poco subjetiva, pero generalmente se piensa que un compilador genera un código de muy bajo nivel y un transpilador como un código de alto nivel .
- Las linters , los marcadores , los verificadores de tipo , etc. , toman texto de JavaScript y generan algún tipo de producto analítico, texto resaltado, por ejemplo, que está influenciado por la semántica de ejecución, pero no es realmente representativo de él.
Ahora, profundicemos un poco en la semántica de ejecución. En general, la semántica de ejecución implica un proceso de lectura de texto de lenguaje y llegar a una descripción de una máquina abstracta o una descripción de efectos secundarios observables . Lo que me gustaría sugerir es que ambos asumen la necesidad de que haya algún tipo de "API de bajo nivel", ya sea para operar la máquina o para realizar los efectos observables. Estos generalmente se consideran parte del entorno de tiempo de ejecución
- El entorno de tiempo de ejecución o tiempo de ejecución es un conjunto de primitivas asumidas que la convención de lenguaje requiere para existir. En lo que respecta al lenguaje, puede haber alguna suposición sobre su comportamiento, pero son inobservables. En las imágenes del intérprete anterior, el "hombre dentro" simplemente acciona los interruptores del tiempo de ejecución; no puede inspeccionar personalmente lo que están haciendo.
Se suele abusar de la palabra tiempo de ejecución para referirse tanto al conjunto de primitivas asumidas como a una instanciación real de ellas.
Entonces, ahora llegamos a algo peludo. Un lenguaje es un conjunto de convenciones que asume la existencia de un tiempo de ejecución para proporcionar significado a su semántica de ejecución. Nunca "los investiga" ya que están fuera de alcance.
Para utilizar realmente un lenguaje, desea algo como un compilador o un intérprete junto con una implementación en tiempo de ejecución. El compilador / intérprete y este tiempo de ejecución van de la mano en la ejecución de su código.
- El V8 de Chrome , a menudo llamado motor , es un paquete que contiene un intérprete, compilador, implementación de tiempo de ejecución compatible con la interfaz de tiempo de ejecución exigida por las convenciones estándar de JavaScript de ECMA.
Entonces, ¿dónde encaja Node.js en esto?
Tenemos que dividirlo en partes:
- Node.js expande el lenguaje JavaScript al proporcionar un conjunto más amplio de primitivas de entorno de tiempo de ejecución, aquellas que están fuera del alcance de los estándares de ECMA. Estos incluyen cosas como E / S de archivo . Esto significa que Node.js cambia el idioma y, en cierto sentido, es un idioma nuevo: "Node.js JavaScript"
- Node.js, como paquete, contiene un intérprete y un compilador. Simplemente roba estos de V8.
- Node.js proporciona una implementación del entorno de tiempo de ejecución Node.js que permite ejecutar "Node.js JavaScript".
- Node.js proporciona un conjunto de bibliotecas estándar creadas sobre las nuevas primitivas que las hacen más accesibles para los usuarios finales de "Node.js JavaScript".
¡Entonces Node.js es muchas cosas!
¿Pero es un marco?
Aquí es donde la terminología se desmorona totalmente: nadie tiene una definición buena, coherente y significativa de lo que realmente es un marco.
Hay debates que enfurecen: "qué es un marco versus una biblioteca" y terminan en cosas insatisfactorias como "una biblioteca es algo que llamas y un marco es algo que te llama". Ni siquiera quiero dar una explicación tan triste a la luz del día, pero JavaScript, y Node.js JavaScript en particular, es un gran golpe para esta definición, ya que toda la técnica de devolución de llamada significa que está cambiando constantemente entre llamadas y ser llamado
En mi opinión personal, hay algo sustancial aquí. No quiero dibujar una línea brillante, pero simplemente diré
- Un conjunto de código es similar a una biblioteca si funciona como un conjunto de legos : divisible y hecho para ensamblar. Si bien puede haber algunos ejemplos sobre cómo usar la biblioteca, generalmente depende del usuario ensamblarla según sus necesidades.
- Un conjunto de código es similar a un marco si no es divisible e implica convenciones *: separar partes de él puede hacer que muchas suposiciones fallen, por lo que debe comprender el uso convencional para usar un marco correctamente.
Esta es una línea manual, sin duda, pero quiero extraer un punto realmente interesante sobre los marcos:
Los marcos implican un conjunto de convenciones sobre cómo interpretar el código; son, por lo tanto, un idioma por derecho propio.
Esto podría ser algo sobre lo que la gente también quiera discutir, pero si compró mi definición anterior de que un lenguaje es solo un conjunto de convenciones que dan vida a un bloque de texto, entonces cada vez que establece una nueva capa de convenciones, usted ' He construido un nuevo lenguaje. Quizás con los frameworks las materias primas son las interpretaciones semánticas de su lenguaje anfitrión en lugar de los archivos de texto sin procesar, ¡pero la idea es la misma!
Entonces, con todo lo dicho, ¡estoy totalmente feliz de llamar a Node.js un framework incluso si va un poco en contra de la norma! Node.js agrega funcionalidad a JavaScript sin formato en la forma de expandir el lenguaje . Con esto trae nuevas suposiciones y herramientas para trabajar en este lenguaje expandido. Funcionalmente, estas ideas son las mismas que las de otros marcos bien aceptados como Ruby on Rails .
Yo diría que si en este momento te sientes un poco mareado y quieres argumentar que hay una gran división entre Ruby on Rails y Node.js en esta forma de cosas, entonces estoy ahí contigo , por supuesto. El tipo de mundos conceptuales en los que viven los dos es dramáticamente diferente. Simplemente quiero decir que son el mismo tipo de cosas: conjuntos de convenciones para expandir los poderes de un lenguaje base dentro de un dominio particular.
También me complace sugerir que el dominio de Node.js es pequeño y estricto y, por lo tanto, las convenciones que agrega son fáciles de razonar y relativamente fáciles de corregir. OTOH, Ruby on Rails vive en un dominio complejo y mal definido de "aplicaciones web comerciales", lo que significa que las convenciones que establece son ciertamente confusas y rotas.
Pero todo esto es un largo camino para decir, sí, los reclutadores probablemente no tienen idea de lo que quieren decir cuando dicen eso. Supongo que "marco" suena como una palabra mejor y más asimilable que "tiempo de ejecución" o "motor".