DEV Community: Gabriel Abreu

El punto ciego de la auditoría: pesé el build, no la página

Gabriel Abreu — Fri, 28 Aug 2026 01:56:25 +0000

Publiqué un post que se llamaba "Le hice una auditoría a mi propio portfolio y encontré 20 problemas". Era un inventario: recorrí mi propio sitio —una SPA de React 19 + Vite con Sanity como CMS—, anoté todo lo que estaba mal, arreglé lo que importaba y puse los números de antes y después al lado de cada punto. Si no lo has leído, la única parte que importa aquí es la metodología, y una línea de ella en particular:

Analicé el tamaño del build, chunk por chunk, en build/assets/.

Lo llamé el paso que más duele y el que más gente se salta. Sigo pensando que es verdad. También es el paso que garantizó que se me escapara el problema más grande que tenía el sitio.

El paso que funcionó

Pesar la salida del build funcionó exactamente como prometía. El hallazgo 1 de esa auditoría fue un PNG sin optimizar de una ilustración de desarrollador en /gabriel-abreu, mi página de contacto, 993 KB, servidos a cada visitante que caía ahí. Quedó en 23 KB. Una segunda imagen, el recorte mío que aparece en las tres variantes del componente Greeting, pasó de 358 KB a 45 KB.

Esas dos son assets empaquetados. Un componente importa una:

import p from "../assets/developer-illustration.webp";

Vite sigue esa importación, le pone un hash al archivo y lo emite en build/assets/. Después del build es un archivo en disco con un tamaño. Listar el directorio lo encuentra. Ordenar el listado por tamaño lo encuentra de primero. No hay forma de servirlo sin que aparezca en ese paso.

Así que el método era sólido dentro de su dominio: esas dos imágenes son assets empaquetados, y el paso encontró las dos.

El 23 de agosto abrí el índice del blog en un navegador y miré lo que pedía de verdad. Dieciséis portadas de posts, 9.88 MB.

Nada de eso podía haber aparecido en la auditoría. No porque ese día estuviera descuidado, sino por el lugar del que vienen esos bytes.

Dos ciclos de vida

Un asset empaquetado existe en tiempo de build. Una importación lo convierte en entrada del build, el bundler lo convierte en salida del build, y cualquier cosa que lea la salida del build lo ve.

Una imagen del CMS nunca es una entrada del build. Nadie la importa. Llega como un string en el resultado de una consulta, después de que la página ya cargó. Esta es la consulta que alimenta el índice del blog:

*[_type == "post"] | order(publishedAt desc){
  title,
  slug,
  mainImage{ asset->{ _id, url } },
  publishedAt
}

Eso corre en un useEffect después del montaje. La url que regresa apunta a cdn.sanity.io, React la mete en un img src, y el navegador la baja de un CDN que yo no construyo. En ningún momento del ciclo de vida de esa imagen aterriza un archivo en build/assets/.

Dos ciclos de vida distintos, y el paso más riguroso de mi auditoría solo podía observar uno de ellos. No "no lo observó de casualidad". No podía, por diseño. La balanza estaba bien. No estaba pesando toda la carga.

Lo que de verdad había en la página

Cuando medí con el Accept header real de un navegador en vez de con un listado de directorio:

/allpost, 16 post covers ........ 9.88 MB
one post page, 4 images ......... 4.54 MB
peor imagen suelta .............. 3.13 MB (PNG 2160x2700, mostrada a ~250px)
another cover ................... 2.27 MB (rendered at 433x227)

Las dos imágenes que atrapó la auditoría sumaban 1,351 KB entre las dos. Una sola ruta estaba sirviendo 9.88 MB.

Todos mis cross-posts en dev.to cierran con un enlace a /allpost. La ruta más pesada que medí era la página a la que mando a la gente.

`urlFor` se llamaba una sola vez

Sanity trae un builder de URLs de imagen, urlFor, que aplica transformaciones en el CDN: ancho, fit, formato. Antes del arreglo, urlFor se llamaba exactamente una vez en toda la aplicación. No una vez por componente. Una. Estaba en OnePost.tsx, dentro del serializador de PortableText para las imágenes incrustadas en el cuerpo de un artículo:

const src = value?.asset
  ? urlFor(value).width(1600).fit("max").auto("format").url()
  : value?.url;

Ancho topado, fit: max para que nada se escale hacia arriba, auto: format para que los navegadores modernos reciban WebP. Esa es la llamada correcta. Vale para las imágenes que un autor soltó en medio de un párrafo, las que un lector casi ni nota.

AllPosts.tsx no tenía ni una sola referencia a él. El encabezado del post tampoco. Esas tarjetas renderizaban mainImage.asset.url —el archivo original subido, directo del CDN— y dejaban que el CSS lo encogiera dentro de una caja de 250px. El navegador se baja los 3.13 MB completos primero y después lo pinta pequeño.

El sitio se veía como uno que servía sus imágenes del tamaño correcto. No lo era.

El arreglo

Las consultas que alimentan esas tarjetas proyectan asset->{url}, no el objeto de referencia que urlFor quiere, así que pasar por el constructor significaba reescribir las consultas. En vez de eso, el helper toma la URL que la consulta ya devuelve:

export function sizedImage(url: string | undefined | null, width: number): string {
  if (!url) return "";
  // Non-Sanity URLs (the BlockNote editor stores upload-endpoint URLs directly)
  // do not understand these parameters.
  if (!url.includes("cdn.sanity.io")) return url;
  const sep = url.includes("?") ? "&" : "?";
  return `${url}${sep}w=${width}&fit=max&auto=format&q=75`;
}

auto=format negocia según el Accept header de la petición, así que un navegador moderno recibe WebP y uno viejo recibe el formato original. fit=max solo escala hacia abajo, así que un original pequeño nunca se agranda. El chequeo de cdn.sanity.io está ahí porque mi editor BlockNote guarda directamente URLs del endpoint de subida y esas no entienden los parámetros: agregárselos habría roto imágenes que estaban funcionando.

Medidas otra vez de la misma manera, esas dieciséis portadas sumaron 182 KB, 56 veces menos que antes. El PNG de 2160x2700 pesa 24 KB.

Ese es el número de esas imágenes en esas rutas, medido con un navegador y en un solo día. No he medido el tiempo de carga en una conexión real, y no te voy a decir que ahora el sitio es rápido.

El alcance es la afirmación que no audité

Una auditoría contesta la pregunta que le hagas, y nada más. La mía preguntaba: ¿qué pesa mucho dentro de lo que sirvo? La respuesta era correcta.

Pero "lo que sirvo" es una frontera que dibuja el bundler, y el navegador no sabe que esa frontera existe. Pide lo que la página le dice que pida, venga de donde venga. Mi método trataba un artefacto de build como sustituto de una carga de página, y en un sitio como este esas dos cosas se traslapan sin ser el mismo conjunto.

Lo que hacía que ese paso se sintiera riguroso es lo mismo que lo hacía estrecho: era mecánico. Un directorio, una lista de archivos, tamaños, ordenados. Una medición que puede ser exhaustiva es exhaustiva sobre su propio dominio y muda sobre todo lo demás, y no parece incompleta: parece terminada. Veinte hallazgos, todos reales, y 9.88 MB saliendo todavía por la ruta que anuncio.

La lista de hallazgos es la parte de una auditoría que sí se revisa. El alcance también es una afirmación —una afirmación sobre dónde pueden estar los problemas— y es la que sale sin examinar. La próxima vez voy a escribir esa afirmación al lado del método, en el mismo documento: esto fue lo que medí, y esto es lo que esta medición no puede ver.

Verde y ciego: cuando un check que pasa no significa nada

Gabriel Abreu — Fri, 28 Aug 2026 01:56:22 +0000

Escribí un mensaje de commit que dice que SEO.tsx "pone documentElement.lang" y "emite enlaces hreflang". Abrí un post en español en el navegador, miré el documento, y ahí estaba: documentElement.lang === "es", y tres etiquetas <link rel="alternate" hreflang> para es, en y x-default. Idioma correcto, pares correctos, default correcto.

El mensaje de commit era exacto. El sitio también estaba sirviendo <html lang="en"> en cada post en español, con cero anotaciones hreflang.

Las dos frases son ciertas. Pero cada una habla de una superficie distinta.

La anotación que estaba y no estaba

Este sitio es una SPA de React 19 en Vercel con un paso de prerender en tiempo de build. El prerender escribe el <head> dentro del HTML estático para que los crawlers reciban títulos y meta tags sin ejecutar nada. SEO.tsx es un componente de React. Corre en el navegador, después de que React monta, y hace exactamente lo que dice su mensaje de commit.

scripts/prerender.mjs escribe el HTML que el servidor manda de verdad. En ese commit:

$ git show 86569b0:scripts/prerender.mjs | grep -c hreflang
0

El prerender reescribía solo el elemento <head>. Nunca tocaba la etiqueta <html>, así que el atributo lang se quedaba con lo que index.html traía de fábrica, que era en. Y no emitía ningún alternate, porque nada dentro de él sabía que la tabla de traducciones existía.

Lo confirmé con curl en las cuatro URLs emparejadas: original en inglés y traducción en español, en las dos direcciones. Después probé otra vez con un user-agent de Googlebot, por si Vercel estaba haciendo alguna jugada con los crawlers. Respuesta idéntica byte a byte. No había una segunda vía de entrega. El sitemap tampoco tenía alternates xhtml:link.

Aquí hay una trampa que vale la pena nombrar, porque es lo que deja que el error sobreviva un rato. Cada página del sitio sirve esto:

<link rel="alternate" type="application/rss+xml" ...>

Le haces grep a alternate sobre el HTML servido y encuentras una coincidencia. Si estás revisando rápido, y ya estás bastante seguro de que la funcionalidad jala porque la viste funcionar, una coincidencia es suficiente. La cadena que buscaste estaba presente. Era el feed.

La consecuencia práctica es más limitada de lo que suena. Google renderiza JavaScript, así que para Google esto fue un retraso y no una pérdida. El riesgo estaba en los motores que no renderizan, que veían posts en español declarados como inglés y sin ninguna indicación de que existiera una traducción.

Arreglado el 21 de agosto. prerender.mjs ahora pone lang en el elemento <html> y emite los alternates, leyendo src/config/translations.json, el mismo archivo que lee src/config/translations.ts. La tabla vive en JSON porque un script de build en .mjs no puede importar un módulo .ts, y tener dos copias de ella es precisamente la forma en que las dos mitades se volverían a separar.

Verificado después: lang="es" en los dos posts en español, lang="en" en los dos en inglés, tres enlaces hreflang en cada uno de los cuatro posts emparejados, y cero en un post sin pareja como /tailwind-css, que es el número correcto, porque un hreflang que apunta a una traducción que no existe es una afirmación falsa.

Aquí no verifiqué lo equivocado. Verifiqué algo real en la superficie que era más fácil de alcanzar.

El slot que ningún test estaba mirando

El segundo no se trata de revisar la superficie equivocada. No había superficie que revisar.

Cada post lleva dos unidades de anuncio: una dentro del artículo y otra al pie del post. El 20 de agosto a las 22:48 subí esta línea:

setStatus(ins.getAttribute('data-ad-status') ?? 'no-response');

Tres segundos después del montaje, si AdSense no había escrito un veredicto sobre el elemento, el código se inventaba uno. El CSS colapsaba el contenedor en no-response, así que el slot pasaba a display: none, mientras AdSense todavía lo estaba midiendo. No se puede colocar un anuncio dentro de una caja oculta y de ancho cero. La suposición se cumplía sola.

Eso estuvo en producción unas diez horas. El arreglo, a las 08:46 de la mañana siguiente, quitó el timeout por completo: solo el veredicto propio de AdSense cambia el estado, y un veredicto ausente significa "pending", que reserva espacio en vez de colapsarlo.

Eso metió el mismo bug, pero al revés.

En producción, la unidad del final del post llega a data-adsbygoogle-status="done" y después nunca recibe data-ad-status. Con la regla nueva, "nunca" es indistinguible de "todavía no". Se quedaba en pending permanentemente. Medido en un navegador real el 23 de agosto, en /portfolio-audit-20-problems, los dos slots en el mismo momento:

slot 9344511662 (end of post)
  data-adsbygoogle-status "done"
  data-ad-status null
  iframes 0
  height 303px
  display block
  "Advertisement" label visible

slot 2970675007 (in-article)
  data-adsbygoogle-status "done"
  data-ad-status "unfilled"
  height 0px
  display none

Misma página, misma carga. La asimetría estaba en mi máquina de estados, no en AdSense.

Así que durante dos días y medio, cada post de este sitio terminaba con un rectángulo vacío etiquetado "Advertisement", de 303 píxeles de alto en la página que medí. Nada estaba en rojo. Ningún test falló. El build pasó, la página renderizó.

El arreglo de verdad: el periodo de gracia ahora empieza solo cuando el propio AdSense reporta done, y el observer se queda escuchando después para que un veredicto tardío igual gane. También lee el atributo una vez, de inmediato, al engancharse, porque un MutationObserver no te dice nada de lo que pasó antes de que llamaras a observe(). Verificado después: los dos slots en 0px, display: none.

Verde porque nadie pregunta

Los dos fallos no tienen la misma forma.

En el caso del hreflang había un check, y estaba mirando el DOM del navegador en vez del cuerpo de la respuesta. Superficie equivocada, error honesto, encontrable.

En el caso del anuncio no había check. No uno débil: ninguno. Y desde afuera, "no hay check" y "el check pasó" producen una señal idéntica: un build que se pone verde. La ausencia de un test que falla se ve exactamente igual que la presencia de uno que pasa cuando lo único que puedes ver es el color. Un assert que falta no se anuncia. Uno roto sí.

Por eso la caja vacía duró dos días y medio y el bug del hreflang duró hasta que se me ocurrió correr curl.

El hilo del que salió esto

Escribo esto por un comentario. En el cross-post de dev.to de "How I Actually Code with Claude Code", Heinrich Neb lo dijo mejor de lo que yo puedo: un check puede estar verde y ciego. Su ejemplo era un test que afirmaba que un número de benchmark aparecía en la salida de su servidor, y el número era una cadena escrita a mano. El check vigilaba la frase, no la medición. Se quedó verde durante semanas. Debashish Ghosal, en el mismo hilo, sugirió escribir una nota de resultado en cada archivo de plan después de ejecutarlo, que es otra manera de atacar el mismo problema: que el registro diga lo que pasó, no lo que se pretendía.

No tengo una solución general. No voy a terminar esto con una filosofía de testing, porque me la estaría inventando en el momento para que el post parezca terminado.

Lo que sí tengo es una costumbre: abrir un navegador, buscar el elemento específico y medirlo. No la idea que el framework tiene del elemento: el elemento. Hacerle curl a la URL en vez de confiar en el componente que escribe la etiqueta. Leer la altura de la caja en vez de confiar en el estado que decide la altura.

Así fue como aparecieron los dos: uno a la vez, a mano, porque se me ocurrió mirar. No habría encontrado un tercero.

The Audit's Blind Spot: I Weighed the Build, Not the Page

Gabriel Abreu — Wed, 26 Aug 2026 12:27:09 +0000

I published a post called "I Audited My Own Portfolio and Found 20 Problems". It
was an inventory: I went through my own site — a React 19 + Vite SPA with Sanity
as the CMS — wrote down everything that was wrong with it, fixed what mattered, and put the before and after numbers next to each item. If you haven't read it, the
only part that matters here is the methodology, and one line of it in particular:

I went through the build output chunk by chunk in build/assets/.

I called that the step that hurts and the one most people skip. I still think
that is true. It is also the step that guaranteed I would miss the largest thing
wrong with the site.

The step that worked

Weighing the build output worked exactly as advertised. Finding 1 of that audit
was an unoptimized PNG of a developer illustration on /gabriel-abreu, my contact page, 993 KB, sent
to every visitor who landed there. It went to 23 KB. A second image, the cutout
of me that sits in three different greetings, went from 358 KB to 45 KB.

Those two are bundled assets. A component imports one:

import p from "../assets/developer-illustration.webp";

Vite follows that import, hashes the file, and emits it into build/assets/.
After the build it is a file on disk with a size. Listing the directory finds it.
Sorting the listing by size finds it first. There is no way to ship it and not
have it show up in that step.

So the method was sound within its domain: both of those images are bundled assets, and the step found both.

On August 23 I opened the blog index in a browser and watched what it actually
requested. Sixteen post covers, 9.88 MB.

None of that could have appeared in the audit. Not because I was sloppy that day
— because of where those bytes come from.

Two lifecycles

A bundled asset exists at build time. An import makes it a build input, the
bundler makes it a build output, and anything that reads the build output sees
it.

A CMS image is never a build input. Nothing imports it. It arrives as a string in
a query result, after the page has already loaded. This is the query that feeds
the blog index:

*[_type == "post"] | order(publishedAt desc){
  title,
  slug,
  mainImage{ asset->{ _id, url } },
  publishedAt
}

That runs in a useEffect after mount. The url that comes back points at
cdn.sanity.io, React puts it in an img src, and the browser fetches it from a
CDN I do not build. At no point in the lifecycle of that image does a file land
in build/assets/.

Two different lifecycles, and my audit's most rigorous step could only observe
one of them. Not "did not happen to observe." Could not, by construction. The
scale was accurate. It was not weighing the whole load.

What was actually on the page

Once I measured with a browser's real Accept header instead of a directory
listing:

/allpost, 16 post covers ........ 9.88 MB
one post page, 4 images ......... 4.54 MB
worst single image .............. 3.13 MB  (2160x2700 PNG, rendered ~250px wide)
another cover ................... 2.27 MB  (rendered at 433x227)

The two images the audit caught came to 1,351 KB between them. One route was
serving 9.88 MB.

Every one of my dev.to cross-posts closes with a link to /allpost. The heaviest route I measured was the page I send people to.

`urlFor` was called once

Sanity ships an image-URL builder, urlFor, that applies CDN transformations —
width, fit, format. Before the fix, urlFor was called exactly once in the application. Not once per component. Once. It was in OnePost.tsx, inside the
PortableText serializer for images embedded in the body of an article:

const src = value?.asset
  ? urlFor(value).width(1600).fit("max").auto("format").url()
  : value?.url;

Width capped, fit: max so nothing upscales, auto: format so modern browsers
get WebP. That is the correct call. It applies to images an author dropped into
the middle of a paragraph — the images a reader is least likely to notice.

AllPosts.tsx contained zero references to it. So did the post header. Those
cards rendered mainImage.asset.url — the original upload, straight from the
CDN — and let CSS scale it into a 250px box. The browser downloads all 3.13 MB first
and then paints it small.

It made the site look like a site that sized its images.

The fix

The queries feeding those cards project asset->{url}, not the reference object
urlFor wants, so going through the builder meant rewriting the queries. Instead
the helper takes the URL the query already returns:

export function sizedImage(url: string | undefined | null, width: number): string {
  if (!url) return "";
  // Non-Sanity URLs (the BlockNote editor stores upload-endpoint URLs directly)
  // do not understand these parameters.
  if (!url.includes("cdn.sanity.io")) return url;
  const sep = url.includes("?") ? "&" : "?";
  return `${url}${sep}w=${width}&fit=max&auto=format&q=75`;
}

auto=format negotiates on the request's Accept header, so a modern browser gets
WebP and an older one gets the original format. fit=max only ever scales down,
so a small source is never blown up. The cdn.sanity.io check is there because
my BlockNote editor stores upload-endpoint URLs directly and those do not
understand the parameters — appending them would have broken images that were
working.

Measured the same way afterward, those sixteen covers came to 182 KB, 56 times
less than before. The 2160x2700 PNG is 24 KB.

That is the number for those images on those routes, measured with one browser on one day. I have not measured load time on a real connection, and I am not
going to tell you the site is fast now.

The scope is the claim I did not audit

An audit answers the question you point it at. Mine asked: what is heavy in what
I ship? The answer was correct.

But "what I ship" is a boundary drawn by the bundler, and the browser does not
know that boundary exists. It requests what the page tells it to request, from
wherever. My method treated a build artifact as a stand-in for a page load, and
those two things overlap on a site like this without being the same set.

What made that step feel rigorous is the same thing that made it narrow: it was
mechanical. A directory, a list of files, sizes, sorted. A measurement that can
be exhaustive is exhaustive over its own domain and silent about everything else,
and it does not feel silent — it feels finished. Twenty findings, all real, and 9.88 MB still going out on the route I advertise.

The list of findings is the part of an audit that gets checked. The scope is a
claim too — a claim about where problems are allowed to be — and it is the one
that ships unexamined. Next time I will write that claim down next to the
method, in the same document: here is what I measured, and here is what this
measurement cannot see.

I write up the things I break and fix at codewithgabo.com.

Green and Blind: When a Passing Check Means Nothing

Gabriel Abreu — Tue, 25 Aug 2026 13:12:59 +0000

I wrote a commit message that says SEO.tsx "sets documentElement.lang" and "emits hreflang links". I opened a Spanish post in the browser, looked at the document, and there it was: documentElement.lang === "es", and three <link rel="alternate" hreflang> tags for es, en, and x-default. Right language, right pairs, right default.

The commit message was accurate. The site was also serving <html lang="en"> on every Spanish post, with zero hreflang annotations.

Both of those sentences are true. They are true of different surfaces.

The annotation that was there and wasn't

This site is a React 19 SPA on Vercel with a build-time prerender step. The prerender writes the <head> into the static HTML so that crawlers get titles and meta tags without executing anything. SEO.tsx is a React component. It runs in the browser, after React mounts, and it does exactly what its commit message claims.

scripts/prerender.mjs writes the HTML the server actually sends. At that commit:

$ git show 86569b0:scripts/prerender.mjs | grep -c hreflang
0

The prerender rewrote only the <head> element. It never touched the <html> tag at all, so the lang attribute stayed at whatever index.html had baked in, which was en. And it emitted no alternates, because nothing in it knew the translation table existed.

I confirmed it with curl on all four paired URLs — English original and Spanish translation, both directions. Then I tried again with a Googlebot user-agent, in case Vercel was doing something clever for crawlers. Byte-identical response. There was no second delivery path. The sitemap had no xhtml:link alternates either.

There is a trap in this one worth naming, because it is what lets the mistake survive for a while. Every page on the site serves this:

<link rel="alternate" type="application/rss+xml" ...>

Grep the served HTML for alternate and you find a hit. If you are checking quickly, and you are already fairly sure the feature works because you watched it work, a hit is enough. The string you searched for was present. It was the feed.

The practical consequence is narrower than it sounds. Google renders JavaScript, so for Google this was a delay rather than a loss. The exposure was to engines that do not render, which saw Spanish posts declared as English with no indication that a translation existed.

Fixed on 21 August. prerender.mjs now sets lang on the <html> element and emits the alternates, reading src/config/translations.json — the same file src/config/translations.ts reads. The table lives in JSON because a .mjs build script cannot import a .ts module, and keeping two copies of it is precisely how the two halves would drift apart again.

Verified after: lang="es" on the two Spanish posts, lang="en" on the two English ones, three hreflang links on each of the four paired posts, and zero on an unpaired post like /tailwind-css — which is the correct number, since an hreflang pointing at a translation that doesn't exist is a false claim.

I did not verify the wrong thing here. I verified a real thing on the surface that was easier to reach.

The slot no test was watching

The second one isn't about checking the wrong surface. There was no surface to check.

Every post carries two ad units: one in-article, one at the foot of the post. On 20 August at 22:48 I shipped this line:

setStatus(ins.getAttribute('data-ad-status') ?? 'no-response');

Three seconds after mount, if AdSense had not written a verdict onto the element, the code invented one. The CSS collapsed the container on no-response, so the slot went display: none — while AdSense was still measuring it. An ad cannot be placed into a hidden, zero-width box. The guess made itself come true.

That was live for about ten hours. The fix, at 08:46 the next morning, removed the timeout entirely: only AdSense's own verdict changes the state, and a missing verdict means "pending", which reserves space instead of collapsing it.

That installed the exact mirror of the bug it fixed.

In production, the end-of-post unit reaches data-adsbygoogle-status="done" and then never receives data-ad-status at all. Under the new rule, "never" is indistinguishable from "not yet". It sat in pending permanently. Measured in a real browser on 23 August, on /portfolio-audit-20-problems, both slots at the same moment:

slot 9344511662  (end of post)
  data-adsbygoogle-status   "done"
  data-ad-status            null
  iframes                   0
  height                    303px
  display                   block
  "Advertisement" label     visible

slot 2970675007  (in-article)
  data-adsbygoogle-status   "done"
  data-ad-status            "unfilled"
  height                    0px
  display                   none

Same page, same load. The asymmetry was in my state machine, not in AdSense.

So for two and a half days, every post on this site ended with an empty rectangle labeled "Advertisement" — 303 pixels tall on the page I measured. Nothing was red. No test failed. The build passed, the page rendered.

The real fix: the grace period now starts only once AdSense itself reports done, and the observer stays attached afterward so a late verdict still wins. It also reads the attribute once immediately on attach, because a MutationObserver tells you nothing about what happened before you called observe(). Verified after: both slots 0px, display: none.

Green because nothing is asking

The two failures are not the same shape.

In the hreflang case there was a check and it was watching the browser DOM instead of the response body. Wrong surface, honest mistake, findable.

In the ad case there was no check. Not a weak one — none. And from outside, "no check" and "check passed" produce the identical signal: a build that goes green. Absence of a failing test looks exactly like presence of a passing one when all you can see is the color. A missing assertion doesn't announce itself the way a broken one does.

That is why the empty box lasted two and a half days and the hreflang bug lasted until I happened to run curl.

The thread this came from

I'm writing this because of a comment. On the dev.to cross-post of "How I Actually Code with Claude Code", Heinrich Neb put it better than I can: a check can be green and blind. His example was a test asserting that a benchmark number appeared in his server's output — where the number was a hardcoded string. The check guarded the sentence, not the measurement. It stayed green for weeks. Debashish Ghosal, in the same thread, suggested writing an outcome note onto each plan file after execution, which is a different attack on the same problem: make the record say what happened, not what was intended.

I don't have a general solution. I'm not going to end this with a testing philosophy, because I'd be inventing one on the spot to make the post feel finished.

What I actually have is a habit: open a browser, find the specific element, and measure it. Not the framework's idea of the element — the element. curl the URL instead of trusting the component that writes the tag. Read the height off the box instead of trusting the state that decides the height.

That is how both of these turned up: one at a time, by hand, because I happened to look. It would not have found a third.

I write up the things I break and fix at codewithgabo.com.

How I Actually Code with Claude Code: My Real Workflow on a Real Project

Gabriel Abreu — Mon, 24 Aug 2026 04:02:37 +0000

There are two kinds of articles about coding with AI. The ones that generate a sorting function and conclude the profession is over, and the ones that show a dumb bug and conclude none of this works.

Neither one looks anything like my actual workday.

This is the third kind: the concrete workflow I use with Claude Code on this very site, three tasks I actually delegated, the trail in the repository to back it up, and a section on where it fails that runs as long as the section on where it works. That's the part I would have wanted to read.

What it is, without the marketing

Claude Code is an agent that runs in your terminal, inside your repository. It reads your files, runs your commands, edits your code, makes your commits. It isn't editor autocomplete, and it isn't a separate chat window where you paste fragments back and forth.

That difference matters more than it sounds. An assistant that sees one file helps you write a function. An agent that sees the whole repo, runs the tests and reads the output can take a complete task off your hands. It's the difference between asking for advice and delegating work.

My setup

Nothing exotic:

The repo for this site: a React frontend on Vite, Sanity as the CMS, and a small backend of Vercel Functions.
A .claude/ folder in the project with the local config and permissions.
A docs/plans/ folder where every design and plan lives. This is the key piece, and I'll explain why in a second.
Git worktrees when a big task deserves isolation from the current working tree.

And one rule of my own, which is what actually changed my results: nothing big gets written without a written plan first.

The workflow: design, plan, execute

The temptation with an agent is to open the terminal and say "add me an admin panel." Sometimes that works. Often it produces something that runs but isn't what you wanted, and you find out after six hundred lines are already on disk.

So I split it into three phases, and I don't let them overlap.

One: design. Before touching code, a conversation. What problem are we solving, two or three approaches with their downsides, which one we pick and why. Out comes a design document in docs/plans/. Short, but written.

Two: plan. The design turns into a task-by-task plan. Which files each task touches, which test gets written first, which command verifies it, where the commit goes. My plans folder has files like 2026-04-28-slice-2-vercel-migration.md and 2026-04-29-portfolio-audit-implementation.md. Each one is a plan that got executed task by task.

Three: execute. Now the code. With the plan in front of it, the session doesn't drift. If something doesn't fit, it shows up right away, because there's a document saying what should be happening.

It sounds like bureaucracy, and I thought so at first. It isn't. The written plan is what turns "the agent did something weird" into "the agent went off script at step 4," which is a very different problem and a much easier one to fix.

Three tasks I actually delegated

The portfolio audit

I asked it to audit this site as if it belonged to a client. Read every public component, walk the routes on mobile and desktop, measure the build chunk sizes, count the real posts in Sanity.

It came back with 20 findings across four areas, each with a priority and an effort estimate. Among them: a 993 KB unoptimized illustration, a sitemap containing zero of nine published posts, and a 404 page that hung forever on "Loading post...".

I wrote that one up in detail in a separate post, but what matters here is the division of labor: the machine found, I prioritized. The document came back with findings and no fixes, on purpose, so I would be the one deciding what got touched and what didn't. Three of the twenty I threw out.

Migrating Express to Vercel Functions

I had a small Express server on Railway wrapping the Google Analytics API. It worked, but it cost money every month to sit there 24/7 serving a dashboard almost nobody visits.

Moving it to serverless functions was textbook work: pull the helpers into api/_utils/, turn the route into a handler, move the environment variables, verify the external contract didn't change. The frontend never noticed. The bill went to zero.

This is exactly the kind of task where delegating wins: mechanical, well defined, with an objective success criterion. It doesn't take judgment, it takes not getting twenty details in a row wrong. A machine does that better than I do at eleven at night.

The sitemap generated from Sanity

My sitemap was a static file I had to edit by hand every time I published. Which is to say: never.

Now it's a script that runs on prebuild, queries Sanity with GROQ, and writes the file with every post and its real date. Eighty lines of Node, no new dependencies.

Small task, and that's exactly why it sat there for months. That's the pattern I've noticed most: what has saved me the most time isn't the big tasks, it's the forty-minute ones that had been on the list for half a year because they were never urgent enough.

Where it fails

This is where most of these articles go blurry. Straight to it.

It accepts your premise too fast. If you say "fix this CSS bug," it will go looking for a CSS bug. If the real problem was route ordering, you may get a CSS fix that covers the symptom. Now, when something breaks, I describe the behavior and not my diagnosis. The difference in outcome is enormous.

It's too agreeable about your ideas. If you propose a bad approach, the default response tends to be helping you build it well. I explicitly ask for two or three options with their downsides before anything gets decided, because if I don't ask for alternatives, they don't show up.

Context degrades in long sessions. Over a session of several hours, the decisions from the first half hour get fuzzy. That's why the plan goes into a file instead of staying in the conversation: the file doesn't forget.

It doesn't know what ugly looks like. It can write a component that is correct, accessible, passes the tests, and looks bad. Visual judgment is still yours. On this site I've redone by hand a fair amount of CSS that was technically fine.

And the big one: you are still responsible for what gets merged. I read every diff. Not because I trust it less than a human colleague, but exactly as much as I'd check a human colleague. A commit with my name on it is mine, no matter who typed it.

When it costs more than it saves: tasks under ten minutes that I already know how to do, one-line changes, and anything where explaining the context takes longer than doing the thing. Writing a good prompt for a trivial change is net negative work.

How to start tomorrow

If you want to try this without getting burned:

Start with a boring, well-defined task. Migrating a format, writing tests for something that already exists, updating dependencies. Don't start with your product's flagship feature.
Ask for a plan before code. Even when the task is small. Reading the plan tells you in thirty seconds whether you were understood, and fixing a plan is free compared to fixing an implementation.
Work on a branch or a worktree. So you can throw it all away without thinking twice if it goes sideways.
Read the diffs. All of them. If you're not going to read them, don't delegate.
Leave the context in the repository, in writing. Decisions that live only in a conversation get lost. The ones in docs/plans/ are still there three months later, when you no longer remember why you chose that.

What actually changed

I don't code faster. I code with less friction on the boring parts, which turn out to be most of the work.

The tasks that used to sit on the list out of inertia now get done, because the cost of starting them dropped enough. The sitemap had been pending for months. The audit for longer. Neither was hard; both were tedious, and tedious is exactly what piled up on me.

What didn't change: I still decide what gets built, I still review every line that goes in, and I'm still the one responsible when something breaks in production.

That seems right to me. It's the part of the job I like.

I write up the things I break and fix at codewithgabo.com.

I Audited My Own Portfolio and Found 20 Problems

Gabriel Abreu — Fri, 21 Aug 2026 20:25:06 +0000

Auditing someone else's site is easy. You open devtools, point at what's broken, send the invoice, leave. Auditing your own is a different job, because every bad decision in it is yours, most of them made around eleven at night on a Tuesday, and you have spent months certain they were fine.

So I sat down with codewithgabo.com and reviewed it like it belonged to a client. No excuses, no "I'll get to that later." The review turned up 20 findings across four areas. Five of them stung.

This post is the honest list: what I found, why it was there, and which number moved when I fixed it.

How I audited

There's no trick to it. The method was boring on purpose, because boring is what actually finds things.

I read every public component and every route definition in src/.
I walked the 10 public routes in a browser, at 375px and on desktop, writing down each page's h1, its character count, its internal links, and any broken image.
I queried Sanity to count the posts and words I actually had, not the ones I assumed I had.
I ran npm audit and npm outdated.
I went through the build output chunk by chunk in build/assets/.

That last step is the one that hurts and the one most people skip. Looking at the real weight of what you ship is like stepping on a scale in January: you already know it's bad, but you need the number.

Finding 1: a 993 KB illustration

The worst of the twenty. On /gabriel-abreu I was serving an unoptimized PNG of a developer illustration. 993 KB. Almost a megabyte of decoration.

It had company. nobggabo.png weighed 358 KB and shipped on the home page, the blog index and the repos page, because all three variants of my Greeting component import it. So those 358 KB sat on the critical path of the three pages people land on first.

The fix has no technical merit whatsoever: convert to WebP at quality 80.

developer-illustration:  993 KB  ->  23 KB   (-98%)
nobggabo:                358 KB  ->  45 KB   (-87%)

Ninety-eight percent. Nearly a megabyte, for a drawing that looks identical. The credit isn't in the conversion. It's in finally bothering to look.

The lesson: if you've never checked what your images weigh, that is your biggest problem right now. Statistically, it just is.

Finding 2: the sitemap contained zero posts

I had 9 published posts. My sitemap.xml listed 7 static pages and no posts at all. The lastmod dates were frozen months in the past on top of that.

Which means I'd been writing content and then not showing it to Google. All of the writing work, none of the distribution work.

The root cause was that the sitemap was a static file I had to update by hand. By hand means never.

It's now generated at build time from a GROQ query against Sanity, running as prebuild:

*[_type=="post" && !(_id in path("drafts.**")) && defined(slug.current)]{
  "slug": slug.current,
  _updatedAt
}

Every npm run build writes a fresh sitemap.xml with all the posts and real dates. It no longer depends on me remembering.

The lesson: anything that depends on your memory is already broken. You just haven't found out yet.

Finding 3: my 404 page didn't exist in practice

This is the one I'm most embarrassed by, because it was a real bug and not an oversight.

If you typed codewithgabo.com/anything, the site hung forever on "Loading post...". No 404. No error message. Just a spinner, until you got bored and closed the tab.

The cause: my post route, /:slug, caught any unknown URL before it could ever reach the * route that renders NotFound. OnePost queried Sanity, got nothing back, and since it didn't distinguish "still loading" from "this doesn't exist," it sat in the loading state indefinitely.

The fix was separating those two states:

const [postData, setPostData] = useState<SanityPostData | null>(null);
const [notFound, setNotFound] = useState(false);

// ...

if (notFound) return <NotFound />;
if (!postData) return <LoadingSpinner message="Loading post..." />;

Three lines. One extra useState and two returns in the right order. That was the fix for a bug that had spent months quietly turning visitors away.

While I was in there I gave the 404 page an actual design: the big number, a bilingual heading, and three buttons that take you somewhere useful instead of leaving you stranded.

The lesson: a loading state that never resolves looks exactly like "slow." That's why nobody reports it.

Finding 4: a feature that hadn't rendered in months

In data.ts I have three projects tagged badge: "New": Analytics Dashboard, NegocioRD and A2C International. The Card component accepts a badge prop and renders it as a pill.

The pill never appeared. Not once.

Why? Because Portfolio.tsx destructured image, title, description, url and languages off each project, and forgot badge. The data existed. The component that renders it existed. Nobody had ever introduced the two to each other.

  description={project.description}
  url={project.url}
  languages={project.languages}
+ badge={project.badge}

One line. I wrote the data, I wrote the component, and I left out the wire between them. It sat like that for months, and I never noticed because I never looked at the project grid asking "does this look the way it should?" I looked at it asking "does it load?"

The lesson: check your UI against what it's supposed to show, not against what it shows. Those are different questions and only one of them catches this bug.

Finding 5: 405 KB of charting library for people who hadn't asked for charts

I keep an analytics dashboard at /dashboard-demo, public, so the work is visible. It uses recharts.

Recharts is heavy. And it was sitting inside the chunk loaded eagerly when you hit the route. So anyone who opened the demo downloaded 405 KB of charting library before deciding whether they even cared.

The fix was wrapping ChartCard in React.lazy with Suspense, so recharts becomes its own chunk and only comes down when the charts are actually about to mount:

before:  useAnalyticsData chunk = 405 KB   (recharts inside)
after:   useAnalyticsData chunk =   3 KB
         ChartCard chunk        = 411 KB   (lazy)

405 KB down to 3 KB on initial load. The library still weighs what it weighs, obviously. What changed is when you pay for it, and who does.

The lesson: code splitting doesn't make your app smaller. It stops the people who bounce from paying for what they never used.

The other fifteen

Not all of them were dramatic. Six unused images sitting in the repo, more than a megabyte of dead weight. One moderate vulnerability in a dependency. A page, /education, that existed and rendered content but wasn't linked from anywhere in the menu. Forgotten console.log and console.warn calls in five files. No privacy policy page and no terms page.

There were also things that were fine, which is worth writing down so you don't drive yourself crazy: the mobile layout was clean, the content density was good, and the ad configuration was correct. An honest audit also tells you what to leave alone.

How to audit yours

If you're up for it, this is the order I'd go in. It's sorted by return per hour spent:

Weigh your images. Sort by size and look at the top three. If anything is over 200 KB, there's your afternoon.
Type a URL that doesn't exist on your own site. Watch what happens. Count to ten. If it's still loading, you have my finding number 3.
Open your sitemap and count the URLs. Is your actual content in there? Are the dates real?
Look at your build chunk sizes. Anything over 300 KB that isn't required for the first paint is a candidate for lazy loading.
Walk every page asking what it should be showing, not whether it loads. That's where bugs like the badge one turn up.
Run npm audit and npm outdated. Ten seconds.
Grep the project for console.log. Another ten seconds.

All seven steps fit in an afternoon. It took me one afternoon to find these and another to fix the ones that mattered.

What I actually learned

None of these problems were hard. Not one. The most complex fix was three lines; the highest-impact one was converting a PNG to WebP, which is a single command.

They weren't there because they were difficult. They were there because I never sat down and looked. Building is more fun than reviewing, so you keep building on top, and the broken things stay underneath, holding up the building with a months-old bug.

If you have a portfolio, a blog or a side project you haven't honestly looked at in a while: put two hours on the calendar this week. Not to add anything. Just to look.

You'll find your own 993 KB PNG. I promise.

I write up the things I break and fix at codewithgabo.com.

Migrating an Express Backend to Vercel Functions Without Downtime

Gabriel Abreu — Fri, 21 Aug 2026 19:59:20 +0000

Earlier this year I migrated the analytics backend behind this site from a long-running Express server on Railway to a set of Vercel Functions. The frontend never noticed. Cost dropped from a small monthly Railway bill to $0/month on Vercel's hobby tier. This post walks through how I did it, what broke, and when this kind of migration actually makes sense.

Why migrate at all

The backend was a tiny Express server that did two things:

Wrap the Google Analytics 4 Data API behind an admin-only endpoint so the dashboard on this site could read GA4 metrics without exposing the service-account key.
Validate an ADMIN_TOKEN to gate that endpoint.

That was it. A few hundred lines of Node, three dependencies, one route. Running it as a 24/7 container on Railway was fine, but it had three quiet costs:

Money. Hobby tier on Railway isn't free anymore. Even a small workload was a recurring charge.
Cold starts I didn't need. The dashboard isn't visited often. The Express server sat idle 99% of the time, costing money to do nothing.
Deploy ceremony. Two repositories, two pipelines, two environments to keep aligned. Every backend change meant context-switching to the Railway dashboard.

Vercel Functions felt like the right shape: stateless handlers that spin up on request, scale to zero when idle, deploy from the same git push flow as anything else.

The before / after

BEFORE:
  Frontend
        │ HTTPS
        ▼
  Railway: long-running Node + Express
        ├─ /api/analytics
        ├─ middleware: cors, helmet
        └─ env: ADMIN_TOKEN, GA4 credentials

AFTER:
  Frontend
        │ HTTPS
        ▼
  Vercel Functions
        ├─ api/analytics.js (one handler per route)
        ├─ api/health.js
        └─ api/_utils/ (extracted helpers — auth, ga4 client)

Same external contract, completely different runtime model. The frontend was not part of this migration — it was still on GitHub Pages at the time, and has since moved to Vercel too, but that was a separate change.

Step 1 — Turn each Express route into a Vercel handler

A Vercel Function is just a Node module that exports a handler matching (req, res) => void | Promise<void>. The shape is essentially http.IncomingMessage / http.ServerResponse with some extras.

The Express version looked like this:

// Before
app.get('/api/analytics', requireAuth, async (req, res) => {
  const { startDate, endDate } = req.query;
  const data = await runAnalyticsQuery(startDate, endDate);
  res.json(data);
});

The Vercel version is the same logic, no app, no next:

// After: api/analytics.js
const { applyCors, requireAuth } = require('./_utils/auth');
const { runAnalyticsQuery } = require('./_utils/ga4');

module.exports = async (req, res) => {
  if (!applyCors(req, res)) return;
  if (req.method !== 'GET') {
    return res.status(405).json({ error: 'Method not allowed' });
  }
  if (!requireAuth(req, res)) return;

  const { startDate, endDate } = req.query;
  const data = await runAnalyticsQuery(startDate, endDate);
  res.json(data);
};

Three things to notice:

No middleware chain. Each handler runs the few checks it needs explicitly. With one or two routes per file, this is clearer than a global middleware stack.
CORS becomes a function call. I extracted applyCors to share between handlers. It returns false and writes the response if the request was a preflight, so the handler can early-exit.
Auth, same. requireAuth reads the Authorization: Bearer <token> header, compares to process.env.ADMIN_TOKEN, and writes a 401 if it fails.

Step 2 — Extract helpers into `api/_utils/`

Vercel ships every file in api/ (excluding _-prefixed paths) as a public route. Anything starting with _ is treated as a private utility. This is the convention I used for shared code:

api/
├── analytics.js
├── health.js
└── _utils/
    ├── auth.js
    └── ga4.js

The GA4 helper memoises the client across invocations, which matters because Vercel Functions reuse warm container instances when traffic is steady:

// api/_utils/ga4.js
const { BetaAnalyticsDataClient } = require('@google-analytics/data');

let cached = null;

function getClient() {
  if (cached) return cached;
  cached = new BetaAnalyticsDataClient({
    credentials: {
      client_email: process.env.GA4_CLIENT_EMAIL,
      private_key: process.env.GA4_PRIVATE_KEY.replace(/\\n/g, '\n'),
    },
  });
  return cached;
}

That replace(/\\n/g, '\n') is the one consistent pain point of moving service-account keys between secret stores. Vercel preserves real newlines in multi-line env values, so if you paste with literal \n from a copied JSON file, you have to undo the escaping.

Step 3 — Configure `vercel.json`

Vercel infers most of the project layout, but it's worth being explicit about CORS origins and Node version:

{
  "version": 2,
  "functions": {
    "api/**/*.js": {
      "runtime": "nodejs20.x"
    }
  },
  "headers": [
    {
      "source": "/api/(.*)",
      "headers": [
        { "key": "Access-Control-Allow-Origin", "value": "https://codewithgabo.com" }
      ]
    }
  ]
}

I keep the dynamic origin allowlist (which supports multiple domains during development) inside applyCors and use the static header here only as a defense-in-depth layer.

Step 4 — Migrate environment variables

I copied each env var from Railway's dashboard to Vercel's, set them for Production + Preview + Development so dev runs (vercel dev) work locally. The two non-trivial ones:

GA4_PRIVATE_KEY — multi-line value with real newlines. Pasted directly; no escaping.
FRONTEND_URL — a comma-separated list (https://codewithgabo.com,https://gabbs27.github.io,http://localhost:3000) consumed by the CORS helper. This was new — Express had it baked into a cors() middleware config.

Step 5 — Smoke-test before flipping traffic

The old Railway service was still live during the migration. I deployed Vercel to a preview URL, hit it from curl with a real ADMIN_TOKEN, confirmed the JSON response matched the Railway version, then updated the frontend's VITE_ANALYTICS_API_URL env to point at the new Vercel alias and redeployed.

Once the dashboard rendered metrics from Vercel, I stopped the Railway service. No DNS games, no routing rules, no reverse proxy cutover. The frontend rebuild was the cutover.

Three gotchas I hit

1. File uploads. A later endpoint (api/upload.js) accepts a multipart image and proxies it to Sanity's asset API. Express handled multipart through multer middleware. On Vercel I had to parse the multipart body manually because the platform's default body parser only handles JSON. Vercel exposes req.body as a Buffer for unknown content types — from there it's busboy or roll-your-own boundary parsing.

2. Cold starts on the first hit of the day. A Vercel Function that hasn't been invoked recently can take ~500–1500ms to spin up. For a dashboard that's only checked occasionally, this is fine. For a user-facing API on the critical path, it would be a real concern — pre-warming or pinning the function to a region helps, but it's a tradeoff to keep in mind.

3. The _utils/ import path. The first time I deployed, I forgot that Vercel's build doesn't follow files outside api/ automatically. Putting helpers under api/_utils/ (with the leading underscore) lets the bundler find them while keeping them private.

The result

Concrete before / after:

Monthly cost: small but recurring → $0
Cold start: ~50 ms (always warm on Railway) → 500–1500 ms on first hit, then cached
Deploy flow: separate Railway dashboard → git push from the same monorepo
Dependencies: express, cors, helmet, nodemon → none (the platform handles all of it)
Repo footprint: server.js, routes/, middleware/ → a handful of small handlers under api/

For a small admin endpoint like this one, Vercel Functions are clearly the right fit. For a high-traffic API where every millisecond matters, Railway or Fly would still be the better answer.

When NOT to do this

A migration like this only makes sense if:

Your traffic is bursty or low — cold starts won't dominate the user experience.
Your handlers are stateless. Long-lived WebSocket connections, in-memory caches, or background workers don't translate cleanly.
You can live with your plan's per-invocation timeout. Check the current limit for your tier before you assume a long-running job will fit.

If you're running a chat server, a worker pool, or anything with sticky in-memory state, stay on a long-running container. For everything else — REST endpoints, webhooks, glue between services — serverless is hard to beat.

Closing thought

The most underrated part of this migration was deleting server.js, the routes/ folder, and four packages from package.json. Less code is less to maintain. Less infrastructure is less to monitor. The new setup does exactly the same thing, on better terms, with fewer moving parts.

If you have a small backend doing low-traffic admin work and you're paying month after month to keep it running, this is worth half a day of your time.

I write up the things I break and fix at codewithgabo.com.

Axios Or Fetch

Gabriel Abreu — Sun, 19 Feb 2023 01:30:00 +0000

Consuming REST APIs is a fundamental part of building modern web applications. In React, several libraries are available to handle this task, including Fetch and Axios. They look almost identical in a simple example, which is why the choice feels arbitrary at first — but they behave differently in the exact places where beginners get stuck. Let's go through both, and then through the differences that actually matter.

Fetch

Fetch is a built-in browser API for making HTTP requests. It is a promise-based API, which means it returns a promise that resolves to a Response object when the request is complete.

import React, { useEffect, useState } from 'react';

// eslint-disable-next-line no-unused-vars
function TodoList() {
  const [todos, setTodos] = useState([]);

  useEffect(() => {
    fetch('https://jsonplaceholder.typicode.com/todos')
      .then(response => response.json())
      .then(data => setTodos(data));
  }, []);

  return (
    <ul>
      {todos.map(todo => (
        <li key={todo.id}>{todo.title}</li>
      ))}
    </ul>
  );
}

In the example above, we're using the useEffect hook to make the API call when the component mounts. We then use the json() method to convert the response to a JSON object, which we then set as the state of our component using the setTodos function.

Axios

Axios is a popular third-party library for making HTTP requests in JavaScript. It is also promise-based, and it provides a simple API for making requests and handling responses. You install it first with npm install axios.

import React, { useEffect, useState } from 'react';
import axios from 'axios';

// eslint-disable-next-line no-unused-vars
function TodoList() {
  const [todos, setTodos] = useState([]);

  useEffect(() => {
    axios.get('https://jsonplaceholder.typicode.com/todos')
      .then(response => setTodos(response.data));
  }, []);

  return (
    <ul>
      {todos.map(todo => (
        <li key={todo.id}>{todo.title}</li>
      ))}
    </ul>
  );
}

In the example above, we're using the get() method of the Axios library to make the API call. We then use the data property of the response object to set the state of our component. Notice there is no json() step — Axios already parsed the body for you.

The difference that actually bites you: errors

This is the one I wish someone had told me on day one. Fetch does not reject on a 404 or a 500. As far as fetch is concerned, the server answered, so the promise resolves. Only a network failure (no connection, DNS error, CORS block) rejects it. That means a broken endpoint quietly flows into your success path, response.json() tries to parse an error page, and you end up debugging the wrong thing.

You have to check response.ok yourself. The two snippets below are just the useEffect from the components above, with one extra piece of state alongside todos to hold the message:

const [error, setError] = useState(null);

useEffect(() => {
  fetch('https://jsonplaceholder.typicode.com/todos/999999')
    .then(response => {
      if (!response.ok) {
        throw new Error(`Request failed with status ${response.status}`);
      }
      return response.json();
    })
    .then(data => setTodos(data))
    .catch(error => setError(error.message));
}, []);

Axios rejects on any non-2xx status by default, so the failure lands in catch where you expect it. The error object carries a response when the server replied, and doesn't when the request never got there:

useEffect(() => {
  axios.get('https://jsonplaceholder.typicode.com/todos/999999')
    .then(response => setTodos(response.data))
    .catch(error => {
      if (error.response) {
        setError(`Request failed with status ${error.response.status}`);
      } else {
        setError(error.message);
      }
    });
}, []);

Both are fine. Fetch just makes you opt in to the behaviour most people assumed they already had.

Cleaning up when the component unmounts

If the user navigates away before your request finishes, your .then still runs and calls setTodos on a component that no longer exists. The fix is an AbortController and a cleanup function returned from useEffect:

useEffect(() => {
  const controller = new AbortController();

  fetch('https://jsonplaceholder.typicode.com/todos', { signal: controller.signal })
    .then(response => response.json())
    .then(data => setTodos(data))
    .catch(error => {
      if (error.name === 'AbortError') return;
      console.error(error);
    });

  return () => controller.abort();
}, []);

Axios accepts the same AbortController signal in current versions:

useEffect(() => {
  const controller = new AbortController();

  axios.get('https://jsonplaceholder.typicode.com/todos', { signal: controller.signal })
    .then(response => setTodos(response.data))
    .catch(error => {
      if (axios.isCancel(error)) return;
      console.error(error);
    });

  return () => controller.abort();
}, []);

The aborted request throws, so remember to swallow that specific error instead of showing it to the user.

Timeouts

Neither one waits forever by default in a useful way. Axios has a timeout option in milliseconds:

axios.get('https://jsonplaceholder.typicode.com/todos', { timeout: 5000 })
  .then(response => console.log(response.data))
  .catch(error => {
    if (error.code === 'ECONNABORTED') {
      console.log('The request timed out');
    }
  });

Fetch has no option, but you can pass AbortSignal.timeout() as the signal:

fetch('https://jsonplaceholder.typicode.com/todos', { signal: AbortSignal.timeout(5000) })
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => {
    if (error.name === 'TimeoutError') {
      console.log('The request timed out');
    }
  });

Sending data

With fetch you serialise the body and set the header yourself. Forget the Content-Type and many APIs will reject the request:

fetch('https://jsonplaceholder.typicode.com/todos', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ title: 'Write a blog post', completed: false })
})
  .then(response => response.json())
  .then(data => console.log(data));

Axios does both for you when you hand it a plain object:

axios.post('https://jsonplaceholder.typicode.com/todos', {
  title: 'Write a blog post',
  completed: false
}).then(response => console.log(response.data));

Instances and interceptors

This is the real reason teams reach for Axios once an app grows. You create one configured client and every call inherits the base URL, the timeout, and the auth header — and you write the "token expired, log the user out" logic once instead of in every component.

// src/api/client.js
import axios from 'axios';

const client = axios.create({
  baseURL: 'https://jsonplaceholder.typicode.com',
  timeout: 5000,
  headers: { 'Content-Type': 'application/json' }
});

client.interceptors.request.use(config => {
  const token = localStorage.getItem('token');
  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }
  return config;
});

client.interceptors.response.use(
  response => response,
  error => {
    if (error.response && error.response.status === 401) {
      localStorage.removeItem('token');
      window.location.href = '/login';
    }
    return Promise.reject(error);
  }
);

export default client;

Your components then import that file instead of Axios directly:

import client from '../api/client';

// inside useEffect
client.get('/todos').then(response => setTodos(response.data));

You can build the same thing on top of fetch — it's just a wrapper function you write and maintain yourself.

So which one should you pick

For a small app with a handful of requests, use fetch. It's built into every modern browser and into recent versions of Node, it's zero bytes of dependency, and the only tax is remembering to check response.ok.

Reach for Axios once you have auth headers on every call, refresh-token logic, a dozen endpoints, or a team that will otherwise each invent their own wrapper. Paying for a dependency to delete that duplication is a good trade.

Two honest limits. First, Axios is a dependency you have to keep updated, and if you only ever make two GET requests it's weight you don't need. Second — and more important — neither of these solves caching, request deduplication, refetching on focus, or loading and error state. If you find yourself writing the same useState trio in every component, the answer isn't switching HTTP clients; it's a data-fetching library like React Query or SWR, which sits on top of either one.

Tailwind CSS

Gabriel Abreu — Fri, 10 Feb 2023 20:05:00 +0000

Having trouble with CSS? Try Tailwind.

Are you tired of writing countless lines of CSS to style your web pages, only to end up with messy, hard-to-maintain code? Or perhaps you're just starting out with web development and feeling overwhelmed by the complexity of CSS? If so, you might want to consider giving Tailwind CSS a try.

Tailwind is a utility-first CSS framework. Instead of giving you components like .btn or .card, it gives you hundreds of tiny single-purpose classes — p-4, text-sm, flex, rounded-xl — and you compose them directly in your markup. That sentence is easy to say and hard to picture, so the rest of this post is one small component built both ways.

The same card, twice

Here's a card: an image, a title, a paragraph, a link. First the way most of us learned to write it.

<article class="card">
  <img class="card__image" src="/coffee.jpg" alt="A cup of cold brew on a wooden table">
  <div class="card__body">
    <h2 class="card__title">Cold brew, at home</h2>
    <p class="card__text">Twelve hours, a jar, and coarse ground coffee. That's the whole recipe.</p>
    <a class="card__link" href="/recipes/cold-brew">Read the recipe</a>
  </div>
</article>

And the stylesheet that makes it real:

.card {
  max-width: 20rem;
  background-color: #ffffff;
  border: 1px solid #e5e7eb;
  border-radius: 0.75rem;
  overflow: hidden;
  box-shadow: 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1);
}

.card__image {
  display: block;
  width: 100%;
  height: 10rem;
  object-fit: cover;
}

.card__body { padding: 1rem; }

.card__title {
  margin: 0 0 0.5rem;
  font-size: 1.125rem;
  line-height: 1.75rem;
  font-weight: 600;
  color: #111827;
}

.card__text {
  margin: 0 0 1rem;
  font-size: 0.875rem;
  line-height: 1.25rem;
  color: #4b5563;
}

.card__link {
  display: inline-block;
  padding: 0.5rem 1rem;
  border-radius: 0.375rem;
  background-color: #2563eb;
  color: #ffffff;
  font-size: 0.875rem;
  text-decoration: none;
}

.card__link:hover { background-color: #1d4ed8; }

Nothing is wrong with that code. But notice what it costs: six class names you had to invent, a naming convention you have to remember, a second file you have to keep in sync with the first, and — the part that actually hurts six months later — no way to tell from the HTML what any of it looks like.

Now the same card in Tailwind:

<article class="max-w-xs overflow-hidden rounded-xl border border-gray-200 bg-white shadow-sm">
  <img class="block h-40 w-full object-cover" src="/coffee.jpg" alt="A cup of cold brew on a wooden table">
  <div class="p-4">
    <h2 class="mb-2 text-lg font-semibold text-gray-900">Cold brew, at home</h2>
    <p class="mb-4 text-sm text-gray-600">Twelve hours, a jar, and coarse ground coffee. That's the whole recipe.</p>
    <a href="/recipes/cold-brew"
       class="inline-block rounded-md bg-blue-600 px-4 py-2 text-sm text-white hover:bg-blue-700">
      Read the recipe
    </a>
  </div>
</article>

Same card — near enough. The hex values above are v3-era approximations of v4's palette, which is defined in oklch and renders a slightly different blue. No stylesheet, no invented names, nothing to keep in sync.

To run it you need the build step wired up, not just the import. On a Vite project — which is how this site is set up — that means installing tailwindcss and @tailwindcss/vite, adding tailwindcss() to the plugins array in vite.config.ts, and then putting one line at the top of your CSS file:

@import "tailwindcss";

So what does "utility-first" actually mean

Look at p-4. It is a class whose entire definition is padding: 1rem. That's it. text-sm sets a font size and a line height. rounded-md sets a border radius. Every class does one thing and its name tells you which thing.

Because each class is a fixed, self-contained rule, three things follow:

The styles live in the markup, which is where you're already looking. You read mb-4 text-sm text-gray-600 and you know exactly what that paragraph looks like without opening another file.
You stop naming things. Naming is genuinely one of the hardest parts of CSS, and utilities delete the problem. There is no .card__body--compact to argue about.
Deleting an element deletes its styles. No orphaned rules accumulating in a stylesheet nobody dares to clean up.

The values aren't arbitrary either. p-1 through p-8 walk a consistent spacing scale, so a page built out of utilities tends to look coherent almost by accident.

Responsive, hover, focus, dark mode

This is the part I would miss most if I stopped using it. Any utility takes a prefix, and the prefix is the condition:

<article class="max-w-xs overflow-hidden rounded-xl border border-gray-200 bg-white shadow-sm
                md:flex md:max-w-2xl
                dark:border-gray-800 dark:bg-gray-900">
  <img class="block h-40 w-full object-cover md:h-auto md:w-48"
       src="/coffee.jpg" alt="A cup of cold brew on a wooden table">
  <div class="p-4">
    <h2 class="mb-2 text-lg font-semibold text-gray-900 dark:text-gray-100">Cold brew, at home</h2>
    <p class="mb-4 text-sm text-gray-600 dark:text-gray-400">Twelve hours, a jar, and coarse ground coffee.</p>
    <a href="/recipes/cold-brew"
       class="inline-block rounded-md bg-blue-600 px-4 py-2 text-sm text-white
              hover:bg-blue-700
              focus-visible:ring-2 focus-visible:ring-blue-400 focus-visible:ring-offset-2 dark:focus-visible:ring-offset-gray-900
              dark:bg-blue-500 dark:hover:bg-blue-400">
      Read the recipe
    </a>
  </div>
</article>

md:flex means "flex, from the medium breakpoint up". hover:bg-blue-700 means "this background, on hover". dark:bg-gray-900 follows the reader's system theme by default. No media queries, no pseudo-class selectors, no jumping between files to check which breakpoint you used.

Customising the design tokens

You are not stuck with Tailwind's defaults. In Tailwind v4, configuration moved into your CSS file as an @theme block:

@import "tailwindcss";

@theme {
  --color-brand: oklch(58% 0.11 180);
  --color-brand-dark: oklch(48% 0.10 180);
  --font-display: "Inter", ui-sans-serif, system-ui, sans-serif;
  --radius-card: 0.75rem;
}

Those variables generate classes. --color-brand gives you bg-brand, text-brand, border-brand; --font-display gives you font-display; --radius-card gives you rounded-card. So the link becomes:

<a href="/recipes/cold-brew"
   class="inline-block rounded-card bg-brand px-4 py-2 font-display text-sm text-white hover:bg-brand-dark">
  Read the recipe
</a>

One note if you're reading older tutorials: projects still on Tailwind v3 configure all of this in a tailwind.config.js file instead, and that file is not how v4 works.

"But now my markup is ugly"

This is the honest complaint about Tailwind and it deserves an honest answer: yes, a long class list is ugly, and the fix is not a shorter class list — it's fewer copies of it.

If you're writing that card once, leave it inline. If you're writing it twenty times, extract a component. In React:

export function Card({ image, alt, title, href, children }) {
  return (
    <article className="max-w-xs overflow-hidden rounded-card border border-gray-200 bg-white shadow-sm dark:border-gray-800 dark:bg-gray-900">
      <img className="block h-40 w-full object-cover" src={image} alt={alt} />
      <div className="p-4">
        <h2 className="mb-2 text-lg font-semibold text-gray-900 dark:text-gray-100">{title}</h2>
        <p className="mb-4 text-sm text-gray-600 dark:text-gray-400">{children}</p>
        <a
          href={href}
          className="inline-block rounded-md bg-brand px-4 py-2 text-sm text-white hover:bg-brand-dark"
        >
          Read the recipe
        </a>
      </div>
    </article>
  );
}

Now the ugly class list exists in exactly one place, and every usage reads <Card title="Cold brew, at home" ... />. That's better than a CSS class would have been, because the structure is reused too, not just the styles.

Tailwind also has an @apply directive that folds utilities into a regular CSS class. It works, and it's the right tool when you can't create a component — but reach for a component first. @apply quietly reintroduces the naming problem and the second file you were trying to escape.

When Tailwind is the wrong choice

I use Tailwind on most things I build, but "most" is not "all".

A tiny static page. If you're styling one landing page with forty lines of CSS, a build step and a new vocabulary are more overhead than the CSS you're avoiding. Just write the CSS.
A team that already has a working design system. If your company ships a component library people are happy with, replacing it with utilities is a large migration in exchange for a smaller win than you think.
Markup you can't easily edit. Utility-first assumes you control the HTML. If your output comes from a CMS's rich text, a third-party widget, or an email template, you can't sprinkle classes onto elements you never see — that's a job for regular CSS selectors.
A project where nobody will learn the class names. Tailwind has a real learning curve, and its payoff is fluency. If you're handing the project to someone who'll fight the vocabulary for the rest of its life, you've made their job harder, not easier.

If you're new to Tailwind, its syntax will feel overwhelming at first — I found the same thing. But once you get the hang of it, it's a much more direct way to write CSS, and the card above is the reason why: everything that card looks like is right there in the file you're already reading.

I write up the things I break and fix at codewithgabo.com.

DEV Community: Gabriel Abreu

El punto ciego de la auditoría: pesé el build, no la página

El paso que funcionó

Dos ciclos de vida

Lo que de verdad había en la página

urlFor se llamaba una sola vez

El arreglo

El alcance es la afirmación que no audité

Verde y ciego: cuando un check que pasa no significa nada

La anotación que estaba y no estaba

El slot que ningún test estaba mirando

Verde porque nadie pregunta

El hilo del que salió esto

The Audit's Blind Spot: I Weighed the Build, Not the Page

The step that worked

Two lifecycles

What was actually on the page

urlFor was called once

The fix

The scope is the claim I did not audit

Green and Blind: When a Passing Check Means Nothing

The annotation that was there and wasn't

The slot no test was watching

Green because nothing is asking

The thread this came from

How I Actually Code with Claude Code: My Real Workflow on a Real Project

What it is, without the marketing

My setup

The workflow: design, plan, execute

Three tasks I actually delegated

The portfolio audit

Migrating Express to Vercel Functions

The sitemap generated from Sanity

Where it fails

How to start tomorrow

What actually changed

I Audited My Own Portfolio and Found 20 Problems

How I audited

Finding 1: a 993 KB illustration

Finding 2: the sitemap contained zero posts

Finding 3: my 404 page didn't exist in practice

Finding 4: a feature that hadn't rendered in months

Finding 5: 405 KB of charting library for people who hadn't asked for charts

The other fifteen

How to audit yours

What I actually learned

Migrating an Express Backend to Vercel Functions Without Downtime

Why migrate at all

The before / after

Step 1 — Turn each Express route into a Vercel handler

Step 2 — Extract helpers into api/_utils/

Step 3 — Configure vercel.json

Step 4 — Migrate environment variables

Step 5 — Smoke-test before flipping traffic

Three gotchas I hit

The result

When NOT to do this

Closing thought

Axios Or Fetch

Fetch

Axios

The difference that actually bites you: errors

Cleaning up when the component unmounts

Timeouts

Sending data

Instances and interceptors

So which one should you pick

Tailwind CSS

The same card, twice

So what does "utility-first" actually mean

Responsive, hover, focus, dark mode

Customising the design tokens

"But now my markup is ugly"

When Tailwind is the wrong choice

`urlFor` se llamaba una sola vez

`urlFor` was called once

Step 2 — Extract helpers into `api/_utils/`

Step 3 — Configure `vercel.json`