Seguir aprendiendo: la comunidad, los frameworks, los recursos clave y un plan de dominio continuo

Hay una experiencia común a casi todo el que llega a Elm desde el ecosistema de JavaScript, y es una forma leve de desconcierto. Se busca el paquete de moda y no existe. Se mira la fecha del último lanzamiento del compilador y hace años que no cambia. Se pregunta en un foro por la hoja de ruta y la respuesta es que no hay hoja de ruta pública. Alguien concluye entonces que el lenguaje está abandonado y se marcha, y comete un error de lectura que vale la pena deshacer, porque lo que está observando no es el síntoma de una comunidad que se apaga sino la consecuencia visible de un conjunto de decisiones tomadas a propósito. Elm decidió que la estabilidad es una característica y no una falta de actividad; que un catálogo pequeño y curado vale más que uno enorme y desigual; que el versionado semántico debe imponerlo una herramienta y no la buena voluntad de los autores. Esta lección explica ese ecosistema tal como es, señala los recursos que enseñan de verdad, sitúa los frameworks disponibles con criterio para elegir, y propone el único método conocido para pasar de saber a dominar, que consiste en construir y en leer con constancia durante bastante más tiempo del que a nadie le gustaría.

Un ecosistema pequeño, estable y con reglas propias

El rasgo que más desconcierta es el ritmo. El compilador lleva mucho tiempo sin cambios de versión mayor, y esa quietud es objeto de un debate genuino dentro y fuera de la comunidad: hay quien la considera la mayor virtud del proyecto y quien la considera un riesgo de adopción, y ambas posturas tienen argumentos que merecen escucharse sin caer en la caricatura. Lo que no admite discusión es el efecto práctico: una aplicación Elm escrita hace varios años compila hoy sin tocar una línea, y en un oficio donde la mitad del esfuerzo de mantenimiento se va en perseguir cambios rompedores de dependencias, eso tiene un valor económico que no suele contabilizarse hasta que se pierde.

El catálogo de paquetes funciona con reglas propias que conviene conocer. Todo paquete publicado obedece a un versionado semántico que el compilador calcula comparando las firmas expuestas entre dos versiones, de modo que un autor no puede publicar como parche un cambio que rompe el tipo de una función aunque quiera. Los paquetes no pueden contener JavaScript arbitrario salvo un conjunto muy reducido y controlado, lo cual explica a la vez por qué el catálogo es más pequeño y por qué instalar una dependencia no introduce riesgo de ejecución. La consecuencia cultural es que en Elm se escribe más código propio y se instala menos, y que la pregunta habitual no es qué paquete resuelve esto sino cuántas líneas cuesta resolverlo aquí.

Esa regla tiene un efecto secundario que solo se aprecia después de mantener un proyecto durante un par de años: actualizar dependencias deja de ser una actividad de riesgo. Cuando la herramienta garantiza que una subida de versión menor no puede cambiar ninguna firma expuesta, revisar el registro de cambios se vuelve opcional en lugar de obligatorio, y la práctica habitual en otros ecosistemas de fijar versiones exactas y no tocarlas durante años, que es la causa principal de la deuda de dependencias, aquí carece de sentido.

-- El versionado no lo decide el autor, lo calcula la herramienta.
--
--   parche  cambia solo la implementacion interna
--   menor   anade algo nuevo sin tocar lo existente
--   mayor   cambia o elimina una firma expuesta
--
-- Anadir un constructor a un tipo expuesto es cambio MAYOR,
-- porque rompe el case of exhaustivo de todos los consumidores.
-- Esa consecuencia sorprende la primera vez y es exactamente correcta.

Los recursos que importan y en qué orden

La guía oficial es breve y está deliberadamente incompleta: enseña el bucle y se detiene antes de lo interesante, lo cual la hace excelente como primera lectura y decepcionante como referencia. El salto siguiente son los libros. Elm in Action, de Richard Feldman, es el texto que más gente cita como el que hizo clic, porque construye una aplicación real y va introduciendo los conceptos cuando el proyecto los necesita. Programming Elm, de Jeremy Fairbank, cubre parte del mismo terreno con más énfasis en pruebas y en integración con JavaScript. Ninguno de los dos sustituye al recurso que más rinde a partir de este punto, que es leer código ajeno bien escrito.

Hay además una habilidad que casi nadie enseña explícitamente y que a partir de aquí rinde más que cualquier lectura: saber decidir si un paquete sirve leyendo únicamente sus firmas. La documentación del catálogo es uniforme y muestra el tipo de cada función expuesta, y con el criterio que ya tienes esa lista basta para responder las preguntas que importan. Si una función devuelve Cmd msg, sabes que describe un efecto y que el resultado volverá como mensaje. Si devuelve un Result, sabes que el fallo es un caso que tendrás que tratar y no una sorpresa. Si un tipo expuesto no revela sus constructores, sabes que el autor ha cerrado la construcción a propósito y que solo podrás fabricar valores mediante sus funciones, lo cual suele indicar que hay invariantes que proteger. Diez minutos leyendo firmas ahorran una tarde de integración fallida.

Entre las charlas hay tres que funcionan como piezas de formación de criterio más que como tutoriales. Making Impossible States Impossible es la exposición canónica del argumento de modelado que has trabajado durante todo el track. The Life of a File defiende una tesis contraria a la intuición dominante sobre cuándo partir un módulo, y merece verse precisamente si te resulta incómoda. Types Without Borders conecta el sistema de tipos con la generación automática de decoders a partir de esquemas del servidor, que es la técnica que elimina la última fuente de trabajo manual repetitivo en la frontera.

Frameworks y plataformas: qué hay y cuándo adoptarlo

Durante años el proyecto de referencia para aplicaciones de una sola página fue elm-spa, que resolvía el enrutado y la composición de páginas con generación de código y una convención de directorios. Su autor lo dio por concluido y lo sucedió con Elm Land, que persigue el mismo objetivo con un alcance mayor: proyecto inicial completo, rutas basadas en ficheros, capas y una experiencia de desarrollo cuidada. Si vas a arrancar hoy una aplicación con muchas páginas y quieres saltarte la ceremonia del enrutador, ese es el camino con más tracción. En un terreno distinto está elm-pages, orientado a sitios con contenido y generación estática, con carga de datos en tiempo de construcción y una integración fuerte con el sistema de tipos. Y en un terreno más radical está Lamdera, que no es un framework sino una plataforma donde el cliente y el servidor se escriben ambos en Elm, comparten tipos y el estado del servidor persiste sin base de datos explícita, con migraciones de tipo comprobadas por el compilador.

flowchart TD
A[Que estas construyendo] --> B{Cuantas paginas}
B -->|Una o dos| C[Browser element o document a mano]
B -->|Varias con rutas| D{Contenido o aplicacion}
D -->|Sitio con contenido| E[elm-pages]
D -->|Aplicacion interactiva| F[Elm Land]
D -->|Cliente y servidor en Elm| G[Lamdera]
C --> H[Enrutador propio si crece]
F --> I[Convenciones y rutas por fichero]
style C fill:#a6e3a1,color:#11111b
style F fill:#89b4fa,color:#11111b
style G fill:#cba6f7,color:#11111b

-- Lo que un framework de rutas automatiza, escrito a mano una vez.

type Pagina
    = PaginaInicio
    | PaginaInformes Informes.Model
    | PaginaDetalle Detalle.Model
    | PaginaNoEncontrada


type Msg
    = CambioLaUrl Url
    | PidioNavegar UrlRequest
    | MsgInformes Informes.Msg
    | MsgDetalle Detalle.Msg


update : Msg -> Model -> ( Model, Cmd Msg )
update msg modelo =
    case ( msg, modelo.pagina ) of
        ( MsgInformes hijo, PaginaInformes estadoHijo ) ->
            Informes.update hijo estadoHijo
                |> conPagina modelo PaginaInformes MsgInformes

        ( CambioLaUrl url, _ ) ->
            irA (Route.desdeUrl url) modelo

        _ ->
            ( modelo, Cmd.none )

Esa función conPagina que envuelve el modelo hijo y traduce el comando con Cmd.map es literalmente todo lo que un framework de rutas te ahorra escribir, repetido una vez por página. Escribirla a mano cuesta una tarde y enseña más sobre la arquitectura que cualquier lección, porque obliga a entender por qué el mensaje del hijo tiene que envolverse y por qué la rama que combina un mensaje de una página con el estado de otra existe y debe ignorarse en silencio.

El criterio para elegir no es cuál es mejor sino cuánta convención estás dispuesto a aceptar a cambio de cuánta ceremonia te ahorras. Un framework te da estructura el primer día y te cobra el día en que necesitas algo que su convención no previó. En Elm ese cobro es más suave que en otros ecosistemas, porque debajo sigue habiendo un Browser.application con su Model y su update, y siempre puedes bajar un nivel. Aun así, la recomendación que más gente suscribe después de varios proyectos es haber escrito al menos una vez el enrutador y la composición de páginas a mano, aunque después nunca vuelvas a hacerlo, porque solo entonces entiendes qué está automatizando la herramienta y puedes diagnosticar cuando se comporte de forma inesperada.

Un plan de dominio continuo

El conocimiento se convierte en dominio por una vía y solo una: construir cosas de dificultad creciente y someterlas a revisión. Una secuencia que funciona bien empieza por una aplicación de una sola pantalla con estado no trivial, sin red, para consolidar el modelado; sigue con una que consuma un API real y obligue a diseñar decoders y estados de error de verdad; continúa con una aplicación de varias rutas con sesión persistida, que es donde aparecen los problemas interesantes de composición; y culmina con una que integre una biblioteca de JavaScript a través de ports, que es donde se aprende a diseñar una frontera bajo presión. En paralelo, dos disciplinas constantes: leer una aplicación ajena completa al mes y publicar un paquete pequeño, aunque no lo use nadie, porque el versionado impuesto por el compilador enseña sobre diseño de APIs más que cualquier lectura.

-- Un plan de doce semanas, con una sola dificultad nueva por proyecto.
--
--   1 a 2   Una pantalla, estado no trivial, sin red.
--           Dificultad nueva: modelar sin banderas booleanas.
--
--   3 a 5   Consumo de un API real con errores de verdad.
--           Dificultad nueva: decoders y estados de fallo del dominio.
--
--   6 a 9   Varias rutas, sesion persistida, formularios.
--           Dificultad nueva: composicion de paginas y navegacion.
--
--   10 a 12 Integracion con una biblioteca de JavaScript.
--           Dificultad nueva: disenar una frontera bajo presion.
--
-- En paralelo, cada mes: leer una aplicacion ajena entera
-- y publicar o revisar un paquete propio muy pequeno.

La parte del plan que más gente se salta es la revisión, y es justamente la que produce el salto. Construir sin que nadie mire consolida los hábitos buenos y también los malos, y a partir de cierto punto los malos pesan más porque ya están automatizados. Las dos formas de revisión que funcionan sin necesitar un mentor son publicar el código y pedir opinión en el foro de la comunidad, donde la cultura es sorprendentemente generosa con las preguntas de diseño bien formuladas, y releerse a uno mismo con distancia: volver a un proyecto propio tres meses después y anotar cada decisión que hoy tomarías distinta. Ese segundo ejercicio no cuesta nada y es el que mejor mide si has progresado, porque el progreso en diseño no se nota mientras ocurre.