Elegir backend: cuándo Wasm, cuándo JS, cuándo ninguno

Cuando una plataforma ofrece dos caminos hacia el mismo destino, la pregunta interesante nunca es cuál es mejor sino qué restricción es la que manda en el caso concreto, porque los dos caminos existen precisamente porque ninguna respuesta única servía para todos. Kotlin llega a la web por dos rutas que comparten lenguaje, biblioteca estándar y modelo de concurrencia, y difieren en todo lo demás: una emite JavaScript y hereda la fluidez y la laxitud de ese mundo; la otra emite un binario verificado que ejecuta más rápido y habla con el exterior a través de una frontera estrecha y explícita. Elegir entre ambas comparando cifras de rendimiento es el error más común y el más caro, porque el rendimiento rara vez es la restricción dominante en un proyecto de web, mientras que la intensidad de la interoperabilidad, la naturaleza de la interfaz y el conjunto de navegadores que hay que cubrir lo son casi siempre. Y conviene decir desde el principio que hay una tercera respuesta legítima, que consiste en no llevar Kotlin al navegador en absoluto.

Los tres criterios que deciden

Antes de enunciarlos conviene descartar el criterio que casi todo el mundo aplica primero y que casi nunca decide nada: la velocidad de ejecución. En una aplicación de web típica, el tiempo se va en esperar respuestas de red, en recalcular disposición y en pintar; la fracción que ocupa el cómputo del lenguaje suele ser pequeña, y duplicar o triplicar su velocidad no mueve ninguna métrica que el usuario perciba. Solo cuando existe un núcleo de cálculo real en el cliente, como un motor de reglas, un cifrado, un procesamiento de imagen o el dibujado de una interfaz completa, ese criterio pasa a mandar. Los tres que siguen mandan casi siempre.

El primero y más determinante es la intensidad de la interoperabilidad. Si el módulo tiene que conversar de forma continua y fina con código JavaScript existente, pasando objetos de forma irregular, recibiendo callbacks y manipulando estructuras cuya forma solo se conoce en ejecución, el backend adecuado es JavaScript, y esa es además la recomendación explícita de quienes mantienen ambos. La razón es estructural y ya la conocemos: allí un objeto Kotlin es un objeto JavaScript, mientras que en WebAssembly cada cruce exige una traducción y muchos tipos ni siquiera cruzan.

El segundo es la naturaleza de la interfaz. Una interfaz construida a partir del modelo de documento, con marcado, hojas de estilo y componentes del ecosistema, vive de forma natural en JavaScript. Una interfaz declarativa que se dibuja sobre un lienzo y comparte código con las versiones de móvil y escritorio es el caso de uso para el que se construyó el objetivo de WebAssembly, y donde su ventaja de ejecución se nota de verdad: las mediciones publicadas sobre cargas dominadas por la interfaz sitúan a Wasm en el entorno del triple de velocidad frente al mismo código emitido a JavaScript.

Este criterio arrastra consecuencias que van más allá del rendimiento y que conviene poner sobre la mesa antes de decidir. Una interfaz dibujada sobre un lienzo no produce marcado, de modo que la accesibilidad, la selección de texto, la búsqueda dentro de la página y la indexación dejan de venir dadas por el navegador y pasan a ser responsabilidad del marco de trabajo. Compose Multiplatform aporta soluciones para lo esencial, pero el reparto de responsabilidades cambia y hay que saberlo de antemano.

El tercero es el suelo de navegadores. El binario de Kotlin exige un motor con recolección de basura de WebAssembly, disponible desde Chrome 119, Firefox 120 y Safari 18.2. Para un producto interno o para una audiencia que actualiza, esto es irrelevante; para un servicio público con obligación de cubrir dispositivos antiguos, es una restricción dura que decide sola. Nótese que el criterio no admite grados: o el motor implementa la propuesta o el módulo no arranca, sin degradación posible más allá de servir una aplicación alternativa.

Hay una cuarta consideración que no es un criterio sino un aviso: la elección no tiene por qué ser exclusiva ni definitiva. Un proyecto puede declarar ambos objetivos y compartir entre ellos todo lo que no toque la frontera, pagando el precio de que el código de interoperabilidad se escriba dos veces.

kotlin {
    js { browser(); binaries.executable() }
    wasmJs { browser(); binaries.executable() }

    sourceSets {
        // Logica pura, compartida por los dos objetivos
        val commonMain by getting
        // La frontera, escrita por separado en cada uno
        val jsMain by getting
        val wasmJsMain by getting
    }
}

flowchart TD
A[Necesito Kotlin en el navegador] --> B{Interop fina y continua con JavaScript}
B -- Si --> C[Kotlin JS]
B -- No --> D{La interfaz es Compose compartida}
D -- Si --> E{Puedo exigir navegadores con WasmGC}
E -- Si --> F[Kotlin Wasm]
E -- No --> C
D -- No --> G{Solo comparto logica de negocio}
G -- Si --> H[Modulo exportado, cualquiera de los dos]
G -- No --> I[Quiza no necesito ninguno]

Qué esperar de Kotlin/Wasm

La palabra Beta describe la superficie de interoperabilidad, no la fiabilidad del código generado. Lo que puede moverse entre versiones son los detalles de cómo se declara la frontera; lo que ya no se mueve es el modelo de memoria, que descansa en una propuesta cerrada de la plataforma, ni la corrección de la ejecución. La lectura operativa es que conviene concentrar toda la interoperabilidad en una capa fina y propia, para que una eventual migración toque pocos ficheros.

El cambio más relevante del último ciclo no es de lenguaje sino de herramientas. Kotlin 2.4 declaró estable la compilación incremental de Kotlin/Wasm y la activó por defecto, de modo que el compilador reconstruye únicamente los ficheros afectados por cada edición en lugar del módulo completo. La queja histórica sobre este objetivo era casi siempre la misma, que el ciclo de editar y ver el resultado no aguantaba la comparación con el del ecosistema de web, y esa queja deja de ser válida. Sigue existiendo un interruptor para desactivarla en las propiedades del proyecto, útil solo para aislar un problema de construcción y no para el trabajo diario.

Ese interruptor vive en las propiedades del proyecto y solo debería aparecer de forma temporal, mientras se aísla un fallo de construcción sospechoso de venir de la reconstrucción parcial.

// gradle.properties del proyecto
// kotlin.incremental.wasm=false

El detalle de por qué esto costó tanto ilumina la naturaleza del objetivo. La eliminación de código muerto que hace viable el tamaño de un binario de Wasm es un análisis de programa completo, y un análisis de programa completo es, por definición, lo contrario de un análisis incremental: cambiar una línea puede alterar la alcanzabilidad de cualquier otra. Compaginar ambas cosas exigió reconstruir la contabilidad de dependencias entre ficheros, y ese es el trabajo que la serie 2.x fue completando durante tres versiones seguidas hasta estabilizarlo.

Junto a eso conviene tener presente qué implica en la práctica adoptar un objetivo en Beta. No es un problema de fiabilidad sino de coste de mantenimiento: hay que leer las notas de versión, hay que estar dispuesto a ajustar la capa de interoperabilidad una o dos veces al año y hay que evitar que una biblioteca ajena se interponga entre el proyecto y esa capa, porque entonces el ritmo de actualización ya no lo marca el equipo.

Fuera del navegador el objetivo tiene una segunda vida que conviene no pasar por alto. Con la interfaz de sistema de WebAssembly y el modelo de componentes se pueden construir servicios y complementos que se despliegan como binarios portátiles y aislados, en entornos donde la unidad de despliegue ya no es un contenedor sino un módulo. El atractivo aquí no es la velocidad sino el arranque instantáneo y el aislamiento por capacidades: un módulo no puede tocar nada que el anfitrión no le haya concedido explícitamente, lo que convierte la ejecución de código de terceros en un problema tratable. Es un territorio joven, pero es el que explica por qué este backend importa más allá de la web.

Qué esperar de Kotlin/JS

Es el objetivo maduro y el que mejor se integra. Su ventaja no está en ninguna cifra sino en la ausencia de fricción: cualquier paquete del ecosistema se consume describiéndolo, cualquier objeto se manipula con dynamic cuando no queda otra, el resultado se empaqueta con las herramientas que el equipo de web ya conoce y el módulo publicado con @JsExport es indistinguible de uno escrito allí.

// La interoperabilidad aqui no cuesta nada porque no hay traduccion:
// un objeto Kotlin ya es un objeto JavaScript
external fun observar(nodo: dynamic, opciones: dynamic): dynamic

fun montar(raiz: dynamic) {
    observar(raiz, js("({ childList: true, subtree: true })"))
}

Su punto débil es el que tiene todo JavaScript: la ejecución depende de la optimización especulativa del motor y la representación de los tipos numéricos no es la que Kotlin querría, con lo que el cálculo intensivo rinde peor y de forma menos predecible. Para la inmensa mayoría de las aplicaciones de web, eso no es la restricción que manda.

El caso de uso donde este objetivo brilla sin discusión es el del módulo compartido: una organización que ya tiene aplicaciones de móvil en Kotlin y quiere que la web use exactamente las mismas reglas de negocio, la misma validación y los mismos modelos de datos, sin reimplementarlos en otro lenguaje y sin que se desincronicen a la tercera semana.

@JsExport
class ValidadorDePedido(private val catalogo: Catalogo) {
    fun validar(lineas: Array<Linea>): Array<String> =
        lineas.flatMap { catalogo.problemasDe(it) }.toTypedArray()
}

Un módulo así se publica, se consume desde TypeScript con sus definiciones de tipos generadas y el equipo de web no necesita saber en qué lenguaje se escribió. Esa invisibilidad es el mejor indicador de que la integración se hizo bien.

Cuándo ninguno

Hay tres situaciones en las que la respuesta correcta es no compilar Kotlin al navegador, y merecen decirse con la misma claridad que las otras dos.

La primera es la de los sitios cuyo valor está en el contenido y en su indexación. Ahí lo que se necesita es marcado servido desde el servidor, accesible y legible por un rastreador sin ejecutar nada, y cualquier arquitectura que genere la página en el cliente juega en contra del objetivo del producto. Una interfaz dibujada sobre un lienzo es el caso extremo: para un rastreador, y también para un lector de pantalla mal atendido, esa página está sencillamente vacía.

La segunda es la del presupuesto de descarga muy ajustado, típica de mercados con conectividad pobre o de módulos incrustados en páginas ajenas, donde cada kilobyte se negocia y una interfaz que arrastra su propio motor de dibujo no es defendible bajo ningún argumento de productividad.

La tercera es organizativa y es la más frecuente de todas. Si el equipo de web no tiene ninguna relación con Kotlin, imponerle un backend que no sabe depurar transfiere el coste de la elección a quien no la tomó, y ese coste se cobra en cada incidente de producción a las tres de la mañana. Casi siempre sale mejor exponer la lógica compartida como un servicio, o publicar un módulo pequeño y bien tipado que el equipo consuma como cualquier otra dependencia, que unificar el lenguaje por principio.