Todo sobre Apple, Android, Juegos Apks y Sitios de Peliculas

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

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.