Jason Orendorff de Mozilla publicó un excelente análisis en profundidad de las peculiaridades sintácticas de JS. Aunque los detalles de implementación difieran, cada motor JS enfrenta los mismos problemas con estas peculiaridades.
En este episodio, profundizaremos en la definición del lenguaje ECMAScript y su sintaxis. Si no estás familiarizado con las gramáticas libres de contexto, ahora es un buen momento para revisar los conceptos básicos, ya que la especificación utiliza gramáticas libres de contexto para definir el lenguaje. Consulta el capítulo sobre gramáticas libres de contexto en "Crafting Interpreters" para una introducción accesible o la página de Wikipedia para una definición más matemática.
Practiquemos un poco más nuestras increíbles habilidades para leer especificaciones. ¡Si todavía no has visto el episodio anterior, ahora es un buen momento para hacerlo!
Una forma divertida de conocer la especificación es comenzar con una característica de JavaScript que sabemos que existe y averiguar cómo está especificada.
¡Advertencia! Este episodio contiene algoritmos copiados de la especificación ECMAScript de febrero de 2020. Eventualmente estarán desactualizados.
Sabemos que las propiedades se buscan en la cadena de prototipos: si un objeto no tiene la propiedad que intentamos leer, subimos por la cadena de prototipos hasta encontrarla (o encontramos un objeto que ya no tiene prototipo).
Por ejemplo:
const o1 = { foo: 99 };
const o2 = {};
Object.setPrototypeOf(o2, o1);
o2.foo;
// → 99
Intentemos averiguar dónde se define este comportamiento. Un buen lugar para comenzar es una lista de Métodos Internos de Objetos.
Existen tanto [[GetOwnProperty]] como [[Get]] — estamos interesados en la versión que no está restringida a propiedades propias, así que iremos con [[Get]].
Desafortunadamente, el tipo de especificación Descriptor de Propiedades también tiene un campo llamado [[Get]], así que mientras navegamos por la especificación en busca de [[Get]], debemos distinguir cuidadosamente entre los dos usos independientes.
o2.foo una AssignmentExpression?o2.foo no parece una AssignmentExpression ya que no hay asignación. ¿Por qué es una AssignmentExpression?
La especificación permite en realidad una AssignmentExpression tanto como argumento como en el lado derecho de una asignación. Por ejemplo:
function simple(a) {
console.log('El argumento fue ' + a);
}
simple(x = 1);
// → Registra “El argumento fue 1”.
x;
// → 1
…y…
x = y = 5;
x; // 5
y; // 5
o2.foo es una AssignmentExpression que no asigna nada. Esto se deduce de las siguientes producciones gramaticales, cada una tomando el caso "más simple" hasta la última:
Una AssignmentExpression no necesita tener una asignación, también puede ser simplemente una ConditionalExpression:
(También hay otras producciones, aquí mostramos solo la relevante.)
Una ConditionalExpression no necesita tener una condicional (a == b ? c : d), también puede ser simplemente una ShortcircuitExpression:
Y así sucesivamente:
ShortCircuitExpression : LogicalORExpression
LogicalORExpression : LogicalANDExpression
LogicalANDExpression : BitwiseORExpression
BitwiseORExpression : BitwiseXORExpression
BitwiseXORExpression : BitwiseANDExpression
BitwiseANDExpression : EqualityExpression
En este artículo, tomamos una función simple de la especificación y tratamos de entender la notación. ¡Vamos allá!
Incluso si conoces JavaScript, leer la especificación del lenguaje, Especificación del lenguaje ECMAScript, o simplemente la especificación ECMAScript, puede ser bastante desalentador. Al menos así me sentí cuando la leí por primera vez.
La especificación de la API de Internacionalización de ECMAScript (ECMA-402, o Intl) proporciona funcionalidades clave específicas de locales como formato de fechas, formato de números, selección de formas plurales y ordenación. Los equipos de Chrome V8 y Google Internationalization han estado colaborando para añadir características a la implementación ECMA-402 de V8, mientras eliminan deuda técnica y mejoran el rendimiento y la interoperabilidad con otros navegadores.
Durante sus tres meses de prácticas en el equipo de V8, Hai Dang trabajó en mejorar el rendimiento de [...array], [...string], [...set], [...map.keys()] y [...map.values()] (cuando los elementos extendidos están al inicio del literal de array). Incluso hizo que Array.from(iterable) fuese mucho más rápido. Este artículo explica algunos de los detalles de sus cambios, que están incluidos en V8 a partir de la versión 7.2.
El procesamiento asíncrono en JavaScript tradicionalmente tenía la reputación de no ser particularmente rápido. Para empeorar las cosas, depurar aplicaciones JavaScript en vivo — en particular servidores Node.js — no es una tarea fácil, especialmente cuando se trata de programación asíncrona. Afortunadamente, los tiempos están cambiando. Este artículo explora cómo optimizamos las funciones asíncronas y las promesas en V8 (y hasta cierto punto en otros motores de JavaScript), y describe cómo mejoramos la experiencia de depuración para el código asíncrono.
Array.prototype.sort fue una de las últimas funciones integradas implementadas en JavaScript autohospedado en V8. Trasladarlo nos dio la oportunidad de experimentar con diferentes algoritmos y estrategias de implementación y finalmente hacerlo estable en V8 v7.0 / Chrome 70.
DataViews son una de las dos maneras posibles de realizar accesos a memoria de bajo nivel en JavaScript, siendo la otra los TypedArrays. Hasta ahora, los DataView estaban mucho menos optimizados que los TypedArray en V8, lo que resultaba en un menor rendimiento en tareas como cargas de trabajo intensivas gráficamente o al decodificar/codificar datos binarios. Las razones de esto han sido principalmente elecciones históricas, como el hecho de que asm.js eligió TypedArray en lugar de DataView, incentivando a los motores a centrarse en el rendimiento de los TypedArray.