Notas &
reflexiones

La mayoría de mis proyectos terminan en uno de los dos. Con el tiempo fui desarrollando un criterio claro para elegir.

GitHub Pages

Ideal para proyectos estáticos simples: portafolios, landing pages, demos de HTML/CSS/JS puro. Cero configuración si el repo es público.

Vercel

Cuando el proyecto tiene; dominio propio, React, variables de entorno, o necesito features como redirects y edge functions.

GitHub y Vercel juntos

La tercera opción, y la que uso en la actualidad, es subir el repositorio a GitHub y desplegar el proyecto en Vercel.

La razón técnica concreta: Vercel entiende frameworks como React, Next.js o Vite, hace el npm run build por vos, sirve los archivos estáticos optimizados, y te da CDN global, HTTPS y dominio custom sin configurar nada. GitHub Pages no tiene ese pipeline de build integrado.

En una línea: GitHub = repositorio, Vercel = servidor inteligente que escucha ese repositorio.

Cerrar ↑

Antes de usar custom properties en serio, mi CSS era un cementerio de valores hardcodeados repetidos. Un color cambiaba y tenía que hacer find & replace por todo el proyecto.

¿Qué cambió?

Empecé a definir todas mis variables en :root y a pensar en el CSS como un sistema de tokens. Colores, espaciados, tipografías, tiempos de animación. Todo centralizado.

• Un cambio en :root impacta todo el sitio al instante.
• Podés tener temas (dark/light) con solo sobrescribir variables.
• Tu CSS se vuelve autodocumentado.

El salto de calidad es real. Cuando un cliente te pide cambiar la paleta de colores a último momento, tener todo en :root te salva la vida 😅. Si todavía no lo hacés en todos tus proyectos, te recomiendo que empieces hoy.

Cerrar ↑

Cuando empecé a dar clases en el Instituto CEA, todavía estaba consolidando muchos de los conceptos que enseñaba. Eso generaba una tensión constante.

La trampa de esperar estar listo

Nadie se siente completamente listo para enseñar y el sindrome del inspostor siempre está latente. Pero esa brecha entre lo que sabés y lo que tenés que explicar te fuerza a estructurar el conocimiento de una forma que simplemente consumirlo no te lo da. Te obliga a investigar, codear para crear ejemplos simples para explicar conceptos y estar preparado para responder dudas.

Explicar flexbox, grid o integraciones a personas con distintos niveles técnicos te obliga a entenderlo desde múltiples ángulos. Creo que eso te hace mejor desarrollador, no solo mejor docente.

Cerrar ↑

Después de meses trabajando en proyectos propios y freelance, noté que la diferencia de velocidad no vino de aprender una tecnología nueva sino de estos tres cambios:

1. Snippets para todo lo que repito

Estructura HTML base, componentes comunes, funciones de utilidad. Si lo escribí más de dos veces, lo convierto en snippet en VS Code.

2. Commits pequeños y descriptivos

Un commit por feature o fix. Nada de "cambios varios". Cuando tengo que revertir algo, me agradezco a mí mismo.

3. Diseñar en el browser, no solo en Figma

Para proyectos chicos, empiezo directo en CSS. Itero más rápido y el resultado final ya está en código.

Cerrar ↑