Baseline: el secreto para enviar mucho menos JavaScript

Baseline: el secreto para enviar mucho menos JavaScript

¿Te acuerdas de aquellos días gloriosos de jQuery? Metías un archivo de 90KB en tu proyecto y de repente `$(document).ready()` lo hacía todo tan suave que daba gusto. Luego fuimos más listos, separamos nuestros bundles y cambiamos jQuery por React, Vue y un armario lleno de micro-librerías para absolutamente todo.

Pero hay algo que no dejo de hacer: echar mano de una librería de formato de fechas de 20KB cuando el navegador al que me dirijo ya tiene una API que hace exactamente lo mismo. Gratis. Sin petición de red. Sin actualizar versiones. Sin mantenimiento futuro.

Ahí es donde entra **Baseline**.

Si todavía no lo conoces, Baseline es una iniciativa respaldada por el W3C que nos da una etiqueta sencilla y universal para responder a la pregunta: “¿cuándo puedo usar esta función con seguridad?”. Resuelve la pregunta más molesta del desarrollo web con una sola palabra: **hoy**. Y al ayudarte a identificar lo que la plataforma web ya puede hacer por ti, Baseline puede reducir muchísimo el JavaScript que envías. Vamos a verlo.

¿Qué es Baseline, de verdad?

Baseline es un entendimiento común del soporte de navegadores en todos los grandes: Chrome, Edge, Firefox, Safari y Opera. En lugar de consultar una matriz de “funciona en el 97% de los navegadores”, Baseline te dice si una función está **disponible** (funciona en los navegadores actuales) o **recién disponible** (acaba de llegar a las últimas versiones). La idea es quitarte las adivinanzas.

Piénsalo como “caniuse, pero con un veredicto más amigable”. Cuando una función se convierte en Baseline, significa que todos los navegadores del ecosistema común la soportan. Es tu semáforo en verde.

Y lo mejor: Baseline ya está integrado en sitios que seguramente usas. Mírate las tablas de compatibilidad de MDN, busca una función, y verás una insignia de Baseline al lado. O echa un ojo a [web.dev/baseline](https://web.dev/baseline) para ver un panel de lo que está listo hoy.

Por qué esto importa para el tamaño de tu bundle

La distancia entre “necesitas una librería para esto” y “el navegador ya hace esto” se está cerrando. Cada año, los navegadores añaden APIs que antes requerían polyfills, librerías auxiliares y funciones de utilidad. Si todavía estás enviando `moment-timezone` para cálculos de zonas horarias o `lodash` para `_.debounce()`, estás pagando por algo que la plataforma ya ofrece: tanto en bytes como en complejidad.

Te voy a mostrar tres ejemplos prácticos donde Baseline te puede ayudar a eliminar lastre.

Escenario 1: Formato de fechas sin la dependencia de 50KB

Una vez trabajé en un proyecto que importaba `date-fns` solo para formatear un par de fechas en un dashboard. La aplicación entera era un dashboard estático. Enviábamos 16KB de funciones de fecha localizadas para mostrar textos como “9 ago 2026”.

Pero aquí tienes un pequeño experimento: abre la consola de tu navegador y escribe esto:

```js
new Intl.DateTimeFormat('es-ES', { dateStyle: 'full' }).format(new Date())
```

Ahí lo tienes. **Sin import, sin npm install, sin fijar versiones.** El objeto `Intl` es una función Baseline desde hace años. Gestiona formatos locales, zonas horarias e incluso el tiempo relativo estilo date-fns con `Intl.RelativeTimeFormat`.

¿Quieres eliminar el bundle entero? Mapea tus funciones de date-fns a sus equivalentes nativas:

- `format` → `Intl.DateTimeFormat`
- `formatDistance` → `Intl.RelativeTimeFormat`
- `parseISO` → `Date.parse()` (o `new Date()` con cuidado)
- `zonedTimeToUtc` → `Intl` con la opción `timeZone`

Sí, existen casos límite, pero para el 90% de los proyectos la API nativa de `Intl` hace el trabajo. Y es Baseline disponible, así que todos los navegadores modernos lo soportan.

Escenario 2: Sustituir Lodash por el DOM

Todavía veo `lodash.debounce` en muchos codebases. Cinco kilobytes para que una función espere un poco antes de ejecutarse. Pero el navegador ya lo trae incorporado:

```js
function debounce(fn, delay) {
let timer;
return (...args) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), delay);
};
}
```

O si eres perezoso como yo, un simple `setTimeout` dentro de un event listener funciona para la mayoría de los casos. Lo mismo con `_.throttle`, `_.clamp`, `_.range`... todo son unas pocas líneas de JavaScript sencillo.

Pero va más allá. ¿Alguna vez usaste `_.forEach`? El prototipo Array tiene `forEach`, `map`, `filter`, `reduce`... todo Baseline. ¿`_.get` para acceder a propiedades anidadas con seguridad? El encadenamiento opcional es Baseline desde 2020. ¿`_.unique`? Eso es simplemente `Set`.

El DOM también es una mina de oro: `classList.toggle()` sustituye a `_.toggleClass`, `Element.matches()` sustituye a los selectores de `_.is()`, y el nativo `IntersectionObserver` reemplaza librerías enteras de scroll-spy. La próxima vez que vayas a añadir una dependencia, pregúntate: “¿es esto solo un envoltorio elegante de algo que `document.querySelectorAll` ya me da?”.

Escenario 3: Peticiones HTTP sin axios

Axios es una librería preciosa, pero en 2026 la API nativa `fetch` es Baseline y cubre casi todos los casos de uso. ¿Streaming? `fetch` soporta `response.body.getReader()` para hacer streaming. ¿Autenticación? Puedes configurar cabeceras, credenciales e interceptores con un pequeño wrapper. ¿Cancelar peticiones? Eso es `AbortController`, que también es Baseline.

Para un proyecto pequeño, sustituí axios por completo con un helper de 20 líneas:

```js
async function request(url, options = {}) {
const res = await fetch(url, {
headers: { 'Content-Type': 'application/json', ...options.headers },
signal: options.signal ?? (options.timeout && AbortSignal.timeout(options.timeout)),
...options,
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}
```

Sin npm, sin inflar `node_modules`, sin avisos de dependencias circulares. Solo rápido, nativo y fiable.

Cómo auditar tus dependencias con Baseline

Ya te he convencido, ¿y ahora qué? Aquí tienes un proceso práctico que puedes hacer esta misma tarde.

1. Haz una lista de tus dependencias de runtime

Ejecuta `npm ls --production` o simplemente mira tu `package.json`. Marca todo lo que no sea tu framework o una librería de gestión de estado. Esos paquetes de utilidades pequeñas son el objetivo principal.

2. Compara cada una contra Baseline

Para cada librería de tu lista, hazte dos preguntas:

- ¿Qué problema resuelve?
- ¿Puedo resolverlo con una API web que sea Baseline disponible?

Busca la función en MDN. Si ves la insignia verde “Baseline available”, vas bien. Si ves “Newly available” y solo quieres llegar a navegadores modernos, también merece la pena considerarlo. Si es rojo “Limited”, igual es mejor mantener la librería por ahora.

Un consejo rápido: abre las herramientas de desarrollo en Chrome, Safari o Firefox y prueba la API directamente. Si funciona sin ninguna bandera, es una buena señal.

3. Busca en tu código señales evidentes

Busca patrones como `import * as _ from 'lodash'`, `from 'date-fns'`, `from 'axios'` o `from 'jquery'`. Luego mira con qué frecuencia se usan esas funciones. A veces descubres que solo usas tres métodos de una librería que tiene doscientos. Eso es una oportunidad clarísima.

4. Sustituye y compara

Haz la migración de una librería a la vez. Mantén cada PR separado para poder medir el cambio en el tamaño del bundle. Usa el informe de tamaño de tu herramienta de build o simplemente mira el tamaño de los archivos en devtools. Te recomiendo ejecutar Lighthouse antes y después. Ver cómo baja el “tiempo de ejecución de JavaScript” es una sensación preciosa.

El lado humano de enviar menos JavaScript

¿Por qué nos importa esto más allá de la satisfacción de tener un bundle más pequeño? Porque JavaScript es el recurso más caro que enviamos a los navegadores. Cada byte debe descargarse, analizarse, compilarse y ejecutarse. Cada API que te ahorras significa una carga de página más rápida para alguien con un Android barato y una conexión 3G irregular. No todo el mundo tiene un MacBook Pro conectado a fibra.

Enviar menos JavaScript también significa menos carga mental para ti, que eres quien desarrolla. Cada dependencia es una posible vulnerabilidad de seguridad, un posible dolor de cabeza en una migración y una posible fuente de bugs raros cuando su mantenedor decida retirarse. Las APIs nativas las mantienen los propios navegadores, así que se actualizarán, documentarán y soportarán durante años.

Y hay un beneficio más profundo: empiezas a entender la plataforma web de verdad. Cuando usas `Intl`, `URL`, `Promise`, `Map`, el encadenamiento opcional y `fetch` directamente, te conviertes en mejor desarrollador web. Ya no eres solo un consumidor de abstracciones; eres alguien que construye conociendo la veta de la madera.

¿Hay pegas? Sí. No seas tonto.

Baseline no es una varita mágica. Algunas APIs avanzadas son todavía demasiado nuevas como para ser Baseline disponibles en todas partes. Por ejemplo, la Popover API o la View Transitions API son “nuevas”, pero no han llegado por completo a todos los navegadores. Si estás construyendo un sitio público para una audiencia amplia, igual quieres esperar u ofrecer un fallback elegante.

Además, quitar una librería no siempre significa escribir menos código. A veces tienes que escribir un poco más de JavaScript vainilla para conseguir el mismo comportamiento. Pero oye: unas pocas líneas extra de tu propio código son más mantenibles que una librería de utilidades monolítica que no entiendes del todo.

Y por último, no te conviertas en un “fanático de las APIs nativas”. Si una librería cambia por completo tu productividad y te hace la vida más fácil, úsala. El objetivo de Baseline no es hacerte sentir mal por usar librerías chulas. Es ayudarte a tomar decisiones informadas. Solo no envíes `safe-password-generator` cuando `crypto.getRandomValues()` es Baseline desde 2015.

Extra: cómo estar al día con Baseline

La plataforma web evoluciona rápido. Para estar al tanto de lo que se está convirtiendo en Baseline disponible, hago dos cosas:

1. Consulto el panel de **Web Platform Features** en [web.dev/baseline](https://web.dev/baseline) una vez al mes, más o menos.
2. Leo la sección de noticias de **MDN Baseline**, que cada mes lista las funciones recién disponibles.

También puedes seguir el repositorio de GitHub del grupo comunitario WebDX en [github.com/web-platform-dx/baseline](https://github.com/web-platform-dx/baseline). Ahí es donde pasa la magia.

Preguntas frecuentes

¿Qué significa exactamente “Baseline available”?

Significa que una función está soportada en las versiones actuales y recientes de todos los navegadores principales: Chrome, Edge, Firefox, Safari y Opera. Puedes usarla sin polyfill ni fallback en esos navegadores.

¿Es Baseline lo mismo que “caniuse.com”?

No, pero están relacionados. Caniuse te da tablas de compatibilidad detalladas, incluyendo versiones antiguas. Baseline resume esos datos en una etiqueta simple de “listo o no listo”. También garantiza que la información tenga contexto: que algo funcione en Chrome 120 no significa que funcione en Safari 12.

¿Y si todavía tengo que dar soporte a navegadores antiguos como IE11?

IE11 está muerto, e incluso antes era una excepción. Baseline excluye explícitamente navegadores heredados como IE11. Si tienes que dar soporte a entornos tan antiguos, necesitarás consultar tablas individuales y quizá incluir polyfills para las APIs que elijas. Pero en 2026, es razonable preguntarse por qué sigues dando soporte a IE11: son tus usuarios los que deciden seguir con tecnología vieja, y tú estás pagando el precio.

¿Cómo convenzo a mi equipo de usar Baseline?

Enséñales los números. Elige una dependencia, calcula el tamaño del bundle y el coste de mantenimiento, y demuestra la alternativa nativa con un prototipo rápido. Yo hice esto con `lodash` en un trabajo anterior, y cuando mi líder vio el diff —una utilidad de 5KB sustituida por dos líneas de JavaScript vainilla— se convenció al momento. Y pídeles que lean este post. 😉

En resumen

Baseline no es solo otra herramienta de compatibilidad: es un cambio de mentalidad. En lugar de preguntarte “¿qué librería debería usar para esto?”, empiezas a preguntarte “¿qué puede hacer ya el navegador por mí?”. En el momento en que haces ese cambio, la hinchazón de JavaScript empieza a derretirse.

Tus usuarios consiguen un sitio más rápido. Tu yo del futuro consigue un código más limpio. Y la web se vuelve un poquito más ligera para todos.

Ahora ve, abre tus devtools, mira el bundle de tu proyecto y descubre qué puedes recortar. Tu navegador seguramente ya tiene la respuesta.