La paridad de funcionalidades y la tabla de equivalencias

Decir que dos productos alcanzaron la paridad es una afirmación fuerte y merece verificarse capacidad por capacidad, no creerse por anuncio. La utilidad práctica de hacerlo es doble: si vas a migrar, necesitas saber a qué campo concreto se traduce cada cosa que hoy usas; y si vas a empezar de cero, necesitas saber qué nombres buscar cuando pidas algo que en la vieja documentación se llamaba de otra forma. Esta lección hace ese recorrido de frente: las cuatro capacidades que retenían a la gente en Pages, su equivalente exacto en Workers, la tabla que traduce un vocabulario al otro, y las tres diferencias que todavía existen y conviene conocer antes de tocar nada.

Las cuatro capacidades, una a una

El método para verificar una paridad es siempre el mismo: nombrar la capacidad tal como la usa quien la tiene, buscar el mecanismo que la cubre en el otro lado, y comprobar que no solo existe sino que cuesta lo mismo y se comporta igual bajo carga. Aplicado a este caso, salen cuatro capacidades y ninguna queda coja.

Assets estáticos. En Pages el hosting estático era el producto: subías un directorio de build y se servía desde el edge, gratis e ilimitado. En Workers esa misma capacidad vive en el bloque assets del manifiesto. Apuntas directory a la carpeta de salida de tu build y el edge sirve esos archivos con la misma red y la misma caché. Lo determinante es que las peticiones resueltas por un asset no cuentan como invocación del Worker: no se factura por servir tu front-end en ninguno de los dos productos.

El bloque no se limita a apuntar a una carpeta. Admite declarar cabeceras por patrón de ruta, redirecciones, el comportamiento ante rutas sin archivo y el orden de resolución frente al código. Es decir, cubre exactamente lo que en Pages se repartía entre dos archivos especiales del directorio de salida y algunas casillas del panel, pero en un solo lugar y versionado con el proyecto.

Hay un matiz sobre los assets que conviene no pasar por alto: en Workers el directorio no es solo un origen pasivo. Si declaras el campo binding, tu código obtiene un objeto capaz de pedir un asset por su cuenta, lo que permite decidir algo antes de entregarlo —comprobar una sesión, elegir entre dos variantes, añadir una cabecera— sin renunciar a que el resto del sitio se siga sirviendo solo. Pages no ofrecía ese punto intermedio: un archivo se servía o no se servía.

Renderizado en servidor. Aquí Pages era el que iba detrás. Su modelo de funciones dependía del directorio functions/, donde cada archivo se convertía en una ruta por convención de nombres, con un acceso a la plataforma que siempre fue parcial. En Workers el renderizado en servidor no es un añadido: es el producto. Tu main apunta a un módulo con un handler fetch, y ese handler tiene el objeto env completo, con todos los bindings, sin ninguna categoría de segunda clase.

La diferencia se aprecia en cuanto miras qué puede hacer ese handler sin pedir permiso a nadie. Puede consultar una base de datos, leer y escribir en almacenamiento de objetos, invocar un modelo de lenguaje, hablar con otro Worker sin salir a la red pública, coordinar estado con un objeto durable y diferir trabajo después de responder. En Pages, cada una de esas capacidades era una pregunta con respuesta incierta; en Workers todas son la misma respuesta, que es un campo más en el manifiesto.

Dominios personalizados. Pages permitía asociar un dominio a un proyecto desde el panel. Workers ofrece lo mismo y algo más fino: además de asociar un dominio propio, puedes declarar rutas que capturan solo una parte del tráfico de una zona, lo que te deja convivir con un origen existente mientras migras por partes.

Esa distinción entre asociar un dominio y declarar rutas es la que convierte una migración arriesgada en una gradual. Un dominio personalizado dice que todo el tráfico de ese nombre es tuyo; una ruta dice que solo lo es el que coincide con un patrón, y el resto sigue su camino anterior. Con rutas puedes llevarte primero una sección del sitio, observarla en producción real, y ampliar el patrón cuando la evidencia acompañe.

Previsualizaciones. Era el argumento afectivo más fuerte a favor de Pages: cada rama y cada commit con su URL. Workers cubre esa necesidad con URLs de previsualización por versión desplegada, integradas con el mismo flujo de Git. El detalle mental que cambia es el eje: en Pages la previsualización colgaba de la rama; en Workers cuelga de la versión, que es una unidad más precisa porque es exactamente lo que se despliega.

Ese cambio de eje tiene una consecuencia que va más allá de la comodidad. Cuando la unidad es la versión, subir y activar dejan de ser el mismo acto: puedes publicar algo sin que reciba tráfico, revisarlo en su URL, promoverlo después y, si hace falta, repartir el tráfico entre la versión nueva y la anterior. Pages nunca ofreció esa separación, y es probablemente la capacidad en la que Workers no alcanza la paridad sino que la supera.

flowchart LR
A[Assets estaticos] --> Z[Bloque assets en wrangler]
B[Funciones en directorio functions] --> Y[Handler fetch en main]
C[Dominios del panel] --> X[Custom domains y routes]
D[Preview por rama] --> W[Preview URL por version]
style Z fill:#a6e3a1,color:#11111b
style Y fill:#a6e3a1,color:#11111b
style X fill:#a6e3a1,color:#11111b
style W fill:#a6e3a1,color:#11111b

La tabla de equivalencias

Esta es la traducción que conviene tener a mano durante una migración. La columna de la izquierda es lo que hoy tienes; la de la derecha, dónde vive ahora. Léela en las dos direcciones: de izquierda a derecha si estás migrando, y de derecha a izquierda si estás leyendo documentación antigua y necesitas saber de qué te hablaba.

El patrón que atraviesa la tabla entera es que la configuración cambia de lugar: deja de vivir en un panel del navegador y pasa a vivir en un archivo del repositorio. Ese desplazamiento tiene tres efectos que se notan enseguida. La configuración se revisa como código, en el mismo sitio donde se revisa todo lo demás. Se reproduce en local, porque el entorno de desarrollo lee el mismo archivo. Y se recupera, porque su historial es el del repositorio y no la memoria de quien pinchó la última vez.

Tres observaciones sobre la tabla. La primera es que casi todo lo que era una convención implícita en Pages se convierte en una declaración explícita en Workers: no se pierde la capacidad, se pierde la magia, y a cambio la configuración deja de vivir en un panel y pasa a estar versionada junto al código. La segunda es que la fila del directorio functions/ es la única que exige escribir código en lugar de rellenar un campo, y por eso ocupa una lección entera. La tercera es la más significativa: las últimas filas no tienen columna izquierda. La paridad no fue un empate, fue una absorción, y quien migra no solo conserva lo que tenía sino que hereda una plataforma entera que antes le quedaba al otro lado del muro.

Hay una fila que merece un comentario aparte por lo mucho que se malinterpreta: la de not_found_handling. En Pages, el comportamiento ante una ruta sin archivo dependía de una convención y de si existía o no una página de error en el directorio de salida. En Workers es un campo con tres valores posibles y una consecuencia visible en cada uno: devolver el documento principal para que el enrutador del cliente se ocupe, devolver tu página de error con el código correcto, o no hacer nada y dejar que la petición caiga en tu handler. Elegir mal aquí produce el fallo más frecuente de toda migración, que es un sitio de página única donde las rutas profundas funcionan al navegar pero devuelven un error al recargar.

El manifiesto resultante hace visible esa herencia en un solo vistazo:

{
  "assets": {
    "directory": "./dist",
    "not_found_handling": "single-page-application",
    "headers": { "/assets/*": { "cache-control": "public, max-age=31536000" } }
  },
  "triggers": { "crons": ["0 3 * * *"] }
}

La paridad económica

Una tabla de funciones puede estar completa y aun así describir dos productos que no son intercambiables, porque la misma capacidad a distinto precio no es la misma capacidad. Por eso la fila que decidía la migración no aparece en la tabla anterior: es la de cuánto cuesta servir un archivo.

La prueba mental es sencilla. Imagina la paridad de 2026 con todas las funciones idénticas salvo que cada asset servido contase como una invocación. Técnicamente sería la misma tabla; en la práctica no habría migrado nadie con tráfico real, porque un sitio de contenido dispara decenas de peticiones de archivo por visita y la factura se multiplicaría por un factor que ninguna elegancia de configuración compensa. La paridad de funciones es condición necesaria; la paridad económica es la suficiente.

En Pages, el hosting estático era gratuito e ilimitado, y esa gratuidad sostenía todo el producto. En Workers, desde 2026, las peticiones que resuelve un asset tampoco cuentan como invocación. No es una promoción ni un umbral generoso: es la misma condición en ambos lados. Un sitio con un millón de visitas diarias que sirve imágenes, hojas de estilo y fragmentos de JavaScript paga por esos archivos exactamente lo mismo aquí y allí, es decir, nada.

El coste aparece solo cuando se ejecuta código, y ahí es donde tu manifiesto se convierte en una decisión de factura. Cada ruta que declaras en run_worker_first deja de ser gratuita, porque garantiza que el Worker la vea antes que los assets. Es exactamente la propiedad que quieres para tu API y exactamente la que no quieres para tu directorio de imágenes. La arquitectura y el precio dejan de ser dos conversaciones separadas.

De ahí sale una heurística útil para diseñar: mira tu sitio y pregúntate qué fracción de las peticiones necesita de verdad que se ejecute código. En un sitio de contenido, esa fracción suele estar por debajo del cinco por ciento, y el modelo te cobra exactamente por ese cinco por ciento. En una aplicación con sesión en cada vista, la fracción se acerca al total, y entonces el precio refleja lo que realmente estás haciendo, que es computar. El modelo no premia ni castiga arquitecturas: hace visible cuál tienes.

Esa correspondencia entre manifiesto y factura es, de hecho, una herramienta de revisión. Un cambio en la lista de run_worker_first es un cambio de coste, y merece leerse en una revisión de código con la misma atención que un cambio de consulta a la base de datos.

Queda un detalle administrativo que elimina la última fricción: Pages y Workers comparten el mismo plan de pago. Migrar no implica contratar nada nuevo, ni duplicar una suscripción durante la transición, ni justificar una línea de gasto adicional ante nadie. Puedes tener los dos productos vivos a la vez mientras compruebas que el nuevo responde igual que el viejo, sin coste añadido por el solapamiento, que es justamente lo que hace segura la migración gradual.

Lo que todavía difiere

La paridad es real, pero no significa identidad, y el ingeniero honesto conoce las costuras que quedan. Ninguna de las tres siguientes es una capacidad perdida; las tres son cambios de reparto de responsabilidad, y por eso se notan sobre todo en las primeras horas de trabajo con un proyecto migrado.

Las tres diferencias tienen una raíz común y merece la pena nombrarla: Pages optimizaba para que no tuvieras que decidir, y Workers optimiza para que puedas decidir. Donde antes había una convención que resolvía el caso frecuente y no admitía excepciones, ahora hay un campo que rellenas. Eso convierte los primeros minutos en algo más laborioso y los meses siguientes en algo más manejable, porque cada comportamiento del sistema tiene un lugar donde está escrito. Ninguna de las tres es una capacidad perdida; las tres son responsabilidad recuperada.