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:

1. Weigh your images. Sort by size and look at the top three. If anything is over 200 KB, there's your afternoon.
2. 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.
3. Open your sitemap and count the URLs. Is your actual content in there? Are the dates real?
4. Look at your build chunk sizes. Anything over 300 KB that isn't required for the first paint is a candidate for lazy loading.
5. Walk every page asking what it should be showing, not whether it loads. That's where bugs like the badge one turn up.
6. Run `npm audit` and `npm outdated`. Ten seconds.
7. 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.

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:

1. 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.
2. 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.
3. Work on a branch or a worktree. So you can throw it all away without thinking twice if it goes sideways.
4. Read the diffs. All of them. If you're not going to read them, don't delegate.
5. 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.

Sanity viene con Studio, un editor de contenido completo, mantenido por gente que sabe más que yo del tema, gratis y ya integrado con mi esquema. Y aun así escribí el mío.

Esto normalmente es mala señal. La mayoría de las veces que un desarrollador reconstruye algo que ya existía, la respuesta honesta es "porque me dio la gana". Así que déjame defender la decisión con argumentos, enseñar el código de la parte interesante, y admitir lo que me costó. Al final hay una sección de cuándo no deberías hacer esto, que es probablemente la más útil.

El problema no era el editor

Studio es bueno. El problema nunca fue la calidad del editor.

El problema era que publicar en mi propio blog requería salir de mi propio sitio. Studio corre aparte, con su propio despliegue, su propia interfaz y su propia sesión. Para escribir un post: abrir otra aplicación, entrar otra vez, escribir en una interfaz que no se parece en nada al sitio donde va a salir el texto, publicar, y volver a mi sitio a comprobar cómo quedó.

Para un equipo de contenido con varios autores, revisiones y permisos, ese es exactamente el producto correcto. Para un blog de un solo autor que además es el desarrollador, es fricción sin contrapartida. Y la fricción en publicar tiene un efecto muy medible: publicas menos.

Ya tenía sesión de administrador en mi sitio, un panel en /admin, y un backend con permisos de escritura sobre Sanity. Faltaba una pantalla.

Qué construí

Dos rutas:

• /admin/write para un post nuevo
• /admin/write/:id para editar uno existente

Dentro, un editor de bloques con BlockNote, que da la experiencia tipo Notion que quería: menú de barra inclinada, arrastrar bloques, pegar imágenes directamente. Se conecta a mi tema claro/oscuro y a mi sesión de administrador, así que se siente parte del sitio y no un injerto.

La subida de imágenes va al mismo endpoint que ya tenía, así que pegar una imagen en el editor la sube a Sanity y devuelve el identificador del asset sin que yo salga de la pantalla.

Nada de esto es difícil. La parte difícil es otra.

La pieza interesante: traducir entre dos formatos

Aquí está el trabajo real, y es el motivo por el que este post existe.

BlockNote guarda su contenido en su propio JSON de bloques. Sanity guarda el contenido enriquecido en Portable Text, que es un formato distinto con otra filosofía: en vez de HTML anidado, una lista plana de bloques donde el formato inline vive en marcas y los enlaces en definiciones separadas.

No son compatibles. Hace falta un traductor, y tiene que funcionar en las dos direcciones: al guardar, de BlockNote a Portable Text; al abrir un post existente para editarlo, de Portable Text a BlockNote.

Ese traductor vive en un archivo, src/utils/blocknoteToPortable.ts, y empieza declarando su propia tabla de equivalencias:

// Mapping table:
//   BN paragraph / heading / bulletListItem / numberedListItem  ->  PT block with style/listItem
//   BN inline content (text + styles bold/italic/code, link)    ->  PT spans with marks
//   BN image                                                    ->  PT type: image with asset reference

La conversión de formato inline es la parte que más se piensa. En BlockNote, un fragmento de texto lleva un objeto styles con banderas booleanas. En Portable Text, lleva un array de marcas con nombres:

if (styles.bold) marks.push('strong');
if (styles.italic) marks.push('em');
if (styles.code) marks.push('code');

Los enlaces son más sutiles, porque Portable Text no guarda la URL en el span. Guarda una definición aparte con una clave, y el span solo lleva esa clave entre sus marcas. Hay que generar la clave, registrar la definición, y luego pegársela a cada hijo del enlace:

const linkKey = makeKey();
markDefs.push({ _type: 'link', _key: linkKey, href: node.href });
const inner = inlineToSpans(node.content || []);
for (const span of inner.spans) {
  span.marks = [...(span.marks || []), linkKey];
  spans.push(span);
}

La lección que me costó datos: nunca pierdas contenido

La primera versión hacía lo obvio con los tipos de bloque que no soportaba: ignorarlos.

Eso significa que si pegabas una tabla, o un archivo incrustado, y guardabas, ese contenido desaparecía en silencio. Sin aviso, sin error. Escribías algo, le dabas a guardar, y ya no estaba.

La versión actual, cuando encuentra un bloque que no sabe traducir, hace el mejor esfuerzo por rescatar el texto plano antes de rendirse:

// Unsupported block types (table, embed, file, audio, video, etc.) -
// best-effort extract plain text so content isn't lost on save.
if (block.type && !SUPPORTED.has(block.type)) {
  const fallback = Array.isArray(block.content)
    ? block.content
        .map((n) => (typeof n?.text === 'string' ? n.text : ''))
        .join('')
    : '';

El resultado queda feo: una tabla se convierte en un párrafo de texto corrido. Pero feo y recuperable es infinitamente mejor que limpio y perdido. Puedo arreglar un párrafo feo. No puedo recuperar un texto que se borró sin avisar.

Hay una defensa parecida en el manejo de contenido inline, con un comentario que documenta por qué existe:

// Some BlockNote versions return objects we can't iterate (e.g. for table
// cells, embeds). Skip rather than throw "T is not iterable".

Ese comentario es el resumen de una tarde entera. Lo dejé escrito para no repetirla.

Si escribes un conversor entre dos formatos de contenido, esta es la regla: cuando no sepas qué hacer con algo, degrada. Nunca descartes. El contenido del usuario, aunque el usuario seas tú, no es tuyo para perderlo.

El precio

Toca ser honesto con los costes, porque son reales.

Cuando audité este sitio, uno de los hallazgos fue que el chunk del `PostEditor` pesa 1,3 MB. BlockNote más Mantine no son ligeros. Es tanto que dispara el aviso de tamaño de chunk de Vite en cada build.

El atenuante es que la ruta se carga de forma diferida, así que solo lo paga quien entra a /admin/write, que soy yo. Ningún visitante del blog descarga un solo byte de eso. Por eso quedó como prioridad baja y sigue ahí.

Pero el coste real no es el megabyte. Es que ahora ese conversor es mío. Cuando BlockNote cambie su formato de bloques en una versión mayor, el problema es mío. Cuando aparezca un caso raro de Portable Text que no contemplé, lo arreglo yo. Studio no me habría cobrado nada de eso nunca.

Escribir el código es la parte barata. Mantenerlo es la factura, y llega en cuotas.

Cuándo NO deberías hacer esto

Con lo que sé ahora, usa Studio y no mires atrás si te reconoces en algo de esto:

• Hay más de un autor. En cuanto necesitas permisos, roles o saber quién cambió qué, estás reimplementando un producto entero, no una pantalla.
• Hay revisión editorial. Borradores, estados, programación de publicaciones, historial de versiones. Studio te da todo eso; tú no lo vas a construir en un fin de semana.
• Tu contenido no es sobre todo texto. Si tus documentos tienen referencias cruzadas, objetos anidados o campos complejos, los editores de Studio ya resuelven eso y a ti te tocaría inventarlo.
• Quien escribe no eres tú. Si el editor lo va a usar alguien no técnico, la interfaz pulida y mantenida vale mucho más que la integración con tu tema.
• Tu fricción para publicar no es el problema. Si publicas de forma constante y el cambio de contexto no te frena, no tienes el problema que esto resuelve. No construyas la solución.

Mi caso cumplía justo lo contrario: un autor, sin revisión, contenido casi todo texto, y una fricción para publicar que se notaba en la cadencia. Por eso valió la pena.

Lo que haría igual

Volvería a construirlo. Pero la razón importa: no lo construí porque Studio fuera malo, sino porque mi problema no era el editor, era el cambio de contexto. Y ese, ninguna mejora de Studio me lo iba a quitar.

Antes de reconstruir algo que ya existe, la pregunta útil no es "¿puedo hacerlo mejor?". Casi siempre la respuesta es no. La pregunta es "¿es mi problema el que esta herramienta resuelve?". Si no lo es, ninguna cantidad de calidad ajena te va a servir.

Ahora escribo un post desde el mismo sitio donde se publica, con mi tema, con mi sesión, sin cambiar de aplicación. Ese era el objetivo entero. Todo lo demás fue el precio.

Hay dos tipos de artículos sobre programar con IA. Los que te enseñan a generar una función de ordenamiento y concluyen que el oficio se acabó, y los que enseñan un bug tonto y concluyen que esto no sirve para nada.

Ninguno de los dos se parece a mi trabajo diario.

Este post es lo tercero: el flujo concreto que uso con Claude Code sobre este mismo sitio, con tres tareas que delegué de verdad, el rastro en el repositorio para probarlo, y una sección sobre dónde falla que va a ser tan larga como la de dónde funciona. Porque esa es la parte que a mí me habría servido leer.

Qué es, sin marketing

Claude Code es un agente que corre en tu terminal, dentro de tu repositorio. Lee tus archivos, corre tus comandos, edita tu código y hace tus commits. No es autocompletado en el editor y no es una ventana de chat aparte donde copias y pegas fragmentos.

La diferencia importa más de lo que parece. Un asistente que ve un archivo te ayuda a escribir una función. Un agente que ve el repositorio entero, corre los tests y lee la salida puede encargarse de una tarea completa. Es la diferencia entre pedir consejo y delegar trabajo.

Mi setup

Nada exótico:

• El repositorio de este sitio, que es un frontend en React con Vite, Sanity como CMS y un backend pequeño de funciones en Vercel.
• Una carpeta .claude/ en el proyecto con la configuración local y los permisos.
• Una carpeta docs/plans/ donde vive todo lo que se ha diseñado y planificado. Esta es la pieza clave y ahora explico por qué.
• Worktrees de git cuando una tarea grande merece aislarse del árbol de trabajo actual.

Y una regla propia, que es la que de verdad cambió mi resultado: nada grande se escribe sin un plan escrito antes.

El flujo: diseñar, planificar, ejecutar

La tentación con un agente es abrir la terminal y decir "añádeme un panel de administración". A veces sale. Muchas veces sale algo que funciona pero que no es lo que querías, y lo descubres cuando ya hay seiscientas líneas escritas.

Así que separo en tres fases, y no dejo que se solapen:

Uno, diseñar. Antes de tocar código, una conversación. Qué problema resolvemos, dos o tres enfoques con sus contras, cuál elegimos y por qué. Sale un documento de diseño en docs/plans/. Corto, pero escrito.

Dos, planificar. Del diseño sale un plan por tareas. Qué archivos toca cada una, qué test se escribe primero, qué comando la verifica, dónde va el commit. En mi carpeta de planes hay archivos como 2026-04-28-slice-2-vercel-migration.md o 2026-04-29-portfolio-audit-implementation.md. Cada uno es un plan que se ejecutó tarea a tarea.

Tres, ejecutar. Ahora sí, código. Con el plan delante, la sesión no deriva. Si algo no encaja, se ve enseguida, porque hay un documento que dice qué debería estar pasando.

Suena a burocracia y al principio lo pensé. No lo es. El plan escrito es lo que convierte "el agente hizo algo raro" en "el agente se desvió del paso 4", que es un problema muy distinto y mucho más fácil de arreglar.

Tres tareas que delegué de verdad

La auditoría del portfolio

Le pedí que auditara este sitio como si fuera de un cliente. Leer cada componente público, recorrer las rutas en celular y escritorio, medir el tamaño de los chunks del build, contar los posts reales en Sanity.

Salieron 20 hallazgos en cuatro áreas, cada uno con prioridad y esfuerzo estimado. Entre ellos: una ilustración de 993 KB sin optimizar, un sitemap con cero posts de nueve publicados, y una página 404 que se quedaba colgada para siempre en "Loading post...".

Lo escribí en detalle en otro post, pero lo relevante aquí es el reparto del trabajo: la máquina encontró, yo prioricé. El documento salió con hallazgos y sin arreglos, a propósito, para que yo decidiera qué tocaba y qué no. Tres de los veinte los descarté.

La migración de Express a Vercel Functions

Tenía un servidor Express pequeño en Railway envolviendo la API de Google Analytics. Funcionaba, pero costaba dinero todos los meses por estar encendido 24/7 sirviendo un dashboard que casi nadie visita.

La migración a funciones sin servidor fue una tarea de manual: extraer los ayudantes a api/_utils/, convertir la ruta en un handler, mover las variables de entorno, verificar que el contrato externo no cambiara. El frontend nunca se enteró. La factura pasó a cero.

Esta es exactamente la clase de tarea donde delegar gana: mecánica, bien definida, con un criterio de éxito objetivo. No requiere criterio, requiere no equivocarse en veinte detalles seguidos. Eso lo hace mejor una máquina que yo a las once de la noche.

El sitemap generado desde Sanity

Mi sitemap era un archivo estático que había que editar a mano cada vez que publicaba. O sea: nunca.

Ahora es un script que corre en prebuild, consulta Sanity con GROQ, y escribe el archivo con todos los posts y sus fechas reales. Son ochenta líneas de Node sin dependencias nuevas.

Tarea pequeña, y justamente por eso llevaba meses sin hacerla. Ese es el patrón que más he notado: lo que más me ha ahorrado no son las tareas grandes, sino las de cuarenta minutos que llevaban medio año en la lista porque nunca eran lo bastante urgentes.

Dónde falla

Aquí es donde la mayoría de estos artículos se ponen borrosos. Vamos al grano.

Acepta tu premisa demasiado rápido. Si le dices "arregla este bug de CSS", va a buscar un bug de CSS. Si el problema real era el orden de las rutas, puede que te entregue un arreglo de CSS que tapa el síntoma. Ahora, cuando algo se rompe, describo el comportamiento y no mi diagnóstico. La diferencia en resultado es enorme.

Es demasiado agradable con tus ideas. Si propones un enfoque malo, la respuesta por defecto tiende a ser ayudarte a construirlo bien. Yo pido explícitamente que me den dos o tres opciones con contras antes de decidir nada, porque si no pido alternativas, no aparecen.

El contexto se degrada en sesiones largas. En una sesión de horas, las decisiones de la primera media hora se vuelven borrosas. Por eso el plan va a un archivo y no se queda en la conversación: el archivo no se olvida.

No sabe qué es feo. Puede escribir un componente correcto, accesible y que pasa los tests, y que se vea mal. El criterio visual sigue siendo tuyo. En este sitio he rehecho a mano bastante CSS que estaba técnicamente bien.

Y lo más importante: sigues siendo responsable de lo que se mergea. Reviso cada diff. No porque desconfíe más que de un compañero humano, sino exactamente igual que de un compañero humano. Un commit con mi nombre es mío, lo haya escrito quien lo haya escrito.

Cuándo sale más caro: tareas de menos de diez minutos que ya sé hacer, cambios de una línea, y cualquier cosa donde explicar el contexto tarde más que hacerlo. Escribir un buen prompt para un cambio trivial es trabajo neto negativo.

Cómo empezar mañana

Si quieres probar sin quemarte:

1. Empieza por una tarea aburrida y bien definida. Migrar un formato, escribir tests de algo que ya existe, actualizar dependencias. No empieces por la funcionalidad estrella de tu producto.
2. Pide un plan antes que código. Aunque la tarea sea pequeña. Leer el plan te dice en treinta segundos si se entendieron, y corregir un plan es gratis comparado con corregir una implementación.
3. Trabaja en una rama o en un worktree. Para poder tirarlo todo sin pensarlo si se tuerce.
4. Lee los diffs. Enteros. Si no vas a leerlos, no delegues.
5. Deja el contexto por escrito en el repositorio. Las decisiones que viven solo en una conversación se pierden. Las que viven en docs/plans/ siguen ahí en tres meses, cuando ya no te acuerdes de por qué elegiste eso.

Lo que de verdad cambió

No programo más rápido. Programo con menos fricción en lo aburrido, que resulta ser la mayoría del trabajo.

Las tareas que antes se quedaban en la lista por pereza ahora se hacen, porque el coste de arrancarlas bajó lo suficiente. El sitemap llevaba meses pendiente. La auditoría llevaba más. Ninguna era difícil; las dos eran tediosas, y lo tedioso es exactamente lo que se me acumulaba.

Lo que no cambió: sigo decidiendo qué se construye, sigo revisando cada línea que entra, y sigo siendo el responsable cuando algo se rompe en producción.

Eso me parece bien. Es la parte del trabajo que me gusta.

Auditar el sitio de otra persona es fácil. Abres las herramientas de desarrollo, señalas lo que está mal, cobras y te vas. Auditar el tuyo es otra cosa, porque cada decisión mala la tomaste tú, normalmente un martes a las once de la noche, y llevas meses convencido de que estaba bien.

Eso hice con codewithgabo.com: senté a revisarlo como si fuera de un cliente. Sin excusas, sin "eso lo arreglo después". Salieron 20 hallazgos repartidos en cuatro áreas. Cinco me dolieron de verdad.

Este post es la lista honesta: qué encontré, por qué pasó, y qué número cambió al arreglarlo.

Cómo audité

No hay magia. El método fue aburrido a propósito, porque lo aburrido es lo que encuentra cosas:

• Leí cada componente público y cada definición de ruta en src/.
• Recorrí las 10 rutas públicas en el navegador, a 375px y en escritorio, anotando el h1 de cada una, el número de caracteres, los enlaces internos y las imágenes rotas.
• Consulté Sanity para contar posts y palabras reales, no las que yo creía tener.
• Corrí npm audit y npm outdated.
• Analicé el tamaño del build, chunk por chunk, en build/assets/.

Ese último paso es el que más duele y el que más gente se salta. Mirar el peso real de lo que sirves es como pesarte después de las fiestas: sabes que va a estar mal, pero necesitas el número.

Hallazgo 1: una ilustración de 993 KB

El peor. En /gabriel-abreu servía una ilustración de desarrollador en PNG sin optimizar. 993 KB. Casi un megabyte para un dibujo decorativo.

Y no era el único. nobggabo.png pesaba 358 KB y se cargaba en todas las páginas públicas, porque lo importan las tres variantes del componente Greeting que uso en el inicio, en los posts y en los repositorios. Cada navegación pagaba esos 358 KB otra vez.

La solución no tiene ningún mérito técnico: convertir a WebP con calidad 80.

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

Un 98%. Casi un megabyte por un dibujo que se ve exactamente igual. El mérito no está en la conversión, está en haberme molestado en mirar.

La lección: si no has revisado el peso de tus imágenes, ese es tu problema más grande ahora mismo. Estadísticamente, lo es.

Hallazgo 2: el sitemap no tenía ni un solo post

Tenía 9 posts publicados. Mi sitemap.xml listaba 7 páginas estáticas y cero posts. Las fechas de lastmod, además, estaban congeladas meses atrás.

O sea: llevaba tiempo escribiendo contenido y luego no se lo enseñaba a Google. Todo el trabajo de escribir, ninguno del de distribuir.

El problema de fondo era que el sitemap era un archivo estático que había que actualizar a mano. Y a mano significa nunca.

Ahora se genera en tiempo de build, con una consulta GROQ a Sanity, corriendo como prebuild:

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

Cada npm run build escribe un sitemap.xml fresco, con todos los posts y con fechas reales. Ya no depende de que yo me acuerde.

La lección: cualquier cosa que dependa de tu memoria, ya está rota. Solo que todavía no lo sabes.

Hallazgo 3: mi página 404 no existía en la práctica

Este es el que más vergüenza me da, porque era un bug de verdad, no un descuido.

Si entrabas a codewithgabo.com/cualquier-cosa, el sitio se quedaba colgado para siempre en "Loading post...". No mostraba un 404. No mostraba un error. Se quedaba ahí, girando, hasta que te aburrías y cerrabas la pestaña.

La causa: mi ruta comodín de posts, /:slug, capturaba cualquier URL desconocida antes de que llegara a la ruta * del componente NotFound. OnePost consultaba Sanity, no recibía nada, y como no distinguía entre "todavía cargando" y "esto no existe", se quedaba en el estado de carga eternamente.

El arreglo fue separar esos dos estados:

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

// ...

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

Tres líneas. Un useState más y dos returns en el orden correcto. Ese era el arreglo de un bug que llevaba meses echando visitantes del sitio en silencio.

Aproveché para darle a la página 404 un diseño real: el número grande, un encabezado bilingüe, y tres botones que llevan a algún sitio útil en vez de dejarte tirado.

La lección: un estado de carga que nunca termina se ve igual que "lento". Por eso nadie lo reporta.

Hallazgo 4: una funcionalidad que llevaba meses sin renderizarse

En data.ts tengo tres proyectos marcados con badge: "New": Analytics Dashboard, NegocioRD y A2C International. El componente Card acepta la prop badge y la renderiza como una pastilla.

La pastilla no aparecía nunca. Ni una sola vez.

¿Por qué? Porque Portfolio.tsx desestructuraba image, title, description, url y languages de cada proyecto... y se olvidaba de pasar badge. El dato existía. El componente que lo renderiza existía. Simplemente nadie los presentó.

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

Una línea. Escribí el dato, escribí el componente, y se me olvidó el cable entre los dos. Llevaba meses así, y nunca lo noté porque nunca miré la parrilla preguntándome "¿esto se ve como debería?". La miraba preguntándome "¿carga?".

La lección: revisa tu interfaz contra lo que debería mostrar, no contra lo que muestra. Son preguntas distintas y solo una encuentra este bug.

Hallazgo 5: 405 KB de librería de gráficos para gente que no los quería

Tengo un dashboard de analítica en /dashboard-demo, público, para que se vea el trabajo. Usa recharts.

Recharts es pesado. Y estaba metido dentro del chunk que se cargaba de forma eager al entrar en la ruta. Resultado: cualquiera que abriera la demo se descargaba 405 KB de librería de gráficos antes de decidir si le interesaba siquiera.

La solución fue envolver ChartCard en React.lazy con Suspense, para que recharts se convierta en su propio chunk y solo baje cuando los gráficos van a montarse de verdad:

antes:  useAnalyticsData chunk = 405 KB   (recharts dentro)
después: useAnalyticsData chunk =   3 KB
         ChartCard chunk        = 411 KB  (lazy)

De 405 KB a 3 KB en la carga inicial. La librería sigue pesando lo mismo, claro. La diferencia es cuándo la pagas, y quién.

La lección: el código dividido no hace tu aplicación más pequeña. Hace que la gente que rebota no pague por lo que no llegó a usar.

Los otros quince

No todos eran dramáticos. Hubo seis imágenes sin usar sumando más de un megabyte muerto en el repositorio. Una vulnerabilidad moderada en una dependencia. Una página, /education, que existía y renderizaba contenido pero no estaba enlazada desde ninguna parte del menú. console.log olvidados en cinco archivos. Ninguna página de política de privacidad ni de términos.

Y también hubo cosas bien, que conviene anotar para no volverse loco: el diseño móvil estaba limpio, la densidad de contenido era buena, y la configuración de anuncios estaba correcta. Una auditoría honesta también dice qué no hay que tocar.

Cómo auditar el tuyo

Si te animas, este es el orden por el que yo iría. Está puesto de mayor a menor retorno por hora invertida:

1. Pesa tus imágenes. Ordena por tamaño y mira las tres primeras. Si hay algo por encima de 200 KB, ahí tienes tu tarde.
2. Escribe una URL que no exista en tu propio sitio. Mira qué pasa. Cuenta hasta diez. Si sigue cargando, tienes mi hallazgo número 3.
3. Abre tu sitemap y cuenta las URLs. ¿Está tu contenido de verdad ahí? ¿Las fechas son reales?
4. Mira el tamaño de los chunks del build. Cualquier cosa por encima de 300 KB que no sea imprescindible en la primera pintura, es candidata a carga diferida.
5. Recorre cada página preguntándote qué debería mostrar, no si carga. Ahí es donde salen los bugs como el badge.
6. Corre `npm audit` y `npm outdated`. Diez segundos.
7. Busca `console.log` en todo el proyecto. Otros diez segundos.

Los siete pasos caben en una tarde. Yo tardé una en encontrarlos y otra en arreglar lo importante.

Lo que de verdad aprendí

Ninguno de estos problemas era difícil. Ni uno. El arreglo más complejo fueron tres líneas; el más impactante fue convertir un PNG a WebP, algo que se hace en un comando.

No estaban ahí porque fueran difíciles. Estaban ahí porque nunca me senté a mirar. Construir es más divertido que revisar, así que uno sigue construyendo encima, y las cosas rotas se quedan abajo, sosteniendo el edificio con un bug de meses.

Si tienes un portfolio, un blog o un proyecto paralelo que llevas tiempo sin revisar de verdad: agenda dos horas esta semana. No para añadir nada. Solo para mirar.

Vas a encontrar tu propio PNG de 993 KB. Te lo prometo.

Probé 3 prompts en Nano Banana 2 y los resultados me sorprendieron

Llevaba un par de semanas viendo screenshots de gente sacando imágenes increíbles con Nano Banana 2 (el modelo de imagen de Gemini), pero la mayoría compartía el resultado sin el prompt. Decidí hacer mi propio experimento: tres prompts diseñados para sacar provecho de tres "superpowers" distintos del modelo, ejecutarlos en serio, y documentar todo —prompt, resultado, lo que falló, lo que aprendí—.

Este post es ese registro completo. Si quieres replicar los resultados, los prompts están aquí en su forma final, listos para pegar.

Por qué Nano Banana 2 ≠ otro generador de imágenes

Antes de los prompts, vale la pena entender qué hace distinto a este modelo. Nano Banana 2 no es "el Midjourney de Google". Es un modelo construido sobre el reasoning de Gemini, lo que significa tres diferencias prácticas que cambian cómo lo prompteas:

1. Procesa prompts conversacionales largos mejor que strings de keywords. Donde Midjourney premia listas tipo cinematic, 8k, ultra-realistic, masterpiece, Nano Banana premia descripciones tipo "fotografía editorial estilo Kinfolk, luz golden hour, taza humeando".
2. Mantiene identidad facial al editar fotos. Esto es lo que más me sorprendió. Si le pasas una foto tuya y le pides que cambie el contexto, mantiene tu cara intacta —no te "mejora", no te cambia los rasgos, no te hace genérico—.
3. Itera sobre resultados anteriores con instrucciones, no con prompts nuevos. Después del primer output puedes decirle "más texturizado, menos AI-perfect" y modifica el output sin empezar de cero.

Cada uno de los 3 prompts que siguen está diseñado para demostrar uno de estos comportamientos.

El experimento

Mi setup:

• Modelo: Gemini 3 Pro con Nano Banana 2 activado
• Output: vertical 4:5 (1080x1350) — formato Instagram-friendly
• Brand visual: Editorial Zine, paleta cream + ink + terracotta
• Tiempo total: ~25 minutos para los 3 prompts (incluyendo iteraciones)

Nada de hacks, nada de plugins, nada de wrappers. Solo el modelo y los prompts.

Prompt 1 — Foto cinematográfica de workspace

Objetivo: generar una imagen que se vea como foto de stock premium, no como AI render genérico.

Superpower que demuestra: procesar prompts conversacionales largos.

El prompt completo

Photograph of a minimalist developer workspace shot on
35mm film. A vintage wooden desk by a window with golden
hour light streaming in. On the desk: an open MacBook Pro
displaying code in a dark editor (Catppuccin-style colors,
purple and cyan accents), a ceramic mug with steam, a small
notebook with a fountain pen, and a single dried flower in
a clear glass.

Background: warm cream-colored wall with subtle grain
texture, a small framed art print partially visible.

Mood: contemplative, editorial, "build in public" energy.
Slight film grain, shallow depth of field, warm color
grading with terracotta and ember accents. Vertical
composition, 4:5 ratio.

Style: editorial photography, Kinfolk magazine aesthetic,
not generic stock. Imperfect by design.

El resultado

Lo que funcionó

• La luz golden hour real entrando por la ventana (no esa "luz dorada AI" plástica)
• El vapor de la taza se ve natural
• La pantalla del MacBook muestra código con sintaxis real
• La madera del escritorio tiene grano visible y patina
• El frasco de cristal con la flor seca refleja la luz

Lo que aprendí

Mientras más específico el prompt, menos genérico el output. "MacBook Pro displaying code in a dark editor" daría una pantalla negra random. "Catppuccin-style colors, purple and cyan accents" forzó al modelo a renderizar una paleta específica que se ve como código real.

Regla: no describas la escena, descríbele al modelo qué cámara, qué luz, qué referencia visual quieres. Es la diferencia entre dirigir un set y pedir una imagen.

Prompt 2 — Poster editorial con typography

Objetivo: diseñar un poster con texto, layout y elementos gráficos —sin abrir Figma—.

Superpower que demuestra: iteración sobre resultados anteriores.

El primer intento (el que no funcionó)

Mi primer prompt salió muy plain —tipografía limpia, sin textura, sin profundidad—. Looked like Canva. En lugar de descartarlo y empezar de cero, le pedí al modelo que iterara sobre el resultado anterior agregando capas. Eso fue el cambio de juego.

El prompt de iteración

Iterate on this editorial poster. Keep the central
composition (crossed-out "M" in serif italic, "HTML" in
monospace below it, terracotta strikethrough), but make
it MUCH richer and more textured:

LAYERING & DEPTH:
- Add visible risograph misregistration — slight color
  offset where the terracotta ink doesn't perfectly align
  with the black ink. Like a real two-color print where
  registration is intentionally imperfect.
- Add visible paper texture: warm cream paper with
  noticeable fiber grain, small specks, slight age marks.
- The terracotta strikethrough should look like a real
  brush stroke with visible texture, slight ink bleeding
  at the edges, and a small dry-brush effect at the tail.
- Subtle ink bleed on the serif "M" — like the ink soaked
  into the paper slightly.

ADDITIONAL ELEMENTS (break the symmetry):
- Top-left corner: a faded, half-cropped photo of an old
  computer terminal or vintage Macintosh, printed in
  monochrome black on the cream paper. Small, like a
  postage stamp size. Slightly rotated.
- Right side, mid-height: a vertical strip of monospace
  code text running sideways, very small and faded,
  containing snippets like "<div>", "</section>",
  "<article>". Rotated 90 degrees.
- Bottom-left: a hand-drawn arrow pointing toward "HTML"
  with a small handwritten annotation in terracotta ink
  that reads "← future" in messy sans-serif.
- Replace one of the brackets "[ ]" with a small circled
  number "1." in terracotta, like an editor's mark.
- Add 2-3 small irregular ink dots/splatters scattered
  across the composition, very subtle.

OVERALL:
- More layers, more density, more "human zine" feeling.
- Less centered/symmetric, more intentional asymmetry.
- Should look like a real printed zine page, not a digital
  poster.
- Vertical 4:5 composition.
- Keep typography sharp and legible.

El resultado

Lo que funcionó

• El misregistration de print real se ve perfectamente —esa silueta naranja detrás del "M" y "HTML"—
• El vintage Macintosh rotado arriba-izquierda
• La brush stroke del strikethrough tiene textura real, no es una línea perfecta
• El code strip vertical con <div> </section> <article> rotado 90°
• El "← future" handwritten en terracotta
• El "1." circled como editor's mark
• Los ink splatters scattered
• El paper grain visible

Lo que aprendí

No descartes outputs imperfectos. Itera sobre ellos. El segundo prompt no inventa la composición desde cero —respeta lo que ya estaba bien y agrega solo lo que faltaba—. Es como dirigir a un fotógrafo: "esa toma estuvo bien, ahora hazla con menos luz".

Esto solo funciona porque Nano Banana 2 puede ver el output anterior y editarlo, no regenerarlo. Es una capacidad única que la mayoría de generadores de imagen no tienen tan bien resuelta.

Prompt 3 — Selfie convertida en retrato editorial

Objetivo: tomar una selfie y convertirla en una imagen que se vea como cover de revista —sin alterar la cara—.

Superpower que demuestra: mantener identidad facial al editar fotos.

El prompt completo

Editorial magazine portrait, "Developer Issue" October
2026 cover style. Transform this photo into a cinematic
editorial portrait.

SETTING:
Place the person in a sun-drenched home developer studio.
Key elements visible in the scene:
- Warm wooden floors with visible grain
- An olive-green accent wall behind them
- A floating wooden shelf with dried flowers in a glass
  vase and one small framed art print
- A vintage wooden desk with an open MacBook (slightly
  out of focus in foreground or mid-ground)
- A ceramic mug
- Natural late-afternoon golden hour light streaming
  through an unseen window from camera-left

COMPOSITION:
- The person should be the clear focal point, slightly
  off-center (not centered).
- Medium portrait crop — head and upper torso visible.
- Shallow depth of field, background slightly soft but
  recognizable.
- Vertical 4:5 ratio.

COLOR GRADE:
- Warm highlights with golden hour tone on skin and wood
- Slightly desaturated shadows (not blue, just muted)
- Terracotta and cream palette overall
- Subtle film grain throughout
- Slight teal-and-orange balance, very gentle

MOOD:
- Contemplative, "build in public" energy
- Editorial magazine, NOT corporate headshot
- Kinfolk magazine meets Wired profile aesthetic
- Imperfect by design, photographic, NOT AI-perfect

CRITICAL CONSTRAINTS:
- Keep the person's face, identity, skin tone, hair,
  beard, glasses (if any), and clothing EXACTLY as they
  are in the source photo.
- Do NOT alter their facial features.
- Do NOT make them more attractive or "AI-enhanced".
- Do NOT change their ethnicity or skin tone.
- Do NOT change their clothing.
- Only modify the background, lighting, and color grade.

This should look like a real photographer took it in
the person's actual studio, not a CGI render.

El resultado

Lo que funcionó

• La pared olive-green exacta, sin glitches
• El floating shelf de madera con lavender y eucalipto
• El vintage wooden desk con drawer y MacBook con código visible
• El golden hour real en la cara y el hombro (no luz dorada plástica)
• Mi cara intacta: lentes, sonrisa, rasgos, tono de piel, todo igual
• Tattoo del brazo preservado
• Apple Watch preservado
• Color grade warm + film grain editorial

Lo que aprendí

El bloque "CRITICAL CONSTRAINTS" al final del prompt es lo que evita que el modelo "mejore" tu cara —cosa que casi todos los generadores de imagen hacen por defecto—. Sin esas reglas explícitas, el modelo te haría más simétrico, te quitaría imperfecciones, te haría más AI-perfect.

Regla: si estás editando fotos de personas reales, escribe las restricciones como si estuvieras hablando con un photo editor obsesivo. Cualquier cosa que no prohibas explícitamente, el modelo lo puede cambiar.

Las 3 lecciones que me llevo

Después de los 3 prompts, estos son los principios que aplicarían a cualquier prompt nuevo:

1. Conversación, no keywords

Gemini responde mejor a prompts largos y descriptivos que a strings tipo Midjourney. Olvídate del 8k, ultra-realistic, trending on artstation. Describe la escena como se la describirías a un fotógrafo en un set.

Mal: developer workspace, cinematic, professional, 8k

Bien: Photograph of a minimalist developer workspace shot on 35mm film, vintage wooden desk by a window with golden hour light

2. Especifica el mood, no el estilo

"Editorial zine, imperfecto, golden hour" produce mejores resultados que "professional photo, ultra-realistic, masterpiece". El primero le dice al modelo qué sentimiento debe transmitir; el segundo le dice qué adjetivos usar.

Mal: beautiful, stunning, masterpiece, award-winning

Bien: contemplative, build in public energy, Kinfolk magazine aesthetic

3. Itera con instrucciones, no con prompts nuevos

Si el primer output no te convence, no empieces de cero. Pídele al modelo que modifique lo que ya tiene: "más texturizado, menos AI-perfect, agrega ink bleed, más asimetría". Vas a llegar mucho más rápido al resultado que quieres.

Lo que no funcionó (gotchas)

No todo fue perfecto:

• El primer intento del Prompt 2 salió completamente plain. Tuve que iterar 2 veces para llegar a algo decente.
• En el Prompt 1, el código en la pantalla del MacBook tiene typography "AI" (no es código real de un lenguaje específico). Si esto importa para tu use case, vas a tener que componer la imagen final con un mockup separado.
• Nano Banana 2 sigue luchando con texto largo dentro de las imágenes. Cualquier oración de más de 5 palabras dentro del frame puede salir warpeada o con typos. Si necesitas texto preciso, agrégalo después en Figma o Photoshop.

Cuándo (no) usar Nano Banana 2

Después de este experimento, mi take honesto:

Sí lo usaría para:

• Hero images de blog posts
• Covers de Instagram donde necesito flexibilidad rápida
• Mockups iniciales de campañas
• Prototipos visuales de productos antes de la sesión fotográfica real
• Editar fotos personales con cambios de contexto (background, lighting)

No lo usaría para:

• Producto final de campañas con presupuesto (sigue siendo AI, va a tener artifacts)
• Cualquier cosa que requiera texto preciso dentro de la imagen
• Imágenes que necesitan ser pixel-perfect a una guía de marca específica
• Reemplazar a un fotógrafo real cuando el tiempo y el budget lo permiten

Cierre

El mejor "prompt engineering" no es saber palabras mágicas. Es saber qué quieres ver, describirlo con la precisión de un director, y darle al modelo las restricciones para que no te sorprenda donde no quieres.

Si tienes 25 minutos esta semana, replica el experimento con tus propios prompts. Los 3 que están arriba son un buen punto de partida —cópialos, modifícalos, comparte qué te salió—.

¿Probaste alguno de los 3 prompts? Comparte el resultado en mis comentarios de Instagram @codewithgabo o en X @Gabbs279.

Migrating an Express Backend to Vercel Functions Without Downtime

Last week 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:

1. 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.
2. 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 (GitHub Pages)
        │ HTTPS
        ▼
  Railway: long-running Node + Express
        ├─ /api/analytics
        ├─ middleware: cors, helmet
        └─ env: ADMIN_TOKEN, GA4 credentials

AFTER:
  Frontend (GitHub Pages)
        │ 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.

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 the 10-second per-invocation timeout on the hobby tier (or pay for longer on a higher tier).

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.

Chatbots look intimidating from the outside and turn out to be surprisingly approachable once you actually start one. In this post I want to build a small chatbot in Python using NLTK, the Natural Language Toolkit. We'll start with the simplest version that works, then look honestly at where it breaks and fix it step by step.

You don't need any machine learning background for this. If you can write a Python function and a while loop, you can follow along.

Setting up NLTK

NLTK is a library for working with human language in Python. Install it with pip:

pip install nltk

The library itself is small, but most of what makes it useful lives in separate data packages: tokenizer models, word lists, a dictionary of word forms. You download those once from Python:

import nltk

nltk.download('popular')

A word of warning: popular is a bundle of the most commonly used datasets and it is a few hundred megabytes. It only needs to run once per machine. After that the data sits in your home directory and you can delete the nltk.download line from your script. If NLTK later complains about a missing resource, the error message names the exact package it wants and you download just that one. On my machine the tokenizer still asked for punkt_tab after installing popular, so I ran nltk.download('punkt_tab') once and moved on.

Splitting a sentence into tokens

The first thing NLTK gives you is tokenisation: turning a string into a list of words and punctuation marks.

from nltk.tokenize import word_tokenize

text = "Hello, welcome to Code With Gabo!"
print(word_tokenize(text))

Which prints:

['Hello', ',', 'welcome', 'to', 'Code', 'With', 'Gabo', '!']

Notice that the comma and the exclamation mark came out as their own items. That's the point. text.split() would have given you 'Gabo!' as a single chunk, and 'Gabo!' is not a word you can look up in anything. Tokenisation is what lets you compare against real words instead of against whatever the user happened to type around them.

That matters more than it looks right now, so hold on to it.

The simplest chatbot that works

Here's the naive version. A dictionary of exact phrases, and a lookup with a fallback:

responses = {
    "hi": "Hello! I am GaboBot.",
    "what is your name": "My name is GaboBot.",
    "bye": "See you around!",
}

def chatbot_response(user_input):
    return responses.get(user_input, "I'm not sure how to respond to that.")

And a loop to talk to it. This uses the chatbot_response defined above, so keep both in the same file:

print("Chatbot: Hi, I am GaboBot. Type 'quit' to exit.")

while True:
    user_input = input("You: ")
    if user_input.lower() == "quit":
        print("Chatbot: Bye!")
        break
    print("Chatbot:", chatbot_response(user_input))

Run it and type hi. It works. Now type hi there, or Hi!, or hello. All three fall through to "I'm not sure how to respond to that."

That's the real lesson of the naive version. A dictionary lookup asks "is this string exactly equal to a key I know", and humans never type exactly the key you know. This is where tokenisation stops being a demo and starts being useful.

Matching on tokens instead of whole strings

Instead of comparing the entire sentence, break it into tokens and check whether any of them is a keyword we recognise:

from nltk.tokenize import word_tokenize

KEYWORD_RESPONSES = {
    "hi": "Hello! I am GaboBot.",
    "hello": "Hello! I am GaboBot.",
    "hey": "Hello! I am GaboBot.",
    "name": "My name is GaboBot.",
    "help": "I can greet you and tell you my name. That's about it so far.",
    "bye": "See you around!",
}

DEFAULT_RESPONSE = "I'm not sure how to respond to that."

def chatbot_response(user_input):
    tokens = [token.lower() for token in word_tokenize(user_input)]
    for token in tokens:
        if token in KEYWORD_RESPONSES:
            return KEYWORD_RESPONSES[token]
    return DEFAULT_RESPONSE

Drop this in place of the old chatbot_response and keep the same loop. Now hi there and HI! both get the greeting: Hi! tokenises to ['Hi', '!'], lowercasing gives ['hi', '!'], and hi is in the dictionary.

It also shows you the next flaw, which is worth seeing rather than hiding. Type Hey, what is your name? and you get the greeting, not the name — the loop returns on the first token that matches, and hey comes before name. Whichever keyword appears earliest in the sentence wins, which is not a rule you ever meant to write. Keeping the first match is fine for a handful of rules; past that you want to score every candidate and pick the best one, which is exactly the road to intent classification further down.

The bot went from matching a handful of exact sentences to matching an unlimited number of sentences that happen to contain a keyword. Same amount of code, much better behaviour.

Refining the tokens: stopwords and lemmatisation

Two more NLTK tools clean up the token list before you search it.

Stopwords are the extremely common words that carry almost no meaning on their own: the, is, are, you, with. Lemmatisation reduces a word to its dictionary form, so helping becomes help and projects becomes project.

from nltk.corpus import stopwords
from nltk.stem import WordNetLemmatizer
from nltk.tokenize import word_tokenize

STOPWORDS = set(stopwords.words("english"))
lemmatizer = WordNetLemmatizer()

def clean_tokens(text):
    tokens = [token.lower() for token in word_tokenize(text) if token.isalpha()]
    tokens = [token for token in tokens if token not in STOPWORDS]
    return [lemmatizer.lemmatize(token, pos="v") for token in tokens]

print(clean_tokens("Are you helping me with these projects?"))

That prints:

['help', 'project']

Then swap the first line of chatbot_response to use it:

def chatbot_response(user_input):
    for token in clean_tokens(user_input):
        if token in KEYWORD_RESPONSES:
            return KEYWORD_RESPONSES[token]
    return DEFAULT_RESPONSE

What this buys you is fewer keys to maintain. You no longer need separate entries for help, helping and helped — they all collapse to help. What it costs you is precision, and you should know about both costs:

• Your dictionary keys now have to be in lemmatised form. thanks lemmatises to thank, so the key "thanks" will never match again.
• Stopword removal deletes not. After cleaning, "I like this" and "I do not like this" look identical to your bot.
• Passing pos="v" lemmatises every token as if it were a verb, which is a blunt shortcut. The proper way is to tag each word with nltk.pos_tag and pass the matching part of speech. For a keyword bot, the shortcut is usually fine.

What this approach can't do

I want to be straight about the ceiling here, because it arrives quickly.

• It has no memory. Every message is handled on its own. Ask "what is your name", then "and how old are you" — the bot has no idea what you refers to, because nothing carries over between turns.
• It doesn't understand intent, only keywords. "I need help" and "I don't need help" both contain help and both get the same answer.
• First match wins. In a sentence with two keywords, the answer depends on word order, which is not a rule you ever meant to write.
• It doesn't scale. Around a few dozen rules the dictionary starts contradicting itself and you spend more time debugging keyword collisions than adding features.

When you outgrow it, there are two usual next steps. One is intent classification: you collect a handful of example phrasings for each intent and train a classifier to pick the intent, using the same cleaned tokens as input features. The other is calling an LLM API and letting the model handle the language, keeping your code for the actions the bot can actually take. Both are more machinery than a dictionary, and if your bot really only needs to answer ten fixed questions, the dictionary is still the right call — it's predictable, it's free, and it never invents an answer.

Where to go from here

The most fun next experiment is sentiment analysis: scoring whether a message reads as positive or negative, and having GaboBot respond differently to each. NLTK ships a rule-based scorer that needs one extra download:

import nltk
nltk.download('vader_lexicon')

from nltk.sentiment import SentimentIntensityAnalyzer

sia = SentimentIntensityAnalyzer()
print(sia.polarity_scores("I love this bot"))

Wire that score into chatbot_response and you have a bot that reacts to how someone said something, not just what they said. That's a small change on top of everything above, and it's a good way to get a feel for how far simple tools can take you before you need the heavy ones.

I reach for Python whenever I need data off a page that has no API. This post walks through the pieces I actually use — Requests, Beautiful Soup, robots.txt — and the habits that keep a scraper from breaking or getting you blocked.

What is web scraping?

Web scraping involves programmatically gathering data from websites. This can be done for various purposes, such as analyzing content, aggregating data, or automating tasks that would otherwise require manual input.

Why Python for web scraping?

The libraries are the reason. Requests handles HTTP, Beautiful Soup parses broken HTML without complaining, and Scrapy takes over when a job outgrows a single script.

Step 1: Setting up your environment

Before we start, make sure you have Python installed on your system. You'll also need two key libraries: Beautiful Soup and Requests. Install them with pip:

python3 -m pip install beautifulsoup4 requests

Step 2: Making your first request

Let's start by fetching the content of a webpage. We'll use the Requests library for this:

import requests

url = "https://quotes.toscrape.com/page/1/"
response = requests.get(url)
html_content = response.text
print(html_content[:500])

That works, but it has two problems that will bite you on a real site.

Send a User-Agent header

By default, Requests identifies itself with a User-Agent like python-requests/2.x. That string is a giveaway that you are not a browser, and plenty of sites either block it outright or serve a stripped-down page. Set a header that says who you are:

import requests

HEADERS = {"User-Agent": "GaboScraper/1.0 (+https://codewithgabo.com)"}

url = "https://quotes.toscrape.com/page/1/"
response = requests.get(url, headers=HEADERS, timeout=10)
html_content = response.text

I prefer an honest custom string over pretending to be Chrome. If the site owner looks at their logs, they can see what hit them and where to complain. The timeout matters too: without it, a slow server can hang your script forever.

Check the response before you parse it

This is the mistake I see most often from beginners. A 404 or a 403 still returns HTML, so Beautiful Soup happily parses the error page, find_all returns an empty list, and you spend an hour debugging a selector that was fine all along. Check first:

response = requests.get(url, headers=HEADERS, timeout=10)
print(response.status_code)   # 200 means OK
response.raise_for_status()   # raises an exception on 4xx / 5xx
html_content = response.text

raise_for_status() turns a silent wrong answer into a loud error, which is exactly what you want while you are still building the thing.

Step 3: Parsing HTML with Beautiful Soup

Once you have the HTML content, use Beautiful Soup to parse and navigate the data. This snippet assumes html_content from the previous step:

from bs4 import BeautifulSoup

soup = BeautifulSoup(html_content, "html.parser")
print(soup.prettify())

prettify() prints the document with indentation. It is noisy, but early on it is the fastest way to see what you actually received rather than what you assumed you received.

Step 4: Extracting data

Now let's extract specific data. Suppose we want every top-level headline on a page:

headlines = soup.find_all("h1")
for headline in headlines:
    print(headline.text.strip())

.strip() is not optional in practice. HTML is full of stray newlines and indentation, and without it your data ends up padded with whitespace.

Step 5: Handling more complex queries

For more complex data extraction, you can use CSS selectors. select returns every match, select_one returns the first or None:

quotes = soup.select("div.quote")
for quote in quotes:
    text = quote.select_one("span.text").text
    print(text)

Careful: select_one returns None when nothing matches, and None.text raises AttributeError. On a page where one item is missing a heading, guard it:

for quote in quotes:
    author = quote.select_one("small.author")
    print(author.text.strip() if author else "(unknown)")

Step 6: Be a polite scraper

While web scraping is powerful, it's important to respect website terms and avoid overloading servers. Two concrete habits cover most of it.

Read robots.txt in code, not just with your eyes. Python ships with a parser, so your script can ask the question itself:

from urllib.parse import urljoin
from urllib.robotparser import RobotFileParser

USER_AGENT = "GaboScraper/1.0 (+https://codewithgabo.com)"
BASE = "https://quotes.toscrape.com"

rp = RobotFileParser()
rp.set_url(urljoin(BASE, "/robots.txt"))
try:
    rp.read()
except Exception:
    print("could not read robots.txt - stopping")
    raise SystemExit(1)

print(rp.can_fetch(USER_AGENT, f"{BASE}/page/1/"))
print(rp.crawl_delay(USER_AGENT))  # None if the site doesn't specify one

Read robots.txt once at startup and reuse the parser. robots.txt is a request, not a lock, but ignoring it is how you get your IP banned.

Slow down. One request per second is plenty for a hobby project and keeps you off anyone's radar:

import time

time.sleep(1)  # between requests, every time

Step 7: Pagination

Most listings span several pages. The reliable pattern is to follow the site's own "next" link and stop when it disappears, rather than guessing how many pages exist. Add a hard page cap so a bug can't turn into an accidental crawl of the whole internet.

Putting it all together

Here is the complete script. It reads robots.txt, sets a User-Agent, checks the status, walks the pages, and sleeps between requests. It runs against quotes.toscrape.com, a site built specifically for scraping practice:

import time
import requests
from bs4 import BeautifulSoup
from urllib.parse import urljoin
from urllib.robotparser import RobotFileParser

BASE = "https://quotes.toscrape.com"
USER_AGENT = "GaboScraper/1.0 (+https://codewithgabo.com)"
HEADERS = {"User-Agent": USER_AGENT}
DELAY = 1.0
MAX_PAGES = 5


def fetch(url):
    response = requests.get(url, headers=HEADERS, timeout=10)
    response.raise_for_status()
    return response.text


def parse_page(html):
    soup = BeautifulSoup(html, "html.parser")
    quotes = []
    for quote in soup.select("div.quote"):
        text = quote.select_one("span.text")
        author = quote.select_one("small.author")
        quotes.append({
            "text": text.text.strip() if text else "",
            "author": author.text.strip() if author else "",
            "tags": [tag.text.strip() for tag in quote.select("a.tag")],
        })
    next_link = soup.select_one("li.next a")
    next_url = urljoin(BASE, next_link["href"]) if next_link else None
    return quotes, next_url


def main():
    rp = RobotFileParser()
    rp.set_url(urljoin(BASE, "/robots.txt"))
    rp.read()

    url = f"{BASE}/page/1/"
    collected = []
    pages = 0

    while url and pages < MAX_PAGES:
        if not rp.can_fetch(USER_AGENT, url):
            print(f"robots.txt disallows {url} - stopping")
            break
        print(f"Fetching {url}")
        quotes, url = parse_page(fetch(url))
        collected.extend(quotes)
        pages += 1
        time.sleep(DELAY)

    for quote in collected:
        print(f"{quote['author']}: {quote['text']}")
    print(f"\n{len(collected)} quotes from {pages} page(s)")


if __name__ == "__main__":
    main()

Save it as scrape.py, run python3 scrape.py, and you should see quotes printed one page at a time.

When not to scrape

This is the part I wish someone had told me first.

• If the site has an API, use the API. It returns structured JSON, it is versioned, and it won't break because a designer renamed a CSS class. Check for /api, a developer subdomain, or an RSS feed before you write a single selector.
• Scrapers are fragile by design. You are depending on markup that nobody promised to keep stable. Expect your script to break, and write it so a failure is loud rather than silently producing empty rows.
• Some sites forbid it in their terms of service. Read them. "Technically possible" and "allowed" are different questions.
• Personal data brings legal obligations no matter how you obtained it. Rules vary by jurisdiction and by site, and I'm a developer, not a lawyer. If you are collecting anything that identifies a person, get real advice before you collect it.

For bigger jobs, look at Scrapy for large crawls with retries and throttling built in, and Playwright for pages whose content is rendered by JavaScript after load.

Start with simple targets, keep the volume low, and let the site's own signals tell you what is fair game. Practice is key to getting comfortable with scraping, and the good habits are much easier to build on day one than to retrofit later.

State Management in React – Props vs the Context API

Figuring out state management in React applications can feel like finding your way through a labyrinth. You'll constantly be searching for the most efficient, scalable, and maintainable solution. The journey often leads to two primary paths: Using Props or the Context API. As you embark on this quest for state management mastery, it's crucial to understand the intricacies, trade-offs, and use cases of each approach.

In this tutorial, we'll delve into React state management, dissecting the advantages and disadvantages of using props and the Context API and providing valuable insights to help you make informed decisions for your application. You'll be able to unravel the mysteries of state management in React and discover which path will lead you to success.

Prerequisites

Before proceeding, you should have the following:

• React Fundamentals such as components, JSX syntax, props, and state.
• Familiarity with different state management techniques in React, such as using props and the Context API.

What is State Management in React?

State management refers to the methods and techniques used to handle, organize, and share data within a React application. It involves the systematic management and manipulation of data, ensuring seamless integration and synchronization across various components.

Benefits of React State Management

State management plays a pivotal role in developing dynamic and interactive applications that need to handle evolving data. This data can come from user interactions or other triggering events. By implementing robust state management techniques, React applications can maintain data integrity, enhance performance, and provide a smooth user experience.

State Management Using Props

Using props for state management is a technique where the state is managed in a parent component and passed down to child components via props. This approach is suitable for small-scale applications with simple state requirements and a shallow component hierarchy. Using props is considered a local state management method, as the state is maintained and shared within a limited scope of closely related components.

To illustrate how this works, let's create a ParentComponent that maintains the state and passes it down to a ChildComponent:

While props are straightforward and intuitive for small applications, they can become cumbersome and inefficient as your app grows, leading to "prop drilling" where props need to be passed through multiple component levels.

Introducing the Context API

The Context API is a feature provided by React that allows you to share state and other data without having to pass props through intermediate components. Using the Context API, you can avoid the problems of "prop drilling".

Here's an example of the previous ParentComponent and ChildComponent using the Context API instead:

Choosing between Props and the Context API

When choosing between using props or the Context API for state management, consider the scale and complexity of your project.

For small-scale projects with a simple component hierarchy, using props may be more suitable. However, as the scale of your project grows and the component tree becomes deeper, the Context API can provide a more scalable and maintainable solution. But remember to use Context sparingly, as overusing it can lead to unnecessary re-renders and lower reusability of components.

Conclusion

State management is a core concept in React and essential for building dynamic and interactive applications. Both props and the Context API are powerful tools for managing state in React, each with their own advantages and suitable scenarios. Whether you choose to use props or the Context API, understanding their implications will help you make the best choice for your application.

The Fluent UI Revolution: A Comprehensive Guide to the Future of Interface Design

Introduction

As technology continues to permeate every aspect of our lives, the importance of creating user-friendly and accessible interfaces cannot be overstated. Fluent UI, developed by Microsoft, is a game-changing design system that has emerged as a powerful tool for designers and developers alike. In this comprehensive guide, we'll delve into the core principles of Fluent UI, its benefits, and how it's shaping the future of interface design. We'll also explore how to implement Fluent UI in your projects and examine some real-world applications of this innovative design system.

Part 1: The Core Principles of Fluent UI

1.1 Clarity Fluent UI aims to provide clear and straightforward user experiences by minimizing visual clutter and unnecessary elements. This helps reduce the learning curve for new users, ensuring that interfaces remain intuitive and easy to navigate. Clarity is achieved by using clear typography, meaningful icons, and a consistent visual hierarchy.

1.2 Efficiency The design system offers a range of versatile components and tools that enable designers and developers to create efficient and streamlined interfaces. By focusing on common design patterns and reusable components, Fluent UI ensures minimal effort from users while maximizing productivity.

1.3 Consistency One of the main goals of Fluent UI is to maintain consistency across platforms and devices. By using a consistent design language, users can quickly adapt to different environments without confusion. This consistency is achieved through a shared set of design principles, components, and styles that can be applied to various platforms and products.

1.4 Flexibility Fluent UI acknowledges the diverse needs of users and offers adaptable components that can be customized to cater to different preferences and use cases. By providing a flexible foundation, Fluent UI enables designers and developers to build interfaces that can accommodate a wide range of user requirements and scenarios.

Part 2: The Benefits of Fluent UI

2.1 Enhanced User Experience Focusing on clarity, efficiency, and consistency, Fluent UI helps deliver a seamless and enjoyable user experience. By reducing the likelihood of user frustration and disengagement, Fluent UI enables products to better retain and satisfy users.

2.2 Faster Development Fluent UI's comprehensive set of tools and components allows developers to create interfaces more quickly and efficiently. This results in faster project completion, reduced development costs, and the ability to rapidly prototype and iterate on designs.

2.3 Improved Accessibility Fluent UI is designed with accessibility in mind, ensuring that interfaces are usable and comprehensible for users of all abilities. This focus on accessibility not only complies with legal requirements but also creates more inclusive products that cater to a wider audience.

2.4 Cross-Platform Compatibility Fluent UI's consistent design language enables seamless adaptation across various platforms, devices, and screen sizes. This provides a cohesive experience for users, regardless of their preferred device or platform.

Part 3: Implementing Fluent UI in Your Projects

3.1 Getting Started with Fluent UI To begin using Fluent UI, you'll first need to install the necessary packages and dependencies for your chosen platform (e.g., React, Web, or Xamarin). Microsoft provides extensive documentation and resources to help you get started, including sample code, tutorials, and a library of pre-built components.

3.2 Customizing Fluent UI Components One of the strengths of Fluent UI is its flexibility, allowing you to customize components to fit your specific needs. You can modify the appearance, behavior, and layout of components by adjusting their properties or applying custom styles.

3.3 Building Custom Components While Fluent UI offers an extensive library of pre-built components, you may encounter situations where you need to create a custom component from scratch. Fluent UI provides guidance and best practices for building custom components that adhere to the design system's principles and are compatible with existing Fluent UI components.

3.4 Design Tokens and Theming Fluent UI utilizes design tokens to maintain consistency across different platforms and devices. Design tokens are a set of predefined variables that store design-related values, such as colors, typography, and spacing. By leveraging design tokens, you can easily create and apply themes to your application, ensuring a consistent look and feel throughout.

3.5 Responsive Design with Fluent UI Creating responsive interfaces is essential for catering to various screen sizes and devices. Fluent UI provides tools and guidance for implementing responsive design, such as using CSS Grid, Flexbox, and media queries. This ensures that your interface can adapt to different screen sizes while maintaining a consistent user experience.

Part 4: Real-World Applications of Fluent UI

4.1 Microsoft Office Suite One of the most prominent implementations of Fluent UI can be found in the Microsoft Office Suite, which includes applications like Word, Excel, PowerPoint, and Outlook. Fluent UI has helped create a consistent and cohesive experience across these applications, making it easier for users to navigate and use the software.

4.2 Microsoft Teams, a popular collaboration and communication platform, also utilizes Fluent UI to deliver a consistent and intuitive user experience. The platform's interface is designed to facilitate seamless communication, file sharing, and project management among team members.

4.3 Third-Party Applications Many third-party developers have adopted Fluent UI to build their applications, taking advantage of the design system's flexibility, consistency, and efficiency. By using Fluent UI, these developers can ensure their applications are accessible, user-friendly, and compatible with Microsoft products and services.

Conclusion

Fluent UI has emerged as a powerful design system that is shaping the future of interface design. Its focus on clarity, efficiency, consistency, and flexibility makes it an ideal choice for creating intuitive, efficient, and enjoyable experiences that cater to diverse user needs. By harnessing the power of Fluent UI, designers, and developers can build user interfaces that not only provide a seamless experience across platforms and devices but also promote inclusivity and accessibility. As the adoption of Fluent UI continues to grow, its influence on the world of interface design is poised to revolutionize the way we interact with technology.

Build a simple but genuinely useful weather app that displays real-time weather data for any city using JavaScript, HTML, CSS, and WeatherAPI. It is a good project to pick up after your first few tutorials, because it makes you deal with three things at once: talking to an API, writing asynchronous code, and handling the moment when the request comes back wrong.

No framework, no build step, no dependencies. Three files and a free API key.

Step 1: Set up the project structure

Create a new folder for the project and add three files:

• index.html
• style.css
• script.js

You can open index.html directly in the browser. That is all the tooling this needs.

Step 2: index.html

The markup is small. What matters is the IDs, because the JavaScript looks each element up by ID: city-input, weather-info, city-name, temperature, and description.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Weather App</title>
    <link rel="stylesheet" href="style.css" />
  </head>
  <body>
    <header>
      <h1>Weather App</h1>
    </header>

    <main>
      <label for="city-input">Type a city and press Enter</label>
      <input
        type="text"
        id="city-input"
        name="city"
        autocomplete="off"
        placeholder="Santo Domingo"
      />

      <section id="weather-info" class="hidden" aria-live="polite">
        <h2 id="city-name"></h2>
        <p id="temperature"></p>
        <p id="description"></p>
      </section>
    </main>

    <script src="script.js"></script>
  </body>
</html>

Two details worth noticing. The <label> is tied to the input with for="city-input", so clicking the text focuses the field and screen readers announce it. And aria-live="polite" on the results container means the new weather is read out when it appears, instead of changing silently.

The <script> tag goes at the end of <body> on purpose. The JavaScript calls getElementById as soon as it runs, so the elements have to exist already.

Step 3: style.css

body {
  font-family: Arial, sans-serif;
  text-align: center;
  background-color: #f0f0f0;
}

header {
  background-color: #3b3b3b;
  padding: 20px;
}

header h1 {
  color: #ffffff;
  margin: 0;
  font-size: 24px;
}

input[type="text"] {
  font-size: 18px;
  padding: 10px;
  width: 80%;
  max-width: 300px;
  margin-top: 40px;
  border-radius: 5px;
  border: 1px solid #ccc;
}

#weather-info {
  margin-top: 40px;
}

.hidden {
  display: none;
}

Add these two rules at the bottom of the same file so the label sits on its own line above the input. They come later in the stylesheet, so the smaller margin-top wins over the earlier one:

label {
  display: block;
  margin-top: 40px;
  color: #3b3b3b;
}

input[type="text"] {
  margin-top: 10px;
}

.hidden is the whole show/hide mechanism. The results block starts hidden and the JavaScript removes the class once there is something to show.

Step 4: Register for WeatherAPI

Go to weatherapi.com and sign up for a free account, then generate an API key from your dashboard. Keep the key somewhere handy, you need it in the next step.

Step 5: script.js

const cityInput = document.getElementById("city-input");
const weatherInfo = document.getElementById("weather-info");
const cityName = document.getElementById("city-name");
const temperature = document.getElementById("temperature");
const description = document.getElementById("description");

cityInput.addEventListener("keyup", (event) => {
  if (event.key === "Enter") {
    fetchWeatherData(cityInput.value);
  }
});

async function fetchWeatherData(city) {
  const API_KEY = "your_weatherapi_key_here";
  try {
    const response = await fetch(
      `https://api.weatherapi.com/v1/current.json?key=${API_KEY}&q=${city}&aqi=no`
    );
    if (!response.ok) {
      throw new Error("Failed to fetch weather data");
    }
    const data = await response.json();
    displayWeatherData(data);
  } catch (error) {
    console.error("Error:", error);
  }
}

function displayWeatherData(data) {
  cityName.textContent = data.location.name;
  temperature.textContent = `${data.current.temp_c}°C`;
  description.textContent = data.current.condition.text;
  weatherInfo.classList.remove("hidden");
}

Replace your_weatherapi_key_here with your actual WeatherAPI key. Save all three files, open index.html, type a city, press Enter.

What the async function is actually doing

This is the real lesson of the project, so it is worth slowing down on the three pieces.

await

fetch does not return the response. It returns a promise, an object that stands in for a result that has not arrived yet. await pauses the function until that promise settles, then hands you the value. The rest of the page keeps running while it waits, which is why nothing freezes.

You need two awaits here because there are two waits: one for the response headers to arrive, and a second one for response.json() to finish reading and parsing the body.

response.ok

fetch only rejects when the request itself fails, for example when the network is down. A 400 or a 401 from the server is still a successful round trip as far as fetch is concerned, so it resolves normally. If you skip the response.ok check, a bad API key or a misspelled city gives you a data object with no location in it, and the error you eventually see is a confusing Cannot read properties of undefined.

response.ok is simply true for any status in the 200 range. Checking it turns a silent wrong answer into a clear one.

try/catch

throw inside an async function jumps straight to catch, and so does any rejected promise you awaited. That means one catch block covers the network failing, the JSON being unparseable, and the error you threw yourself.

Handling a city that doesn't exist

This is the first thing a beginner hits, and right now the app does nothing visible: it logs to the console and the old weather stays on screen. When you send an unknown city, WeatherAPI responds with a non-OK status and a JSON body containing an error object with a message field explaining what went wrong. You can read that and put it in front of the user.

Add a place to show it, right after the </section> in index.html:

<p id="error-message" class="hidden" role="alert"></p>

Then replace fetchWeatherData in script.js with this version, and add the two helpers below it:

const errorMessage = document.getElementById("error-message");

async function fetchWeatherData(city) {
  const API_KEY = "your_weatherapi_key_here";
  if (!city.trim()) return;

  hideError();
  try {
    const response = await fetch(
      `https://api.weatherapi.com/v1/current.json?key=${API_KEY}&q=${encodeURIComponent(
        city
      )}&aqi=no`
    );
    const data = await response.json();

    if (!response.ok) {
      throw new Error(data.error?.message || "Failed to fetch weather data");
    }

    displayWeatherData(data);
  } catch (error) {
    console.error("Error:", error);
    showError(error.message);
  }
}

function showError(message) {
  errorMessage.textContent = message;
  errorMessage.classList.remove("hidden");
  weatherInfo.classList.add("hidden");
}

function hideError() {
  errorMessage.classList.add("hidden");
}

Three changes matter here. The body is parsed before the ok check, so the error message is available to throw. encodeURIComponent means city names with spaces or accents survive the trip. And showError hides the stale weather, so the user is never looking at yesterday's city next to today's error.

A network failure lands in the same catch, but with a browser message like "Failed to fetch". If that bothers you, check error instanceof TypeError and show your own wording.

About that API key

Your key is sitting in script.js, which the browser downloads in full. Anyone who opens DevTools can read it, copy it, and spend your quota. Minifying does not help, and neither does moving it to another file.

For learning, this is fine. Use a free key, and rotate it if you ever paste the file publicly. For anything real, the request belongs behind a small server endpoint of your own: your page calls /api/weather?city=London, the server holds the key, adds it, calls WeatherAPI, and returns the result. The key never reaches the browser. That is one short serverless function, and it is the right moment to learn one.

Make it yours

Show the weather icon. data.current.condition.icon comes back as a URL with no protocol, like //cdn.weatherapi.com/..., so prefix it: iconEl.src = "https:" + data.current.condition.icon;. Give the <img> an alt of data.current.condition.text.

Add a three day forecast. Swap the endpoint to https://api.weatherapi.com/v1/forecast.json?key=${API_KEY}&q=${encodeURIComponent(city)}&days=3&aqi=no&alerts=no. The response still has location and current, plus data.forecast.forecastday, an array you can loop over.

Remember the last city. Call localStorage.setItem("lastCity", data.location.name) inside displayWeatherData, then on load read it back and fetch it if it exists. Two lines, and the app feels like it knows you.

Where this stops

The Enter key is the only way to trigger a search, which means no mouse and no comfortable path on mobile. Add a button that calls the same function before you show this to anyone. There is no loading state either, so on a slow connection the page looks broken for a second.

Beyond that, this is a learning project and it should stay one until the key moves to a server. If you want to build a weather feature people actually use, you will also want caching, since free tiers have request limits and hitting the API on every keystroke will burn through them fast. Get this version working first, then move the key, then worry about the rest.

A Brief Full Stack Engineer Guide

What is a Full Stack Developer?

A full-stack developer is a software engineer who can develop both the front-end and back-end of a web application. This means a full-stack developer has knowledge and experience with multiple programming languages, databases, servers, and frameworks.

Front-end development involves creating the user interface and experience of a web application, while back-end development involves writing code that runs on the server and communicates with databases and other resources.

Full-stack developers need to be proficient in both areas to create a complete, functional web application. They are also responsible for integrating different components of a web application and making sure everything works together smoothly.

Skills Required for Full Stack Development

To become a full-stack developer, you need to have a solid foundation in a variety of technical skills. Here are some of the most important skills you should focus on:

1. HTML, CSS, and JavaScript: These are the fundamental building blocks of front-end development. You need to understand how to use these technologies to create user interfaces and make web applications interactive.
2. Server-side languages: Popular server-side languages include Java, Python, Ruby, and PHP. You need to have a solid understanding of at least one of these languages to develop the back end of a web application.
3. Databases: You need to understand how to store and retrieve data from databases, as well as how to optimize queries and manage data efficiently. Some popular databases include MySQL, MongoDB, and PostgreSQL.
4. Web frameworks: Frameworks like React, Angular, and Vue.js can help you create complex front-end applications quickly and efficiently. You also need to be familiar with server-side frameworks like Node.js, Django, or Flask.
5. DevOps: DevOps refers to the set of practices that combine software development and IT operations to improve the delivery of software. You need to understand how to use tools like Git, Docker, and Kubernetes to deploy and manage web applications.

Steps to Becoming a Full-Stack Developer

Here are some steps you can take to become a full-stack developer:

1. Learn the fundamentals of programming: Start by learning a programming language like Python, Java, or JavaScript. You need to have a strong foundation in programming concepts before you can start developing web applications.
2. Learn front-end technologies: HTML, CSS, and JavaScript are essential front-end technologies. You can start learning these technologies by taking online courses or watching tutorial videos.
3. Learn a server-side language: Once you have a solid understanding of front-end technologies, you can start learning a server-side language like Java, Python, or Ruby.
4. Learn databases: You need to understand how to work with databases to create dynamic web applications. Take online courses or read documentation to learn how to work with databases like MySQL or MongoDB.
5. Learn web frameworks: Web frameworks can help you develop web applications more efficiently. Start by learning front-end frameworks like React or Angular, then move on to server-side frameworks like Node.js, Django, or Flask.
6. Learn DevOps: DevOps skills are essential for deploying and managing web applications. Start by learning how to use version control systems like Git, and then move on to containerization technologies like Docker.
7. Practice building projects: Building projects is the best way to solidify your skills and gain practical experience. Start by building simple applications and gradually move on to more complex projects.
8. Get involved in the developer community: Join developer communities online or in person to network and learn from other developers. Attend meetups, hackathons, and conferences to stay up-to-date with the latest technologies and trends.

Conclusion

Becoming a full-stack developer requires a lot of hard work and dedication, but it can be a rewarding career path for those who enjoy working with both front-end and back-end technologies. To become a successful full-stack developer, you need to have a solid foundation in programming fundamentals, front-end technologies, server-side languages, databases, web frameworks, and DevOps.

Remember to focus on building practical experience by working on projects and collaborating with other developers. By continually learning and growing your skills, you can become a valuable asset to any team and develop innovative web applications that meet the needs of users.

In 2023, full-stack development is a fast-growing and constantly evolving field, with new tools and technologies always emerging. By staying up-to-date with the latest trends and best practices, you can remain competitive and continue to grow your skills and career as a full-stack developer.

Thank you for reading, and remember "Success is not linear."

HTTP errors are response status codes that indicate that something has gone wrong with a website or web application. These errors can be caused by a variety of factors, such as invalid input, server issues, or user authentication problems. In this blog post, we'll cover some of the most common HTTP errors and how to handle them.

404 (Not Found) Error

The 404 error occurs when a user tries to access a web page that doesn't exist on the server. This can happen for a variety of reasons, such as a mistyped URL or a broken link.

To handle a 404 error, you should provide a custom error page that explains to the user what has happened and provides suggestions for what they can do next. The error page should have a clear message and a search bar to help users find what they're looking for.

You can also customize the error page with your own branding and design, but make sure that it's still easy to use and navigate. Additionally, you should include a link to your homepage or other relevant pages to help users get back on track.

403 (Forbidden) Error

The 403 error occurs when a user tries to access a resource that they don't have permission to access. This can happen when a user tries to access a page or file that is restricted to certain users or groups.

To handle a 403 error, you should display a message to the user explaining that they don't have permission to access the resource. Additionally, you can provide a link to the login page or a button to retry the request once the user has been granted the necessary permissions.

401 (Unauthorized) Error

The 401 error occurs when a user tries to access a protected resource without proper authentication. This can happen when a user tries to access a page that requires a login, but they haven't logged in yet or their session has expired.

To handle a 401 error, you should redirect the user to the login page and display a message explaining that they need to log in to access the resource. If the user is already logged in, you can display a message telling them that they don't have permission to access the resource.

Additionally, you can provide a link to the login page or a button to retry the request once the user has logged in.

400 (Bad Request) Error

The 400 error occurs when the server cannot process a request due to invalid input or a malformed request. This can happen when a user submits a form with missing or incorrect data, or when a request is made with invalid parameters.

To handle a 400 error, you should display a message to the user explaining that the request could not be processed due to invalid input. Additionally, you can provide guidance on how to correct the input and resubmit the request.

500 (Internal Server Error) Error

The 500 error occurs when the server encounters an unexpected error that prevents it from fulfilling the user's request. This can happen for a variety of reasons, such as database errors, server configuration issues, or application bugs.

To handle a 500 error, you should display a message to the user explaining that there was an error and that the problem is being investigated. Additionally, you should log the error on the server and provide information to the development team so that they can fix the problem.

503 (Service Unavailable) Error

The 503 error occurs when the server is temporarily unavailable due to maintenance or overload. This can happen when a website experiences a sudden surge in traffic or when the server is being updated.

To handle a 503 error, you should display a message to the user explaining that the server is temporarily unavailable and provide an estimated time when it will be available again. Additionally, you can provide links to related resources or a button to retry the request once the server is back online.

In conclusion, HTTP errors can be frustrating for users and can negatively impact the performance and reputation of your web application. By being prepared to handle these errors, you can provide a more positive user experience and minimize the impact of errors on your application.

Remember to always provide clear and informative error messages, along with relevant links and suggestions for what users can do next. It's also important to log errors on the server and provide information to your development team so that they can identify and fix any underlying issues.

By taking these steps, you can help ensure that your web application runs smoothly and that your users have a positive experience, even in the face of errors and other unexpected events.

In the next post i will be showing how to fix or handle those errors, stay tuned!!!

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.

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.