DEV Community: Juan Torchia

De DOS a Cloud: mi viaje de 33 años con la tecnología — desde una Amiga en 1994 hasta deployar en Railway con Next.js

Juan Torchia — Tue, 07 Apr 2026 00:29:58 +0000

Hay una foto que no tengo pero que existe perfectamente nítida en mi memoria: yo, 1994, tres años recién cumplidos, parado frente a una Commodore Amiga 500 con un joystick que me quedaba enorme en las manos. Mi viejo había traído esa máquina de quién sabe dónde y yo no entendía absolutamente nada de lo que pasaba en la pantalla. Pero algo en ese monitor — los colores, el sonido, la idea de que yo podía hacer que algo pasara — me enganchó de una manera que nunca más me soltó.

Eso fue hace treinta y un años. Y acá estoy.

La Amiga como primer maestro

La Amiga 500 no era una computadora de Windows ni de DOS. Era un bicho aparte, con su propio sistema operativo (AmigaOS), con una interfaz gráfica en una época donde la mayoría del mundo todavía tipeaba comandos en pantallas verdes. Obviamente yo no sabía nada de eso. Lo que sabía era que si agarraba el disquete correcto y lo metía en el drive, aparecía un juego. Y si hacía algo mal, aparecía el Guru Meditation — esa pantalla de error roja que para mí era aterradora, como si la máquina se estuviera muriendo.

Pero el Guru Meditation fue mi primer contacto con la idea de que las computadoras fallan. Que no son magia. Que hay algo adentro que puede romperse. Esa intuición — que después se convirtió en conocimiento real — es probablemente lo más valioso que me dejó esa Amiga oxidada.

A los 5 años ya tenía mi primer dominio. No, no es un chiste. Mi viejo era de esa generación que entendió internet antes que nadie en Argentina, y de alguna manera yo estaba metido en ese mundo también. No entendía qué era un DNS ni por qué funcionaba, pero sabía que ese nombre era mío y que apuntaba a algo en internet. La semilla del orgullo nerd estaba plantada.

Los cyber cafés como universidad

Salteemos algunos años de caos típico de crecer en Argentina en los '90 y lleguemos a los 14. Estaba trabajando en cyber cafés. Y cuando digo trabajando, no digo atendiendo la caja — digo metido abajo de los escritorios, pasando cables, configurando Windows 98 que se rompía solo mirándolo, instalando drivers de red que no existían para hardware que tampoco debería haber existido.

Los cyber cafés de esa época eran una jungla. Diez máquinas conectadas con cable UTP pelado, hubs baratos que se calentaban como hornos, Windows pirata que cada tanto decidía que el mejor momento para reiniciar era en medio de un Counter-Strike. Mi trabajo no oficial era que todo siguiera andando. Y aprendí más redes en seis meses de cyber café que en cualquier curso formal.

Aprendí qué es una subred porque tuve que configurarlas. Aprendí qué es DHCP porque cuando no funcionaba, los chicos no podían jugar y me gritaban. Aprendí qué es una dirección MAC porque era la única manera de identificar cuál de esas diez máquinas era la que se caía siempre. El conocimiento forzado por el caos es el que más dura.

Linux a las 3am y el primer servidor real

A los 18 el salto fue a web hosting con Linux. Y acá es donde la cosa se pone seria.

Instalar Linux en 2009 no era como ahora. No había un instalador bonito que te guiaba de la mano. Había particiones que tenías que calcular a mano, había GRUB que si lo instalabas mal te quedabas sin sistema operativo en absolutamente todas las particiones que tenías, había controladores de red que a veces no existían para tu hardware y tenías que compilarlos desde código fuente descargado con la única máquina que sí tenía internet.

Pero una vez que andaba... era mío. Completamente mío. Un servidor corriendo Apache, MySQL, PHP — el stack LAMP que movía la mitad de internet en esa época. Configurando virtual hosts a las 3am porque ese era el único momento en que podía trabajar sin interrupciones. Mirando logs en tiempo real con tail -f como si fueran telemetría de una nave espacial.

Esa sensación — la de tener una máquina real en internet, respondiendo requests de gente real — es algo que nunca se va. Es adictiva. Hoy tengo esa misma sensación cuando hago deploy y veo los logs de Railway actualizarse en tiempo real, pero la primera vez que la sentí tenía 18 años y era con un servidor físico en algún datacenter que nunca llegué a ver en persona.

El desvío: Cisco CCNA y la UBA

Hubo un período donde me fui más hacia las redes que hacia el software. Hice la certificación Cisco CCNA — una de esas credenciales que te hacen estudiar routing protocols, spanning tree, VLANs, subnetting hasta que lo soñás — y entré a Ciencias de la Computación en la UBA.

La UBA me enseñó a pensar. Eso suena a cliché pero es literal. Álgebra, lógica, algoritmos — la parte de la computación que no se aprende tocheando servidores. Aprendí por qué ciertos algoritmos son más eficientes que otros. Aprendí a demostrar cosas. Aprendí que hay una diferencia enorme entre código que funciona y código que es correcto.

También aprendí que la academia argentina tiene una relación complicada con la tecnología del mundo real. Estábamos estudiando teoría de compiladores mientras afuera el mundo estaba explotando con Node.js y el primer boom de las startups. No me arrepiento — la base teórica vale oro — pero había una desconexión que a veces desesperaba.

El CCNA, por otro lado, fue brutal en el buen sentido. Estudiar para esa certificación es como meterse en la cabeza de los ingenieros de Cisco y entender por qué internet funciona como funciona. Por qué los paquetes toman ciertas rutas. Por qué falla cuando falla. Ese conocimiento de red de bajo nivel es algo que hoy, cuando debuggeo problemas de conectividad en Docker o configuro reglas de firewall en un VPS, sigo usando constantemente.

2020: el pivot que cambió todo

Y llegamos al momento que cambió todo. 2020. Sí, ese año.

Con el mundo en pausa forzada, yo tomé la decisión de meterme de lleno en desarrollo de software moderno. No como hobby — como carrera principal. Y el mundo que encontré era irreconocible comparado con el PHP que había tocado diez años antes.

React. TypeScript. Next.js. Docker. PostgreSQL. Un ecosistema completamente diferente, con sus propias convenciones, sus propias peleas internas (¿Redux o Context? ¿REST o GraphQL? ¿tabs o espacios — bueno, esa está resuelta), su propia cultura.

El primer mes fue humillante. Yo que había configurado servidores Linux, que entendía cómo funciona TCP/IP, que había estudiado algoritmos en la UBA — no podía hacer andar un componente de React sin romper todo. El modelo mental es completamente diferente. El estado reactivo, el ciclo de vida de los componentes, el sistema de tipos de TypeScript que al principio parece un obstáculo y después te das cuenta de que es lo que te salva la vida — todo nuevo.

Pero acá es donde los treinta años anteriores pagaron dividendos. Cuando algo fallaba, yo sabía leer el error. Cuando había un problema de red en Docker, yo sabía qué estaba pasando. Cuando la base de datos se portaba raro, tenía intuición de dónde buscar. La experiencia acumulada no era transferible directamente, pero creaba un contexto que aceleraba el aprendizaje de manera brutal.

Railway, Next.js y el deploy de 2024

Hoy el stack en el que trabajo es Next.js con TypeScript, PostgreSQL para los datos persistentes, Docker para que el ambiente local sea igual al de producción (la promesa eterna que Docker por fin cumplió), y Railway para el deploy.

Railway merece un párrafo aparte porque representa exactamente el contraste con mis inicios. En 2009, para poner algo en producción, necesitaba: contratar un servidor, configurarlo desde cero con SSH, instalar todo el stack, configurar el dominio, configurar SSL manualmente con Let's Encrypt o pagar un certificado, configurar backups, monitoreo... Días de trabajo para la infraestructura antes de poder desplegar una línea de código de producto.

Con Railway hoy: railway up. Listo. En serio. La infraestructura está toda abstraída. PostgreSQL con un click. Variables de entorno en una interfaz. Deploys automáticos desde GitHub. SSL automático. Monitoreo incluido.

La primera vez que hice un deploy así me quedé mirando la terminal en silencio unos segundos. Pensé en las noches configurando Apache, en los GRUB rotos, en los cyber cafés con calor de diciembre y cables por todos lados. Y pensé: esto es demasiado fácil. Y después me corregí: no es fácil, es que alguien hizo el trabajo duro por vos.

Esa es la paradoja de la abstracción tecnológica. Todo se vuelve más accesible, y eso es bueno — significa más gente puede construir cosas. Pero también significa que hay capas de complejidad que se vuelven invisibles, y cuando algo sale mal en esas capas, el desarrollador que no pasó por los servidores físicos no tiene las herramientas mentales para entender qué está pasando.

Por qué importa de dónde venís

Soy un producto raro: demasiado joven para haber vivido los mainframes, demasiado viejo para haber empezado con smartphones y tutoriales de YouTube. Caí justo en el medio de la transición más grande de la historia de la computación personal.

Y eso me dio algo que valoro cada vez más: contexto histórico. Sé por qué las cosas son como son. Sé por qué Docker existe — porque el "funciona en mi máquina" es un problema real que yo viví. Sé por qué TypeScript existe — porque JavaScript a escala es una pesadilla de mantenimiento que yo también viví. Sé por qué los servicios cloud existen — porque la alternativa era lo que yo hacía a los 18.

Esta historia — la historia programador argentino que creció con la tecnología en tiempo real — no es nostalgia. Es contexto. Y el contexto es lo que separa a alguien que usa herramientas de alguien que las entiende.

La Amiga 500 de 1994 y el Railway de 2024 son el mismo continuo. Cambió todo y no cambió nada: sigue siendo sobre hacer que las máquinas hagan lo que vos querés que hagan. Sigue siendo sobre entender qué pasa cuando algo falla. Sigue siendo sobre esa sensación — adictiva, visceral, única — de ver algo que construiste funcionando en el mundo real.

Tres años. Una Amiga. Treinta y uno después, acá sigo.

Este artículo fue publicado originalmente en juanchi.dev

De 3 segundos a 300ms: cómo optimicé el performance de una app Next.js en producción

Juan Torchia — Tue, 07 Apr 2026 00:29:49 +0000

Hay un momento específico en la vida de un desarrollador donde te das cuenta que rompiste algo. No con un error. Con silencio. Con lentitud. Con ese spinner que gira y gira mientras el usuario se pregunta si tu app está viva o ya murió.

Me pasó en producción. Una app Next.js que habíamos lanzado con orgullo estaba tardando entre 2.8 y 3.4 segundos en el First Contentful Paint. En mobile, peor. El LCP rondaba los 4 segundos. Google Lighthouse me miraba con cara de asco y yo no tenía excusas — era mi código, mis decisiones, mi problema.

Este es el relato de cómo diagnostiqué el desastre, qué cambié, y cómo llegué a 300ms de FCP en producción. Sin bullshit, sin "simplemente usá un CDN", con el trabajo sucio que nadie muestra en los tutoriales.

El diagnóstico: primero entendé qué está ardiendo

Antes de tocar una sola línea de código, necesitás saber qué está lento. Yo cometí el error clásico: asumir. "Seguro es el bundle", pensé. Spoiler: no era solo el bundle.

Las herramientas que usé:

Lighthouse en modo incógnito (sin extensiones que contaminen los resultados)
Chrome DevTools → Network tab con throttling a "Fast 3G"
Vercel Analytics para datos reales de usuarios
next build con ANALYZE=true para ver el bundle

Para el bundle analyzer, instalé esto:

npm install @next/bundle-analyzer

Y en next.config.js:

const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
})

/** @type {import('next').NextConfig} */
const nextConfig = {
  // tu config
}

module.exports = withBundleAnalyzer(nextConfig)

Después corrés:

ANALYZE=true npm run build

Y ahí fue cuando vi el horror. Tenía moment.js importado completo — 67kb gzipped — para formatear dos fechas en toda la app. Tenía una librería de gráficos cargando en el bundle principal cuando solo aparecía en una página de dashboard. Tenía componentes que fetcheaban datos en el cliente cuando perfectamente podían ser Server Components.

El diagnóstico real mostró tres problemas grandes:

Bundle de cliente inflado con dependencias innecesarias
Waterfall de requests en el cliente (fetch tras fetch, en cadena)
Imágenes sin optimizar y sin tamaño declarado (layout shift asesino)

Problema 1: el bundle era un desastre

Bye bye moment.js

Reemplacé moment.js con date-fns usando imports específicos:

// ❌ Antes — importaba todo moment
import moment from 'moment'
const fecha = moment(timestamp).format('DD/MM/YYYY')

// ✅ Después — solo lo que necesito
import { format } from 'date-fns'
import { es } from 'date-fns/locale'
const fecha = format(new Date(timestamp), 'dd/MM/yyyy', { locale: es })

Resultado: -67kb gzipped del bundle principal. Sí, así de ridículo era.

Dynamic imports para lo que no se ve al inicio

El gráfico de dashboard no debería estar en el bundle de la página de inicio. Dynamic import con next/dynamic:

import dynamic from 'next/dynamic'

// ❌ Antes
import { RevenueChart } from '@/components/RevenueChart'

// ✅ Después
const RevenueChart = dynamic(
  () => import('@/components/RevenueChart'),
  {
    loading: () => <ChartSkeleton />,
    ssr: false // este componente usa window, no puede hacer SSR
  }
)

Esto sacó ~45kb del bundle inicial y el usuario ve el skeleton mientras carga — mucho mejor UX que ver nada.

Problema 2: el waterfall de fetches en el cliente

Acá estaba el problema más gordo. Tenía una página de perfil de usuario que hacía esto:

// ❌ El horror — cada fetch espera al anterior
const ProfilePage = () => {
  const [user, setUser] = useState(null)
  const [posts, setPosts] = useState([])
  const [stats, setStats] = useState(null)

  useEffect(() => {
    fetch('/api/user')
      .then(r => r.json())
      .then(user => {
        setUser(user)
        // Espera al user para fetchear posts
        return fetch(`/api/posts?userId=${user.id}`)
      })
      .then(r => r.json())
      .then(posts => {
        setPosts(posts)
        // Espera a posts para fetchear stats
        return fetch(`/api/stats?userId=${user.id}`)
      })
      .then(r => r.json())
      .then(setStats)
  }, [])
}

Tres requests en cadena. Esperaba request 1 para lanzar request 2. Esperaba request 2 para lanzar request 3. En una conexión normal eso son 800ms de overhead puro.

La solución en dos pasos:

Paso 1: Paralizar lo que se puede paralelizar

Si tenés el userId desde el principio (por ejemplo, de la sesión), no necesitás esperar a que llegue el user para pedir sus posts:

// ✅ Paralelo cuando es posible
const ProfilePage = ({ userId }: { userId: string }) => {
  useEffect(() => {
    Promise.all([
      fetch(`/api/user/${userId}`).then(r => r.json()),
      fetch(`/api/posts?userId=${userId}`).then(r => r.json()),
      fetch(`/api/stats?userId=${userId}`).then(r => r.json()),
    ]).then(([user, posts, stats]) => {
      setUser(user)
      setPosts(posts)
      setStats(stats)
    })
  }, [userId])
}

Paso 2: Moverlo al servidor con Server Components (la solución real)

Pero la solución de verdad era dejar de fetchear en el cliente. Con el App Router de Next.js 13+, esto se convierte en:

// app/perfil/[userId]/page.tsx
// ✅ Server Component — todo en el servidor, en paralelo
import { getUserData, getUserPosts, getUserStats } from '@/lib/api'

export default async function ProfilePage({ 
  params 
}: { 
  params: { userId: string } 
}) {
  // Paralelo en el servidor — no hay waterfall, no hay round trip al cliente
  const [user, posts, stats] = await Promise.all([
    getUserData(params.userId),
    getUserPosts(params.userId),
    getUserStats(params.userId),
  ])

  return (
    <div>
      <UserHeader user={user} />
      <StatsBar stats={stats} />
      <PostsList posts={posts} />
    </div>
  )
}

Esto eliminó completamente el round trip cliente → servidor para el data fetching inicial. El HTML llega al navegador ya con los datos adentro. El tiempo de esos tres fetches dejó de contar para el usuario.

Problema 3: las imágenes me estaban matando

Tenía imágenes con <img> nativo en vez de next/image. Sin width/height declarados. Sin lazy loading inteligente. El Cumulative Layout Shift era de 0.34 — Google te odia si superás 0.1.

// ❌ Layout shift garantizado
<img src={user.avatar} alt={user.name} />

// ✅ Next.js Image con todo configurado
import Image from 'next/image'

<Image
  src={user.avatar}
  alt={user.name}
  width={64}
  height={64}
  className="rounded-full"
  priority={false} // true solo para imágenes above the fold
/>

Para las imágenes hero (above the fold), usé priority={true} para que Next.js las precargue. Para todo lo demás, lazy loading automático.

También configuré los dominios permitidos en next.config.js:

module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'storage.googleapis.com',
        pathname: '/mi-bucket/**',
      },
    ],
    formats: ['image/avif', 'image/webp'],
  },
}

Next.js convierte automáticamente a WebP/AVIF según lo que soporte el browser. Mis imágenes de 800kb bajaron a 120kb en WebP.

El toque final: caching agresivo

Venía cacheando prácticamente nada. Las rutas del App Router tienen cache por defecto, pero yo lo estaba rompiendo sin querer:

// ❌ Esto desactiva el cache estático
export const dynamic = 'force-dynamic'

// ✅ Revalidación cada 60 segundos — fresco pero cacheado
export const revalidate = 60

Para el fetch dentro de Server Components, usé las opciones de cache:

// Cache con revalidación por tiempo
const data = await fetch('https://api.ejemplo.com/data', {
  next: { revalidate: 3600 } // 1 hora
})

// Cache estático (no cambia nunca hasta el próximo deploy)
const config = await fetch('https://api.ejemplo.com/config', {
  cache: 'force-cache'
})

// Sin cache (datos en tiempo real)
const liveData = await fetch('https://api.ejemplo.com/live', {
  cache: 'no-store'
})

Los resultados reales

Una semana después del deploy con todos los cambios, los números de Vercel Analytics:

Métrica	Antes	Después	Mejora
FCP (p75)	3.1s	310ms	-90%
LCP (p75)	4.2s	820ms	-80%
CLS	0.34	0.02	-94%
Bundle size	487kb	198kb	-59%
TTFB	890ms	180ms	-80%

El score de Lighthouse pasó de 42 a 91. En mobile, de 31 a 84.

Lo que más impactó, en orden:

Server Components eliminando el client waterfall (40% de la mejora)
Bundle splitting y eliminación de dependencias pesadas (30%)
Optimización de imágenes (20%)
Caching (10%)

Lo que aprendí — y lo que hubiera hecho diferente

El error fundamental fue no medir desde el principio. Desarrollé meses asumiendo que "estaba bien" y recién en producción con usuarios reales vi el desastre. Ahora tengo Lighthouse en el CI/CD que falla el build si el score baja de 80.

También aprendí que optimizar performance no es un sprint, es una mentalidad. Cada dependencia que agregás tiene un costo. Cada fetch en el cliente tiene un costo. Cada imagen sin dimensiones tiene un costo. El costo se paga después, con usuarios frustrados y SEO en el piso.

La optimización de performance en Next.js no es magia — es diagnóstico honesto, decisiones conservadoras con las dependencias, y aprovechar las herramientas que ya tenés. Los Server Components existen para esto. El Image component existe para esto. El bundle analyzer existe para esto.

Usalos antes de que el Lighthouse te grite.

Este artículo fue publicado originalmente en juanchi.dev

pnpm vs npm vs yarn vs bun: la comparativa definitiva que nadie te va a dar en 2025

Juan Torchia — Tue, 07 Apr 2026 00:29:00 +0000

Hay decisiones en el desarrollo de software que parecen triviales hasta que te explotan en la cara. Qué package manager usar es una de esas. Yo las pagué todas: proyectos con node_modules de 4GB, deploys que fallaban por conflictos de versiones que "no deberían existir", monorepos que tardaban 8 minutos en instalarse en CI. Todo eso me hizo obsesionarme con este tema.

Así que vamos directo al hueso: pnpm vs npm vs yarn vs bun — qué son, qué hacen diferente, cuándo usar cada uno, y cuál ganó mi corazón (y mi .zshrc).

Un poco de historia para que entiendas por qué existe este caos

npm llegó en 2010 pegado a Node.js. Era la única opción y, francamente, era un desastre. El node_modules flat que conocemos hoy ni existía — en las versiones viejas tenías árbol anidado infinito, carpetas dentro de carpetas que llegaban a rutas tan largas que Windows directamente se rendía. En serio.

Yarn apareció en 2016, creado por Facebook (ahora Meta) en colaboración con Google y otros. Fue una bocanada de aire fresco: instalaciones paralelas, lockfile determinístico, cache local. npm tardó años en ponerse al día.

pnpm llegó también por esa época pero tardó más en tomar tracción. Y Bun... Bun es el newcomer que llegó en 2023 a decir que todos los demás son lentos y tiene cierta razón.

npm: el que ya tenés instalado

Lo bueno: Viene con Node. Sin instalación extra, sin explicarle nada a nadie. Para un proyecto pequeño o para onboardear a alguien nuevo es imbatible en simplicidad.

Lo malo: Sigue siendo el más lento de los cuatro en instalaciones en frío. El node_modules es un monstruo flat que duplica paquetes alegremente. En un monorepo mediano vi node_modules llegar a 3.8GB. Eso no es normal. Eso es un problema.

La versión 7 trajo workspaces, la 8 mejoró bastante el performance, y npm hoy en día es decente. Pero "decente" no es suficiente cuando existían mejores alternativas hace años.

Mi experiencia real: En 2021 arranqué un proyecto con npm por defecto. A los tres meses el CI tardaba 6 minutos solo en el npm install. Migré a pnpm en un viernes a la tarde (error mío, nunca migrés nada importante un viernes) y el lunes el CI tardaba 90 segundos. Eso me marcó.

Cuándo usarlo: Cuando el proyecto es chico, cuando el equipo no quiere fricción de setup, o cuando trabajás con herramientas que tienen bugs conocidos con pnpm (sí, existen, aunque cada vez menos).

Yarn: el que prometía mucho y se complicó

Yarn clásico (v1) fue revolucionario en su momento. Lockfile determinístico, caché que realmente funcionaba, parallelismo. npm tardó literalmente años en igualar esas features.

Pero después llegó Yarn Berry (v2 en adelante) y todo se complicó. Introdujeron Plug'n'Play (PnP): en lugar de node_modules, un sistema de resolución propio donde los paquetes están en archivos .zip y un loader los resuelve en runtime. La teoría es preciosa. La práctica es otro tema.

Probé Yarn Berry en un proyecto Next.js y fue una tarde entera de debuggear por qué ciertos paquetes no levantaban. Algunos tools del ecosistema simplemente no entienden el modelo PnP. Terminé en nodeLinker: node-modules en el .yarnrc.yml, que básicamente es usar Yarn Berry actuando como Yarn clásico. ¿Para qué, entonces?

Lo bueno de Yarn: La DX cuando funciona es muy linda. Los workspaces de Yarn son muy maduros. El equipo de Yarn lleva años puliendo esto.

Lo malo: La fragmentación entre v1 y v2/v3/v4 es un quilombo. Si buscás un error en Stack Overflow, el 60% de las respuestas son para la versión equivocada. Y PnP, aunque brillante conceptualmente, genera fricción real.

Cuándo usarlo: Yarn clásico (v1) en proyectos legados que ya lo usan y no vale la pena migrar. Yarn Berry si estás dispuesto a invertir tiempo en entender PnP y tu equipo está alineado.

pnpm: mi favorito sin discusión

Acá es donde me pongo intenso, así que aguantame.

pnpm resuelve el problema fundamental del package management de Node de una manera elegante: el content-addressable store. En lugar de copiar paquetes en cada node_modules, usa hard links a un store global en tu máquina. lodash instalado en 47 proyectos distintos ocupa espacio de disco una sola vez. El node_modules de cada proyecto son mayormente symlinks y hard links.

Esto tiene consecuencias reales:

Velocidad: Primera instalación comparable a npm/yarn. Segunda instalación y en adelante: ridículamente rápida.
Espacio en disco: Tengo quizás 200 proyectos en esta máquina. Si usara npm serían cientos de GB. Con pnpm el store global ocupa ~15GB para todo.
Correctitud: pnpm es estricto con las dependencias. No podés acceder a un paquete que no declaraste en tu package.json. Esto parece una molestia hasta que te das cuenta de que npm/yarn te dejan acceder a dependencias transitivas silenciosamente — una bomba de tiempo.

Los workspaces de pnpm son los mejores del ecosistema, punto. El archivo pnpm-workspace.yaml es simple, el hoisting configurable, y el comando pnpm -r para correr scripts en todos los packages es una joya.

Mi experiencia real: Hoy uso pnpm en absolutamente todos mis proyectos personales y profesionales. El comando que más escribo después de git es probablemente pnpm install. Tuve exactamente un problema de compatibilidad en dos años: una librería vieja que asumía hoisting de npm. Lo resolví en 10 minutos con .npmrc ajustado.

Lo malo de pnpm: La instalación inicial es un paso extra. Algunos proyectos open source con configs de npm legacy pueden dar dolores de cabeza. Y el store global puede crecer mucho si no hacés pnpm store prune de vez en cuando (yo lo tengo en un cron).

Cuándo usarlo: Casi siempre. Especialmente en monorepos. Especialmente si te importa el espacio en disco. Especialmente si querés que tus dependencias estén correctamente declaradas.

Bun: el que llegó a romper todo

Bun no es solo un package manager — es un runtime completo (reemplazo de Node), un bundler, un test runner, y un transpiler. Pero acá hablamos de su faceta como package manager.

Los números: Bun install es absurdamente rápido. Hablo de instalaciones en frío de proyectos medianos en 2-3 segundos. Lo que npm hace en 45 segundos, Bun lo hace en 3. Está escrito en Zig, usa su propio runtime, y tiene un caché binario que hace que las instalaciones repetidas sean casi instantáneas.

Lo probé en un proyecto Next.js y funcionó perfecto. El lockfile (bun.lockb) es binario, lo cual es raro conceptualmente pero funciona. Los workspaces están soportados. La compatibilidad con el ecosistema npm es muy buena.

Pero acá viene mi hesitación: Bun como runtime todavía tiene edge cases donde el comportamiento difiere de Node. Si usás Bun solo como package manager (con Node como runtime), eso desaparece — pero entonces estás instalando un tool enorme para usar solo una fracción.

El ecosistema de Bun maduró muchísimo en 2024. Para 2025 es una opción real y seria. Pero yo todavía no migré mis proyectos productivos porque el riesgo/beneficio no cierra para mí. La velocidad de pnpm con caché es más que suficiente, y el modelo mental de Bun como "todo en uno" todavía me genera incertidumbre en deployments complejos.

Cuándo usarlo: Si arrancás un proyecto nuevo y querés experimentar. Si el performance de instalación es crítico para vos (¿monorepo enorme en CI sin caché?). Si sos el tipo de persona que le gusta estar en la vanguardia y bancarse algún rough edge.

La tabla que todos quieren

	npm	Yarn	pnpm	Bun
Velocidad (frío)	Lento	Medio	Rápido	Muy rápido
Velocidad (caché)	Medio	Rápido	Muy rápido	Muy rápido
Espacio en disco	Mucho	Mucho	Poco	Poco
Monorepos	Básico	Bueno	Excelente	Bueno
Madurez	Alta	Alta	Alta	Media
Compatibilidad	Total	Alta	Alta	Alta
Strictness	No	No	Sí	No

Mi recomendación final, sin rodeos

¿Proyecto nuevo, 2025? → pnpm. Sin dudarlo. La curva de aprendizaje es mínima (es casi idéntico a npm en la interfaz), los beneficios son inmediatos y reales, y el soporte del ecosistema es excelente.

¿Monorepo? → pnpm con workspaces. Es la mejor opción disponible hoy.

¿Querés vivir en el futuro? → Bun. Pero sabé que vas a ser el beta tester de algunas cosas.

¿Proyecto legado que ya tiene yarn.lock o package-lock.json? → No migrés por migrar. El lockfile es contrato. Si no tenés un motivo real de performance o correctitud, dejalo como está.

npm puro en 2025 sin una razón específica: No. Ya no. Es como usar jQuery en un proyecto nuevo — funciona, pero hay mejores opciones y vos lo sabés.

El ecosistema JavaScript tiene sus mil problemas, pero en package management llegamos a un punto donde tenemos opciones genuinamente buenas. Aprovechalo. Yo tardé demasiado en salir de npm por inercia, y esos 6 minutos de CI en 2021 me los voy a cobrar de alguna forma.

Este artículo fue publicado originalmente en juanchi.dev

Cómo construí juanchi.dev con el stack más bleeding edge de 2025: Next.js 16, React 19, Tailwind v4 y Railway

Juan Torchia — Tue, 07 Apr 2026 00:28:36 +0000

Hay una pregunta que me hice durante meses antes de arrancar con juanchi.dev: ¿uso el stack probado o me tiro de cabeza con lo más nuevo y aguanto los golpes?

Elegí los golpes. Siempre elijo los golpes.

Esto es lo que pasó cuando intenté montar un portfolio de desarrollador con Next.js 16, React 19, Tailwind v4 y Railway en producción — con todo lo que salió mal documentado en tiempo real, porque alguien tiene que hacerlo.

El setup inicial: la arrogancia de los primeros 20 minutos

Empecé con confianza de CEO de startup imaginaria. Tres comandos y ya:

npx create-next-app@latest juanchi-dev \
  --typescript \
  --tailwind \
  --eslint \
  --app \
  --src-dir \
  --import-alias "@/*"

Bien. Proyecto andando. Tailwind v4 instalado automáticamente porque usé el flag correspondiente. Acá fue cuando me di cuenta que v4 no tiene tailwind.config.js por defecto — toda la configuración vive en el CSS directamente:

@import "tailwindcss";

@theme {
  --font-family-display: "Inter Variable", sans-serif;
  --color-brand: oklch(62% 0.25 240);
  --color-brand-dark: oklch(45% 0.25 240);
  --breakpoint-xs: 20rem;
}

Esto es raro al principio. Muy raro. Durante dos horas busqué dónde meter mi extend de colores personalizados hasta que leí la documentación de verdad. Con v4, el archivo CSS es la configuración. Una vez que lo internalizás, es hermoso. Hasta entonces, duele.

React 19 y los Server Components: amigos con beneficios que te complican la vida

La idea era simple: portfolio estático en su mayoría, con algunas partes dinámicas. Uso de Server Components para todo lo que pueda, Client Components solo donde necesito interactividad.

Acá está la estructura que terminé usando:

src/
  app/
    page.tsx          → Server Component (hero + about)
    projects/
      page.tsx        → Server Component (fetch de proyectos)
      [slug]/
        page.tsx      → Server Component (detalle del proyecto)
    blog/
      page.tsx        → Server Component
    contact/
      page.tsx        → mezcla de los dos mundos
  components/
    ui/               → Client Components (animaciones, forms)
    server/           → Server Components (cards, layouts)

El problema vino con las animaciones. Quería ese efecto de entrada donde cada sección aparece al hacer scroll. Usé framer-motion y el compilador me mandó directo al carajo:

Error: useState can only be used in a Client Component.
Add the "use client" directive at the top of the file.

Claro. framer-motion necesita el DOM. Solución: wrapper client-side que envuelve los Server Components:

// components/ui/animated-section.tsx
'use client'

import { motion } from 'framer-motion'
import { ReactNode } from 'react'

interface AnimatedSectionProps {
  children: ReactNode
  delay?: number
}

export function AnimatedSection({ children, delay = 0 }: AnimatedSectionProps) {
  return (
    <motion.div
      initial={{ opacity: 0, y: 24 }}
      whileInView={{ opacity: 1, y: 0 }}
      viewport={{ once: true }}
      transition={{ duration: 0.5, delay, ease: 'easeOut' }}
    >
      {children}
    </motion.div>
  )
}

Y en el Server Component:

// app/page.tsx (Server Component)
import { AnimatedSection } from '@/components/ui/animated-section'
import { HeroContent } from '@/components/server/hero-content'

export default function HomePage() {
  return (
    <main>
      <AnimatedSection>
        <HeroContent />
      </AnimatedSection>
    </main>
  )
}

El patrón de "wrapper client, contenido server" es la clave. Lo entendí tarde, pero lo entendí.

El sistema de proyectos: MDX + generación estática

Para los proyectos decidí usar archivos MDX locales. Sin CMS, sin base de datos, sin dependencias externas para el contenido. Los archivos viven en el repo.

// lib/projects.ts
import fs from 'fs'
import path from 'path'
import matter from 'gray-matter'

const projectsDir = path.join(process.cwd(), 'content/projects')

export interface Project {
  slug: string
  title: string
  description: string
  stack: string[]
  year: number
  liveUrl?: string
  repoUrl?: string
  featured: boolean
  content: string
}

export async function getAllProjects(): Promise<Project[]> {
  const files = fs.readdirSync(projectsDir)

  return files
    .filter(f => f.endsWith('.mdx'))
    .map(filename => {
      const slug = filename.replace('.mdx', '')
      const raw = fs.readFileSync(path.join(projectsDir, filename), 'utf8')
      const { data, content } = matter(raw)

      return {
        slug,
        title: data.title,
        description: data.description,
        stack: data.stack ?? [],
        year: data.year,
        liveUrl: data.liveUrl,
        repoUrl: data.repoUrl,
        featured: data.featured ?? false,
        content
      }
    })
    .sort((a, b) => b.year - a.year)
}

export async function getProjectBySlug(slug: string): Promise<Project | null> {
  const projects = await getAllProjects()
  return projects.find(p => p.slug === slug) ?? null
}

Esto funciona perfecto en local. En Railway empezó el drama.

Railway: el deployment que casi me quiebra

Railway es mi plataforma de hosting favorita para proyectos propios. Precio razonable, DX excelente, deploys desde GitHub automáticos. Pero con Next.js 16 hay que tener cuidado con algo: el output mode.

Por defecto, Next.js genera un bundle que asume que tenés Node.js disponible en runtime. Railway lo maneja bien, pero el fs.readdirSync que uso para leer los archivos MDX no funciona si configurás output: 'export' (modo totalmente estático).

Yo, genio que soy, lo había puesto en output: 'export' porque quería el deploy más rápido posible. El resultado:

Error: ENOENT: no such file or directory, scandir '/app/content/projects'

El directorio content/ no estaba en el build de producción. El problema era que Railway copiaba el output exportado pero no los archivos fuente. Dos opciones:

Cambiar a modo Node.js (server-side rendering real)
Mantener export pero pre-generar todo en build time

Elegí el modo Node.js porque igual necesitaba el endpoint de contacto con lógica server-side:

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  // Sin output: 'export' — modo Node.js
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'github.com'
      }
    ]
  },
  experimental: {
    optimizePackageImports: ['framer-motion', 'lucide-react']
  }
}

export default nextConfig

Y el railway.toml que me salvó la vida:

[build]
builder = "nixpacks"
buildCommand = "npm run build"

[deploy]
startCommand = "npm run start"
healthcheckPath = "/"
healthcheckTimeout = 30
restartPolicyType = "on_failure"
restartPolicyMaxRetries = 3

[[services]]
name = "juanchi-dev"

El formulario de contacto: Server Actions al rescate

Con Next.js 15+ y React 19, los Server Actions son ciudadanos de primera clase. El formulario de contacto que manda un mail fue el lugar perfecto para usarlos:

// app/contact/actions.ts
'use server'

import { Resend } from 'resend'
import { z } from 'zod'

const resend = new Resend(process.env.RESEND_API_KEY)

const ContactSchema = z.object({
  name: z.string().min(2).max(100),
  email: z.string().email(),
  message: z.string().min(10).max(2000)
})

export async function sendContactEmail(
  prevState: { success: boolean; error?: string } | null,
  formData: FormData
) {
  const raw = {
    name: formData.get('name'),
    email: formData.get('email'),
    message: formData.get('message')
  }

  const parsed = ContactSchema.safeParse(raw)

  if (!parsed.success) {
    return { success: false, error: 'Datos inválidos. Revisá los campos.' }
  }

  try {
    await resend.emails.send({
      from: 'contacto@juanchi.dev',
      to: 'yo@juanchi.dev',
      subject: `Nuevo contacto: ${parsed.data.name}`,
      text: `De: ${parsed.data.email}\n\n${parsed.data.message}`
    })

    return { success: true }
  } catch (error) {
    console.error('Error enviando mail:', error)
    return { success: false, error: 'Error al enviar. Probá de nuevo.' }
  }
}

// app/contact/contact-form.tsx
'use client'

import { useActionState } from 'react'
import { sendContactEmail } from './actions'

export function ContactForm() {
  const [state, action, isPending] = useActionState(sendContactEmail, null)

  return (
    <form action={action} className="flex flex-col gap-4">
      <input
        name="name"
        placeholder="Tu nombre"
        className="border border-neutral-700 bg-neutral-900 px-4 py-3 rounded-lg"
        required
      />
      <input
        name="email"
        type="email"
        placeholder="tu@mail.com"
        className="border border-neutral-700 bg-neutral-900 px-4 py-3 rounded-lg"
        required
      />
      <textarea
        name="message"
        placeholder="En qué puedo ayudarte..."
        rows={5}
        className="border border-neutral-700 bg-neutral-900 px-4 py-3 rounded-lg resize-none"
        required
      />
      <button
        type="submit"
        disabled={isPending}
        className="bg-brand text-white py-3 rounded-lg disabled:opacity-50"
      >
        {isPending ? 'Enviando...' : 'Mandar mensaje'}
      </button>
      {state?.success && <p className="text-green-400">¡Mensaje enviado!</p>}
      {state?.error && <p className="text-red-400">{state.error}</p>}
    </form>
  )
}

useActionState es el hook nuevo de React 19 que reemplaza al viejo patrón de useFormState de react-dom. Más limpio, mejor tipado, manejo de pending nativo.

Lo que salió mal: el resumen ejecutivo

Para los que llegaron acá directamente desde el título buscando el drama:

1. Tailwind v4 rompió todos mis snippets guardados. Las utilities cambiaron sutilmente. text-sm sigue existiendo pero los valores por defecto son diferentes. Pasé 40 minutos debuggeando un font-size que "se veía raro" hasta que lo medí con DevTools.

2. framer-motion con React 19 tuvo un bug de hidratación la primera semana. Se resolvió actualizando a framer-motion@12.x. Lección: cuando usás bleeding edge, los paquetes de terceros se quedan atrás.

3. Railway construía bien pero el healthcheck fallaba porque el servidor tardaba más de 10 segundos en responder al primer request (cold start). Solución: aumentar healthcheckTimeout a 30 segundos en el railway.toml.

4. Los tipos de TypeScript de Next.js 16 para algunos parámetros de layouts y pages cambiaron. params ahora es una Promise en algunos contextos. Esto me rompió tres archivos.

// Antes (Next.js 14):
export default function ProjectPage({ params }: { params: { slug: string } }) {

// Ahora (Next.js 15/16):
export default async function ProjectPage(
  { params }: { params: Promise<{ slug: string }> }
) {
  const { slug } = await params

¿Lo volvería a hacer?

Sí. Sin dudas.

Hay algo en trabajar con stack bleeding edge que te fuerza a leer documentación de verdad, a entender por qué las cosas funcionan y no solo cómo. Cuando algo rompe en territorio desconocido no podés copypastear Stack Overflow — tenés que pensar.

Y el resultado final es un portfolio de desarrollador con Next.js y Railway que carga en menos de 1.2 segundos, tiene Lighthouse a 98/100, corre en producción por menos de 5 dólares al mes, y lo más importante: lo entiendo de punta a punta.

La tech nueva duele al principio. Después de eso, es una ventaja competitiva.

El código fuente de juanchi.dev va a estar público en GitHub cuando termine de limpiar los comentarios avergonzantes del proceso. Pronto.

Este artículo fue publicado originalmente en juanchi.dev

Next.js App Router: la guía que me hubiera gustado tener cuando migré de Pages Router

Juan Torchia — Tue, 07 Apr 2026 00:28:28 +0000

Next.js App Router: la guía que me hubiera gustado tener cuando migré de Pages Router

Era un martes a las 11 de la noche y tenía un cliente en producción con el carrito de compras roto. El problema: había migrado a App Router siguiendo la documentación oficial como si fuera un manual de IKEA — metódicamente, con fe ciega — y me había olvidado de entender por qué funcionaba lo que funcionaba. Cuando algo se rompió, no tenía idea de dónde buscar.

Esta es la guía que me hubiera gustado tener. No la de Vercel. La mía.

El cambio mental que nadie te dice que necesitás

El error más grande que cometí fue tratar App Router como si fuera Pages Router con carpetas distintas. No lo es. Es un paradigma diferente.

En Pages Router, todo componente es un Client Component por defecto. Podés usar useState, useEffect, fetch del lado del servidor con getServerSideProps — pero es todo explícito, separado, prolijo.

En App Router, todo componente es un Server Component por defecto. Esto significa que se ejecuta en el servidor, nunca llega al bundle del cliente, puede hablar directo con la base de datos, y no tiene acceso a window, localStorage, ni hooks de React.

Cuando migré mi primer proyecto, pasé tres horas debuggeando esto:

// app/dashboard/page.tsx
export default function Dashboard() {
  const [count, setCount] = useState(0) // 💥 ERROR
  // TypeError: useState is not a function
  return <div>{count}</div>
}

El fix no es "usar Pages Router". El fix es entender cuándo necesitás interactividad y marcar explícitamente ese componente:

'use client'

import { useState } from 'react'

export default function Counter() {
  const [count, setCount] = useState(0)
  return (
    <button onClick={() => setCount(c => c + 1)}>
      Clicks: {count}
    </button>
  )
}

La regla que me tatuaría en la mano: Server Components por defecto, Client Components solo cuando necesitás interactividad, estado del browser, o eventos del DOM.

La estructura de carpetas que sí funciona

El App Router vive en /app. Cada carpeta con un page.tsx se convierte en una ruta. Pero hay archivos especiales que cambian todo:

app/
├── layout.tsx          ← Layout raíz (obligatorio)
├── page.tsx            ← Ruta /
├── loading.tsx         ← UI mientras carga (streaming)
├── error.tsx           ← Manejo de errores
├── not-found.tsx       ← 404
├── dashboard/
│   ├── layout.tsx      ← Layout anidado
│   ├── page.tsx        ← Ruta /dashboard
│   └── settings/
│       └── page.tsx    ← Ruta /dashboard/settings
└── api/
    └── webhook/
        └── route.ts    ← API Route

Los layouts anidados son lo más poderoso y lo que más confunde. El layout.tsx de una carpeta envuelve a todos sus hijos sin remontarse cuando navegás entre subrutas. Esto es exactamente lo que siempre quisimos y nunca tuvimos limpio en Pages Router.

// app/dashboard/layout.tsx
export default function DashboardLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <div className="flex">
      <Sidebar />  {/* Se renderiza UNA vez, no se destruye al navegar */}
      <main className="flex-1">{children}</main>
    </div>
  )
}

Fetch de datos: la parte donde casi todos la cagan

Olvidate de getServerSideProps, getStaticProps y getInitialProps. En App Router, fetcheás datos directamente en el componente:

// app/products/page.tsx
async function getProducts() {
  const res = await fetch('https://api.tudominio.com/products', {
    next: { revalidate: 60 } // Revalida cada 60 segundos
  })
  if (!res.ok) throw new Error('No se pudo cargar products')
  return res.json()
}

export default async function ProductsPage() {
  const products = await getProducts() // async/await directo en el componente

  return (
    <ul>
      {products.map(p => (
        <li key={p.id}>{p.name}</li>
      ))}
    </ul>
  )
}

Sí, el componente es async. Sí, funciona. Sí, me pareció raro al principio también.

El sistema de cache que me hizo perder dos horas

Next.js cachea el fetch por defecto. Esto es un feature, no un bug. Pero si no lo entendés, te volvés loco.

// Cacheado indefinidamente (como getStaticProps)
const data = await fetch('/api/data')

// Sin cache (como getServerSideProps)
const data = await fetch('/api/data', { cache: 'no-store' })

// Revalidación por tiempo
const data = await fetch('/api/data', { next: { revalidate: 3600 } })

// Revalidación por tag (on-demand)
const data = await fetch('/api/data', { next: { tags: ['products'] } })

Ese último es el que me salvó cuando el cliente me preguntaba por qué los precios actualizados no aparecían. Con tags podés invalidar el cache cuando muta un dato:

// app/api/update-product/route.ts
import { revalidateTag } from 'next/cache'

export async function POST(request: Request) {
  const body = await request.json()
  await updateProductInDB(body)
  revalidateTag('products') // 🔥 Invalida todo lo que use este tag
  return Response.json({ ok: true })
}

Streaming y Suspense: la magia que justifica todo el dolor

Esto es lo que más me enamoró del App Router y lo que hacía imposible Pages Router.

El streaming te permite enviar partes de la página al browser mientras otras partes todavía se están computando en el servidor. El usuario ve contenido rápido en lugar de una pantalla en blanco.

Combinado con Suspense, es una locura:

// app/dashboard/page.tsx
import { Suspense } from 'react'
import { UserStats } from './UserStats'    // Query rápida
import { SalesChart } from './SalesChart'  // Query lenta (agrega datos)
import { RecentOrders } from './RecentOrders'

export default function Dashboard() {
  return (
    <div>
      <h1>Dashboard</h1>

      {/* Se renderiza casi instantáneo */}
      <Suspense fallback={<StatsSkeleton />}>
        <UserStats />
      </Suspense>

      {/* Llega cuando termina, sin bloquear lo demás */}
      <Suspense fallback={<ChartSkeleton />}>
        <SalesChart />
      </Suspense>

      <Suspense fallback={<OrdersSkeleton />}>
        <RecentOrders />
      </Suspense>
    </div>
  )
}

Cada Suspense boundary se resuelve independientemente. Si SalesChart tarda 2 segundos y UserStats tarda 200ms, el usuario ve las stats antes y el chart aparece solo después. Sin JavaScript del cliente. Sin useEffect. Sin estado de loading manual.

El archivo loading.tsx hace exactamente esto a nivel de ruta:

// app/dashboard/loading.tsx
export default function Loading() {
  return <DashboardSkeleton />
}

Lo que rompe en producción (mi lista de traumas)

1. Los cookies y headers en Server Components

Si necesitás leer una cookie en un Server Component, no usés document.cookie. Usá las funciones de Next.js:

import { cookies, headers } from 'next/headers'

export default async function Page() {
  const cookieStore = await cookies()
  const token = cookieStore.get('auth-token')

  const headersList = await headers()
  const userAgent = headersList.get('user-agent')

  return <div>Token: {token?.value}</div>
}

2. Pasar funciones como props a Client Components

Esto me rompió la cabeza al principio:

// ❌ NO podés pasar una función de un Server Component a un Client Component
export default function ServerComponent() {
  const handleClick = () => console.log('click')
  return <ClientButton onClick={handleClick} /> // Error en runtime
}

// ✅ La función tiene que vivir en el Client Component
'use client'
export function ClientButton() {
  const handleClick = () => console.log('click')
  return <button onClick={handleClick}>Click</button>
}

La razón es simple: una función de JavaScript no se puede serializar para enviarla entre servidor y cliente. Tiene sentido cuando lo pensás, pero duele cuando lo descubrís a las 2am.

3. El router de navegación cambió

Olvidate de useRouter de next/router. Ahora es next/navigation:

'use client'
import { useRouter, usePathname, useSearchParams } from 'next/navigation'

export function NavComponent() {
  const router = useRouter()
  const pathname = usePathname()
  const searchParams = useSearchParams()

  return (
    <button onClick={() => router.push('/dashboard')}>
      Ir al dashboard
    </button>
  )
}

Importar de next/router en App Router simplemente no funciona. No te da error claro, solo se rompe en formas misteriosas.

4. Variables de entorno y el servidor

En Pages Router, tenías NEXT_PUBLIC_ para el cliente y sin prefijo para el servidor. Sigue siendo así, pero con un detalle: en Server Components podés usar variables de servidor directamente. En Client Components, solo las NEXT_PUBLIC_.

// Server Component - OK
const secret = process.env.DATABASE_URL // ✅

// Client Component - NUNCA hagas esto
const secret = process.env.DATABASE_URL // undefined, y si no fuera undefined, sería una filtración de seguridad brutal

La migración incremental que recomiendo

No migrés todo de una. Next.js te deja tener /pages y /app coexistiendo. La estrategia que funcionó para mí:

Primero los layouts — reemplazá el _app.tsx y _document.tsx con el layout.tsx raíz
Después las páginas estáticas — las que no tienen data fetching complejo
Luego las páginas con fetch — migrá el data fetching a Server Components
Al final la autenticación — es lo más complicado, dejalo para cuando entendés bien el modelo

Cada paso lo podés deployar. Cada paso lo podés testear. No intentés hacer todo de una noche para los lunes.

¿Vale la pena?

Sí. Rotundamente.

Mis métricas antes y después en el proyecto de e-commerce: el Time to First Byte bajó de 340ms a 89ms. El Largest Contentful Paint de 3.2s a 1.1s. El bundle de JavaScript del cliente se redujo un 60% porque la mayoría de los componentes de listado ahora son Server Components.

El cliente ni sabe lo que es App Router, pero me escribió para decirme que la tienda "se siente más rápida". Eso vale todas las noches de debugging.

La curva de aprendizaje es real y duele. Pero una vez que internalizás el modelo mental — servidor por defecto, cliente por excepción, datos cerca de donde se consumen — escribir aplicaciones React se vuelve más limpio que nunca.

Ahora cuando arranco un proyecto nuevo, ya no me imagino volviendo a Pages Router. Es como volver a usar jQuery después de aprender React. Técnicamente funciona. Pero sabés que existe algo mejor.

Este artículo fue publicado originalmente en juanchi.dev

Metí un LLM chico adentro de una app Next.js y esto fue lo que aprendí

Juan Torchia — Tue, 07 Apr 2026 00:20:31 +0000

Eran las 2am y Chrome me estaba mostrando 4.2GB de RAM usados en una sola pestaña. El modelo llevaba 47 segundos "pensando" una respuesta de tres palabras. Yo miraba la pantalla con esa mezcla de fascinación y horror que solo te da la tecnología cuando funciona y no funciona al mismo tiempo. Esto es lo que pasó cuando decidí meter un LLM chico adentro de una app Next.js.

LLM pequeño en el browser: qué promete, qué entrega

Cuando vi el thread de Show HN con 836 puntos sobre LLMs tiny corriendo directo en el browser, lo primero que pensé fue: esto tiene que entrar en mi stack. Después vi el de Gemma con 141 puntos. La idea es simple y poderosa: inferencia local, sin API keys, sin latencia de red, sin costos por token. Privacidad de verdad.

El concepto técnico es concreto: modelos cuantizados (GGUF, int4, int8) que bajan de 7B parámetros a territorios manejables — 1B, 500M, incluso menos — y corren en WebAssembly o WebGPU directamente en el browser. Sin servidor, sin Claude, sin OpenAI. Solo el cliente y el modelo.

Suena hermoso. Y en parte lo es. Pero hay un abismo entre el demo de Show HN y meterlo en producción en una app real.

El setup real: Next.js, WebLLM y el primer encontronazo con la realidad

Empecé con WebLLM de MLC AI — la librería más madura para esto. El approach es WebGPU cuando está disponible, con fallback a WebAssembly. El modelo que elegí: Gemma-2B-it-q4f32_1, que en teoría pesa ~1.5GB.

# Instalación — lo más fácil de todo el proceso
npm install @mlc-ai/web-llm

El primer problema apareció antes de escribir una sola línea de lógica de negocio.

// app/components/LocalLLM.tsx
'use client' // Crítico — todo esto vive en el cliente

import { CreateMLCEngine, MLCEngine } from '@mlc-ai/web-llm'
import { useState, useEffect, useRef } from 'react'

// El modelo que elegí tras varios intentos fallidos
const MODEL_ID = 'Gemma-2B-it-q4f32_1-MLC'

export function LocalLLM() {
  const engineRef = useRef<MLCEngine | null>(null)
  const [status, setStatus] = useState<'idle' | 'loading' | 'ready' | 'error'>('idle')
  const [progress, setProgress] = useState(0)
  const [response, setResponse] = useState('')

  const initEngine = async () => {
    setStatus('loading')

    try {
      // Esto descarga ~1.5GB la primera vez — el usuario necesita saberlo
      engineRef.current = await CreateMLCEngine(MODEL_ID, {
        initProgressCallback: (report) => {
          // El progreso viene en texto, no en número — hay que parsearlo
          const match = report.text.match(/(\d+\.\d+)%/)
          if (match) setProgress(parseFloat(match[1]))
        }
      })

      setStatus('ready')
    } catch (error) {
      // Acá entra si el browser no soporta WebGPU
      // Safari en iOS: directo a error
      console.error('Engine init falló:', error)
      setStatus('error')
    }
  }

  const runInference = async (prompt: string) => {
    if (!engineRef.current) return

    const reply = await engineRef.current.chat.completions.create({
      messages: [{ role: 'user', content: prompt }],
      // Sin esto, espera a tener TODA la respuesta antes de mostrarte algo
      stream: true,
    })

    // Streaming en el browser — lo mejor del experimento
    for await (const chunk of reply) {
      const delta = chunk.choices[0]?.delta?.content || ''
      setResponse(prev => prev + delta)
    }
  }

  return (
    // UI básica para el experimento
    <div>
      {status === 'idle' && (
        <button onClick={initEngine}>Cargar modelo (~1.5GB)</button>
      )}
      {status === 'loading' && <p>Descargando: {progress.toFixed(1)}%</p>}
      {status === 'ready' && (
        <button onClick={() => runInference('Explicá qué es una red neuronal en 2 oraciones')}>Inferir</button>
      )}
      {response && <p>{response}</p>}
    </div>
  )
}

Esto funcionó. Primer token apareció. Me emocioné.

Después miré el task manager.

Dónde se rompe todo — los límites que nadie cuenta en los demos

El tutorial feliz termina cuando el primer token aparece en pantalla. El experimento real empieza ahí.

Problema 1: La descarga inicial es un UX nightmare

1.5GB en la primera visita. Sin cache service worker configurado, eso se baja cada vez que el browser limpia la cache. Con cache, el modelo vive en IndexedDB del browser — que en Safari tiene límites agresivos de almacenamiento.

WebLLM usa Cache API del browser automáticamente, pero la UX de "espere mientras descarga 1.5GB" no existe en ningún producto que hayas usado en tu vida. Tuve que construir una pantalla de progress desde cero.

Problema 2: Memoria — el número que asusta

Gemma 2B cuantizado a int4 promete ~1GB de RAM. En la práctica vi picos de 3-4GB en Chrome durante la carga inicial. Por qué: el proceso de inicialización carga el modelo completo antes de moverlo a la GPU. En dispositivos con menos de 8GB disponibles, es ruleta rusa.

En mobile: directo no. iOS Safari no tiene WebGPU estable. Android Chrome funciona en algunos Pixel, es impredecible en el resto.

Problema 3: La latencia real vs. la latencia de demo

En una M2 MacBook con WebGPU: 8-12 tokens/segundo. Decente.
En un i7 de 2019 sin GPU dedicada (WebAssembly fallback): 0.8-1.2 tokens/segundo. Unusable.
En el server de Railway (CPU): no tiene sentido — para eso usás una API.

El demo de Show HN corrió en el setup perfecto. El usuario promedio de tu app no tiene ese setup.

Problema 4: Next.js y el SSR que rompe todo

// Este import explota en el servidor — WebGPU no existe en Node
import { CreateMLCEngine } from '@mlc-ai/web-llm'

// La solución: dynamic import con ssr: false
import dynamic from 'next/dynamic'

const LocalLLM = dynamic(
  () => import('./components/LocalLLM'),
  { 
    ssr: false, // Sin esto, Railway tira error en build
    loading: () => <p>Cargando interfaz de inferencia...</p>
  }
)

Esto lo aprendí de una manera. Build exitoso, deploy en Railway, pantalla blanca. Tres horas después, ssr: false. Sobre cómo deployar en Railway y las optimizaciones de Next.js que importan, ya escribí antes — pero el ssr: false para WebGPU es un caso que no vi documentado en ningún lado.

Problema 5: El modelo es chico — y se nota

Gemma 2B es impresionante para su tamaño. Pero cuando lo comparás con GPT-4o o Claude, la diferencia en razonamiento es un cañón. Para tasks simples — clasificación, resumen corto, extracción de entidades — funciona bien. Para cualquier cosa que requiera razonamiento complejo, se nota el límite.

Esto no es crítica al modelo. Es calibrar expectativas: es un 2B corriendo cuantizado en un browser. La pregunta correcta no es "¿es tan bueno como GPT-4?" sino "¿alcanza para mi caso de uso específico?".

El momento en que decidí si valía la pena

Después de tres días de experimento, me senté a hacer el análisis frío. Tengo el hábito de pensar en el stack desde la perspectiva del proyecto, no desde el entusiasmo de la tecnología.

Casos donde SÍ lo usaría:

Herramienta interna donde controlás el hardware del usuario (siempre Chrome en desktop potente)
Feature de privacidad como diferencial de producto — procesar texto sensible sin mandarlo a un servidor
Offline-first apps donde la latencia de API es el killer
Prototipos y demos donde el WOW factor importa más que la performance consistente

Casos donde NO lo usaría:

App pública con base de usuarios heterogénea en dispositivos
Cualquier cosa donde la velocidad de respuesta sea crítica
Cuando el modelo chico no alcanza para la tarea (la mayoría de los casos de producción)

La conclusión honesta: es una tecnología en la que voy a seguir mirando, pero que hoy tiene un año o dos para madurar antes de que la meta en algo que use gente real sin que yo controle su hardware. Los patrones TypeScript que uso para abstraer estas decisiones me sirvieron para encapsular esto como un feature flag — el componente existe, está apagado por default, lo prendo solo en contextos donde sé que va a funcionar.

En juanchi.dev lo tengo como experimento en una ruta separada, no como feature principal. Ese es el lugar correcto para esto hoy.

FAQ — Lo que me preguntarían si contara esto en una charla

¿Qué diferencia hay entre correr un LLM en el browser vs. en el edge (Cloudflare Workers, Vercel Edge)?

Son dos cosas distintas. Browser inference = WebGPU/WASM, corre en la máquina del usuario, sin servidor. Edge inference = el modelo corre en el servidor edge, con acceso a GPU limitado (Cloudflare tiene acceso experimental a modelos vía Workers AI). El browser es más privado y no tiene costos de cómputo para vos, pero depende totalmente del hardware del usuario. Edge te da más control sobre la latencia y el modelo, pero tiene costos y los modelos disponibles son limitados.

¿Cuánto pesa el modelo más chico que funciona para algo útil?

En mi experimento, el mínimo viable para tareas de lenguaje natural razonables fue Gemma 2B cuantizado (~1.5GB descarga). Existen modelos más chicos — Phi-3 mini 3.8B es sorprendentemente bueno, y hay variantes de 500M params para clasificación — pero para generación de texto libre, bajás de 1B y la calidad cae cliff-edge. El tamaño del archivo no es el único número: importa la arquitectura y el fine-tuning del modelo.

¿Esto reemplaza usar la API de OpenAI o Anthropic?

No, y no creo que lo haga en el corto plazo para la mayoría de los casos. La diferencia de capacidad entre un 2B local y GPT-4o es enorme. Lo que sí puede reemplazar: tareas simples de NLP donde hoy pagás por millones de tokens para cosas que no necesitan razonamiento complejo — clasificación de sentimiento, extracción de keywords, resúmenes cortos. Para eso, un modelo local tiene sentido económico y de privacidad.

¿WebGPU ya está listo para producción?

Depende de tu definición de producción. En Chrome 113+ en desktop: sí, estable. Firefox: disponible pero más lento. Safari macOS: disponible desde Safari 18. iOS Safari: en progreso, inconsistente. Android Chrome: disponible en dispositivos modernos, impredecible en gama media-baja. Si tu app tiene usuarios en múltiples browsers y dispositivos, necesitás un fallback robusto a WebAssembly y necesitás comunicarle al usuario que la experiencia va a ser más lenta.

¿Se puede hacer streaming de la respuesta o hay que esperar al completion completo?

Sí, WebLLM soporta streaming nativo con la misma interfaz de OpenAI (stream: true). De hecho, el streaming es casi obligatorio — sin él, el usuario ve pantalla en blanco durante 30-60 segundos y después aparece todo el texto junto. Con streaming, el primer token aparece en 2-5 segundos y la respuesta va fluyendo. La diferencia en UX es abismal. Lo implementé con el mismo patrón de for await que uso con la API de Anthropic.

¿Vale la pena para un side project o es solo para grandes empresas con recursos?

Para un side project es perfecto — justamente porque no tenés que pagar por API calls. El costo real es el tiempo de setup y el entender los límites. Si hacés una herramienta de nicho donde podés asumir que tus usuarios tienen hardware decente (pensá: una extensión de Chrome para developers, una herramienta para diseñadores en desktop), el caso de uso encaja bien. Para una app consumer con usuarios heterogéneos, esperaría 12-18 meses más.

Conclusión: la tecnología está, la madurez no tanto

Lo que me llevo de tres días de experimento es esto: la inferencia en el browser funciona. No es marketing, no es smoke and mirrors. Vos podés meter Gemma en una pestaña de Chrome y hacer preguntas y obtener respuestas, sin mandar nada a ningún servidor. Eso es genuinamente notable.

Pero hay un salto grande entre "funciona" y "está listo para usuarios reales". Los 1.5GB de descarga inicial, la dependencia de WebGPU, la variabilidad brutal entre dispositivos — eso son problemas de producto, no solo de implementación técnica.

Mi lectura: es el momento perfecto para aprender esto, demasiado pronto para meterlo en producción mainstream. Lo tengo en radar activo, con código funcionando, esperando que el ecosistema madure. En 2026 vuelvo a esta pregunta y apuesto a que la respuesta va a ser diferente.

Si querés reproducir el experimento, el código está en mi repo y las notas de este post son el mapa honesto de dónde vas a gastar el tiempo.

Este artículo fue publicado originalmente en juanchi.dev

Claude Code se rompió con las actualizaciones de febrero — y yo también lo sentí

Juan Torchia — Tue, 07 Apr 2026 00:20:23 +0000

¿Cuándo fue la última vez que escribiste un componente complejo de cero, sin que una IA te sugiriera la estructura? Hacé memoria. Yo lo intenté la semana pasada y tardé el doble de lo normal. No porque hubiera olvidado cómo hacerlo — sino porque mi cerebro buscaba el autocompletado que no llegaba.

Eso me asustó más que cualquier bug en producción.

Todo empezó con un thread en Hacker News. 702 puntos, que en HN no es poco. El título era algo así como "Claude Code has gotten significantly worse" y los comentarios eran un desfile de desarrolladores diciendo exactamente lo que yo había estado sintiendo pero no me había animado a articular: la herramienta que habían integrado en su flujo de trabajo en diciembre empezó a comportarse raro en febrero. Respuestas más genéricas. Menos contexto retenido. Código que antes generaba casi perfecto ahora llegaba con errores obvios que antes nunca aparecían.

Yo lo había notado. Y había hecho lo más humano posible: lo ignoré y seguí adelante.

Claude Code updates febrero 2025: qué cambió (y qué se rompió)

Antes de entrar en lo emocional, vamos a lo técnico. Porque hubo cambios reales.

La percepción general del thread — y la mía propia — es que Anthropic hizo ajustes en el modelo entre enero y febrero que afectaron el comportamiento en tareas de ingeniería complejas. No hay changelog público detallado (gracias, Anthropic), pero los patrones que reporta la comunidad son consistentes:

Lo que dejó de funcionar bien:

Contexto de proyectos grandes: en repos con más de 50 archivos, empezó a perder el hilo de dependencias entre módulos
Refactoring incremental: antes podías decirle "refactorizá este hook manteniendo la interfaz" y lo hacía perfecto; ahora a veces rompe contratos de tipos sin avisar
Debugging con stack traces complejos: se volvió más genérico, menos quirúrgico
Consistencia de estilo: en sesiones largas empezaba a mezclar patterns distintos en el mismo archivo

Lo que siguió funcionando (o mejoró):

Tareas de escritura y documentación
Preguntas de arquitectura de alto nivel
Generación de tests unitarios simples
Explicar código ajeno

En mi caso concreto, lo sentí más en el trabajo de performance y optimización que venía haciendo en proyectos Next.js. Le pedía análisis de bundle, sugerencias de lazy loading, identificación de re-renders innecesarios. Antes llegaba con análisis precisos y código funcional. En febrero empezó a darme respuestas correctas pero... vacías. Como cuando le preguntás a alguien algo y te contesta bien pero notás que no lo pensó.

// Lo que le pedía en enero — llegaba bien:
// "Analizá este componente y decime qué está causando re-renders innecesarios"

const MiComponente = ({ data, onUpdate }: Props) => {
  // Claude identificaba que esta función se recreaba en cada render
  // y sugería useCallback con las dependencias correctas
  const handleClick = () => onUpdate(data.id)

  return <Button onClick={handleClick}>Actualizar</Button>
}

// Lo que empezó a pasar en febrero:
// Misma pregunta → respuesta genérica sobre "usar useCallback y useMemo"
// Sin analizar el código específico. Sin ver que onUpdate ya era estable.
// Solución correcta en abstracto, incorrecta en contexto.

Esa diferencia parece pequeña. No lo es. La mitad del valor de una IA en el flujo de desarrollo está en que entiende TU contexto, no en que sabe los conceptos generales. Los conceptos generales ya los sé yo.

La pregunta que no quería hacerme

Acá es donde el post se pone incómodo. Para mí, no para vos.

Cuando Claude Code empezó a fallar, mi primer instinto fue frustración con la herramienta. Busqué el thread de HN para validar que no era yo. Encontré 702 personas diciéndome que tenía razón. Me sentí mejor.

Y después me cayó la ficha.

Había pasado los últimos dos meses construyendo juanchi.dev y varios proyectos paralelos con Claude Code como co-piloto permanente. No solo para boilerplate — eso es lo que todos admiten. Lo usaba para decisiones de arquitectura. Para elegir entre patterns. Para debuggear lógica compleja. Para validar si mi approach tenía sentido.

La pregunta que no quería hacerme: ¿estaba yo escribiendo código, o estaba aprobando código ajeno?

No es lo mismo. Y la diferencia importa.

Cursé Ciencias de la Computación en la UBA mientras laburaba full time. Había materias donde llegaba directo del trabajo con el traje puesto. Aprobé Análisis II en el cuarto intento. Eso me dio algo que no se consigue fácil: la capacidad de sostener un problema difícil en la cabeza el tiempo suficiente como para realmente entenderlo. No para googlear la solución. Para entenderlo.

Y en algún momento de los últimos meses, sin que me diera cuenta, había empezado a cortocircuitar ese proceso. Le llevaba el problema a Claude Code antes de haberlo pensado yo solo el tiempo suficiente. El resultado era más rápido. Y más superficial.

// Patrón que empecé a detectar en mi propio código de febrero:
// Código que "funciona" pero que yo no podría explicar completamente
// si alguien me preguntara en una code review por qué hice ESTO
// y no AQUELLO.

// Ejemplo anónimo — no es de un proyecto real pero representa el pattern:
const useDataSync = <T extends Record<string, unknown>>(
  // ¿Por qué este constraint específico? Claude lo sugirió.
  // ¿Tiene sentido? Sí. ¿Lo hubiera elegido yo? No sé.
  key: string,
  fetcher: () => Promise<T>,
  options?: SyncOptions
) => {
  // Lógica que funciona.
  // Que entiendo si la leo.
  // Que no estoy seguro de haber *diseñado*.
}

Hay una diferencia entre entender código y haberlo diseñado. La segunda te da intuición. La primera, solo comprensión.

Los errores que cometí (y que probablemente estés cometiendo)

Sin juzgar — porque yo caí en todos estos:

1. Usar la IA antes de pensar, no después
El flujo correcto: pensás el problema, tenés una hipótesis, usás la IA para validarla o explorar alternativas. El flujo que adopté sin querer: abrís Claude Code y describís el problema esperando que te dé la dirección. El segundo es más rápido a corto plazo y más caro a largo plazo.

2. No cuestionar el código generado con suficiente rigor
Cuando el código funciona, el incentivo para entender por qué funciona desaparece. En el stack que uso hoy — Next.js, TypeScript, PostgreSQL — hay suficiente complejidad como para que esto te pase factura eventualmente.

3. Confundir velocidad con productividad
Sí, estaba shipeando más rápido. ¿Pero cuánta deuda técnica invisible estaba acumulando? ¿Cuántas decisiones de arquitectura había delegado sin registrarlas mentalmente?

4. No mantener el músculo
Este es el más jodido. Las habilidades técnicas son literalmente musculares — si no las ejercitás, se atrofian. Yo vengo de 30 años con la tecnología, diagnostiqué cortes de red en un cyber a las 11pm, tiré un servidor de producción con rm -rf en mi primera semana de trabajo. Ese background me da criterio. Pero el criterio también se oxida.

5. Olvidar que la IA optimiza para coherencia local, no para arquitectura global
Este es el error técnico más concreto. Claude Code es muy bueno generando código que es localmente correcto. Es menos bueno manteniendo consistencia arquitectural a través de un proyecto grande. Eso requiere que vos tengas el mapa mental del sistema completo. Si terciarizás ese mapa, perdés el timón.

FAQ: Claude Code, las actualizaciones de febrero y el elefante en el cuarto

¿Claude Code realmente se deterioró en febrero 2025 o es percepción?
Es una pregunta legítima y honesta. Anthropic no publicó un changelog detallado de los cambios al modelo. Lo que existe es evidencia anecdótica consistente de muchos desarrolladores — el thread de HN con 702 puntos es la punta del iceberg. Mi experiencia personal coincide con los patrones reportados: degradación en tareas complejas de ingeniería, no en tareas simples. ¿Podría ser placebo colectivo? En teoría sí. En práctica, cuando 700 personas describen el mismo patrón específico, algo pasó.

¿Sigue valiendo la pena usar Claude Code después de esto?
Sí, con ajustes. El deterioro es real pero parcial — sigue siendo muy útil para ciertas tareas. La clave es ser más intencional sobre cuándo lo usás y para qué. Yo volví a usarlo, pero cambié el workflow: primero pienso yo, después lo consulto. Antes era al revés.

¿Cómo sé si estoy dependiendo demasiado de la IA en mi trabajo?
Hacé este test: tomá un problema de complejidad media de tu trabajo actual e intentá resolverlo sin ninguna IA, en el tiempo que normalmente te llevaría. Si tardás mucho más o te sentís perdido, es una señal. Otro indicador: ¿podés explicar todas las decisiones de diseño del código que mandaste a producción en el último mes? ¿O hay partes donde dirías "Claude lo sugirió y funcionó"?

¿Esto aplica solo a Claude Code o a GitHub Copilot y otros también?
Aplica a todos, pero el vector de riesgo varía. Copilot tiene más presencia en el autocompletado granular — el riesgo es más sobre patrones micro. Claude Code (y similar: ChatGPT en modo coding, Cursor) tiene más presencia en decisiones de arquitectura y lógica compleja — el riesgo es más sobre el diseño macro del sistema. Los dos son reales, los dos requieren atención.

¿Debería dejar de usar IA para programar?
No. Esa conclusión sería tan incorrecta como la dependencia total. La IA es una herramienta genuinamente poderosa — el trabajo de TypeScript con patterns avanzados que hago sería más lento sin ella. La pregunta no es si usarla, sino cómo mantener tu propio criterio técnico activo mientras la usás. Es la misma tensión que existe con Stack Overflow desde hace 15 años, pero amplificada por un orden de magnitud.

¿Las actualizaciones de Anthropic van a mejorar esto?
Probablemente sí, para el deterioro específico de febrero. Anthropic itera rápido. Pero el problema estructural que describe esta reflexión — la dependencia cognitiva — no lo resuelve ninguna actualización del modelo. Ese es tu problema, no el de ellos.

Conclusión: el deterioro de la herramienta como servicio

Cuando Claude Code empezó a fallar, la reacción sana hubiera sido usarlo menos y pensar más. Mi reacción inicial fue buscar validación en HN y esperar que Anthropic lo arreglara.

Lo segundo va a pasar. Lo primero dependía de mí.

Lo que me llevo de este episodio es una regla nueva en mi workflow: la IA entra al proceso después de que yo tengo una hipótesis propia, no antes. No es una regla anti-IA — es una regla pro-criterio. El valor que le aporto a los proyectos que construyo no es solo que sé usar las herramientas. Es que tengo 30 años de intuición técnica acumulada sobre qué funciona y qué explota a las 11pm con el local lleno.

Esa intuición no se delega. Se ejerce.

Y sí — cuando Anthropic arregle el modelo y Claude Code vuelva a estar en su mejor forma, voy a seguir usándolo. Pero con el músculo propio un poco más activo que antes.

El deterioro de febrero me hizo un favor que no pedí.

Este artículo fue publicado originalmente en juanchi.dev

El stack tecnológico perfecto en 2025: lo que elegiría si arrancara un proyecto hoy

Juan Torchia — Tue, 07 Apr 2026 00:19:59 +0000

El stack tecnológico perfecto en 2025: lo que elegiría si arrancara un proyecto hoy

Son las 2 de la mañana. Tengo tres pestañas con documentación de frameworks que existían hace seis meses y ya tienen un sucesor. Hay un hilo de 200 respuestas en X donde la gente se pelea por si usar Bun o Node. Y yo, con el mate frío al lado, tomé una decisión: me bajo del carrusel del hype y te cuento qué elegiría hoy si tuviera que arrancar un proyecto desde cero.

No es un tutorial. Es una opinión. Fuerte, con fundamentos, y con los errores propios que la sostienen.

Por qué importa elegir bien el stack tecnológico en 2025

Elegir un stack tecnológico en 2025 no es lo mismo que elegir zapatillas. Una mala elección de stack te persigue durante años. Te lo digo por experiencia: en 2021 arranqué un proyecto con Create React App porque "era lo que conocía" y en 2023 estaba migrando a Vite con la misma energía con que uno muda un departamento después de una ruptura — doloroso, inevitable, y con cosas que directamente terminan en la basura.

El ecosistema de hoy tiene una trampa sutil: hay demasiadas opciones buenas. Y eso paraliza. Entonces lo que hago acá es simple: te digo qué elegiría yo, por qué, y qué descarté con argumentos concretos.

El stack: la decisión

Voy directo:

Frontend: Next.js 15 con App Router
Lenguaje: TypeScript en todo
Estilos: Tailwind CSS v4
Base de datos: PostgreSQL
ORM: Drizzle ORM
Auth: Auth.js (NextAuth v5)
Deploy: Vercel para frontend, Railway o Fly.io para backend/DB
Containerización: Docker para desarrollo local
Testing: Vitest + Playwright

Eso es todo. Sin microservicios desde el día uno, sin Kubernetes hasta que de verdad lo necesites, sin event sourcing para una app que tiene doce usuarios.

Next.js 15: el centro de todo

Next.js es el framework que más veces me hizo decir "esto está buenísimo" y "esto me quiero matar" en el mismo día. Pero después de trabajar con él en serio, con el App Router desde que salió en versión estable, llegué a la conclusión de que nada más se le acerca para proyectos full-stack en 2025.

El App Router cambió todo. El modelo mental de Server Components vs Client Components al principio parece una abstracción innecesaria, pero cuando lo entendés, es como cuando aprendiste a andar en bicicleta: no podés creer que alguna vez hayas pensado diferente.

// app/productos/[id]/page.tsx
// Este componente corre en el servidor. Zero JS al cliente.
import { db } from '@/lib/db'
import { productos } from '@/lib/schema'
import { eq } from 'drizzle-orm'

interface Props {
  params: { id: string }
}

export default async function ProductoPage({ params }: Props) {
  const producto = await db
    .select()
    .from(productos)
    .where(eq(productos.id, parseInt(params.id)))
    .limit(1)

  if (!producto.length) return <div>No encontrado</div>

  return (
    <article>
      <h1>{producto[0].nombre}</h1>
      <p>{producto[0].descripcion}</p>
    </article>
  )
}

Eso es una query directa a la base de datos desde un componente de React. Sin API route, sin fetch, sin loading states innecesarios. El HTML llega renderizado al browser. Esto en 2020 requería un backend separado, un endpoint REST, manejo de estados de carga... Era una locura.

TypeScript: no es opcional en 2025

En 2022 todavía discutía con gente si TypeScript valía la pena. En 2025, esa discusión me parece arqueológica. TypeScript no es "más trabajo" — es descubrir los bugs antes de que los descubra el cliente.

El momento en que me convertí fue en un proyecto de e-commerce donde teníamos una función que recibía el objeto de un pedido. Sin tipos, nadie sabía qué campos existían. Todos mirábamos la base de datos o el código anterior para saber qué tenía ese objeto. Con TypeScript:

interface Pedido {
  id: string
  userId: string
  items: Array<{
    productoId: string
    cantidad: number
    precioUnitario: number
  }>
  estado: 'pendiente' | 'pagado' | 'enviado' | 'cancelado'
  creadoEn: Date
}

function calcularTotal(pedido: Pedido): number {
  return pedido.items.reduce(
    (acc, item) => acc + item.cantidad * item.precioUnitario,
    0
  )
}

Ahora el IDE te dice exactamente qué podés hacer con ese objeto. Si alguien agrega un campo nuevo a la interfaz, TypeScript te avisa en todos los lugares donde eso importa. Eso es productividad real.

Drizzle ORM: el ORM que no te esconde SQL

Acá es donde me voy a ganar algunos enemigos: Prisma está sobrevalorado.

Prisma es fantástico para empezar, la documentación es excelente, y el developer experience inicial es impecable. Pero cuando empezás a necesitar queries complejas, te encontrás luchando contra el ORM en lugar de trabajar con él. El cliente de Prisma es una capa de abstracción que a veces hace magia negra con el SQL generado y cuando algo falla, debuggear es una pesadilla.

Drizzle es diferente. Drizzle es "SQL pero con tipos". La API está diseñada para que sepas exactamente qué query se está ejecutando:

// lib/schema.ts
import { pgTable, serial, text, timestamp, integer } from 'drizzle-orm/pg-core'

export const usuarios = pgTable('usuarios', {
  id: serial('id').primaryKey(),
  email: text('email').notNull().unique(),
  nombre: text('nombre').notNull(),
  creadoEn: timestamp('creado_en').defaultNow()
})

export const pedidos = pgTable('pedidos', {
  id: serial('id').primaryKey(),
  usuarioId: integer('usuario_id').references(() => usuarios.id),
  total: integer('total').notNull(),
  estado: text('estado').notNull().default('pendiente')
})

// Uso en cualquier Server Component o Server Action
const usuariosConPedidos = await db
  .select({
    usuario: usuarios,
    cantidadPedidos: count(pedidos.id)
  })
  .from(usuarios)
  .leftJoin(pedidos, eq(pedidos.usuarioId, usuarios.id))
  .groupBy(usuarios.id)
  .where(gt(count(pedidos.id), 0))

Sabés qué SQL se ejecuta. Tenés autocompletado completo. Si el esquema cambia, TypeScript te rompe donde hay inconsistencias. Es la combinación perfecta entre control y ergonomía.

PostgreSQL: aburrido y perfecto

No, no voy a usar MongoDB. Ya lo usé. Ya migré de MongoDB a PostgreSQL en un proyecto que creció. Fue horrible.

PostgreSQL en 2025 hace todo: JSON nativo si necesitás flexibilidad, full-text search, extensiones como pgvector para embeddings de IA, transacciones ACID reales. Es la base de datos que escala desde tu laptop hasta millones de usuarios sin que tengas que reaprender nada.

El único argumento real a favor de MongoDB hoy es "mi equipo lo conoce mejor" — y ese argumento tiene fecha de vencimiento.

Lo que descarté y por qué

Remix: Me encanta el modelo mental de Remix. Las loaders y actions son elegantes. Pero el ecosistema es más chico, la integración con el mundo React es más friccionosa, y Vercel está invirtiendo en Next.js de una manera que hace que sea difícil competir en velocidad de features. Si Shopify sigue apostando fuerte a Remix, lo reevalúo.

SvelteKit: Svelte es un placer de escribir. En serio. Pero el mercado laboral y la cantidad de librerías disponibles para React no tienen comparación. Si estoy solo en un proyecto, quizás. Con un equipo, no puedo pedirle a todos que aprendan Svelte.

tRPC: Lo usé, me gustó, pero con Next.js App Router y Server Actions, la fricción de montar tRPC se justifica cada vez menos. Las Server Actions con TypeScript te dan type safety end-to-end sin la infraestructura extra:

// app/actions/pedidos.ts
'use server'
import { db } from '@/lib/db'
import { pedidos } from '@/lib/schema'

export async function crearPedido(data: {
  usuarioId: number
  items: Array<{ productoId: number; cantidad: number }>
}) {
  // Validación, lógica de negocio, escritura a DB
  const [nuevoPedido] = await db
    .insert(pedidos)
    .values({ usuarioId: data.usuarioId, estado: 'pendiente', total: 0 })
    .returning()

  return nuevoPedido
}

Eso se llama desde un Client Component con await crearPedido(data) y TypeScript garantiza que los tipos sean correctos de punta a punta. tRPC resuelto.

Bun como runtime en producción: Bun es increíblemente rápido. Lo uso para correr tests y scripts localmente y es un placer. Pero para producción en 2025, todavía me quedo con Node. El ecosistema, la estabilidad comprobada, y la cantidad de artículos de troubleshooting disponibles cuando algo sale mal a las 3am siguen siendo argumentos sólidos.

El entorno de desarrollo: Docker sí, pero con criterio

Docker para desarrollo local es indispensable. No instales PostgreSQL directamente en tu máquina. No le pidas a tu equipo que instale Redis de forma nativa. Un docker-compose.yml sencillo resuelve todo:

# docker-compose.yml
services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: dev
      POSTGRES_PASSWORD: dev
      POSTGRES_DB: miapp
    ports:
      - '5432:5432'
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    ports:
      - '6379:6379'

volumes:
  postgres_data:

docker compose up -d y tenés tu entorno listo. Cualquier persona del equipo clona el repo, corre ese comando, y está. No hay "en mi máquina funciona".

El elefante en la habitación: ¿y la IA?

Todo stack en 2025 tiene que tener una respuesta para IA generativa. La mía es: empieza simple.

Vercel AI SDK con cualquier modelo de OpenAI o Anthropic es suficiente para el 90% de los casos de uso. pgvector en PostgreSQL para embeddings. No necesitás Pinecone, no necesitás una base de datos vectorial especializada hasta que tengas un problema de escala real que justifique la complejidad.

La conclusión que nadie quiere escuchar

El mejor stack tecnológico en 2025 no es el más nuevo, no es el más performante en benchmarks sintéticos, y no es el que tiene más estrellas en GitHub esta semana. Es el que te permite entregar — con calidad, con mantenibilidad, con un equipo que puede sumarse rápido.

Next.js + TypeScript + PostgreSQL + Drizzle es mi respuesta a esa pregunta hoy. El año que viene puede cambiar. Pero si cambia, va a ser porque algo fundamentalmente mejor apareció — no porque me convencieron con un thread de Twitter con gráficos bonitos.

Arrancá a construir. Los benchmarks son para las charlas de conferencia. El código que llega a producción es el que importa.

Este artículo fue publicado originalmente en juanchi.dev

TypeScript: los patrones que realmente uso todos los días

Juan Torchia — Tue, 07 Apr 2026 00:19:51 +0000

Hay un momento específico en tu relación con TypeScript donde dejás de pelearle y empezás a entenderlo. Para mí fue a las 2AM de un martes, con un bug de producción que hubiera sido imposible con tipos bien definidos. Desde ese momento cambié cómo pienso el código.

Esto no es un tutorial de introducción. Si todavía estás peleando con interface vs type, hay mil artículos para eso. Esto es lo que realmente tengo en mi cabeza cuando programo en TypeScript hoy — los patrones que uso sin pensar, los que me salvaron el culo más de una vez y los errores que cometí antes de entenderlos.

Discriminated Unions: el patrón que más uso

Si tuviera que quedarme con un solo patrón de TypeScript, es este. La idea es simple: tenés un tipo unión donde cada variante tiene una propiedad discriminante — generalmente type o kind — que le dice a TypeScript exactamente con qué estás trabajando.

type ApiResponse<T> =
  | { status: 'loading' }
  | { status: 'error'; error: string; code: number }
  | { status: 'success'; data: T; timestamp: Date };

function renderUser(response: ApiResponse<User>) {
  switch (response.status) {
    case 'loading':
      return <Spinner />;
    case 'error':
      // TypeScript sabe que acá existe response.error y response.code
      return <ErrorMessage message={response.error} code={response.code} />;
    case 'success':
      // TypeScript sabe que acá existe response.data y response.timestamp
      return <UserCard user={response.data} />;
  }
}

Lo que me encanta de esto es que TypeScript te avisa si te olvidás un caso. Agregás 'cancelled' a la unión y de repente el compilador te dice exactamente dónde tenés que manejar esa situación. Es como tener un colega que revisa tu código sin ser molesto.

Lo uso en eventos de dominio, estados de UI, resultados de operaciones asíncronas. En un proyecto de e-commerce que hice el año pasado, modelé todos los estados de un pedido así:

type OrderState =
  | { kind: 'draft'; items: CartItem[] }
  | { kind: 'pending_payment'; orderId: string; total: Money }
  | { kind: 'paid'; orderId: string; paymentId: string; paidAt: Date }
  | { kind: 'shipped'; orderId: string; trackingCode: string }
  | { kind: 'delivered'; orderId: string; deliveredAt: Date }
  | { kind: 'cancelled'; orderId: string; reason: string };

Cada estado tiene exactamente la información que tiene sentido para ese estado. No hay campos opcionales raros, no hay trackingCode: string | null que no sabés si es null porque no fue enviado o porque es un pedido viejo. La forma del tipo es la documentación.

Branded Types: cuando `string` no alcanza

Este me costó más entenderlo pero hoy no puedo vivir sin él. El problema es simple: userId: string y productId: string son el mismo tipo para TypeScript, pero no para tu negocio. Mezclarlos es un bug.

// Sin branded types — TypeScript no se queja de esto:
function getUser(id: string) { /* ... */ }
function getProduct(id: string) { /* ... */ }

const productId = '123';
getUser(productId); // TypeScript dice que está bien. Está mal.

La solución con branded types:

type Brand<T, B> = T & { readonly __brand: B };

type UserId = Brand<string, 'UserId'>;
type ProductId = Brand<string, 'ProductId'>;
type OrderId = Brand<string, 'OrderId'>;

// Funciones constructoras que validan y brandean
function createUserId(id: string): UserId {
  if (!id.match(/^usr_[a-z0-9]+$/)) {
    throw new Error(`Invalid user ID format: ${id}`);
  }
  return id as UserId;
}

function getUser(id: UserId): Promise<User> { /* ... */ }
function getProduct(id: ProductId): Promise<Product> { /* ... */ }

const userId = createUserId('usr_abc123');
const productId = 'prod_xyz789' as ProductId;

getUser(productId); // TS Error: Argument of type 'ProductId' is not assignable to parameter of type 'UserId'
getUser(userId);    // OK

El __brand nunca existe en runtime — es solo una ficción para el type checker. El costo es cero en producción, el beneficio es enorme en desarrollo.

Lo uso también para valores primitivos con semántica específica:

type Percentage = Brand<number, 'Percentage'>;
type Milliseconds = Brand<number, 'Milliseconds'>;
type USD = Brand<number, 'USD'>;

function calculateDiscount(price: USD, discount: Percentage): USD {
  return (price * (1 - discount / 100)) as USD;
}

// No podés accidentalmente pasar milisegundos como precio
const delay: Milliseconds = 5000 as Milliseconds;
const price: USD = 99.99 as USD;
calculateDiscount(delay, price); // Error en compilación, no en producción

Generics avanzados: más allá de `Array<T>`

Generics es donde TypeScript se pone realmente poderoso y donde la gente se pierde. Yo me perdí muchas veces. Voy a mostrar los patrones que quedaron en mi toolbelt.

Conditional Types

type Awaited<T> = T extends Promise<infer U> ? U : T;

// Uso real: cuando tenés que manejar valores que pueden ser async o sync
type MaybeAsync<T> = T | Promise<T>;
type Resolved<T> = T extends Promise<infer U> ? U : T;

// Unwrap nested arrays
type Flatten<T> = T extends Array<infer U> ? U : T;
type StringOrNumber = Flatten<string[]>; // string
type JustString = Flatten<string>;       // string

Template Literal Types

Este me voló la cabeza cuando lo descubrí. Podés hacer aritmética de strings en el type system:

type HttpMethod = 'GET' | 'POST' | 'PUT' | 'DELETE' | 'PATCH';
type ApiEndpoint = '/users' | '/products' | '/orders';

type ApiRoute = `${HttpMethod} ${ApiEndpoint}`;
// = 'GET /users' | 'GET /products' | 'GET /orders' | 'POST /users' | ...

// Esto lo uso para event names en sistemas de eventos
type EntityName = 'user' | 'product' | 'order';
type CrudAction = 'created' | 'updated' | 'deleted';
type DomainEvent = `${EntityName}.${CrudAction}`;
// = 'user.created' | 'user.updated' | 'user.deleted' | 'product.created' | ...

type EventHandler<T extends DomainEvent> = (event: T) => void;

function on<T extends DomainEvent>(event: T, handler: EventHandler<T>) {
  // registro el handler
}

on('user.created', (event) => { /* event es 'user.created' */ });
on('invalid.event', () => {}); // Error de compilación

Mapped Types con modificadores

// El clásico DeepReadonly que no viene en la stdlib
type DeepReadonly<T> = {
  readonly [K in keyof T]: T[K] extends object ? DeepReadonly<T[K]> : T[K];
};

// DeepPartial para formularios
type DeepPartial<T> = {
  [K in keyof T]?: T[K] extends object ? DeepPartial<T[K]> : T[K];
};

// Pick con dot notation — lo escribí para un form builder
type PathsToString<T> = T extends string | number | boolean
  ? never
  : {
      [K in keyof T & string]: K | `${K}.${PathsToString<T[K]>}`;
    }[keyof T & string];

Cómo pienso en tipos: el cambio mental

Antes pensaba en tipos como anotaciones — escribía el código y después le ponía tipos encima. Error conceptual enorme. Ahora pienso en tipos primero, especialmente en el dominio.

Los tipos son tu modelo de negocio. Si el tipo compila, las invariantes del negocio se cumplen — o deberían. Si podés construir un estado inválido con tus tipos, los tipos están mal.

Un ejemplo concreto: un carrito de compras no puede tener cantidad negativa de items. Si tenés quantity: number, estás mintiendo. Tenés quantity: PositiveInteger o tenés un bug esperando pasar.

type PositiveInteger = Brand<number, 'PositiveInteger'>;

function toPositiveInteger(n: number): PositiveInteger {
  if (!Number.isInteger(n) || n <= 0) {
    throw new Error(`Expected positive integer, got: ${n}`);
  }
  return n as PositiveInteger;
}

interface CartItem {
  productId: ProductId;
  quantity: PositiveInteger;
  unitPrice: USD;
}

Ahora es imposible tener un CartItem con cantidad cero o negativa sin pasar por la función que valida. La validación vive en un solo lugar.

El patrón Result que reemplazó mis try/catch

Esto lo tomé prestado de Rust y cambió cómo manejo errores:

type Result<T, E = Error> =
  | { ok: true; value: T }
  | { ok: false; error: E };

function ok<T>(value: T): Result<T, never> {
  return { ok: true, value };
}

function err<E>(error: E): Result<never, E> {
  return { ok: false, error };
}

// En vez de throw:
async function fetchUser(id: UserId): Promise<Result<User, 'NOT_FOUND' | 'NETWORK_ERROR'>> {
  try {
    const user = await db.users.findById(id);
    if (!user) return err('NOT_FOUND');
    return ok(user);
  } catch {
    return err('NETWORK_ERROR');
  }
}

// En el caller, TypeScript me fuerza a manejar ambos casos:
const result = await fetchUser(userId);
if (!result.ok) {
  switch (result.error) {
    case 'NOT_FOUND': return redirect('/404');
    case 'NETWORK_ERROR': return showRetryButton();
  }
}
// Acá TypeScript sabe que result.value existe y es User
console.log(result.value.name);

Los errores posibles están en la firma de la función. No tenés que leer la implementación para saber qué puede fallar. Es la diferencia entre documentación que se desactualiza y tipos que son verdad por construcción.

Lo que no uso

Serío con esto: no uso any salvo para interop con librerías viejas y siempre lo encapsulo. unknown es casi siempre la respuesta correcta cuando no sabés el tipo. No uso as salvo en las funciones constructoras de branded types y cuando sé exactamente lo que estoy haciendo. Si encontrás que usás as seguido para que el código compile, los tipos están mal — no el compilador.

También evito tipos demasiado complejos que nadie puede leer. Un tipo que necesita comentarios para explicarse falló en su trabajo principal. Si llegás a cuatro niveles de condicional genérico, parateé un segundo y pensá si no hay una abstracción más simple.

El viaje vale la pena

Me acuerdo perfectamente de cuando TypeScript me parecía burocracia innecesaria. "¿Para qué poner tipos si JavaScript igual funciona?" — esa es la pregunta de alguien que todavía no tuvo el bug de producción suficientemente doloroso.

Hoy no concibo escribir una aplicación seria sin él. No porque sea una regla, sino porque cuando los tipos están bien, el código te habla. Refactorizás con confianza porque el compilador te dice exactamente qué rompiste. Entrás a un codebase de otra persona y los tipos te cuentan el modelo de negocio sin que tengas que leer comentarios desactualizados.

Empieza con discriminated unions. Ese es mi consejo. Es el patrón con mejor ratio de complejidad/valor y una vez que lo internalizás, empezás a ver oportunidades para usarlo en todos lados.

Este artículo fue publicado originalmente en juanchi.dev

De DOS a Cloud: mi viaje de 33 años con la tecnología — desde una Amiga en 1994 hasta deployar en Railway con Next.js

Juan Torchia — Tue, 07 Apr 2026 00:19:26 +0000

Hay una foto mía de 1994 que mi vieja guarda en un álbum de plástico verde. Tengo tres años, el pelo cortado a tazón, y estoy sentado frente a una Amiga 500 con una expresión de concentración absoluta. No sé qué estaba mirando. Probablemente algún juego en floppy que mi viejo había copiado de no sé dónde. Pero esa imagen es mi origen story. El big bang personal de esta historia de programador argentino que arrancó antes de que yo pudiera leer.

La Amiga no era una computadora. Era un universo.

La Commodore Amiga 500 era una máquina que en 1994 ya estaba técnicamente muerta en el mercado mundial, pero en Argentina —tierra de contratiempos gloriosos— todavía vivía y coleaba. Mi viejo la había conseguido no sé cómo, en algún intercambio de esos que solo existían en la Argentina de los noventa.

Tenía 512KB de RAM. Corría un sistema operativo multitarea cuando Windows todavía era una cáscara patética sobre DOS. Reproducía samples de audio de 8 bits cuando las PC de IBM apenas podían hacer beeps. Era, objetivamente, una computadora superior que el mercado abandonó por razones políticas y comerciales que me siguen pareciendo un crimen.

Yo no entendía nada de eso. Solo sabía que cuando encendías esa caja gris y metías el kickstart disk, aparecía una pantalla de colores imposibles para la época y el mundo se abría.

Ahí empezó todo.

A los 5 años: mi primer dominio (y no tenía idea de lo que era)

Esto suena a cuento pero es verdad. Mi viejo, que trabajaba en algo relacionado con importaciones y exportaciones, había empezado a meterse en internet alrededor de 1996. Para 1998, cuando yo tenía 5 años, teníamos conexión dial-up y él me dejaba jugar en la computadora.

Registré mi primer dominio —bueno, él lo registró, yo le dije el nombre— porque quería tener "mi propio lugar en internet" para poner dibujos. No entendía absolutamente nada de lo que implicaba un dominio. Para mí era como poner tu nombre en la puerta de una habitación.

Pero esa intuición de que el nombre importa, de que el espacio digital es tuyo si lo reclamás, se quedó grabada a fuego.

Los 14 años y el cyber de Palermo: donde aprendí redes a los golpes

Aquí viene la parte visceral.

Era 2005. Argentina salía de la crisis del 2001 con las costillas rotas pero con ganas de vivir. Los cyber cafés eran el corazón tecnológico del barrio. No había WiFi en todos lados, las netbooks del Plan Ceibal no existían todavía, y si querías jugar Counter-Strike con tus amigos o bajar música de Ares (sí, Ares, no me arrepiento), ibas al cyber.

Yo conseguí laburar en uno. Tenía 14 años, ninguna calificación formal, y el dueño —un tipo de unos 45 que había montado el negocio con sus ahorros— me contrató porque era el único que sabía reiniciar el servidor cuando se colgaba sin romper nada.

Ahí aprendí redes. No en un libro. Aprendí porque cuando se caía la conexión a las 10 de la noche con el local lleno de pibes gritando que habían perdido la partida, tenías que diagnosticar y solucionar ya.

Aprendí qué era un DHCP server cuando el servidor de Windows 2000 dejó de asignar IPs y todos los equipos se quedaron con APIPA (169.254.x.x — ese rango de direcciones me genera PTSD hasta el día de hoy). Aprendí qué era un switch, un hub, la diferencia entre los dos, por qué los hubs eran una basura para gaming (colisiones de paquetes, latencia impredecible). Aprendí a configurar VLANs básicas en switches Cisco de segunda mano que el dueño había comprado en la Feria de La Salada.

Ningún libro me enseñó eso. Me lo enseñó la presión, la adrenalina, y el miedo a que me echaran.

A los 18: Linux, web hosting, y mi primera crisis existencial técnica

Salté del cyber al mundo del web hosting. 2009. Era la época en que Fibertel empezaba a ser algo, en que WordPress ya existía pero todavía la gente construía sitios en Dreamweaver, en que PHP 5 era lo más nuevo del mundo.

Instalé mi primer servidor Linux en una máquina física. Un Pentium 4 reconvertido en servidor con Ubuntu Server 8.04. Sin interfaz gráfica. Solo terminal.

Recuerdo el momento exacto en que levanté mi primer VirtualHost en Apache:

<VirtualHost *:80>
    ServerName miprimerodomain.com.ar
    DocumentRoot /var/www/miprimerodomain
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Parece una boludez. Pero cuando escribís esa configuración, hacés sudo service apache2 reload, abrís el browser y tu dominio carga desde tu propia máquina... algo en tu cerebro hace click. Entendés, a nivel visceral, cómo funciona internet. No como concepto abstracto. Como infraestructura real que vos estás controlando.

Esa sensación no la cambio por nada.

También me rompí la cabeza mil veces. Configuré mal un servidor de correo y quedé en listas negras de spam. Borré /var/www entero con un rm -rf mal escrito (sí, me pasó, sí, quería morirme). Aprendí qué era un backup después de necesitarlo desesperadamente. Todas lecciones que ningún tutorial te enseña porque solo las aprendés cuando el dolor es real.

La CCNA y la UBA: el intento de formalizar el caos

Estudié para el Cisco CCNA porque sentía que mi conocimiento era un archipiélago de islas sin puentes. Sabía hacer cosas pero no entendía la arquitectura completa. El CCNA me dio el framework teórico que ordenó todo el ruido.

OSI model. TCP/IP stack. Spanning Tree Protocol. OSPF. BGP en sus formas más básicas. Todo eso que yo había tocado empíricamente de golpe tenía nombre, estructura, razón de ser.

Después entré a Ciencias de la Computación en la UBA. Y ahí me rompieron la cabeza de otra manera. Álgebra, cálculo, algoritmos, complejidad computacional. La diferencia entre O(n) y O(n²) no es académica — es la diferencia entre una app que escala y una que muere bajo carga.

La UBA me enseñó a pensar. El cyber me había enseñado a hacer. Necesitaba los dos.

2020: El pivot. El año que lo cambió todo.

Vino la pandemia y, como a muchos, me dejó encerrado con tiempo y con preguntas. Estaba haciendo cosas de infraestructura, sysadmin, algo de DevOps. Pero el desarrollo de software siempre me había llamado y siempre había postergado el salto.

En marzo de 2020, con el mundo en llamas, decidí: ahora.

Empecé con JavaScript vanilla. Después React. Después TypeScript (y al principio lo odiaba — todos odian TypeScript al principio, el que dice que no, miente). Después Next.js.

El primer componente React que escribí fue horrible:

// Esto es arqueología. No juzguen.
function MiComponente() {
  var nombre = "Juan";
  return (
    <div>
      <p>Hola {nombre}</p>
    </div>
  )
}

Sin hooks. Sin TypeScript. Sin nada. Pero funcionaba y eso era suficiente para seguir.

Después de meses de iteración, el mismo componente empezó a verse así:

interface GreetingProps {
  userId: string;
  fallbackName?: string;
}

const Greeting: React.FC<GreetingProps> = ({ userId, fallbackName = 'amigo' }) => {
  const { data: user, isLoading } = useUser(userId);

  if (isLoading) return <Skeleton className="h-6 w-32" />;

  return (
    <p className="text-lg font-medium">
      Hola, {user?.displayName ?? fallbackName}
    </p>
  );
};

export default Greeting;

La distancia entre esos dos fragmentos de código es la distancia entre no saber y empezar a saber. Y esa distancia se mide en horas de frustración, en Stack Overflow a las 2AM, en errores de TypeScript que no entendés hasta que de repente entendés todo.

Hoy: Docker, PostgreSQL, Railway, y el deploy que me hace sentir poderoso

Hoy mi stack es Next.js 14, TypeScript, PostgreSQL con Prisma, Docker para desarrollo local, y Railway para producción. Y cuando hago deploy de una app completa —con su base de datos, sus variables de entorno, su dominio custom— todavía siento algo. No sé si llamarlo orgullo o simplemente satisfacción profunda.

Mi docker-compose.yml de desarrollo típico:

version: '3.8'
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile.dev
    ports:
      - "3000:3000"
    volumes:
      - .:/app
      - /app/node_modules
    environment:
      - DATABASE_URL=postgresql://postgres:postgres@db:5432/myapp
    depends_on:
      - db

  db:
    image: postgres:15-alpine
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=myapp
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Eso es infraestructura reproducible. Cualquier dev del equipo hace docker compose up y tiene el entorno exacto. Sin "en mi máquina funciona". Sin dependencias fantasma.

Hay una línea directa entre configurar Apache en Ubuntu 8.04 en 2009 y escribir ese docker-compose.yml en 2024. Es la misma obsesión por entender cómo las piezas encajan.

Lo que 33 años de tecnología me enseñaron (en serio)

No hay atajos para la intuición técnica. Podés aprender sintaxis en un fin de semana. La intuición — saber por qué algo falla antes de leer el error, entender cómo va a escalar un sistema, anticipar los edge cases — esa intuición se construye con tiempo y con dolor.

La historia de este programador argentino no es una historia de genialidad. Es una historia de exposición acumulada. De estar cerca de la tecnología desde tan chico que las capas de abstracción se fueron volviendo transparentes de a poco.

Cada error que cometí —el rm -rf, las configuraciones rotas, los servidores de correo en listas negras— me dejó algo. Una cicatriz que ahora es conocimiento.

Y la Amiga 500. Siempre vuelvo a la Amiga. Esa máquina que hacía más con menos, que era técnicamente superior y perdió igual, que vivió en Argentina cuando ya estaba muerta en el mundo, me enseñó algo sin que yo lo supiera: la tecnología no siempre gana el que la merece. Gana el que la adopta, la empuja, la hace suya.

Eso es lo que hago. Hace 33 años. Y no paro.

Este artículo fue publicado originalmente en juanchi.dev

Docker para desarrolladores Node.js: de cero a producción sin morir en el intento

Juan Torchia — Tue, 07 Apr 2026 00:19:18 +0000

La primera vez que Docker me rompió producción

Era 2021. Tenía una app Node.js corriendo en un VPS de DigitalOcean, funcionaba perfecto en mi máquina (sí, esa frase maldita), y decidí 'modernizar' el deploy metiéndole Docker. Resultado: tres horas de downtime, un cliente furioso y yo a las 3 de la mañana leyendo logs que no entendía.

Hoy, con todo ese dolor convertido en experiencia, puedo decirte que Docker con Node.js es una de las mejores decisiones que podés tomar para tu stack — siempre y cuando lo hagas bien. Y 'bien' implica entender qué está pasando, no copiar un Dockerfile de Stack Overflow y rezar.

Vamos de cero. En serio, de cero.

¿Por qué Docker y Node.js se llevan tan bien?

Node.js tiene un problema histórico: el entorno. La versión de Node en tu máquina, la del servidor de staging, la del servidor de producción — si no las controlás, te esperan bugs que aparecen solo en producción y te hacen dudar de tu cordura.

Docker resuelve esto con contenedores. Un contenedor es básicamente un proceso aislado que lleva su propio sistema de archivos, sus propias dependencias, su propia versión de Node. Vos definís todo eso en un Dockerfile, y ese archivo viaja con tu código. Si funciona en tu contenedor, funciona en cualquier lado.

Eso es la promesa. Ahora veamos cómo no arruinarla.

Tu primer Dockerfile para Node.js

Empezamos con lo básico. Supongamos que tenés una app Express simple:

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./

RUN npm ci --only=production

COPY . .

EXPOSE 3000

CMD ["node", "src/index.js"]

Este Dockerfile hace cosas específicas por razones específicas. Te las explico porque cuando entendés el por qué, dejás de copiar a ciegas:

FROM node:20-alpine: Uso Alpine Linux, que pesa unos 50MB contra los 300MB+ de la imagen Debian/Ubuntu. Para producción, menos superficie = menos vulnerabilidades potenciales. Para desarrollo, a veces Alpine te rompe dependencias nativas (te miro a vos, bcrypt). En esos casos usá node:20-slim.

WORKDIR /app: Definís un directorio de trabajo limpio. Sin esto, Docker tira los archivos en la raíz del contenedor y el caos reina.

COPY package*.json ./ antes del COPY . .: Esto es crítico para el sistema de caché de Docker. Las capas de Docker se cachean. Si copiás primero los package.json y corrés npm ci, Docker va a reusar esa capa mientras los package.json no cambien. O sea: en cada rebuild, si solo tocaste código, Docker no reinstala todas las dependencias. Esto te ahorra minutos reales.

npm ci en lugar de npm install: ci usa exactamente el package-lock.json. Reproducible, determinístico, lo que querés en producción.

El .dockerignore que nadie te enseña

Antes de buildear nada, creá un .dockerignore. Esto es lo que más gente olvida y lo que más me quemó al principio:

node_modules
.git
.gitignore
*.log
.env
.env.local
.env.*.local
dist
build
.next
Dockerfile
docker-compose*.yml
README.md
.DS_Store
coverage

Sin .dockerignore, estás copiando node_modules (que puede pesar gigabytes) al contexto de build, y potencialmente metiendo tus variables de entorno secretas en la imagen. Sí, como suena. El .env adentro de una imagen Docker pública es una pesadilla de seguridad que vi pasar en repos reales.

Docker Compose: el compañero inseparable

Ninguna app vive sola. La tuya necesita una base de datos, quizás Redis, quizás un servicio de cola. Docker Compose te permite orquestar todo eso localmente con un solo archivo:

version: '3.8'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development
      - DATABASE_URL=postgresql://postgres:password@db:5432/myapp
      - REDIS_URL=redis://cache:6379
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
    volumes:
      - .:/app
      - /app/node_modules

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: password
      POSTGRES_DB: myapp
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

  cache:
    image: redis:7-alpine
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

Notá el depends_on con condition: service_healthy. Esto fue otro de mis errores históricos: arrancar la app antes de que Postgres termine de inicializar. Sin el healthcheck, tu app arranca, intenta conectarse a la base de datos que todavía está bootando, y explota. Con el healthcheck, Docker espera a que Postgres realmente esté listo.

El volumen doble en app:

volumes:
  - .:/app
  - /app/node_modules

Monta tu código local adentro del contenedor (hot reload en desarrollo) pero preserva el node_modules del contenedor. Sin la segunda línea, tu node_modules local pisaría el del contenedor, y si estás en Mac o Windows corriendo Alpine, los binarios compilados son incompatibles. Esta sutileza me hizo perder dos horas una tarde.

Multi-stage builds: el paso de adulto

Cuando empecés a trabajar con TypeScript (y vas a trabajar con TypeScript), necesitás compilar antes de correr. Un Dockerfile naive instalaría todas las devDependencies, compilaría, y dejaría todo ese peso en la imagen final. Multi-stage builds resuelven eso:

# Stage 1: Builder
FROM node:20-alpine AS builder

WORKDIR /app

COPY package*.json tsconfig.json ./
RUN npm ci

COPY src ./src
RUN npm run build

# Stage 2: Production
FROM node:20-alpine AS production

WORKDIR /app

RUN addgroup -g 1001 -S nodejs && \
    adduser -S nodeuser -u 1001

COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force

COPY --from=builder /app/dist ./dist

USER nodeuser

EXPOSE 3000

CMD ["node", "dist/index.js"]

Esto hace dos cosas importantes:

La imagen final solo tiene el código compilado y las dependencias de producción. Sin TypeScript, sin ts-node, sin ninguna devDependency. Imágenes más chicas, más seguras, más rápidas de deployar.
USER nodeuser: No corrás tu app como root adentro del contenedor. Es un principio básico de seguridad que mucha gente ignora hasta que tiene un problema.

Variables de entorno: hacelo bien o no lo hagas

Nunca hardcodees secretos en el Dockerfile ni en el docker-compose.yml que commitás. La forma correcta:

Para desarrollo, usá un .env local (que está en tu .dockerignore y .gitignore) y referencialo en compose:

services:
  app:
    env_file:
      - .env

Para producción, usás los secrets de tu plataforma: Railway, Render, Fly.io, o las variables de entorno de tu CI/CD. Docker Swarm y Kubernetes tienen sus propios sistemas de secrets. Lo importante es que el secreto nunca viva en el código ni en la imagen.

El workflow que uso hoy

Después de todos los tropiezos, mi flujo actual es:

# Desarrollo con hot reload
docker compose up

# Rebuild forzado cuando cambio dependencias
docker compose up --build

# Correr en background
docker compose up -d

# Ver logs en tiempo real
docker compose logs -f app

# Entrar al contenedor a debuggear
docker compose exec app sh

# Limpiar todo y empezar de cero
docker compose down -v

El docker compose exec app sh es tu mejor amigo para debuggear. Entrás al contenedor vivo, podés correr comandos, verificar que las variables de entorno están como esperás, ver si los archivos están donde tienen que estar.

Producción: lo que nadie te dice

Para producción real, algunas cosas que aprendí caro:

Health checks en el Dockerfile:

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD node -e "require('http').get('http://localhost:3000/health', (r) => { process.exit(r.statusCode === 200 ? 0 : 1) })"

Tu orquestador (sea Compose, Swarm o Kubernetes) necesita saber si tu app está viva. Sin health check, puede estar sirviendo errores 500 y el orquestador sigue creyendo que todo está bien.

NODE_ENV=production: Setéalo siempre. Express, entre otros frameworks, tiene optimizaciones específicas para este modo.

Manejo de señales: Node.js adentro de Docker necesita manejar SIGTERM para hacer graceful shutdown. Si no lo implementás, Docker mata el proceso después del timeout y podés perder requests en vuelo. Es un tema que da para otro post entero.

Conclusión: el dolor vale la pena

Docker con Node.js tiene una curva de aprendizaje real. Te va a romper cosas. Vas a tener imágenes que pesan 2GB cuando deberían pesar 200MB. Vas a tener contenedores que no arrancan por problemas de permisos a las 2 de la mañana.

Pero cuando lo tenés aceitado, la sensación de docker compose up y tener todo tu stack corriendo en 30 segundos, en cualquier máquina, con exactamente las mismas versiones de todo, es difícil de superar.

El día que un compañero clonó mi repo y tuvo el proyecto corriendo en 5 minutos sin instalar nada más que Docker, entendí por qué vale el dolor inicial.

El Dockerfile de producción bien hecho es uno de los activos más valiosos de tu proyecto. Tratálo como código, evoluciónalos, revisalos en code review. No es solo infraestructura — es la receta de cómo vive tu app en el mundo.

Este artículo fue publicado originalmente en juanchi.dev

DEV Community: Juan Torchia

De DOS a Cloud: mi viaje de 33 años con la tecnología — desde una Amiga en 1994 hasta deployar en Railway con Next.js

La Amiga como primer maestro

Los cyber cafés como universidad

Linux a las 3am y el primer servidor real

El desvío: Cisco CCNA y la UBA

2020: el pivot que cambió todo

Railway, Next.js y el deploy de 2024

Por qué importa de dónde venís

De 3 segundos a 300ms: cómo optimicé el performance de una app Next.js en producción

El diagnóstico: primero entendé qué está ardiendo

Problema 1: el bundle era un desastre

Bye bye moment.js

Dynamic imports para lo que no se ve al inicio

Problema 2: el waterfall de fetches en el cliente

Problema 3: las imágenes me estaban matando

El toque final: caching agresivo

Los resultados reales

Lo que aprendí — y lo que hubiera hecho diferente

pnpm vs npm vs yarn vs bun: la comparativa definitiva que nadie te va a dar en 2025

Un poco de historia para que entiendas por qué existe este caos

npm: el que ya tenés instalado

Yarn: el que prometía mucho y se complicó

pnpm: mi favorito sin discusión

Bun: el que llegó a romper todo

La tabla que todos quieren

Mi recomendación final, sin rodeos

Cómo construí juanchi.dev con el stack más bleeding edge de 2025: Next.js 16, React 19, Tailwind v4 y Railway

El setup inicial: la arrogancia de los primeros 20 minutos

React 19 y los Server Components: amigos con beneficios que te complican la vida

El sistema de proyectos: MDX + generación estática

Railway: el deployment que casi me quiebra

El formulario de contacto: Server Actions al rescate

Lo que salió mal: el resumen ejecutivo

¿Lo volvería a hacer?

Next.js App Router: la guía que me hubiera gustado tener cuando migré de Pages Router

Next.js App Router: la guía que me hubiera gustado tener cuando migré de Pages Router

El cambio mental que nadie te dice que necesitás

La estructura de carpetas que sí funciona

Fetch de datos: la parte donde casi todos la cagan

El sistema de cache que me hizo perder dos horas

Streaming y Suspense: la magia que justifica todo el dolor

Lo que rompe en producción (mi lista de traumas)

1. Los cookies y headers en Server Components

2. Pasar funciones como props a Client Components

3. El router de navegación cambió

4. Variables de entorno y el servidor

La migración incremental que recomiendo

¿Vale la pena?

Metí un LLM chico adentro de una app Next.js y esto fue lo que aprendí

LLM pequeño en el browser: qué promete, qué entrega

El setup real: Next.js, WebLLM y el primer encontronazo con la realidad

Dónde se rompe todo — los límites que nadie cuenta en los demos

El momento en que decidí si valía la pena

FAQ — Lo que me preguntarían si contara esto en una charla

Conclusión: la tecnología está, la madurez no tanto

Claude Code se rompió con las actualizaciones de febrero — y yo también lo sentí

Claude Code updates febrero 2025: qué cambió (y qué se rompió)

La pregunta que no quería hacerme

Los errores que cometí (y que probablemente estés cometiendo)

FAQ: Claude Code, las actualizaciones de febrero y el elefante en el cuarto

Conclusión: el deterioro de la herramienta como servicio

El stack tecnológico perfecto en 2025: lo que elegiría si arrancara un proyecto hoy

El stack tecnológico perfecto en 2025: lo que elegiría si arrancara un proyecto hoy

Por qué importa elegir bien el stack tecnológico en 2025

El stack: la decisión

Next.js 15: el centro de todo

TypeScript: no es opcional en 2025

Drizzle ORM: el ORM que no te esconde SQL

PostgreSQL: aburrido y perfecto

Lo que descarté y por qué

El entorno de desarrollo: Docker sí, pero con criterio

El elefante en la habitación: ¿y la IA?

La conclusión que nadie quiere escuchar

TypeScript: los patrones que realmente uso todos los días

Discriminated Unions: el patrón que más uso

Branded Types: cuando string no alcanza

Generics avanzados: más allá de Array<T>

Conditional Types

Template Literal Types

Branded Types: cuando `string` no alcanza

Generics avanzados: más allá de `Array<T>`