El panorama del desarrollo web está en un estado de flujo perpetuo, sin embargo, pocas innovaciones han ofrecido un cambio tan fundamental en las capacidades como WebAssembly (WASM). A medida que navegamos por principios de 2026, WASM ha hecho una transición firme de una tecnología naciente a una base sólida y eficiente para experiencias web exigentes, particularmente cuando se combina con Rust. Esto no se trata de "revolucionar" la web; se trata de mejorar sistemáticamente su potencia computacional, superando los límites de lo que es prácticamente alcanzable dentro del navegador. Para los desarrolladores senior que luchan con cuellos de botella en el rendimiento, algoritmos complejos o la integración de herramientas sofisticadas, los desarrollos recientes en WASM, Rust y wasm-bindgen presentan un camino tangible y convincente a seguir.
Habiendo profundizado recientemente en las últimas iteraciones y realizado pruebas exhaustivas, los números cuentan una historia interesante de maduración y optimización especializada. El enfoque se ha agudizado en la interoperabilidad, la gestión de la memoria y la ejecución paralela, acercándonos a un futuro donde el rendimiento de las aplicaciones de clase de escritorio sea una expectativa nativa del navegador, no una aspiración.
La Evolución Arquitectónica: Modelo de Componentes y WasmGC
El Modelo de Componentes de WebAssembly: Un Cambio de Paradigma en la Modularidad
El Modelo de Componentes de WebAssembly se destaca como uno de los avances arquitectónicos más significativos en estabilizarse en el último año, remodelando fundamentalmente cómo concebimos la modularidad y la interoperación dentro del ecosistema WASM. Lanzado como parte de WASI Preview 2 (también conocido como WASI 0.2) a principios de 2024, este modelo proporciona un mecanismo estandarizado, agnóstico del lenguaje, para componer aplicaciones más grandes a partir de componentes WebAssembly más pequeños e independientes.
En su núcleo, el Modelo de Componentes introduce el Tipo de Interfaz de WebAssembly (WIT), un IDL (Lenguaje de Definición de Interfaz) agnóstico del lenguaje que define explícitamente las importaciones y exportaciones de un componente. Esto va más allá de las importaciones de funciones y memoria de bajo nivel de WASM central, permitiendo que tipos de datos de alto nivel como registros, variantes y recursos se pasen directa y eficientemente a través de los límites de los componentes. La ABI (Interfaz Binaria de Aplicación) canónica asegura que estos tipos complejos se serialicen de manera consistente, independientemente del lenguaje de origen. Esto reduce significativamente la repetición y el potencial de errores que plagaron los enfoques anteriores de FFI (Interfaz de Función Externa) manuales, donde cada estructura de datos requería una serialización y deserialización cuidadosas a través del límite JS/WASM.
Para los desarrolladores de Rust, la cadena de herramientas cargo-component, a menudo utilizada en conjunto con wit-bindgen, se ha convertido en el conducto principal para construir estos componentes. cargo-component genera enlaces de Rust directamente en su proyecto (por ejemplo, src/bindings.rs) según las definiciones WIT resueltas de sus dependencias Cargo.toml, en lugar de requerir una definición local de la interfaz del componente. Este enfoque integrado simplifica considerablemente el flujo de trabajo de desarrollo. Si bien cargo-component en sí mismo se encuentra en una fase de transición, con la documentación del modelo de componentes que señala que las cadenas de herramientas Rust modernas pueden construir componentes directamente a través de cargo build --target wasm32-wasip2, las herramientas subyacentes wit-bindgen y wit-component siguen siendo cruciales. Las implicaciones de rendimiento son sustanciales: al estandarizar la comunicación entre componentes y reducir la necesidad de código de pegamento JavaScript, los componentes se pueden vincular con una sobrecarga mínima, allanando el camino para aplicaciones multi-lenguaje altamente componibles y de alto rendimiento. En comparación con los métodos anteriores de federación manual de módulos, el Modelo de Componentes ofrece una solución mucho más robusta y eficiente para arquitecturas de aplicaciones a gran escala.
Realidad a Tener en Cuenta: Si bien el Modelo de Componentes es un gran salto adelante, su integración en el navegador aún está evolucionando. Los navegadores actualmente admiten módulos .wasm sin procesar, no componentes WASM completos directamente. Esto requiere un paso de transpilación, a menudo involucrando herramientas como el paquete jco (JavaScript Component Runtime) en npm, que toma paquetes de componentes y genera el código de pegamento JavaScript necesario junto con el binario .wasm. Esto agrega un paso de compilación y puede afectar el tamaño del paquete, lo que representa un compromiso para los primeros usuarios. Sin embargo, el trabajo fundamental está en su lugar y la trayectoria hacia el soporte nativo del navegador es clara.
WasmGC: Cerrando la Brecha en la Gestión de la Memoria
La Recolección de Basura de WebAssembly (WasmGC) ha sido una característica muy esperada, logrando soporte básico en todos los navegadores principales: Chrome (119+), Firefox (120+) y Safari (18.2+) a diciembre de 2024. Esto no es simplemente una actualización incremental; es una mejora fundamental que impacta profundamente a los lenguajes más allá de Rust, particularmente aquellos con sus propios recolectores de basura (por ejemplo, Java, Kotlin, Dart, Python).
Históricamente, los lenguajes como Java o Kotlin, cuando se compilan a WebAssembly, tenían que incluir todo el recolector de basura de su tiempo de ejecución dentro del binario .wasm. Esto inevitablemente condujo a tamaños de módulo significativamente más grandes y tiempos de inicio aumentados, a menudo erosionando los beneficios de rendimiento y tamaño que WASM pretendía ofrecer. WasmGC aborda esto al proporcionar un mecanismo de recolección de basura estandarizado y nativo directamente dentro del motor de WebAssembly. Esto significa que estos lenguajes de nivel superior ahora pueden aprovechar el GC nativo optimizado del navegador, lo que resulta en tamaños de módulo sustancialmente más pequeños y una ejecución más rápida, ya que ya no están cargados con el envío de su propia implementación de GC. Google Sheets, por ejemplo, migró su trabajador de cálculo a WasmGC, demostrando mejoras de rendimiento tangibles.
Para Rust, un lenguaje construido sobre su sofisticado modelo de propiedad y préstamo para la seguridad de la memoria en tiempo de compilación, el impacto directo de WasmGC en la gestión interna de la memoria es menos pronunciado. Las aplicaciones Rust normalmente gestionan la memoria de forma determinista sin un GC en tiempo de ejecución. Sin embargo, el soporte de WasmGC para "referencias con tipo" y la gestión eficiente de estructuras de datos complejas (estructuras y matrices) tiene beneficios indirectos. Permite una interoperabilidad más eficiente y directa con los objetos JavaScript y otros módulos WASM con GC, reduciendo la sobrecarga de FFI al pasar tipos de datos enriquecidos entre Rust y JavaScript. En lugar de la serialización/deserialización manual, los objetos se pueden pasar por referencia con la VM del host manejando su tiempo de vida. Esto agiliza la capa de interoperabilidad, lo que permite que el código Rust interactúe de manera más fluida con el ecosistema web más amplio.
Potencias de Rendimiento: Hilos, SIMD y Ganancias del Compilador
Turboalimentando con Hilos de WebAssembly y SIMD
La maduración y el amplio soporte del navegador para Hilos de WebAssembly y SIMD (Instrucción Única, Datos Múltiples) han desbloqueado ganancias de rendimiento sustanciales para cargas de trabajo altamente paralelizables e intensivas en computación. A fines de 2024 y principios de 2025, las operaciones SIMD de ancho fijo de 128 bits son ampliamente compatibles en todos los navegadores principales, incluida la integración de Safari en 2024. Para obtener una visión más profunda de los cambios fundamentales, consulte nuestra guía sobre Rust + WebAssembly 2025: Por qué WasmGC y SIMD Cambian Todo.
Las instrucciones SIMD permiten que una sola instrucción opere en múltiples puntos de datos simultáneamente, vectorizando operaciones para tareas como el procesamiento de imágenes/video, la inferencia de aprendizaje automático y la criptografía. Los puntos de referencia de finales de 2025 demuestran que WASM con SIMD puede lograr aumentos de velocidad de 10 a 15 veces sobre JavaScript puro para estos tipos de cargas de trabajo. Por ejemplo, las operaciones de matriz que podrían tardar 1,4 ms en JavaScript podrían reducirse a 0,231 ms con SIMD dentro de WASM, lo que representa una mejora del 6x dentro de WASM en sí. Los desarrolladores de Rust pueden aprovechar SIMD a través de intrínsecos específicos de la plataforma (por ejemplo, std::arch::wasm32::simd128) o crates de nivel superior que abstraen estas operaciones. La compilación para SIMD normalmente implica características de destino específicas, como -C target-feature=+simd que se pasa a rustc o se configura a través de cargo.
Los Hilos de WebAssembly, aunque conceptualmente sencillos, requieren un manejo cuidadoso en el entorno del navegador. Los hilos verdaderos son compatibles a través de Web Workers, donde cada trabajador ejecuta su propia instancia de WASM. En esencia, la capacidad de compartir memoria entre estos trabajadores utilizando SharedArrayBuffer combinado con Atomics.wait() y las instrucciones WASM equivalentes (habilitadas por la propuesta atomics) permite que std::thread de Rust se compile en hilos WASM. Esto habilita el multihilo real para el código Rust en el navegador, aliviando la limitación del bucle de eventos de un solo subproceso de JavaScript para cálculos pesados. Los puntos de referencia recientes de Intel indican mejoras de rendimiento de hasta 3,5 veces en tareas con uso intensivo de computación cuando se aplican estas características de concurrencia en comparación con los módulos WebAssembly de un solo subproceso. El despliegue de Rust con hilos WASM normalmente requiere el establecimiento de marcas específicas de rustc como -C target-feature=+atomics y la garantía de que el servidor web envíe encabezados Cross-Origin-Opener-Policy y Cross-Origin-Embedder-Policy apropiados para habilitar el soporte de SharedArrayBuffer.
Optimizaciones del Compilador Rust para el Objetivo wasm32-unknown-unknown
El compilador Rust, aprovechando LLVM, ha continuado su implacable búsqueda de rendimiento y reducción del tamaño del binario para el objetivo wasm32-unknown-unknown a lo largo de 2024 y 2025. Estos optimizaciones son cruciales para ofrecer la promesa de rendimiento "cercano al nativo" de WebAssembly en el navegador.
Los avances clave incluyen la Optimización Guiada por Perfil (PGO) y la Optimización en Tiempo de Enlace (LTO) mejoradas específicas para WASM. PGO, al retroalimentar los perfiles de ejecución en el proceso de compilación, permite que el compilador tome decisiones más informadas sobre la inserción en línea, la asignación de registros y el diseño del código, lo que lleva a rutas críticas más eficientes. LTO, por otro lado, habilita el análisis de todo el programa en tiempo de enlace, lo que permite la eliminación agresiva de código muerto y las optimizaciones entre módulos, que son particularmente efectivas para reducir el tamaño final del binario .wasm. El backend LLVM del compilador Rust ahora genera constantemente código WASM más ajustado, lo que contribuye a binarios más pequeños y una ejecución más rápida en comparación con otros lenguajes compilados a WASM en puntos de referencia específicos. Un punto de referencia de diciembre de 2025, por ejemplo, encontró que Rust compiló más rápido, produjo binarios más pequeños y mostró una ventaja de rendimiento del 9% sobre C++ para cálculos numéricos recursivos.
Los desarrolladores pueden habilitar explícitamente estas optimizaciones en su Cargo.toml o a través de las marcas CLI de rustc:
[profile.release]
opt-level = 's' # Optimizar para tamaño ('z' para aún más pequeño, pero potencialmente más lento)
lto = true # Habilitar la Optimización en Tiempo de Enlace
codegen-units = 1 # Reducir las unidades de generación de código para una optimización más agresiva
debug = false # Deshabilitar la información de depuración para binarios más pequeños
Junto con los avances del compilador, las herramientas como wasm-opt (del conjunto de herramientas Binaryen) siguen siendo indispensables. wasm-opt aplica optimizaciones posteriores a la compilación, eliminando agresivamente las funciones y los datos no utilizados, simplificando las secuencias de instrucciones y reduciendo aún más el tamaño del binario y los tiempos de carga. Sus mejoras en 2024-2025 se han centrado en una eliminación más inteligente del código muerto y una mejor integración con la información de depuración DWARF para una mejor experiencia del desarrollador durante la optimización. La herramienta wasm-pack, que orquesta todo el flujo de trabajo de Rust a WASM (compilación, ejecución de wasm-bindgen y empaquetado), también ha visto actualizaciones continuas, simplificando el proceso de generación de módulos .wasm optimizados y su código de pegamento JavaScript asociado listo para el consumo por bundlers como Vite o Webpack.
La Capa de Interoperabilidad: wasm-bindgen y Manejo de Excepciones
wasm-bindgen en 2026: Interoperabilidad Refinada y Sobrecarga Reducida
La cadena de herramientas wasm-bindgen sigue siendo la piedra angular para facilitar las interacciones de alto nivel entre los módulos WASM generados por Rust y JavaScript. Su evolución continua a lo largo de 2024 y 2025 se ha centrado en refinar esta interoperabilidad, reducir la sobrecarga y mejorar la experiencia del desarrollador. La organización rustwasm de GitHub, después de años de inactividad, fue archivada oficialmente en 2024, y el repositorio wasm-bindgen en sí se transfirió a una nueva organización wasm-bindgen a finales de 2025. Esta transición significa una reorganización y un enfoque renovado en el mantenimiento a largo plazo del proyecto en lugar de una disminución.
Las actualizaciones recientes han traído enlaces WebIDL ampliados, lo que permite una interacción más directa y eficiente con las API web. Esto significa que wasm-bindgen puede generar código de pegamento JavaScript más optimizado, a menudo reduciendo la necesidad de shims manuales y código repetitivo. Las anotaciones de tipo mejoradas para TypeScript también son una gran victoria, mejorando la ergonomía del desarrollador y el análisis estático para proyectos Rust/TypeScript mixtos. Por ejemplo, pasar estructuras Rust complejas a funciones JavaScript o viceversa se ha simplificado, con wasm-bindgen manejando el diseño de la memoria y las conversiones de tipo de manera inteligente. Al depurar estas estructuras de datos complejas, puede usar este Formateador JSON para verificar su estructura antes de pasarla a través del límite.
Considere un escenario en el que necesita pasar un Vec<String> de Rust a JavaScript. En versiones anteriores, esto podría implicar la asignación y copia manuales en la memoria lineal de WASM, seguidas de la decodificación de cadenas en JavaScript. Con los avances recientes de wasm-bindgen, el proceso a menudo se abstrae:
#[wasm_bindgen]
pub struct DataProcessor {
// ...
}
#[wasm_bindgen]
impl DataProcessor {
pub fn new() -> DataProcessor {
// ...
}
pub fn process_strings(&self, input: Vec<JsValue>) -> Vec<JsValue> {
let rust_strings: Vec<String> = input
.into_iter()
.map(|js_val| js_val.as_string().expect("Expected string"))
.collect();
let processed_strings: Vec<String> = rust_strings.into_iter().map(|s| format!("Processed: {}", s)).collect();
processed_strings.into_iter().map(JsValue::from).collect()
}
}
Este ejemplo ilustra cómo wasm-bindgen facilita el intercambio de tipos de alto nivel, abstrayendo gran parte de la FFI de bajo nivel. En comparación con las exportaciones WASM sin procesar que requieren gestión manual de la memoria y conversiones de tipo, wasm-bindgen proporciona una capa de conveniencia que es 3-5 veces más rápida que JavaScript puro para funciones con uso intensivo de computación, incluso con la ligera sobrecarga de la conversión de datos.
Realidad a Tener en Cuenta: Si bien wasm-bindgen es robusto, la depuración aún es un área con margen de mejora. Si bien las herramientas de desarrollo de los navegadores modernos ofrecen una depuración WASM integrada con soporte de mapas de origen e información de depuración DWARF, recorrer el código Rust e inspeccionar estructuras de datos complejas aún puede ser más engorroso que la depuración pura de JavaScript. Esto es una consecuencia de la pila de múltiples lenguajes y las optimizaciones involucradas.
Manejo de Excepciones de WebAssembly: Un Modelo de Errores Más Limpio
La propuesta de Manejo de Excepciones de WebAssembly, una característica que ha tenido soporte básico en todos los navegadores principales desde principios de 2025, representa un paso crucial hacia un modelo de errores más robusto y predecible. Históricamente, las excepciones lanzadas desde los módulos WASM a menudo se manifestaban como errores JavaScript opacos, lo que dificultaba la depuración y la recuperación de errores elegante.
La propuesta actualizada introduce el valor exnref, que aborda varios problemas con el enfoque existente, en particular facilitando que la API de JavaScript maneje la identidad de las excepciones lanzadas. Este valor exnref también simplifica tanto la especificación como las implementaciones del motor. El objeto WebAssembly.Exception en JavaScript ahora proporciona una forma estructurada de interactuar con las excepciones WASM. Los desarrolladores pueden definir objetos WebAssembly.Tag en JavaScript, que definen de forma única el tipo de una excepción, incluidos el orden y los tipos de datos de sus argumentos. Esto permite que las excepciones lanzadas desde Rust (u otros lenguajes WASM) se capturen e inspeccionen con seguridad de tipos en JavaScript, o viceversa.
Por ejemplo, una función Rust podría lanzar una excepción:
#[wasm_bindgen]
pub fn divide_numbers(a: i32, b: i32) -> Result<i32, JsValue> {
if b == 0 {
return Err(JsValue::from_str("Division by zero error"));
}
Ok(a / b)
}
En el lado de JavaScript, con las definiciones WebAssembly.Tag adecuadas, ahora puede capturar e inspeccionar estos errores con mayor fidelidad:
import init, { divide_numbers, MyWasmErrorTag } from './pkg/my_module.js';
async function run() {
await init();
try {
let result = divide_numbers(10, 0);
console.log("Result:", result);
} catch (e) {
if (e instanceof WebAssembly.Exception && e.is(MyWasmErrorTag)) {
const errorMessage = e.getArg(0);
console.error("Caught WASM-specific error:", errorMessage);
} else {
console.error("Caught generic error:", e);
}
}
}
run();
Este mecanismo de manejo de excepciones mejorado mejora la robustez de las aplicaciones híbridas, lo que permite estrategias de informes y recuperación de errores más precisas, alejándose del patrón anterior de depender de objetos Error genéricos de JavaScript o codificar manualmente los estados de error en los valores de retorno.
El Futuro de los Tiempos de Ejecución Web y la Orquestación
Evolución del Tiempo de Ejecución del Navegador: JIT y Optimización del Cargador
El rendimiento de WebAssembly no solo depende del lenguaje de origen o de la cadena de compilación; el motor JavaScript del navegador y el tiempo de ejecución de WASM desempeñan un papel igualmente crítico. A lo largo de 2024 y 2025, los principales motores de los navegadores como V8 (Chrome), SpiderMonkey (Firefox) y JavaScriptCore (Safari) han continuado invirtiendo fuertemente en la optimización de sus canalizaciones de ejecución de WASM.
Se han logrado avances significativos en la compilación JIT (Just-In-Time) para WASM. Los motores modernos ahora emplean la compilación en niveles, donde el código se compila inicialmente rápidamente para un inicio rápido y luego se vuelve a compilar con optimizaciones más agresivas para las rutas críticas. Este enfoque, combinado con la compilación en flujo (ahora estándar en todos los navegadores principales), reduce drásticamente la fase de "análisis y compilación", lo que permite velocidades de inicio cercanas a las nativas para aplicaciones complejas. Por ejemplo, la aceleración de la carga inicial reportada por juegos y herramientas gráficas a gran escala es un resultado directo de estas mejoras, minimizando los períodos de "espera" que los usuarios experimentaban anteriormente.
La huella de memoria y los tiempos de instanciación también han visto mejoras constantes. Las optimizaciones en la forma en que se instancian los módulos WASM y cómo se gestiona su memoria lineal contribuyen a la capacidad de respuesta general. La integración de WasmGC directamente en el tiempo de ejecución del navegador, por ejemplo, descarga la carga de la recolección de basura de los módulos WASM individuales, lo que permite que el motor gestione la memoria de manera más eficiente y consistente en toda la aplicación. Estos avances continuos, a menudo invisibles, en los tiempos de ejecución del navegador son críticos para traducir las ganancias de rendimiento teóricas de WASM en experiencias de usuario del mundo real.
Información de Expertos: La Capa de Orquestación de WebAssembly
A medida que las características de WebAssembly como el Modelo de Componentes, WasmGC, Hilos y SIMD maduran, el enfoque para 2026 y más allá se desplazará cada vez más de la optimización del rendimiento de los módulos individuales a la orquestación y la gestión del ciclo de vida de las colecciones de componentes WASM. Estamos presenciando las primeras etapas de una capa de abstracción de nivel superior que está surgiendo: una "capa de orquestación WASM" que gestionará la composición, el despliegue y la comunicación entre los componentes WebAssembly, potencialmente en diferentes tiempos de ejecución (navegador, servidor, borde).
Esto no se trata de reemplazar por completo los marcos JavaScript existentes, sino de crear una base sólida para construir segmentos de aplicaciones altamente eficientes, componibles y agnósticos del lenguaje. Considere el auge de los meta-marcos en el mundo de JavaScript; una evolución similar está en el horizonte para WASM. Veremos marcos que no solo se compilan a WASM, sino que están construidos sobre los principios del Modelo de Componentes, ofreciendo mecanismos nativos para el descubrimiento de servicios, el control de versiones y la ejecución con sandbox segura de los componentes WASM. Esto podría manifestarse como marcos de interfaz de usuario nativos de WASM que aprovechen el Modelo de Componentes para la modularidad y el estado compartido, o bundlers avanzados que comprendan los gráficos de componentes y optimicen su carga y vinculación para destinos de implementación específicos. Las líneas borrosas entre lo que es "JS" y lo que es "WASM" se volverán aún más pronunciadas, con los desarrolladores interactuando con interfaces de alto nivel que delegan de forma transparente al entorno de ejecución óptimo. La capacidad de cargar, actualizar y descargar dinámicamente los componentes WASM sin actualizaciones de página, impulsada por el control de versiones semántico definido en WIT, se convertirá en un diferenciador crítico para las aplicaciones web modernas que requieren una agilidad y una eficiencia de recursos extremas. Esto permitirá a los desarrolladores actualizar partes específicas de una aplicación sin volver a implementar todo el código base, lo que conducirá a ciclos de iteración significativamente más rápidos y una sobrecarga operativa reducida.
Conclusión: Un Futuro Robusto para las Aplicaciones Web
Los avances en WebAssembly, particularmente cuando se combinan con Rust y la cadena de herramientas wasm-bindgen en evolución, han solidificado su posición como una tecnología práctica y eficiente para aplicaciones web de alto rendimiento. El Modelo de Componentes promete una verdadera modularidad e interoperabilidad de lenguajes, mientras que WasmGC elimina una barrera significativa para los lenguajes administrados, beneficiando indirectamente la historia de interoperabilidad de Rust. La amplia disponibilidad de Hilos y SIMD ofrece ganancias de rendimiento tangibles para las cargas de trabajo altamente paralelizables e intensivas en computación, respaldadas por puntos de referencia de 2025 convincentes que muestran aumentos de rendimiento de 8-10 a 10-15 veces sobre JavaScript puro en escenarios específicos.
Sin embargo, es crucial mantener una perspectiva pragmática. WASM no es una panacea universal. Destaca en tareas deterministas y con uso intensivo de la CPU, pero no está diseñado para la manipulación directa del DOM o la lógica empresarial simple donde JavaScript sigue siendo la opción pragmática. Los compromisos en el tamaño del binario (una sobrecarga mínima de ~40-50 KB para el binario + código de pegamento) y la complejidad de la depuración, y la necesidad actual de transpilación para el soporte del Modelo de Componentes en el navegador deben sopesarse frente a las ganancias de rendimiento.
En 2026, la estrategia sigue siendo clara: perfilar primero, identificar las rutas críticas de rendimiento y descargar selectivamente estas a WebAssembly generado por Rust. El ecosistema, con sus herramientas maduras, su sólido soporte del navegador y una hoja de ruta clara para una mayor integración, ofrece una base sólida para construir aplicaciones web que realmente superen los límites del rendimiento y las capacidades. El futuro no se trata de reemplazar JavaScript, sino de aumentarlo con un motor de computación potente, seguro y cada vez más ergonómico.
Fuentes
Este artículo fue publicado por el Equipo Editorial de DataFormatHub, un grupo de desarrolladores y entusiastas de los datos dedicados a hacer que la transformación de datos sea accesible y privada. Nuestro objetivo es proporcionar información técnica de alta calidad junto con nuestro conjunto de herramientas de desarrollador centradas en la privacidad.
🛠️ Herramientas Relacionadas
Explore estas herramientas de DataFormatHub relacionadas con este tema:
- Codificador Base64 - Codifique los binarios WASM
- Formateador JSON - Formatee los archivos de configuración