Detección de funciones de WebAssembly y portabilidad de módulos
Detecta capacidades del entorno, clasifica fallos de validación, compilación e instanciación y entrega una alternativa conservando la entrada.
BotBrowser Team
Quieres la documentación estructurada de Plataforma?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
La portabilidad se decide durante la entrega. Un navegador puede exponer WebAssembly y aun así rechazar una instrucción, un límite de memoria o una importación del host. La aplicación debe probar el artefacto que va a usar en la página real, clasificar la etapa que falla, escoger una alternativa preparada y conservar el trabajo del usuario. La unidad que se protege es la tarea, no una puntuación general del navegador.
Sondeo de capacidades
Registra una capacidad mínima con identificador de tarea, resumen del módulo, nivel requerido, versión del contrato de imports y contexto de página. Comprueba que exista la API, que la respuesta contenga los bytes esperados y que la política permita el worker o la ventana. Una comprobación de propiedad solo habilita el siguiente paso; no es una huella del dispositivo. Nombra cada sondeo según la capacidad concreta, por ejemplo image-filter-v4-simd.
Ejecuta WebAssembly.validate(bytes) sobre los bytes candidatos. El resultado positivo acepta la estructura y las funciones usadas por el motor, pero no prueba imports, asignación ni salida. Un resultado negativo debe retirar ese artefacto de la sesión y seleccionar otro. SIMD, memoria compartida y memoria grande necesitan comprobaciones independientes. Separa además respuesta opaca, bloqueo de política, timeout de red y rechazo del binario: todos impiden la ruta rápida, pero no significan lo mismo.
El sondeo se ejecuta en el contexto final: una vista previa, un worker y una página aislada pueden tener políticas y contratos distintos. Conserva solo artefacto, etapa, resultado, versión e incidente informado. No conviertas datos de soporte en una identidad persistente.
Tres etapas de fallo
Usa validación, compilación e instanciación como estados contractuales. La validación rechaza bytes mal formados o funciones no disponibles; todavía no resuelve imports. La compilación puede fallar por presión de recursos o límites del motor después de aceptar la estructura. La instanciación conecta el código con el host y falla por imports ausentes, firmas incorrectas, tablas o memoria. Un error devuelto por una función exportada después de crear la instancia es un resultado de la aplicación, no una falta de soporte.
Guarda { stage: 'compile', code: 'resource-limit' } en vez de mostrar texto de excepción. Así el equipo puede contar rechazos por artefacto y corregir el límite adecuado. La especificación WebAssembly Core define la terminología; los mensajes al usuario deben indicar si se eligió una alternativa, si la entrada necesita cambios o si no existe una ruta disponible.
Entrega alternativa
Publica una variante base, una variante escalar y una implementación JavaScript con contratos de entrada y salida explícitos. El selector elige la ruta más rápida que cumple la tarea. Tras un rechazo de validación o compilación, elimina ese candidato durante la sesión. Ante una instanciación fallida, solo prueba otro mapa de imports o artefacto. Incluye nivel, resumen y versión del host en la clave de caché.
La interfaz debe anunciar la ruta y conservar la entrada al reintentar. Una ruta lenta es correcta si mantiene el contrato; una precisión o tamaño menor debe explicarse antes de continuar. Prueba con los mismos fixtures el caso válido, rechazo, presión de compilación, import faltante, cancelación y reintento. BotBrowser documenta paridad de JavaScript y WebAssembly en pipelines baseline, Turbo y SIMD; el alcance se limita a esos pipelines y no promete idénticos resultados en todos los hosts.
Conservar la entrada
Antes de sondear crea un registro estable de tarea y conserva el archivo, texto o bytes originales. Si el módulo toma propiedad de un búfer, usa una copia o una fuente reabrible. Los adaptadores convierten desde ese registro a la representación del módulo y vuelven al formato común de la aplicación. Al cancelar, libera memoria y evita que una promesa tardía reemplace la vista actual.
La privacidad acompaña cada ruta: ejecutar localmente no impide enviar datos a un servicio. Explica qué alternativa necesita red y no incluyas entradas en la telemetría. Mantén foco y anuncia el cambio para usuarios de teclado o lector de pantalla. Consulta la validación de versiones del navegador y la guía de compatibilidad y alternativas.
Registro de publicación fijo
Congela antes de ampliar soporte los resúmenes de todos los artefactos, ajustes del compilador, niveles, contrato de imports, fixtures, política, perfil y resultados de las tres etapas. Separa corrección de tiempos. Mantén evidencia negativa: por ejemplo, SIMD rechazado en la base antigua, escalar instanciado y misma salida. Las correcciones crean un registro nuevo con motivo.
Publica tarea, ruta preferida, alternativa, rango probado, actualización de caché y recuperación. No afirmes compatibilidad universal. La API se puede consultar en MDN WebAssembly, y las capacidades de BotBrowser en Advanced features. El flujo queda así: sondear, clasificar, cambiar de ruta, conservar entrada y fijar evidencia.
BotBrowser documenta el uso de WebAssembly en sus pipelines baseline, Turbo y SIMD, pero no garantiza resultados idénticos en todos los motores o hosts.
La aplicación puede mostrar la capacidad elegida antes de iniciar el trabajo.
Un digest permite comprobar que la caché contiene el módulo esperado.
La respuesta HTTP debe conservar su tipo y su longitud declarados.
Un worker nuevo necesita repetir la comprobación de sus imports.
La memoria compartida requiere condiciones de página que no son universales.
El modo escalar puede tardar más y seguir entregando el mismo resultado.
Una entrada demasiado grande puede activar un límite de recursos.
La interfaz debe permitir cancelar una operación prolongada.
El estado cancelado no debe ocultar el contenido original.
Una segunda ejecución comprueba que no quedaron punteros retenidos.
El registro de soporte identifica el artefacto sin incluir datos privados.
La política de retención debe estar definida antes de recopilar diagnósticos.
La versión del contrato de imports acompaña a cada publicación.
Una actualización del compilador puede cambiar la selección de funciones.
Los fixtures pequeños ayudan a aislar un rechazo de validación.
La prueba de instancia usa el mismo adaptador que producción.
Una salida provisional no debe reemplazar un resultado confirmado.
El texto de error se traduce desde códigos estables de la aplicación.
Los perfiles más antiguos reciben una ruta explícita y comprobada.
El servidor solo recibe datos cuando la ruta lo declara.
Una página offline debe indicar qué módulos tiene disponibles.
El foco del teclado permanece en el control que inició la tarea.
El lector de pantalla anuncia el cambio de implementación.
La publicación conserva los digests de los artefactos retirados.
Una corrección crea una entrada nueva en el historial.
La evidencia negativa evita eliminar una alternativa necesaria.
La revisión final compara tarea, entrada, salida y limitación visible.
Fuentes públicas
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.