JavaScript pronto podría tener su propia sintaxis de tipo si se presenta una propuesta. presentado por Microsoft y otros desarrolladores a principios de este año pasa a formar parte del estándar ECMAScript. La iniciativa planea agregar soporte para “tipos como comentarios” al lenguaje JavaScript, permitiendo a los desarrolladores anotar código con información de tipo que será utilizada por otros componentes del ecosistema.
La sintaxis
La sintaxis propuesta es la siguiente:
function sayAge(name: string, age: number) {
console.log(`${name} is ${age} years old.`);
}
sayAge("JavaScript", 26);
Le resultará familiar a cualquiera que haya usado anteriormente Mecanografiado, superconjunto escrito de JavaScript de Microsoft. 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.
¿Cuál 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 los tiempos de ejecución de JavaScript, como los navegadores web, Node.js y Deno, que respetan 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 ni en el tiempo de ejecución de su código. Una llamada a 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 tipo que sea oficialmente compatible pero completamente ignorada por los motores. El único cambio para las implementaciones tiene que ver con el reconocimiento y eliminación de anotaciones tipográficas dondequiera que se utilicen.
La propuesta buscaría establecer soporte para anotar los tipos de parámetros, variables y propiedades de clase. También consideraría agregar un
interface
palabra clave, operadores de aserción como
!
y
as
y un
?
Modificador para marcar tipos como opcionales. La intención es que todos estos elementos reflejen TypeScript; Sin embargo, al igual que con cualquier propuesta de la Etapa 0, el resultado final puede ser diferente.
¿Cuál es el punto de?
Si las anotaciones de tipo no cambian 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 cadenas de herramientas modernas de JavaScript.
Actualmente, escribir código con seguridad de tipos requiere el uso de 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 compleja cadena de herramientas con múltiples partes móviles.
Aunque JavaScript es un lenguaje inherentemente de tipo flexible, la comunidad ahora reconoce ampliamente los beneficios del tipo fuerte. Esto es evidente a partir de la impulso que rodea el proyecto TypeScript. La escritura estática también fue el líder indiscutible en el 2021 Estado de JS pregunta de la encuesta sobre “características faltantes”.
Agregar una sintaxis de tipo al propio 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 mientras evoluciona 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 con ámbito de bloque y
async
/
await
. JavaScript incluso tiene un sistema de módulos completo que funciona en todos los motores, incluidos los navegadores.
Hace solo unos años, se requería una larga cadena de herramientas para poder escribir estas funciones en su código con la confianza de que funcionaría en los dispositivos de los usuarios. Hoy en día, los desarrolladores pueden dejar de lado esos procesos de compilación de forma segura y volver al modelo JavaScript original de hacer referencia a 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 cierto grado de soporte de tipos a JavaScript sin romper el código existente ni aplicar comprobaciones de tipos en tiempo de ejecución que afecten el rendimiento.
¿Qué deberían hacer realmente los tipos?
El papel de un “tipo” varía según el idioma. El demoninador común radica en la capacidad de un tipo para expresar el tipo de datos que contendrá una variable particular. Sobre esa base se superponen significados, capacidades y comportamientos adicionales.
En lenguajes compilados de tipo estático 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 los lenguajes interpretados con escritura fuerte opcional, de los cuales PHP es un ejemplo, los tipos se aplican 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 debería extenderse el alcance de cualquier sistema de tipos integrado. Esta propuesta limita su función al elemento más fundamental, una documentación simple 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 mientras escriben código. Puede obtener información sobre problemas de tipografía mientras escribe JavaScript normal en un IDE compatible. Si lo desea, también puede utilizar una herramienta de soporte como TypeScript, un analizador estático o un paquete para auditar su fuente bajo demanda. Esto podría bloquear una implementación en sus canalizaciones de CI cuando existe 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 suelen ser necesarias dentro del ecosistema 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 simple:
/*** @param name {string}
* @param age {number}
*/
function sayAge(name, age) {
console.log(`${name} is ${age} years old.`);
}
Los comentarios de JSDoc están respaldados por varias herramientas populares. Sin embargo, no son una parte estandarizada del lenguaje y requieren que usted mezcle 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 bloque de documentos.
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 los 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 debe crear y mantener por separado.
¿Que sigue?
El equipo de TypeScript de Microsoft y los coautores, incluidos Bloomberg, Igwalia y varios contribuyentes independientes, enviaron la propuesta de la Etapa 0 en el plenario 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 escribir de JavaScript con la demanda actual de una experiencia de desarrollo con tipos más estáticos. El uso de una sintaxis completamente 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 este parece crecer con nuevas opiniones y perspectivas a medida que la propuesta avanza en la vía de los estándares.
