El legado de Flux · Flux y Redux

Flux ocupa un lugar extraño en la historia del frontend: casi nadie usa hoy el Flux original de Facebook, y sin embargo Flux ganó. Ganó porque nunca fue realmente una librería sino un patrón, y los patrones no se adoptan instalando un paquete, se propagan cuando otros los reimplementan con su propia voz. Entre 2014 y 2016 hubo una explosión de librerías que intentaban ser el Flux definitivo; casi todas están muertas. Pero la idea que compartían —estado que solo cambia por hechos con nombre, en una sola dirección— no solo sobrevivió, sino que se volvió tan ubicua que hoy la usamos sin nombrarla. Esta lección trata de cómo una idea derrota a sus propias implementaciones.

🎯 Al terminar esta lección sabrás

Distinguir Flux como patrón de Flux como la librería concreta que publicó Facebook.
Recorrer la explosión cámbrica de implementaciones y entender por qué casi todas se extinguieron.
Ver cómo la Elm Architecture aportó la pieza que a Flux le faltaba: la función pura.
Situar el linaje que va de Flux a Redux y de ahí al ecosistema de 2026.

Flux era un patrón, no una librería

Facebook publicó un paquete flux con una clase Dispatcher, pero nunca entregó un framework completo de gestión de estado. Lo que entregó fue un diagrama y una charla: aquí están las piezas, aquí la dirección, resuelve el resto tú. Esa incompletitud, que parecía una carencia, fue el motor de su difusión. Al no imponer una implementación, Flux invitó a que cada equipo escribiera la suya, y la comunidad respondió con un entusiasmo desbordante.

La consecuencia fue paradójica: al no ser una librería terminada, Flux se convirtió en un espacio de diseño que docenas de librerías exploraron a la vez. Cada una tomaba las cuatro piezas y las reinterpretaba —fusionaba el dispatcher con los stores, hacía las actions asíncronas, cambiaba cómo las vistas se suscribían—. Flux no era el punto de llegada; era el punto de partida de una carrera.

La explosión cámbrica y la extinción

Entre 2014 y 2016 nacieron tantas implementaciones de Flux que la propia comunidad bromeaba con que cada semana aparecía una nueva. Cada una prometía menos ceremonia que las demás.

🔁

Reflux

Eliminaba el dispatcher central: cada action era su propio emisor y los stores se suscribían directamente. Menos ceremonia, a costa de perder el punto único de observación.

⚗️

Alt y Flummox

Reducían el código repetitivo generando actions y stores desde clases. Ergonomía sobre pureza; envejecieron mal cuando llegó algo más simple.

🖥️

Fluxible

La apuesta de Yahoo, pensada para renderizado en servidor y estado aislado por petición. Resolvía un problema real que el Flux original ignoraba.

🧭

Marty, Fluxxor, NuclearJS

Cada una con su giro: datos inmutables, contenedores, fetching declarativo. Un catálogo de ideas que el ecosistema probaría y filtraría.

Casi ninguna sobrevive en 2026. No porque fueran malas, sino porque una sola implementación —Redux— capturó lo esencial del patrón con tan poca ceremonia que hizo innecesarias a las demás. La explosión cámbrica fue seguida de una extinción, y eso es exactamente cómo maduran los ecosistemas de software: muchas variantes compiten, el entorno selecciona una o dos, y el resto queda como registro fósil en repositorios sin mantener. Lo importante es que la extinción de las librerías no fue la extinción de la idea.

ℹ️

MobX no era Flux, y por eso importa

En paralelo a toda esta familia creció MobX, que ganó tracción resolviendo el mismo problema por el camino opuesto: reactividad transparente con datos observables, sin actions ni flujo unidireccional explícito. Su existencia demuestra que Flux no era la única respuesta posible a la crisis del MVC, sino una de dos grandes escuelas —la del flujo explícito y la de la observabilidad implícita— que siguen vivas y en tensión productiva hoy, cuando las signals reavivan justamente la segunda.

Elm y la pieza que faltaba: la función pura

Mientras JavaScript hervía con implementaciones de Flux, un lenguaje funcional para el navegador, Elm, cristalizaba una arquitectura asombrosamente parecida pero más limpia: la Elm Architecture, conocida como TEA. Sus piezas eran un Model —todo el estado en un valor—, una view que lo renderiza, un tipo Msg de mensajes —las actions de Elm— y, la joya, una función update.

-- la funcion update de Elm: pura, sin efectos, total
update : Msg -> Model -> Model
update msg model =
    case msg of
        Incrementar ->
            model + 1
        Decrementar ->
            model - 1

La diferencia decisiva con el store de Flux es esa firma. El update de Elm es una función pura: recibe el mensaje y el estado viejo, y devuelve el estado nuevo, sin mutar nada y sin efectos secundarios. No hay EventEmitter, no hay this, no hay estado escondido. Elm demostró que la transición de estado podía expresarse como matemática, no como manipulación de objetos, y que hacerlo así regalaba propiedades —reproducibilidad, testabilidad trivial, time-travel— que en Flux había que perseguir a mano.

El linaje hasta 2026

Redux, que veremos en detalle en la última lección, fue el cruce genético de estas dos corrientes: tomó de Flux las actions como hechos con nombre y el flujo unidireccional, y tomó de Elm la función pura de actualización. De ese cruce nació el reducer. A partir de ahí, la idea se ramificó y se dispersó por todo el ecosistema.

flowchart TD
F[flux 2014] --> IMPL[docena de implementaciones]
F --> R[redux 2015]
E[elm architecture] --> R
IMPL -.extincion.-> X[fosiles en github]
R --> RTK[redux toolkit]
R --> UR[usereducer de react]
E --> XS[xstate y actor model]
F --> ZU[zustand y jotai con disciplina]
style F fill:#f9e2af,color:#11111b
style E fill:#a6e3a1,color:#11111b
style R fill:#cba6f7,color:#11111b

En 2026 el flujo unidireccional dejó de ser una elección arquitectónica llamativa para volverse el sustrato por defecto. El hook useReducer de React es Flux en miniatura dentro de un componente. Redux Toolkit es el descendiente directo y aún dominante para estado global complejo. XState llevó la idea del mensaje que provoca una transición hasta el modelo de actores y los statecharts. Y hasta librerías que parecen alejarse del patrón —Zustand, Jotai— se usan a menudo con la disciplina unidireccional que Flux sembró. La idea ganó tan completamente que se volvió invisible.

⚡

Las ideas sobreviven a sus implementaciones, y por eso conviene aprender ideas

Hay una lección de carrera escondida en esta historia que vale más que cualquier API. Un ingeniero que en 2015 invirtió meses en dominar Alt, o Flummox, o Marty, vio su inversión evaporarse cuando esas librerías murieron; un ingeniero que en 2015 entendió por qué Flux existía —el problema de la cascada, la cura del sentido único, el hecho con nombre como unidad de cambio— posee en 2026 un conocimiento que sigue rindiendo intacto, porque esa comprensión se transfiere a Redux, a la Elm Architecture, a XState, a los reducers de React y a lo que venga después. Las implementaciones son mortales y las ideas son casi eternas, y el ecosistema del frontend es la prueba más brutal de esta ley porque su tasa de extinción de librerías es altísima. Flux enseña esto de forma perfecta porque es el caso donde la idea ganó precisamente mientras la librería moría: nadie escribe el Flux de Facebook hoy, y sin embargo todos escribimos software con la forma que Flux les dio. Cuando una tecnología nueva te deslumbre, entrénate para hacer la pregunta que separa al aprendiz del maestro: ¿qué idea encarna esto, y de qué problema es la cura? Si sabes responderla, la desaparición de la librería concreta te será indiferente, porque te quedarás con lo único que se acumula a lo largo de una carrera —el modelo mental— mientras los demás vuelven a empezar de cero con cada moda. Aprender librerías te mantiene empleado un año; aprender las ideas que las generaron te mantiene relevante una década.

⚔️ Rastrea el linaje

Elige dos implementaciones muertas de Flux —Reflux y Alt, por ejemplo— y averigua qué decisión de diseño tomó cada una de forma distinta al Flux original. Anota cuál de esas decisiones sobrevivió en algún descendiente y cuál no.
Escribe la función update de un contador en el estilo puro de Elm y compárala con el store con EventEmitter de la lección dos. Nombra tres propiedades que la versión pura tiene gratis.
Toma el hook useReducer de React y mapea cada una de sus partes a una pieza de Flux. Verifica que es Flux dentro de un componente.
Para tres herramientas de estado que uses hoy, identifica de cuál de las dos escuelas descienden —flujo explícito o reactividad implícita— y qué heredaron de Flux o de MobX.
Escribe la idea de Flux en una sola frase, sin nombrar ninguna librería. Esa frase es lo que de verdad heredaste; guárdala junto a la de la lección uno.