Las ideas que se quedaron: el patrimonio común del frontend

Hay lenguajes que ganan por difusión y lenguajes que ganan por infiltración, y confundir las dos cosas lleva a diagnósticos absurdos sobre el éxito o el fracaso. Smalltalk nunca fue mayoritario y su vocabulario está dentro de todo lo que programamos; Lisp lleva sesenta años siendo minoritario y las funciones de primera clase, la recolección de basura y las macros están en todas partes. Elm pertenece a esa familia, y su caso es aún más nítido porque el trasvase ocurrió en poco más de una década y quedó documentado en blogs, charlas y notas de versión que cualquiera puede consultar. En 2013 defender que una interfaz debía ser una función pura del estado, que los estados imposibles debían ser imposibles de escribir y que un compilador debía disculparse por interrumpirte eran posiciones excéntricas que había que argumentar en cada conversación. Hoy son el contenido de la documentación oficial de los frameworks más usados del mundo, escritas como si siempre hubieran sido obvias. Esta lección hace el recuento de ese patrimonio con dos cautelas. La primera es no atribuir a Elm la paternidad de ideas que venían de la familia de lenguajes de la que él mismo bebía, porque los tipos suma y la ausencia de nulo llevaban décadas en circulación. La segunda, más importante, es no dejarse llevar por la celebración y mirar de frente lo que no se transmitió, porque en esa segunda lista está la parte útil de la herencia para quien tiene que decidir hoy cómo se construye un sistema.

Lo que ya nadie discute

La primera idea que se quedó es la vista como función pura del estado. React la popularizó, SwiftUI la impone, Compose la impone, Svelte la asume y hasta las bibliotecas de reactividad de grano fino la respetan aunque cambien el mecanismo de propagación. La segunda es el flujo unidireccional con una única fuente de verdad, que sobrevive incluso allí donde el estado no está centralizado, porque la regla operativa que se generalizó no es hay un solo estado sino cada dato tiene un dueño y solo su dueño lo modifica. La tercera es el evento como dato: acciones serializables, intenciones, mensajes, llámense como se llamen, en lugar de llamadas a métodos, y con ellas toda la familia de herramientas que solo son posibles si el evento es un valor, desde los depuradores con historial hasta la reproducción de sesiones a partir de un registro.

La cuarta y la quinta vienen del sistema de tipos y son, con diferencia, las que más han cambiado el trabajo cotidiano. Modelar con tipos suma para que los estados imposibles no se puedan escribir dejó de ser una excentricidad académica cuando las uniones discriminadas de TypeScript, las interfaces selladas de Kotlin, las enumeraciones con valores asociados de Swift y las de Rust pusieron la herramienta al alcance de todo el mundo; y la eliminación del nulo mediante un tipo opcional explícito es hoy la posición mayoritaria en todos los lenguajes que se diseñan de nuevo. Ninguna de las dos nació en Elm, y decirlo importa, pero Elm fue el vehículo que las trajo al frontend y la comunidad donde se aprendió a explicarlas a programadores que no venían de la teoría de lenguajes.

// Antes: cuatro campos que permiten dieciseis combinaciones,
// de las cuales solo tres tienen sentido
type Pantalla = {
  cargando: boolean
  error: string | null
  datos: Usuario[] | null
  vacio: boolean
}

// Despues: tres estados y ninguno mas
type Pantalla =
  | { estado: 'cargando' }
  | { estado: 'error'; mensaje: string }
  | { estado: 'listo'; datos: Usuario[] }

La sexta idea es el error como valor en lugar del error como interrupción. Devolver un tipo que representa el éxito o el fallo, y obligar a quien lo recibe a decidir qué hace con cada rama, era en 2013 una práctica de comunidades minoritarias frente a la excepción como mecanismo universal; hoy es la posición del lenguaje de sistemas más influyente de la década, es lo que hacen las bibliotecas serias de acceso a red en todos los ecosistemas y es lo que la mayoría de las guías de estilo recomienda para los fallos previsibles. La séptima, y la más incompleta de todas, es el efecto como descripción: sobrevivió allí donde había un runtime dispuesto a ejecutar la descripción, como en Swift con el linaje de Point-Free, y se quedó a medias donde no lo había, que es la historia que ya conocemos de los middleware y de los canales de sucesos.

-- Dos tipos que hoy tienen equivalente exacto en Swift, Kotlin, Rust y TypeScript
type Maybe a
    = Nothing
    | Just a


type Result error valor
    = Err error
    | Ok valor


-- La consecuencia practica: el fallo esta en la firma, no en la documentacion
buscarUsuario : Id -> Result String Usuario

Lo que se quedó en el camino

La lista de lo que no se transmitió es más corta y mucho más reveladora, porque todos sus elementos comparten un rasgo. La pureza obligatoria no viajó: en todos los entornos herederos es posible escribir un efecto en medio de una función que dice ser una transición, y solo la disciplina lo impide. La ausencia de escotillas de escape no viajó: TypeScript tiene una anotación que apaga el verificador, Kotlin tiene la doble exclamación, Swift tiene el desenvuelto forzoso, y en todos los casos existen porque sin ellas la migración de código antiguo habría sido imposible. La interoperación exclusivamente por puertos no viajó: nadie aceptó que hablar con el anfitrión requiriera declarar antes cada canal. Y el versionado mayor decidido por el compilador comparando interfaces públicas tampoco viajó, pese a ser la idea más obviamente correcta de todo el conjunto.

// Las tres escotillas mas usadas del ecosistema, y lo que cuesta cada una
const usuario = datos as Usuario          // apago la comprobacion aqui
// @ts-expect-error                        // apago la comprobacion en esta linea
const nombre = respuesta!.nombre          // afirmo que no es nulo sin probarlo

Ninguna de las tres es un error de diseño de sus lenguajes; las tres son el precio explícito que se pagó para que millones de líneas existentes pudieran migrar de forma gradual. Pero conviene ver lo que ocurre con ellas en la práctica: se introducen para desbloquear una migración, se quedan, se copian por imitación y acaban apareciendo en código nuevo escrito años después, cuando ya no queda nada que migrar. La escotilla temporal es la forma más común de deuda permanente.

flowchart TB
I[Idea de Elm] --> A{Se puede adoptar sin cerrar puertas}
A -->|Si| B[Se convierte en patrimonio comun]
A -->|No| C[Se queda en Elm]
B --> D[Vista pura, eventos como datos, tipos suma]
C --> E[Pureza obligatoria, sin escotillas, semver comprobado]
D --> F[La garantia pasa a ser convencion]
F --> G[Linter, revision o nadie]
style B fill:#a6e3a1,color:#11111b
style C fill:#f38ba8,color:#11111b
style G fill:#f9e2af,color:#11111b

Conviene ser franco también sobre el propio Elm, porque una lección que termine en apología no sirve de nada. El proyecto publicó su última versión mayor en 2018 y una revisión menor en 2019, y desde entonces el ritmo público ha sido casi nulo; el debate sobre la gobernanza, sobre la lentitud y sobre las restricciones impuestas al código nativo alejó a parte de la comunidad, y muchas empresas que lo habían adoptado migraron. Nada de eso invalida las ideas, del mismo modo que la suerte comercial de Smalltalk no invalidó la orientación a objetos, pero explica por qué la herencia viaja hoy sin el nombre del remitente y por qué la mayoría de quienes la usan no sabrían decir de dónde viene.

Qué hacer con esta herencia

La parte accionable de todo el recorrido cabe en una pregunta que conviene hacerse ante cada patrón que se adopta: cuando esta forma funcionaba en su casa, quién impedía que se rompiera, y en la mía quién lo impide. Hay cuatro respuestas posibles y solo la primera es tranquilizadora. La sostiene el compilador, y entonces la garantía es real y no hay que volver a pensar en ella. La sostiene una herramienta automática, y entonces es casi real, siempre que nadie pueda desactivarla sin discusión. La sostiene la revisión de código, y entonces es tan buena como el peor día del equipo. No la sostiene nadie, y entonces no es una garantía sino una intención, y el sistema producirá tarde o temprano exactamente los fallos que el patrón decía evitar.

El ejercicio no es teórico y cabe en un fichero de configuración. Convertir una convención en una regla automática cuesta media tarde y cambia su naturaleza: deja de depender de que alguien se acuerde durante una revisión apresurada y pasa a fallar en la integración continua, que es la única forma de disciplina que no se erosiona con el cansancio ni con la rotación del equipo. Lo mismo vale para la exhaustividad, que en la mayoría de los lenguajes está detrás de una opción del compilador que muchos proyectos dejan en modo aviso por comodidad y que debería estar en modo error desde el primer día.

// Una garantia sin mecanismo es una intencion; con mecanismo, es una regla
export default {
  rules: {
    'no-restricted-imports': ['error', {
      paths: ['node:crypto', 'axios'],
      // en los ficheros de transicion, ningun efecto puede entrar
    }],
    '@typescript-eslint/switch-exhaustiveness-check': 'error',
  },
}

Y queda una última recomendación, menos técnica y probablemente más duradera. Cuando una idea se vuelve invisible, la única forma de mantenerla viva es enseñarla con su historia: no como regla que se acata, sino como respuesta a un problema que alguien tuvo antes y que volverá a aparecer. Esa es, en el fondo, la razón de ser de un nivel entero dedicado al legado de un lenguaje que casi nadie usa.