Mi opinión sobre remix (aka RR7)

Un poco de historia

Aún recuerdo aquel día del 2021 donde corría la noticia de que Michael Jackson y Ryan Florence, creadores de React Router (aquella librería famosa que se encarga de facilitar el manejo de las rutas en aplicaciones de React), anunciaban que su framework aún en desarrollo (ya llevaban 18 meses de desarrollo) en aquella época, “El framework que te ayuda a crear mejores sitios web”, había logrado una financiación para poder hacer el proyecto open source, ya que sí, al iniciar el proyecto tenía un costo; este framework, su idea inicial era que sería de pago para lograr llevar dicho proyecto: 250 dólares la licencia indie o 1000 dólares la licencia enterprise, todo esto al año.

La idea detrás de Remix es que todo es SSR y contendría los estándares de la web; siempre la idea de Remix ha sido estar lo más cercano a los estándares web.

Enrutamiento

Algo que siempre ha sobresalido de Remix es su enrutamiento; tantos años desarrollando React Router tuvieron sus logros.

Primero, su configuración de enrutamiento, donde en un archivo podías definir tus rutas y lo que este debía contener, ya sea, por ejemplo, el componente (la UI), y este a su vez podía tener actions y loaders o hasta tener otras rutas dentro.

C

Mi opinión sobre Remix (aka RR7)

Este artículo representa mi opinión y pensamientos sobre Remix o ahora [laro que sí, si no querías configurar todo a mano, existen aún librerías que se encargan de configurar todo con base en archivos en tu carpeta /routes.

Por mencionar otra cosa, es su componente Outlet que ayuda a crear una jerarquía de rutas anidadas fácilmente.

// app/routes/example.ts = url.com/example

import { useRouteData } from '@remix-run/react'

import React from 'react'
import { Link, Outlet } from 'react-router-dom'

export default function Example() {
  let data = useRouteData()

  return Example
}

Este componente permite, por ejemplo, crear otra ruta y que en esa parte donde se encuentra el Outlet cargar contenido; es cargar toda una lógica (en sí, gracias a una ruta URL) en una parte del layout.

Reponse, loaders y actions

Mi opinión

A mi parecer, cuando conocí Remix y decidí probarlo allá por el 2021 (cuando se decidió que sería open source), se hablaba mucho de Remix (claro, como suele ocurrir con lo nuevo que sale en el ecosistema) y a lo largo de los años he visto cómo ha ido evolucionando. En la versión 1 recuerdo que crearon su propia librería (Remix en sí es una colección de librerías) que ayudaba a enviar los assets al frontend; este se encargaba además de separar los actions y loaders para que fueran solo del backend.

Después, para la versión 2, empezaron a tomar más en serio Vite, y la razón es que Vite ya podía ayudar como “servidor”, entre muchas otras ventajas; Vite ya lograba resolver varios problemas (y hasta de alguna forma mejor). Cuando vi el anuncio de que Remix iba a integrar Vite, me sentía emocionado porque ya saliera, ya que traería muchas ventajas; una de ellas era la velocidad y la experiencia de desarrollo. Fue mucho tiempo, pero al final salió un plugin de Vite para poder usar Remix y todo fue más fácil a partir de ahí.

Y después de unos meses más, otro anuncio más: Remix ahora pasaría a React Router 7. Al principio yo no tenía idea de eso; estaba más concentrado en el desarrollo que en las últimas novedades. Fue hasta después de unos meses, donde entré a un nuevo proyecto y donde me di cuenta de que en su página ya comentaban de usar React Router 7 y de cómo migrar de Remix; me sorprendió la idea.

Pero después de un tiempo y leyendo, me di cuenta de que podría haber tenido sentido este cambio, ya que en sí, pues sí era como un wrapper de React Router con ciertas características extras. Y más razón de este cambio fue por los React Server Components (RSC), ya que React está siguiendo su camino por el backend, mientras Remix ya había empezado por otro (y, según los desarrolladores, por un camino más complicado, ya que los RSC facilitan y abarcan de una mejor manera lo mismo que hace Remix). Podría decirse que por los RSC hay “dos” Reacts.

Remix, como cualquier otro framework o librería, buscaba mejorar y hacer mejor las cosas, pero algo que también me gusta son las future_flags; esto es básicamente decirle al Remix que use las nuevas mejoras o cambios que se vienen, pero cuando así yo lo decida. En el archivo de configuración era tan fácil como definir un objeto y enviarlo con la future flag activada; esto era útil para no tener todos los nuevos cambios de golpe, y poco a poco ir modificando tu código para ir adaptando las nuevas features; con esto se evita muy fácil esos terribles breaking changes.

En la versión 3 es todo un cambio total; lo resumo así de simple: Remix v3, lo único que tiene similar a las versiones anteriores es el nombre (remix). Ya que le dicen adiós a React y en cambio tendrían su propia versión modificada de Preact (o eso fue lo que dijeron en un principio, pero ahora están creando su propia librería, “más cercana a la web”), y sí tiene buen aspecto, pero en mi opinión ya no es Remix.

He visto algunos avances con la versión 3 y se ve interesante a lo que quieren llegar. Lo que no me pareció bien es aprovechar la fama que ya cargaba el nombre de remix para crear un proyecto totalmente diferente.

Si quieres leer otro punto de vista, aquí te dejo este artículo en inglés: https://frantic.im/remix-3/

React Router 7 vs Remix v3

Aquí te mostraré algunas diferencias y el prototipo temprano que mostraron en la remix jam

function Counter() {
  const [count, setCount] = useState(0)

  return (
    <div>
      <div>{count}</div>
      <button onClick={() => setCount((c) => c + 1)}>Increment</button>
    </div>
  )
}

function Counter(this: Remix.Handle) {
  let count = 0 // Plain closure variable, no useState

  return () => (
    <div>
      <div>{count}</div>
      <button
        onClick={() => {
          count++
          this.update() // Explicit re-render command
        }}
      >
        Increment
      </button>
    </div>
  )
}

Examinemos un poco los principios de Remix v3

La versión 3 de Remix tiene en mente seguir estos 6 principios:

1. Model-First Development: La idea en este punto, a lo que entendí, es que actualmente los LLMs (o la IA para la gente no técnica) crean mucho código confuso, a veces incorrecto, y esto se debe en parte a lo complicado y revuelto que suele ser React; la idea es hacer las cosas más simples y entendibles para que los LLMs puedan entender mejor.

2. Build on Web APIs: Este es algo que siempre ha estado presente y ha sobresalido, ya que siempre la idea principal de Remix ha sido acercarse más a los estándares web ya existentes y fundamentos, usando el API de la web.

3. Religiously Runtime: En este principio, la idea es no diseñar remix para que dependa demasiado de bundlers/compiladores/typegens (o cualquier analizador estático), ya que esto lleva a una API pobre. Según sus creadores, “todos los paquetes deben diseñarse sin esperar análisis estáticos”.

4. Avoid Dependencies: La idea en sí es no depender de ninguna librería externa; todo será hecho por ellos mismos.

5. Demand Composition: Abstracciones: La idea es no acoplar todo junto, que cada cambio o feature no dependa de todo el proyecto. Este principio ya se ha visto antes y se trata de extraer en librerías diferentes funcionalidades y no que todo venga de la misma librería.

6. Distribute cohesively: Este principio va de la mano con el anterior, ya que la idea es separar en diferentes paquetes, pero a la vez todo sea reexportado de uno mismo, es decir, que todo se pueda importar desde “remix”, pero que internamente sean diferentes paquetes.

Todo esto es a lo que yo entendí y claro que puedo estar equivocado al no haber comprendido del todo.

Mi conclusión

Sé que este artículo no abarca mucho de Remix, pero la idea fue hacerlo de una forma resumida para hablar de cómo está cambiando Remix. Todo esto es escrito de una forma personal y en base a mis ideas y opiniones, pero en general Remix ha sido de mucha utilidad para mí y me ha simplificado mucho los proyectos que he creado. Al principio es difícil entenderle del todo, ya que tiene su forma de abordar las cosas, pero una vez que le entiendes, el desarrollo es más fácil.

Ya la nueva versión de Remix y, como Remix v2, lo integraron a React Router; tiene sus pros, pero la idea de seguir usando el nombre de Remix es cuestionable. Entiendo que, por un lado, Angular ya hizo algo similar de pasar de la v1 a la v2, pero en este caso ya Remix tenía mucho tiempo en el ecosistema como para ahora hacer un cambio tan grande, pero pues todo es marketing y el nombre de Remix ya era muy conocido.

A mi parecer, Remix v3 va a tener sus cosas buenas y habría que probar cómo lo recibe la comunidad. Ya lo que queda actualmente es seguir usando React Router o ir probando cosas nuevas, como por ejemplo un framework que tiene poco, que ya casi es estable para producción, llamado Tanstack Start. Actualmente hay mucho hype y sí tiene sus razones; yo no lo he probado mucho, pero sé que sí va por buen camino, ya que todas las herramientas del ecosistema de Tanstack son grandiosas. Te invito a probar ese framework si aún no lo has hecho mientras esperamos la versión 3 que puede tardar un tiempo en que salga.

Gracias por leer.