El runtime de Elm: el actor invisible que ejecuta los efectos

Hemos dicho que update describe efectos pero no los ejecuta, y que subscriptions declara escuchas pero no engancha oyentes. La pregunta que queda es inevitable: entonces, ¿quién hace el trabajo? ¿Quién abre el socket, espera la respuesta, la envuelve en un Msg y lo despacha? ¿Quién activa y cancela los oyentes reales del navegador? La respuesta es el runtime de Elm, el actor invisible del sistema: el código que el compilador genera y coloca como una corteza alrededor de tu programa. Tú escribes cuatro cosas puras —init, update, view y subscriptions— y el runtime es todo lo demás, el motor que las orquesta y que concentra, en un único lugar ajeno a ti, toda la impureza del programa. Comprenderlo es dejar de ver la Arquitectura Elm como un conjunto de reglas y verla como lo que es: un contrato entre tu núcleo puro y un intérprete impuro que ejecuta por ti lo que tú solo te atreviste a describir.

El bucle que nunca escribes

El runtime es una máquina de eventos que gira sin descanso y cuyo estado es tu modelo. Su ciclo puede narrarse paso a paso. Guarda en su interior el modelo actual. Cuando ocurre un evento —al arrancar, un Msg que produjo el resultado de un comando, un Msg que emitió una suscripción, o un Msg disparado por la vista— el runtime llama a tu update con ese mensaje y el modelo que custodia. Recibe de vuelta la tupla ( nuevoModelo, cmd ). Entonces hace cuatro cosas que tú nunca escribes: sustituye el modelo por el nuevo, llama a view nuevoModelo y aplica al DOM real el diff con el DOM virtual anterior, ejecuta el cmd realizando la entrada y salida de verdad, y llama a subscriptions nuevoModelo para reconciliar los oyentes activos. Los resultados del comando y los eventos de las suscripciones regresan como nuevos Msg, y el bucle vuelve a empezar.

flowchart TD
Init[init produce Model y Cmd] --> RT[runtime]
RT -->|Model actual| V[view]
V -->|Html Msg| Pantalla[Pantalla]
Pantalla -->|evento Msg| RT
RT -->|Msg y Model| U[update pura]
U -->|Model nuevo y Cmd| RT
RT -->|ejecuta Cmd| Mundo[Mundo exterior]
Mundo -->|resultado Msg| RT
RT -->|reconcilia Sub| Subs[subscriptions]
Subs -->|evento Msg| RT
style RT fill:#cba6f7,color:#11111b
style U fill:#a6e3a1,color:#11111b

Lo decisivo de este dibujo es dónde está cada color. Todo lo verde —update, y por igual view, init y subscriptions— es tuyo y es puro: funciones que transforman valores en valores. Todo lo que ejecuta, espera, pinta y escucha —el nodo malva— es el runtime, y es lo único impuro. La flecha ejecuta Cmd es la única del sistema que toca el mundo, y no la escribes tú.

Núcleo puro, corteza impura, impuesto por el lenguaje

Este reparto tiene un nombre en la disciplina del diseño: núcleo funcional rodeado de una corteza imperativa. La idea circula por muchas comunidades como buena práctica que uno se esfuerza en respetar. Lo singular de Elm es que no la propone como consejo sino que la impone por construcción: el lenguaje, al no darte ninguna función pura que ejecute efectos, hace literalmente imposible mezclar núcleo y corteza. No puedes filtrar impureza a update aunque quieras, porque no existe la herramienta para hacerlo. La separación deja de depender de tu disciplina y pasa a estar garantizada por el sistema de tipos.

-- Browser.element cablea las cuatro piezas puras al runtime
main : Program () Model Msg
main =
    Browser.element
        { init = init                 -- () -> ( Model, Cmd Msg )
        , update = update             -- Msg -> Model -> ( Model, Cmd Msg )
        , view = view                 -- Model -> Html Msg
        , subscriptions = subscriptions  -- Model -> Sub Msg
        }

Browser.element es el punto donde entregas tus cuatro funciones puras al runtime y recibes un Program ejecutable. Fíjate en init: su tipo es () -> ( Model, Cmd Msg ), la misma tupla que update. Esto significa que hasta los efectos iniciales —pedir datos nada más cargar, leer la hora de arranque— se describen igual que cualquier otro: init no ejecuta la primera petición, devuelve su descripción y el runtime la ejecuta. No hay ninguna fase especial de puesta en marcha con reglas distintas; el arranque es solo la primera vuelta del mismo bucle. Browser.document y Browser.application amplían el contrato —control del título, del cuerpo entero, de la navegación por URL— pero conservan exactamente esta estructura de cuatro piezas.

Por qué el runtime puede prometer lo que promete

Que exista un único actor impuro, escrito una vez por el equipo de Elm y compartido por todos los programas, no es solo elegante: es la fuente técnica de las garantías más citadas del lenguaje. La promesa de cero excepciones en tiempo de ejecución sería imposible si tu código pudiera ejecutar efectos, porque la entrada y salida es justo donde nacen los fallos que el compilador no puede prever. Pero como todo efecto pasa por el runtime, este puede envolver cada ejecución, capturar cualquier fallo del mundo y entregártelo como un valor —un Err dentro de un Msg— en lugar de como una excepción que revienta la pila. Un 500 del servidor no lanza nada: llega como un dato que tu update debe manejar. El mismo hecho —el runtime es el dueño de la frontera de efectos— habilita el depurador con viaje en el tiempo, que graba la secuencia de mensajes y la reproduce, y la recarga en caliente que preserva el estado, porque el runtime controla los dos únicos flujos que existen: los mensajes que entran y los comandos que salen.