WinterTC y Cómo los Estándares Ayudan a los Desarrolladores

Hola, soy Oliver Metturst, y voy a hablar sobre WinterTC y cómo te ayuda. Así que los runtimes de JS hoy en día, Node es, por supuesto, el más grande y conocido. También están Deno y Bund y otros, que están surgiendo lentamente. Todos están construidos sobre motores de JS existentes, y todos están destinados a ejecutarse en el servidor. También hay runtimes de edge como Worker Deep de Cloudflare o Deno Deploy.

Así que cada runtime tiene sus propias prioridades, por lo que, por supuesto, hay muchos runtimes diferentes. Las APIs de esos runtimes son básicamente solo Node. Las APIs de Node son geniales, pero no hay un estándar. El único estándar es la documentación de Node, que es buena, pero algunos de los detalles pueden ser muy problemáticos. Así que WinterTC está trabajando en estandarizar esto, porque usar la misma interfaz sin un estándar puede causar mala interoperabilidad. Si miras Deno o Bund, todavía tienen problemas de compilación de Node, que son mitad trabajo de ingeniería de Node y mitad porque no hay especificación. La mayor parte es solo encontrar errores en el mundo real.

Esto ayuda a evitar el bloqueo de proveedores, porque en lugar de tener que reescribir toda tu aplicación o escribirla solo para las APIs de una empresa, tener solo una API universal es básicamente el sueño, porque puedes escribir una vez y ejecutar en cualquier lugar. Algunas de las APIs de Node están quedando un poco obsoletas y no se pueden cambiar debido a la compatibilidad hacia atrás. Y algunos runtimes tienen sus propias versiones junto con las de Node, lo cual no es genial. Así que WinterTC está trabajando en esto. Solía ser WinterCG alrededor de finales del año pasado, pero nos mudamos de un grupo comunitario de W3C a un comité técnico de ECMA, porque nos ayuda a trabajar más de cerca con TC FinnyLine, que redacta la propuesta de JavaScript, que ayuda a hacer las especificaciones de JavaScript, y en general es un mejor ajuste.

Así que el esfuerzo se centra principalmente en redactar especificaciones, definiendo qué API web debería incluirse, como por ejemplo URL, WebAssembly, porque todas esas APIs en realidad no están en la especificación de JavaScript. Así que actualmente, los runtimes solo incluyen lo que todos los demás están incluyendo sin una lista definitiva en ningún lugar, que es una de las principales especificaciones en las que WinterTC está trabajando. Hay algunos pensamientos y propuestas para APIs web existentes, como por ejemplo Fetch, algunos cambios, como por ejemplo restricciones de origen cruzado, no se aplican al servidor porque ese problema de seguridad no existe aquí. Sí, también hay algunas de las propias especificaciones y propuestas del TC, como por ejemplo la API CLI, pero esas todavía están muy emergentes y en desarrollo. Así que la API mínima común es esencialmente la especificación insignia, que incluye el subconjunto de qué APIs web deberían estar en los runtimes de JS del lado del servidor. Así que podría ser cualquier cosa desde Base64 con ATOP y BTOA, hasta Console, Crypto y Fetch. Y hay otras APIs emergentes, como la API CLI, que está tratando de hacer un estándar, no una forma de API de Node de hacer, digamos, variables de entorno o argumentos. Y algunas otras APIs, que todavía están en progreso. Y puedes involucrarte en wintertc.org o unirte a la sala de Matrix. Ya hay algunas especificaciones aquí, y puedes ver las especificaciones, como la API mínima común. Puedes ver que hay una lista definitiva de todo lo que un runtime del lado del servidor debería incluir, que anteriormente no existía. Y sí, todo el trabajo está en GitHub. Y hay una sala de Matrix donde puedes hablar y ayudar con PRs de especificaciones o sugerencias de ideas sobre qué hacer. Así que gracias.