Por qué ports y no llamadas directas a JavaScript

Existe una pregunta que todo programador se hace la primera vez que necesita usar una biblioteca de JavaScript desde Elm, y que suele formularse con cierta impaciencia: por qué no puedo simplemente llamarla. En casi cualquier otro lenguaje compilado al navegador la respuesta sería que sí puedes. TypeScript llama a JavaScript porque es JavaScript. ReScript y PureScript ofrecen bloques de código externo que se insertan literalmente en la salida. Kotlin y Scala tienen anotaciones para declarar funciones nativas. Elm es la excepción deliberada: no hay ninguna construcción del lenguaje que permita invocar una función de JavaScript y recibir su resultado ahí mismo. La única frontera disponible es un buzón asíncrono por el que se depositan y se recogen datos, nunca se ejecutan llamadas. Esta lección defiende que esa restricción no es una limitación que Elm arrastre, sino la condición sin la cual todas sus demás promesas serían retórica vacía.

Qué se rompería con una llamada directa

Cuando se dice que un programa Elm no lanza excepciones en tiempo de ejecución, la afirmación tiene un alcance que conviene medir con precisión: no dice que sea improbable, dice que el compilador ha demostrado que no puede ocurrir, para todo el código que ha visto. Esa demostración descansa en una cadena de suposiciones que se sostienen juntas o no se sostienen: toda función es total sobre su tipo de entrada, todo valor tiene el tipo que declara, ninguna expresión muta nada, ninguna función devuelve un valor distinto ante los mismos argumentos. Introduce un único punto donde el programa pueda invocar código arbitrario y recibir de vuelta un valor cualquiera, y las cuatro suposiciones caen a la vez para todo el programa, no solo para esa línea.

Conviene notar que esta cadena no se debilita gradualmente. Un sistema de tipos no es una red que atrapa más cuanto más tupida: es un argumento deductivo, y un argumento deductivo con una premisa falsa no demuestra un poco menos, no demuestra nada. Por eso la discusión sobre las puertas de escape no admite el término medio que suele proponerse, el de usarlas con moderación. Una puerta usada con moderación sigue siendo una puerta, y el compilador no puede saber si hoy estuvo cerrada.

Piensa en qué tendría que declarar esa hipotética función de escape. Si prometiera devolver un Int, el compilador confiaría en la promesa y propagaría esa confianza por todo el grafo de llamadas, pero nadie podría verificarla: el JavaScript del otro lado puede devolver una cadena, un objeto, undefined o lanzar una excepción. La firma sería una declaración de intenciones sin respaldo, exactamente el mismo contrato roto que hace frágil a TypeScript en sus fronteras. Y el daño no se detendría en el tipo: una llamada síncrona podría mutar el modelo por referencia, disparar efectos en mitad de una expresión pura y hacer que dos evaluaciones idénticas de update produjeran resultados distintos.

-- Esto NO existe en Elm, y la lección es por qué
-- foreign eval : String -> Int


-- Lo que sí existe: una declaración de buzón
port module Main exposing (main)


-- Salida: describe un envío, no lo ejecuta
port guardar : String -> Cmd msg


-- Entrada: describe una escucha, no la resuelve
port llegoAlgo : (String -> msg) -> Sub msg

El buzón: asíncrono por diseño, no por comodidad

La forma de la frontera no es arbitraria. Un port de salida tiene el tipo de una función que recibe un dato y produce un Cmd, es decir, produce una descripción de efecto que update devuelve al runtime junto con el modelo nuevo. Nada se ejecuta en el momento de construir ese valor: update sigue siendo una función pura que recibe un mensaje y un modelo y devuelve un modelo y una descripción. Un port de entrada tiene el tipo de una función que recibe un constructor de mensaje y produce una Sub, es decir, una declaración de escucha que subscriptions devuelve. También aquí lo que se construye es un valor inerte.

flowchart LR
U[update puro] -->|Cmd del port| RT[runtime de Elm]
RT -->|dato serializado| JS[codigo JavaScript]
JS -->|dato serializado| RT2[runtime de Elm]
RT2 -->|Msg| U
style U fill:#89b4fa,color:#11111b
style JS fill:#f9e2af,color:#11111b
style RT2 fill:#a6e3a1,color:#11111b

Observa la asimetría del dibujo: no hay ninguna flecha que salga de update hacia JavaScript y vuelva a update sin pasar por el runtime. El camino de vuelta es el mismo que recorre un clic del usuario o la respuesta de una petición de red. Desde el punto de vista de la lógica de la aplicación, JavaScript no es un colaborador al que se invoca, sino otra fuente de eventos externa e indistinguible de un teclado o de un reloj.

El anfitrión deja de ser un detalle y pasa a ser una pieza

Una consecuencia del diseño que suele pasar desapercibida es que obliga a reconocer al código JavaScript que rodea a la aplicación como un componente de la arquitectura, con nombre, responsabilidades y una interfaz declarada. En un proyecto híbrido convencional, ese código no existe como entidad: son fragmentos dispersos, invocados desde donde hiciera falta, sin ningún punto donde se pueda leer qué hace el sistema fuera del lenguaje principal. Con ports, en cambio, hay un archivo concreto que monta la aplicación, se suscribe a las salidas y empuja las entradas, y ese archivo es la única superficie de contacto que existe.

// El anfitrión es una pieza con contrato, no un vertedero de utilidades
const app = Elm.Main.init({
  node: document.getElementById("raiz"),
  flags: { api: "https://api.ejemplo.test" },
});

// Lo que la aplicación publica hacia fuera
app.ports.guardar.subscribe(function (texto) {
  localStorage.setItem("nota", texto);
});

// Lo que el mundo empuja hacia dentro
window.addEventListener("online", function () {
  app.ports.llegoAlgo.send("conexion recuperada");
});

Léelo como se leería la definición de una interfaz: arriba, lo que la aplicación necesita para existir; en medio, los hechos que publica; abajo, los acontecimientos que se le notifican. No hay una cuarta categoría escondida, y esa ausencia es verificable con solo abrir el archivo. Cuando alguien pregunta qué hace este sistema fuera de Elm, la respuesta cabe en una pantalla, y esa propiedad no se obtiene por disciplina del equipo sino porque el lenguaje no ofrece ninguna otra vía.

El precio del rodeo y lo que compra

Sería deshonesto presentar los ports como algo cómodo. Hacer algo que en JavaScript ocuparía una línea puede exigir aquí una declaración de port, una rama nueva en el tipo de mensajes, un caso más en update, un decodificador para lo que llega de vuelta y unas cuantas líneas de conexión en el anfitrión. El rodeo es real y quien lo niegue no está argumentando. Lo que hay que discutir es qué se compra con él, porque el intercambio es concreto y medible.

-- El rodeo completo, expuesto sin adornos
type Msg
    = PulsoGuardar
    | LlegoDelExterior String


update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        PulsoGuardar ->
            ( model, guardar model.texto )

        LlegoDelExterior crudo ->
            -- Lo que entra es sospechoso hasta que se decodifica
            ( { model | ultimo = crudo }, Cmd.none )

Conviene además medir el rodeo con honestidad estadística. En una aplicación real, la cantidad de código que cruza la frontera es minúscula comparada con la que vive dentro de ella: unas pocas declaraciones frente a miles de líneas de lógica de dominio, transformación y presentación. Lo que se percibe como incomodidad se concentra en un puñado de lugares y se paga una sola vez, mientras que la garantía que compra se cobra continuamente en todo el resto. Quien evalúa el intercambio contando solo el coste está comparando un gasto puntual con un beneficio recurrente, y esa comparación siempre engaña.

Lo que se compra es esto: el conjunto de puntos del programa donde puede ocurrir algo impredecible pasa de ser difuso a ser enumerable. Puedes listar todos los ports de un proyecto con una búsqueda de texto y sabrás, con certeza, que fuera de esa lista no hay ninguna interacción con el exterior. Cuando algo falle, la investigación empieza acotada. Cuando actualices una dependencia de JavaScript, sabrás exactamente qué superficie de contacto revisar. Y cuando el compilador declare que el resto del programa no puede lanzar, no estará haciendo una estimación optimista.