Comportamiento de WebAssembly entre plataformas de navegador

WebAssembly ofrece a los navegadores un formato portable para ejecutar módulos compilados, pero la portabilidad no significa que todos los navegadores y hosts tengan las mismas funciones, recursos o rendimiento. El contrato útil es más concreto: un módulo puede depender de las instrucciones y servicios del host que ofrece su entorno admitido. Conviene registrar esos requisitos antes de comparar versiones. Así, la decisión de compatibilidad se refiere a una tarea de la aplicación, no a la suposición de que el formato elimina las diferencias entre plataformas. La especificación WebAssembly Core define el comportamiento portable de las instrucciones; el navegador proporciona el entorno web circundante.

Un módulo contiene instrucciones tipadas y puede declarar memoria e importaciones que lo conectan con su host. La especificación define el comportamiento de las instrucciones principales admitidas, mientras la página y el navegador ofrecen servicios como entrada, almacenamiento y presentación. Un módulo que usa un conjunto común de funciones y entradas controladas se traslada más fácilmente que otro que depende de funciones opcionales o servicios propios del host. Esta frontera permite distinguir lo que viaja con el módulo de lo que debe comprobarse en la aplicación que lo incorpora.

La disponibilidad de funciones forma parte del contrato. Un compilador puede emitir instrucciones incompatibles con runtimes antiguos aunque el programa fuente parezca no haber cambiado. El soporte avanza a ritmos distintos entre navegadores, de modo que el formato por sí solo no garantiza que todas las instrucciones estén presentes. Mantén visible el conjunto mínimo de funciones en el proceso de compilación. Si se requieren funciones opcionales, ofrece una compilación para una base más amplia o una alternativa de la aplicación, y prueba cómo las selecciona la página.

Las importaciones conectan el módulo con comportamientos que el núcleo de WebAssembly no define. La página puede proporcionar funciones para acceder a datos o servicios de la aplicación, sujetos a sus propios contratos. Las reglas de importación de la especificación Core definen cómo se declaran, pero la coincidencia de importaciones no garantiza capacidades equivalentes del host en distintos navegadores. Mantén limitada la interfaz y documenta sus entradas y salidas permitidas.

Conviene distinguir las etapas: validate() comprueba los bytes del módulo, compile() crea un WebAssembly.Module e instantiate() resuelve las importaciones y crea una instancia. La instanciación también requiere un módulo válido (especificación Core). Gestiona cada fallo como un estado distinto de la aplicación y conserva la entrada original. Si el módulo es opcional, espera a que se solicite su tarea; completar la carga no demuestra nada sobre el sistema del usuario.

El artefacto del módulo también debe tratarse como una interfaz versionada. Sus funciones exportadas y servicios importados forman un contrato con la página, igual que una solicitud de red o un registro almacenado. Una sección personalizada puede contener información de depuración o datos de terceros, pero son metadatos opcionales que la semántica de WebAssembly ignora; no sustituyen el versionado de la aplicación ni una decisión de publicación. Mantén la descripción de interfaz de la página como parte del contrato de la aplicación. Una actualización del compilador puede cambiar el binario sin alterar ese contrato, así que compara el comportamiento y no exijas bytes idénticos.

Por qué existen diferencias válidas

El host proporciona recursos y funciones importadas. Por ello, el acceso a archivos, relojes, red, almacenamiento y servicios de la aplicación sigue contratos distintos. También varían los límites de recursos y la planificación. La velocidad no es una constante entre dispositivos, y un cambio de rendimiento no debe confundirse con un cambio semántico del módulo. Para evaluar la corrección, compara el resultado con el contrato del módulo y de la aplicación, no con una duración medida en otro sistema.

Algunas operaciones numéricas están especificadas con precisión y otras permiten margen a las implementaciones. El resultado también puede depender de conversiones entre valores WebAssembly y JavaScript, o de cómo la aplicación analiza y serializa datos. Si un flujo depende de un resultado numérico concreto, identifica la operación y la representación. No des por hecho que todos los runtimes producen valores idénticos en cada detalle ni amplíes una regla de comparación antes de revisar el estándar y el requisito del dominio.

Los módulos también dependen de los recursos disponibles. La asignación de memoria, el crecimiento de tablas, el uso de pila y el volumen de entrada pueden determinar si una tarea termina. Los navegadores pueden imponer límites por estabilidad, pero esos límites no describen la memoria física del host. Trata una asignación fallida como una condición de recursos, no como una identidad de dispositivo. La aplicación puede acotar la carga, conservar la entrada del usuario y ofrecer otra ruta si la tarea no puede continuar.

Las funciones opcionales también pueden interactuar con el entorno de publicación. Por ejemplo, una página puede carecer de las condiciones de seguridad o configuración de workers que necesita un módulo. Una ruta que funciona en una página local de desarrollo puede ser rechazada en producción. Prueba el contexto real del producto, incluidas sus políticas de página y uso de workers, y registra el requisito pertinente. Esto resulta más útil que recopilar propiedades del runtime no relacionadas.

Los supuestos de concurrencia también pertenecen al contrato de despliegue. Un módulo que usa memoria compartida o coordinación entre workers puede necesitar condiciones de página que no requiere uno de un solo hilo. Si el producto admite ambas rutas, comprueba la selección y que ambas preserven el mismo contrato de datos visible para el usuario. La alternativa de un solo hilo puede responder de otra manera y aun así producir un resultado válido para una tarea acotada. No desactives toda la función porque una ruta de concurrencia opcional no pueda ejecutarse. Indica el contexto admitido y prueba la alternativa bajo la misma política de publicación que la ruta principal.

Conviene separar las diferencias que surgen en tres límites: el módulo compilado, la implementación WebAssembly del navegador y los servicios host que aporta la aplicación. Si cambió el artefacto, un objetivo de compilación o una revisión de fuente nuevos pueden explicar el resultado. Si el artefacto es el mismo pero cambió un servicio importado, conviene revisar la integración de la página. Si ambos permanecen fijos y el comportamiento varía entre versiones del navegador, el runtime pasa a ser un punto de comparación pertinente. No se presupone una causa: se ordena la revisión de evidencias y se evita atribuir toda diferencia de plataforma a un defecto del navegador.

Privacidad y reproducibilidad

WebAssembly es un formato de ejecución, no un límite de privacidad. Un módulo puede procesar información localmente, pero las importaciones del host y la aplicación circundante determinan si después se almacena o transmite la entrada o el resultado. Revisa el flujo completo: recopilación, memoria del módulo, valores devueltos, registros, exportación y eliminación. Que el cálculo ocurra en el navegador no demuestra que el flujo entero permanezca local ni que la aplicación no conserve datos.

Limita los datos enviados al módulo a lo que requiere la tarea. El módulo compilado se entrega al cliente y debe considerarse código de aplicación inspeccionable, no un lugar para ocultar credenciales o registros privados. Las operaciones sensibles deben contar con autorización apropiada, y el host solo debe exponer los servicios necesarios para la tarea del usuario. Al cancelar una tarea o cerrar una vista, detén el trabajo cuando sea posible y libera referencias que mantengan sus datos de entrada.

Para obtener resultados reproducibles, fija el artefacto del módulo, las opciones de compilación, las importaciones, las entradas y las funciones requeridas del navegador. Si el módulo consulta un reloj, recibe datos aleatorios del host o usa almacenamiento mutable, es razonable que produzca resultados diferentes entre ejecuciones. Esas entradas forman parte del contrato de la aplicación. Las pruebas deben controlarlas cuando se necesita reproducibilidad o contemplar expresamente su variación si el flujo del usuario depende de ella.

La información de capacidades puede ayudar a elegir una ruta compatible, pero no debe convertirse por defecto en un registro de identidad persistente. Si se necesitan diagnósticos de soporte, vincúlalos con un problema comunicado por el usuario, conserva solo la versión y el resultado necesarios para reproducirlo y elimina el registro cuando termine ese propósito. Evita recopilar observaciones de tiempo o recursos que no sean pertinentes. Así, la revisión se centra en una tarea reproducible, no en clasificar el entorno.

Las dependencias incluidas en el módulo requieren una revisión normal de privacidad y mantenimiento. Puede haber bibliotecas que procesen entradas o den formato a resultados, y la compilación no cambia sus licencias ni su historial de actualizaciones. Conserva las dependencias de origen y la configuración del compilador utilizadas en el artefacto distribuido. Esto permite saber qué cambió al actualizar una biblioteca sin considerar opaco el binario ni recoger datos del equipo de cada usuario. Si una dependencia incorpora acceso a red o persistencia en la capa de aplicación, revísalo expresamente. Compilar no elimina la responsabilidad de entender el flujo de datos del software entregado.

Conviene explicar con cuidado la ejecución local. Un módulo que se ejecuta en el navegador puede mantener un cálculo intermedio en el dispositivo, pero la aplicación aún puede enviar sus entradas antes de ejecutarlo o sus resultados después. La página también puede descargar el módulo y el modelo desde un origen remoto. Revisa las solicitudes de red y el almacenamiento alrededor del módulo en vez de inferir el manejo de datos a partir del formato de ejecución. Si la aplicación ofrece un modo sin conexión, pruébalo sin red e indica qué funciones siguen disponibles. La explicación debe corresponder al comportamiento real del producto, no a una promesa general sobre WebAssembly.

Compatibilidad del módulo

Documenta el conjunto mínimo de funciones WebAssembly que requiere el módulo y las importaciones del host que necesita la página. Mantén esos requisitos junto a la revisión del módulo para que una compilación posterior no eleve en silencio la versión mínima del navegador. Si hay funciones opcionales, ofrece otra compilación o una alternativa en la página. Una nota de compatibilidad debe indicar qué tarea se probó, no insinuar que el formato garantiza soporte en todos los navegadores.

Prueba el recorrido completo alrededor del módulo: carga, instanciación, importaciones del host, entradas representativas, interpretación de la salida y fallos esperados. Una instanciación correcta no demuestra que la tarea del usuario obtenga un resultado aceptable. Del mismo modo, un fallo puede deberse a una conversión de entrada o a la integración con el host, y no a una instrucción ausente. Separa estos casos en la suite para que el mantenimiento atienda el límite adecuado.

Cuando se intercambian números entre WebAssembly y JavaScript, define su representación y rango. Decide si la interfaz usa enteros, valores de punto flotante, búferes de bytes o registros estructurados, y prueba las conversiones en ambos extremos. La serialización y el almacenamiento añaden sus propias reglas. Para cálculos decimales exactos, elige una representación adecuada y define el redondeo en la interfaz, en vez de depender del comportamiento incidental de un runtime.

La alternativa forma parte de la compatibilidad. Si falta una función requerida, la aplicación puede elegir un módulo para una base más amplia, una solución limitada o un mensaje explicativo. Prueba esa ruta con las mismas entradas del usuario y confirma que no descarte trabajo sin terminar. Si cambian la precisión de salida o la carga admitida, comunica esa diferencia. Una alternativa presente en el código fuente pero imposible de elegir en la página publicada no ayuda al usuario.

La interfaz pública del módulo debe definir la memoria y su propiedad. Quien lo llama necesita saber si el búfer se copia, se toma prestado durante una operación o se conserva para después según la interfaz utilizada. Documenta esa responsabilidad para que la página no reutilice ni descarte datos mientras el módulo los necesita. Al terminar o cancelar, libera las referencias de la aplicación y deja la interfaz lista para otra tarea. Prueba el uso repetido, además de una única llamada correcta, porque algunos problemas del ciclo de vida solo aparecen tras varias operaciones.

La interfaz pública del módulo debe ser lo bastante estable para que quien lo llama pueda gestionar errores. Define qué fallos pueden devolverse como resultados normales y cuáles indican que el módulo no puede continuar. La página debe convertirlos en un estado recuperable, no dejar un registro parcialmente actualizado o un control desactivado. No dependas de una cadena de error propia de un runtime como contrato de la aplicación. Usa la forma de retorno documentada y la gestión de estados de la aplicación, y prueba esa gestión en cada navegador admitido. Así puede evolucionar la implementación sin hacer que la recuperación visible dependa de una frase incidental.

Comparar versiones del navegador

Compara una versión candidata con el mismo artefacto de módulo, revisión de la aplicación, importaciones, entradas y contexto de publicación. Registra la versión y el resultado funcional de cada tarea requerida. Si también cambia el módulo o la suite, conserva el artefacto y las expectativas anteriores hasta entender la diferencia. Cambiar varias variables a la vez dificulta saber si el nuevo resultado provino del navegador, el compilador, la aplicación o la prueba.

Mantén separadas las pruebas de corrección y rendimiento. Un módulo más lento puede cumplir su contrato funcional; una ejecución rápida no demuestra que la salida sea correcta. Si la respuesta afecta al usuario, mide una tarea representativa de la aplicación e indica la carga y el entorno. No reutilices el tiempo transcurrido como etiqueta del navegador o del dispositivo. La planificación, actividad en segundo plano, estado de energía y cambios del runtime también influyen.

Si cambia una prueba, redúcela a una entrada pequeña y revisa el requisito pertinente de la especificación. Un comportamiento definido estrictamente y una operación que permite aproximación requieren interpretaciones diferentes. Antes de atribuir el resultado al navegador, comprueba las conversiones de la aplicación, las importaciones, las opciones de compilación y los datos del host. Una reproducción reducida plantea una pregunta acotada sin necesitar datos del usuario ni un inventario de propiedades ajenas.

Aplica la misma disciplina a las actualizaciones del compilador y la entrega del módulo. El compilador puede cambiar el conjunto de funciones o el artefacto aunque el navegador no cambie. Si la aplicación distribuye varias versiones, prueba su selección y caché para asegurar que cada entorno admitido reciba el archivo correcto tras la publicación. Revisa los navegadores admitidos cuando cambien los requisitos del producto. Este proceso complementa la validación de versiones del navegador y no repite el tema de las señales temporales del navegador.

Las notas de una actualización del módulo deben describir la tarea afectada, cualquier cambio en el contrato de entrada o salida y las versiones de navegador probadas. Si los usuarios necesitan actualizar una caché sin conexión o repetir una tarea interrumpida, indíquelo antes del despliegue. Los mantenedores necesitan el artefacto y su procedencia de compilación, mientras que los usuarios necesitan saber si se afectan su flujo y sus datos guardados. Actualice el registro de compatibilidad cuando cambie el alcance admitido y vuelva a revisarlo cuando el módulo dependa de una función nueva.

Antes de ampliar la gama admitida, define qué versiones del navegador y funciones del módulo se mantendrán. Prueba la base más antigua y la versión candidata, y conserva los resultados junto a las revisiones de la aplicación y del módulo. Puede iniciarse un despliegue limitado si el producto permite comparar resultados y recuperarse ante un problema. Si el módulo cambia datos que el usuario necesita, ofrece una migración o un reintento claro. Retira variantes antiguas solo cuando la política de soporte y el comportamiento de caché lo permitan para el público previsto. Así el mantenimiento sigue un compromiso explícito de compatibilidad y no el navegador más reciente del equipo de desarrollo.

Fuentes públicas

• Especificación WebAssembly Core, versión 2: importaciones
• Especificación WebAssembly Core, versión 2: validación
• Especificación WebAssembly Core, versión 2: instanciación
• Especificación WebAssembly Core, versión 2: secciones personalizadas
• MDN: WebAssembly.validate()
• MDN: WebAssembly.compile()
• MDN: WebAssembly.instantiate()