{"id":499,"date":"2026-03-09T13:23:48","date_gmt":"2026-03-09T13:23:48","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/webassembly-in-2026-where-it-actually-makes-sense\/"},"modified":"2026-03-18T22:31:21","modified_gmt":"2026-03-18T22:31:21","slug":"webassembly-in-2026-where-it-actually-makes-sense","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/webassembly-in-2026-where-it-actually-makes-sense\/","title":{"rendered":"WebAssembly en 2026: D\u00f3nde Realmente Tiene Sentido Reemplazar JavaScript"},"content":{"rendered":"

Llevo ignorando WebAssembly desde m\u00e1s o menos 2022. No porque pensara que era mala tecnolog\u00eda \u2014 era m\u00e1s que cada vez que lo intentaba, el dolor de la toolchain superaba los beneficios reales que obten\u00eda. Lo prob\u00e9 con Emscripten para portar una librer\u00eda de C++, pas\u00e9 dos d\u00edas configurando y al final el bundle pesaba 4MB y el startup time era horrible. Lo dej\u00e9 estar.<\/p>\n

Pero algo cambi\u00f3 este enero.<\/p>\n

Estaba trabajando en un proyecto de procesamiento de im\u00e1genes para un cliente \u2014 una web app que necesitaba aplicar filtros y transformaciones complejas en el<\/a> cliente, sin enviar datos al servidor por razones de privacidad. El equipo \u00e9ramos tres personas. Y por<\/a> primera vez en a\u00f1os, WASM no solo tuvo sentido sino que fue claramente la decisi\u00f3n correcta. Pas\u00e9 dos semanas<\/a> yendo y viniendo entre implementaciones en JavaScript puro y Rust compilado a WASM, y lo que<\/a> encontr\u00e9 cambi\u00f3 bastante c\u00f3mo pienso en todo esto.<\/p>\n

\n

Los n\u00fameros que me convencieron (y los que no tanto)<\/h2>\n

Empec\u00e9 con algo concreto: un filtro de convoluci\u00f3n 5\u00d75 aplicado a im\u00e1genes de 4K. Nada del otro mundo algor\u00edtmicamente, pero computacionalmente intenso si lo haces en JavaScript puro iterando sobre ImageData.<\/p>\n

La implementaci\u00f3n en JS, optimizada razonablemente con TypedArrays y sin objetos intermedios:<\/p>\n

\/\/ JS puro \u2014 sin librer\u00edas, TypedArrays directos\nfunction convolve5x5(data, width, height, kernel) {\n  const output = new Uint8ClampedArray(data.length);\n  const offset = 2; \/\/ Math.floor(5 \/ 2)\n\n  for (let y = offset; y < height - offset; y++) {\n    for (let x = offset; x < width - offset; x++) {\n      let r = 0, g = 0, b = 0;\n      for (let ky = 0; ky < 5; ky++) {\n        for (let kx = 0; kx < 5; kx++) {\n          const px = ((y + ky - offset) * width + (x + kx - offset)) * 4;\n          const kv = kernel[ky * 5 + kx];\n          r += data[px]     * kv;\n          g += data[px + 1] * kv;\n          b += data[px + 2] * kv;\n        }\n      }\n      const out = (y * width + x) * 4;\n      output[out]     = Math.min(255, Math.max(0, r));\n      output[out + 1] = Math.min(255, Math.max(0, g));\n      output[out + 2] = Math.min(255, Math.max(0, b));\n      output[out + 3] = data[out + 3]; \/\/ preservar alpha\n    }\n  }\n  return output;\n}\n<\/code><\/pre>\n
Resultado promedio en Chrome 133, imagen de 3840\u00d72160: ~820ms<\/strong>.<\/p>\n
La misma l\u00f3gica en Rust, compilada con wasm-pack 0.13.1 y wasm-opt -O3<\/code>:<\/p>\n
\/\/ Rust \u2014 wasm-bindgen genera el glue de JS autom\u00e1ticamente\nuse wasm_bindgen::prelude::*;\n\n#[wasm_bindgen]\npub fn convolve_5x5(\n    data: &[u8],\n    width: usize,\n    height: usize,\n    kernel: &[f32],\n) -> Vec<u8> {\n    let mut output = vec![0u8; data.len()];\n    let offset = 2usize;\n\n    for y in offset..(height - offset) {\n        for x in offset..(width - offset) {\n            let (mut r, mut g, mut b) = (0f32, 0f32, 0f32);\n            for ky in 0..5usize {\n                for kx in 0..5usize {\n                    let px = ((y + ky - offset) * width + (x + kx - offset)) * 4;\n                    let kv = kernel[ky * 5 + kx];\n                    r += data[px]     as f32 * kv;\n                    g += data[px + 1] as f32 * kv;\n                    b += data[px + 2] as f32 * kv;\n                }\n            }\n            let out = (y * width + x) * 4;\n            output[out]     = r.clamp(0.0, 255.0) as u8;\n            output[out + 1] = g.clamp(0.0, 255.0) as u8;\n            output[out + 2] = b.clamp(0.0, 255.0) as u8;\n            output[out + 3] = data[out + 3];\n        }\n    }\n    output\n}\n<\/code><\/pre>\n
Resultado: ~95ms<\/strong>. Casi 9\u00d7 m\u00e1s r\u00e1pido.<\/p>\n
Ese n\u00famero hay que tomarlo con contexto. El m\u00f3dulo WASM pesa 180KB gzippeado y tiene un overhead de instanciaci\u00f3n de 15-40ms la primera vez en Chrome. Para una operaci\u00f3n que el usuario dispara una sola vez en toda la sesi\u00f3n, ese costo inicial puede importar. Para algo que se repite \u2014 y en este proyecto se repet\u00eda constantemente \u2014 se amortiza r\u00e1pido.<\/p>\n
Lo que no esperaba: en Firefox 134 el salto fue de solo ~5.5\u00d7 con los mismos datos. No encontr\u00e9 una explicaci\u00f3n definitiva. Sospecho que tiene que ver con c\u00f3mo el JIT de Firefox optimiza bucles num\u00e9ricos densos sobre TypedArrays, que quiz\u00e1s ya los vectoriza mejor que Chrome internamente. Tu kilometraje puede variar.<\/p>\n
\n
Los tres casos donde WASM gana de forma consistente<\/h2>\n
Despu\u00e9s de las dos semanas<\/a>, y de hablar con un par de personas del equipo que hab\u00edan experimentado cosas similares, llegu\u00e9 a tres categor\u00edas donde lo usar\u00eda sin pensarlo dos veces.<\/p>\n
Procesamiento de medios en el<\/a> cliente.<\/strong> Este fue exactamente el caso del proyecto de privacidad \u2014 transformaciones de imagen, codificaci\u00f3n de audio, muxing de video, cualquier cosa que implique iterar sobre millones de bytes con operaciones aritm\u00e9ticas. ffmpeg.wasm en 2026<\/a> ya no es el desastre de startup que era en 2023; el tiempo de instanciaci\u00f3n baj\u00f3 considerablemente con las mejoras en compilaci\u00f3n streaming. Sigue sin ser trivial de integrar, pero al menos ya no me hace querer tirar el laptop.<\/p>\n
Criptograf\u00eda computacionalmente costosa.<\/strong> Los n\u00fameros aqu\u00ed son brutales. Argon2id en JavaScript es pr\u00e1cticamente inutilizable con par\u00e1metros de seguridad reales \u2014 en un proyecto de notas cifradas end-to-end que termin\u00e9 en noviembre, medir argon2 con memory_cost=65536<\/code> e iterations=3<\/code> daba ~4500ms en JS puro. Con WASM: ~280ms, mismos par\u00e1metros. La diferencia entre “el usuario espera casi cinco segundos” y “el usuario no nota nada” es lo que<\/a> decide si un feature existe o no.<\/p>\n
Portar librer\u00edas probadas de otros lenguajes.<\/strong> Si ya existe c\u00f3digo de C\/C++\/Rust con a\u00f1os de tests y auditor\u00edas, reescribirlo en JS es tiempo, riesgo de bugs de compatibilidad y potenciales regresiones de seguridad. Aqu\u00ed Emscripten 3.1.x ha madurado bastante \u2014 sigue siendo m\u00e1s verboso que wasm-pack para c\u00f3digo Rust nuevo, pero para bindings de librer\u00edas existentes es la opci\u00f3n pragm\u00e1tica. No me pagan por reescribir c\u00f3digo que ya funciona.<\/p>\n
\n
El problema del boundary que descubr\u00ed<\/a> de la peor manera<\/h2>\n
Aqu\u00ed viene la parte donde pens\u00e9 que entend\u00eda WASM y result\u00f3 que no.<\/p>\n
Estaba seguro de que si WASM era 9\u00d7 m\u00e1s r\u00e1pido en el<\/a> benchmark aislado, tambi\u00e9n optimizar\u00eda la detecci\u00f3n de bordes que hac\u00eda frame a frame sobre un canvas de 720p a 30fps. La l\u00f3gica parec\u00eda s\u00f3lida: operaci\u00f3n intensa, muchas multiplicaciones, candidato perfecto.<\/p>\n
Lo implement\u00e9. Lo med\u00ed. Era m\u00e1s lento<\/strong> que JavaScript.<\/p>\n
Pas\u00e9 un d\u00eda entero convencido de que hab\u00eda un bug en mi Rust. No hab\u00eda bug.<\/p>\n
El problema era el boundary crossing. Cada vez que JavaScript llama a una funci\u00f3n WASM y le pasa datos, hay un overhead de copia de memoria \u2014 el linear memory de WASM y el heap de JS son espacios separados, no hay zero-copy por defecto. Para el filtro de convoluci\u00f3n, pasaba el buffer de imagen una vez, procesaba todo internamente y devolv\u00eda el resultado. El overhead del boundary era insignificante comparado con el trabajo<\/a> real.<\/p>\n
Para el detector de bordes por frames, estaba llamando a la funci\u00f3n WASM 30 veces por segundo, cada vez copiando un buffer de ~3.3MB (1280\u00d7720\u00d74 bytes). Esa copia era m\u00e1s costosa que simplemente ejecutar el algoritmo en JS. La funci\u00f3n WASM era r\u00e1pida. El problema era que la llamaba demasiadas veces con datos demasiado grandes.<\/p>\n
La soluci\u00f3n fue mover el bucle de frames tambi\u00e9n dentro de WASM, pasar los frames por SharedArrayBuffer desde un Worker, y dejar que WASM manejara la acumulaci\u00f3n por completo. Funcion\u00f3, pero la complejidad de setup subi\u00f3 bastante. Y honestamente, en retrospectiva, para ese caso espec\u00edfico WebGPU hubiera sido m\u00e1s directo.<\/p>\n
Esto es lo que<\/a> m\u00e1s me cambi\u00f3 el criterio: la granularidad de las llamadas importa tanto como el volumen total de c\u00f3mputo. Una sola llamada que procesa 10MB de golpe es completamente diferente a 300 llamadas que procesan 33KB cada una.<\/p>\n
\n
El stack que uso actualmente<\/h2>\n
Para proyectos donde WASM tiene sentido, mi configuraci\u00f3n en 2026<\/a>:<\/p>\n