Recientemente , el Nodo 12 recibió el nombre en código Erbium , cuyo soporte a largo plazo (LTS) durará de octubre de 2019 a abril de 2022.
La nueva versión tiene muchas ventajas y mejoras para el tiempo de ejecución. Además, dado que bajo el capó del V8, el nodo también recibirá todas las mejoras del motor.
Soporte de import/export
El nodo ingresa a la fase 3 en el camino a los módulos ECMAScript . Inicialmente, esta función solo estaba disponible con el --experimental-modules . Para cuando Node cambie a LTS, se planea eliminar la necesidad de usar este indicador.
La sintaxis que usa import/export vuelto preferible cuando se trabaja con módulos de desarrolladores js desde la estandarización en ES6, y el equipo detrás de Node trabajó diligentemente en soporte nativo. Esta característica estaba disponible experimentalmente con el Nodo 8.0 de la fase 0. El lanzamiento actual es un gran paso en esa dirección. Los navegadores más populares ya admiten esta función con <script type="module"> .
A partir de la fase 3, habrá soporte para tres opciones de import de modelos ES:
Los módulos Vanilla solo se pueden exportar de la manera predeterminada:
import module from 'cjs-library'
Puede usar import() para cargar en tiempo de ejecución. import() devuelve Promise y funciona con modelos ES y bibliotecas CommonJS.
V8
El nodo 12 se ejecutará inicialmente en V8 7.4 y eventualmente se actualizará a 7.6. El equipo V8 acordó proporcionar una ABI (interfaz binaria de aplicación). Las mejoras notables en V8 7.4 son mejoras de rendimiento para una ejecución de JavaScript más rápida, una mejor administración de memoria y un soporte mejorado de sintaxis ECMAScript.
Rastros de pila asíncrona
Veamos este código:
async function testAsyncStacktrace() { await killme(); return 42; } async function killme() { await Promise.resolve(); throw new Error('#Feelsbadman'); } testAsyncStacktrace().catch(error => console.log(error.stack));
En versiones anteriores, obtendrá algo como esto:
Error: #Feelsbadman at killme (test.js:8:11) at process._tickCallback (internal/process/next_tick.js:68:7) at Function.Module.runMain (internal/modules/cjs/loader.js:721:11) at startup (internal/bootstrap/node.js:228:19) at bootstrapNodeJSCore (internal/bootstrap/node.js:576:3)
Como puede ver, el mensaje no menciona testAsyncStacktrace . Y ahora el --async-stack-traces está habilitado de manera predeterminada, y el registro se verá así:
Error: #Feelsbadman at killme (test.js:8:11) at async testAsyncStacktrace (test.js:2:5)
Llamada acelerada cuando el número de argumentos no coincide
En JavaScript, es perfectamente aceptable llamar a funciones con menos / más argumentos (es decir, pasar menos o más parámetros formales declarados). En el primer caso es una aplicación insuficiente , y en el segundo es una aplicación excesiva . En el caso de una cantidad insuficiente de argumentos, los parámetros estarán undefined , mientras que en el caso de una gran cantidad de parámetros simplemente se ignorarán.
Sin embargo, las funciones de JavaScript aún pueden obtener los parámetros reales utilizando los arguments , el objeto de parámetros de reposo o incluso utilizando los Function.prototype.arguments no estandarizados en funciones de modo descuidado . Como resultado, los motores de JavaScript deberían proporcionar una forma de obtener los parámetros reales. En V8, esto se hace utilizando la técnica de adaptación de argumentos . Desafortunadamente, tales métodos afectan el rendimiento.
En algunos escenarios, V8 omite completamente la adaptación de argumentos , reduciendo la sobrecarga de llamadas hasta en un 60%.
Los detalles se pueden encontrar en el documento .
Análisis acelerado
En Chrome, las secuencias de comandos lo suficientemente grandes se analizan en secuencias en subprocesos de trabajo durante su carga. V8 7.4 solucionó el problema con el rendimiento de decodificación UTF-8, lo que condujo a una aceleración del 8%.
Cada caída en el diagrama representa una de las mejoras de rendimiento en el analizador de flujo.
Mejora await
Junto con el --async-stack-traces , el indicador --async-stack-traces --harmony-await-optimization ahora está habilitado de forma predeterminada. Detalles aquí
Campos de clases privadas
La capacidad de usar campos privados en V8 ha migrado al nodo. Dichos campos no están disponibles fuera de la clase. Para crearlos, debe especificar # antes de la variable.
class HelloThere { #hidden = 'Hidden'; get hidden() { return this.#hidden; } set hidden(txt) { this.#hidden = txt; } hi() { console.log(`Hello, ${this.#hidden}`); } }
Cuando intentas acceder a #hidden desde el exterior, obtienes un error de sintaxis.
const hello = new HelloThere(); hello.#hidden = 'Visible';
Inicio rápido
El nodo 12 usará el caché para las bibliotecas integradas antes de compilar e incrustar como binarios. Debido al uso de este caché en el hilo principal, el tiempo de inicio se reducirá en un 30%.
TLS y seguridad
Noda ahora es compatible con TLS 1.3, que ofrece seguridad mejorada y reduce la latencia. TLS 1.3 ha cambiado mucho el protocolo y se está integrando activamente en la red. La introducción de TLS 1.3 aumentará la confidencialidad de los datos del usuario, y acelerará el procesamiento de solicitudes al reducir el tiempo de comunicación en HTTPS. Además, TLS 1.0 y 1.1 están deshabilitados de forma predeterminada, y los métodos obsoletos se eliminaron de la crypto .
Tamaño dinámico de cadera
Anteriormente, se usaba el tamaño de almacenamiento dinámico V8 predeterminado de 700 MB (sistemas de 32 bits) o 1400 MB (sistemas de 64 bits). Ahora el nodo determinará los tamaños de almacenamiento dinámico en función de la memoria disponible para optimizar los recursos utilizados de la máquina.
La capacidad de volcar la cadera
El nodo 12 proporciona la capacidad de volcar montones, lo que facilita la detección de problemas de memoria. Los detalles se pueden encontrar aquí y aquí .
Informes de diagnóstico experimental.
Noda ofrece herramientas más potentes para diagnosticar problemas (rendimiento, uso de CPU, memoria, bloqueos, etc.) directamente dentro de la aplicación, proporcionando una función experimental para informes.
Mejoras al trabajar con módulos nativos
El nodo 12 continúa la tendencia hacia la simplificación del trabajo con la N-API . Esta versión ha mejorado el soporte, en particular cuando se trabaja con subprocesos de trabajo.
Conclusión
El nodo 12 tiene muchas mejoras. El CHANGELOG completo se puede ver en Github y en el sitio mismo.