Qué significa la propuesta de sintaxis de tipo ES de Microsoft para JavaScript

Ilustración que muestra el logotipo de JavaScript

JavaScript pronto podría tener su propia sintaxis de tipo si una propuesta enviado por Microsoft y otros desarrolladores a principios de este año se convierte en parte del estándar ECMAScript. La iniciativa planea agregar soporte de “tipos como comentarios” al lenguaje JavaScript, lo que permite a los desarrolladores anotar el código con información de tipo que será utilizada por otros componentes del ecosistema.

la sintaxis

La sintaxis propuesta se ve así:

function sayAge(name: string, age: number) {
    console.log(`${name} is ${age} years old.`);
}
 
sayAge("JavaScript", 26);

Será familiar para cualquiera que haya usado previamente Mecanografiado, el superconjunto escrito de Microsoft de JavaScript. TypeScript ha obtenido una adopción generalizada en toda la industria; esta nueva propuesta pretende llevar algunos de sus beneficios al mundo de JavaScript en general.

¿Qué no es la propuesta?

Si se aprueba, esta propuesta le permitirá escribir JavaScript perfectamente válido con las anotaciones de tipo que se muestran arriba. Será aceptado por tiempos de ejecución de JavaScript como navegadores web, Node.js y Deno que respeten el estándar ES.

Sin embargo, la propuesta en realidad no amplía el lenguaje JavaScript. Sus anotaciones de tipo serán exactamente eso: metadatos inertes que no tienen ningún efecto en el compilador de JavaScript o en el tiempo de ejecución de su código. Una llamada de función como la siguiente funcionaría en tiempo de ejecución:

function sayAge(name: string, age: number) {
    console.log(`${name} is ${age} years old.`);
}
 
// "age" is a string when it should be a number, but this is still allowed
sayAge("JavaScript", "twenty");

La idea es ofrecer una nueva sintaxis de tipos que sea compatible oficialmente pero que los motores ignoren por completo. El único cambio para las implementaciones se refiere al reconocimiento y eliminación de anotaciones de tipo donde sea que se usen.

La propuesta buscaría establecer soporte anotando los tipos de parámetros, variables y propiedades de clase. También buscaría agregar un interface palabra clave, operadores de afirmación como ! y asy un ? modificador para marcar los tipos como opcionales. La intención es que todos estos elementos reflejen TypeScript; Sin embargo, al igual que con cualquier propuesta de Etapa 0, el resultado final puede funcionar de manera diferente.

¿Cuál es el punto de?

Si las anotaciones de tipo no cambiarán su programa, la pregunta obvia es si vale la pena tenerlas. La propuesta argumenta “sí” debido a la capacidad de la sintaxis para acortar los tiempos de iteración y reducir la carga en torno a las modernas cadenas de herramientas de JavaScript.

Escribir código con seguridad de tipos actualmente requiere que use TypeScript, un tipo de lenguaje diferente que agrega dependencias a su proyecto y requiere un paso de compilación manual. Luego, ese código puede pasar por otras herramientas, como un paquete de módulos y un transpilador, antes de que se produzca el JavaScript final para su distribución. Se suma a una cadena de herramientas compleja con múltiples partes móviles.

Aunque JavaScript es un lenguaje intrínsecamente poco tipificado, la comunidad ahora reconoce ampliamente los beneficios de una tipificación fuerte. Esto es evidente a partir de la impulso que rodea el proyecto TypeScript. La mecanografía estática también fue el líder indiscutible en el 2021 Estado de JS la pregunta de “característica faltante” de la encuesta.

Agregar una sintaxis de tipo a JavaScript le permitiría obtener algunos de los beneficios de TypeScript sin tener que compilar su código. Esto simplifica la configuración y el mantenimiento del proyecto, al mismo tiempo que desarrolla JavaScript para alinearse mejor con las prácticas de desarrollo modernas.

En los últimos años, más código ha comenzado a migrar hacia un enfoque de “JavaScript puro”. El declive de los navegadores heredados hace que la transpilación sea menos necesaria de lo que era antes: la mayoría de las implementaciones modernas ofrecer soporte completo para características como clases, funciones de flecha, variables de ámbito de bloque y async/await. JavaScript incluso tiene un sistema de módulos completo que funciona en todos los motores, incluso en los navegadores.

Hace solo unos años, una larga cadena de herramientas fue requerido para poder escribir estas características en su código con confianza, funcionará en los dispositivos de los usuarios. Hoy en día, los desarrolladores pueden dejar de lado esos procesos de compilación de forma segura, volviendo al modelo JavaScript original de referenciar archivos con <script> etiquetas

Los tipos son una de las pocas áreas restantes del ecosistema de JavaScript que no se adaptan al lenguaje en sí. Los ames o los odies, no se puede negar que los tipos se han convertido en una parte integral del desarrollo de JavaScript para muchos equipos y proyectos. La propuesta de sintaxis reconoce formalmente este hecho. Intenta brindar un grado de soporte de tipo a JavaScript sin romper el código existente o hacer cumplir las comprobaciones de tipo de tiempo de ejecución que afectan el rendimiento.

¿Qué deberían hacer realmente los tipos?

El papel de un “tipo” varía entre idiomas. El denominador común radica en la capacidad de un tipo para expresar el tipo de datos que contendrá una variable en particular. Luego, se superponen significados, capacidades y comportamientos adicionales sobre esa base.

En lenguajes compilados con tipos estáticos como C# y Java, los tipos se aplican en el momento de la compilación. Es imposible compilar un programa cuando tienes incompatibilidades de tipos en tu código. En lenguajes interpretados con tipado fuerte opcional, de los cuales PHP es un ejemplo, los tipos se imponen en tiempo de ejecución: el programa arroja un error cuando el tipo de un valor es incompatible con el contexto en el que se usa.

Un debate activo dentro de la comunidad de JavaScript ha sido hasta dónde debe extenderse el mandato de cualquier sistema de tipo integrado. Esta propuesta limita su papel al elemento más fundamental, una simple documentación del tipo esperado de un valor. Esto se alinea bien con la posición de TypeScript como una sintaxis de tipo borrable que se ignora en tiempo de ejecución.

El propósito de este modelo es brindar a los desarrolladores comentarios instantáneos sobre posibles errores a medida que escriben código. Puede obtener información sobre problemas de tipo mientras escribe JavaScript normal en un IDE compatible. Si quisiera, también podría usar una herramienta de soporte como TypeScript, un analizador estático o un paquete para auditar su fuente a pedido. Esto podría bloquear una implementación en sus canalizaciones de CI cuando se presente un problema de tipo.

La sensación actual es que estas capacidades son suficientes para alinear JavaScript con las necesidades más comunes de los desarrolladores. Las características que se encuentran en otros lenguajes, como la introspección y la reflexión, no son comúnmente necesarias dentro del ecosistema de JavaScript, en parte porque los desarrolladores se han acostumbrado al enfoque de borrado de TypeScript.

La alternativa existente: Docblocks

Vale la pena señalar que ya existe algo similar a la sintaxis de anotaciones borradas propuesta: las etiquetas JSDoc familiares se usan comúnmente para agregar detalles de tipo al código JavaScript sin formato:

/**
 * @param name {string}
 * @param age {number}
 */
function sayAge(name, age) {
    console.log(`${name} is ${age} years old.`);
}

Los comentarios de JSDoc son compatibles con varias herramientas populares. Sin embargo, no son una parte estandarizada del lenguaje y requieren que mezcle los detalles de la operación de su código (sus tipos esperados) con la documentación centrada en el ser humano que comprende el resto del docblock.

La sintaxis de JSDoc también es muy detallada. Además de los nombres de etiquetas requeridos, normalmente requiere la repetición de elementos que ya existen en su código, como los nombres de parámetros en el ejemplo anterior. Si modifica un parámetro en la firma de la función, debe recordar cambiar también la etiqueta JSDoc.

La nueva propuesta de sintaxis puede ser funcionalmente equivalente a docblocks pero ofrece una experiencia mucho más optimizada. Los tipos se ubican junto a sus objetivos como parte de su fuente, en lugar de en un bloque de documentos que necesita crear y mantener por separado.

¿Que sigue?

El equipo de TypeScript de Microsoft y los coautores, incluidos Bloomberg, Igwalia y varios colaboradores independientes, enviaron la propuesta Etapa 0 en el pleno del TC39 de marzo de 2022. Desde entonces, la propuesta ha avanzado a la Etapa 1. Sin embargo, la aceptación aún está lejos, y es posible que la implementación dentro de los motores no llegue. durante años.”

El objetivo general de esta propuesta es equilibrar la larga cola de código sin tipo de JavaScript con la demanda actual de una experiencia de desarrollo con tipos más estáticos. El uso de una sintaxis totalmente opcional borrada garantiza la compatibilidad con versiones anteriores, pero plantea la posibilidad de que sea ineficaz para fomentar la adopción y consolidar el ecosistema. El debate en torno a esto parece que va a crecer con nuevas opiniones y perspectivas a medida que la propuesta avanza a través de la vía de los estándares.