Vas a una reunión de planning y el PM dice la frase de siempre: "el backend es lo complicado, el frontend lo armamos rápido al final". Nadie discute. El tech lead asiente. Y ahí, si llevas más de cinco años armando interfaces de verdad, se te tensa algo en el estómago, porque sabes exactamente cómo termina esa historia: con un estado global que nadie entiende del todo, con una decisión de rendering que se tomó sin pensar y que ahora cuesta carísimo revertir, con una UI que se cae bajo su propio peso tres sprints después. El desarrollo frontend dejó de ser sobre acomodar cajas y elegir una paleta de colores hace rato, y sin embargo seguimos planificando como si todavía fuera 2014.
El desarrollo frontend nunca fue sobre maquetación, aunque todavía lo tratamos como si lo fuera
Cuando un equipo trata al frontend como el paso de acabado, lo que en realidad está haciendo es posponer decisiones de arquitectura hasta el momento en que ya no hay margen para tomarlas bien. La API se diseñó pensando en el modelo de datos, no en cómo se va a consumir en pantalla. El contrato entre cliente y servidor se negoció sin nadie que entendiera qué pasa cuando el usuario pierde conexión a mitad de una acción. Y para cuando el frontend "se arma rápido al final", ya heredó todos los problemas que nadie quiso resolver antes.
Esto no es una queja gremial. Es una observación técnica: la mayoría de los bugs de producto que terminan en un ticket de soporte no vienen de una lógica de negocio rota, vienen de un frontend que tuvo que improvisar sobre una base que no lo tuvo en cuenta.
La arquitectura de estado es el trabajo real, no el ajuste de márgenes
Si tuvieras que explicarle a alguien de otra disciplina qué hace un ingeniero senior de frontend en su día a día, la respuesta honesta no tiene nada que ver con CSS. Tiene que ver con decidir qué es fuente de verdad y qué es una copia derivada. Qué vive en el servidor, qué vive en el cliente, qué se cachea, cuándo ese cache se invalida y qué pasa cuando dos pestañas del mismo usuario quedan desincronizadas.
React Query, Zustand, Redux, signals, lo que sea que use tu stack, son herramientas para resolver ese problema, no el problema en sí. Usar Redux para absolutamente todo es tan equivocado como no tener ninguna estrategia de estado y dejar que cada componente maneje su propia verdad a los golpes. La pregunta que separa a un desarrollo frontend bien pensado de uno que colapsa en producción no es qué librería elegiste. Es si entendiste, antes de escribir la primera línea, qué necesita estar sincronizado en tiempo real, qué puede vivir desactualizado unos segundos y qué directamente no debería estar en el cliente.
Esto se nota más en equipos que crecen rápido. El estado que era manejable con cuatro pantallas se vuelve una telaraña con cuarenta, y ahí es donde se separa un frontend que escaló de uno que empieza a necesitar reescrituras cada seis meses.
SSR, CSR o streaming: la pregunta no es cuál es mejor, es qué estás dispuesto a sacrificar
Server-side rendering, client-side rendering, streaming con React Server Components. Cada charla técnica presenta esto como si hubiera una respuesta correcta esperando a ser descubierta. No la hay. Hay trade-offs, y elegir sin entenderlos es donde empiezan los problemas de escalabilidad que después nadie sabe explicar.
SSR te da un primer render rápido y mejor indexación, pero mueve costo de cómputo a tu servidor y complica el cacheo cuando el contenido es personalizado. CSR simplifica la infraestructura y funciona bien para aplicaciones muy interactivas, pero castiga el tiempo hasta contenido visible, sobre todo en conexiones lentas. El streaming promete lo mejor de los dos mundos, contenido progresivo, hidratación selectiva, pero suma una capa de complejidad que un equipo sin experiencia previa subestima sistemáticamente.
La decisión correcta depende de qué tan personalizado es tu contenido, qué tan crítico es el SEO para ese producto puntual, y cuánta capacidad de ingeniería tiene el equipo para mantener la solución elegida. Un equipo que copia la arquitectura de rendering de una empresa con cien ingenieros de plataforma dedicados, sin tener esa capacidad, no está tomando una decisión técnica. Está tomando una decisión de marketing interno.
El rendimiento real se mide en el teléfono de gama media de un usuario, no en tu laptop
Un Lighthouse en verde no significa nada si tu usuario real, con una conexión 4G inestable y un teléfono de dos años, ve una pantalla en blanco durante ocho segundos. La diferencia entre performance de laboratorio y performance real es exactamente la diferencia entre medir en condiciones ideales y medir lo que de verdad le pasa a la gente que usa tu producto.
Core Web Vitals importa porque Google lo usa para rankear, sí, pero importa más porque son proxies razonablemente buenos de frustración real: cuánto tarda en aparecer algo, cuánto se mueve la pantalla mientras carga, cuánto tarda en responder a una interacción. Los equipos que solo miran métricas sintéticas, generadas en un entorno controlado, terminan optimizando para un usuario que no existe.
Medir con datos reales de usuarios, no solo con corridas automatizadas, cambia las prioridades. A veces el cuello de botella no es el bundle de JavaScript, es una imagen sin optimizar en el hero de la home. A veces no es el rendering, es una API de terceros que bloquea el hilo principal durante segundos. Sin esa visibilidad, un equipo de frontend optimiza lo que puede medir fácil, no lo que realmente importa.
Cada decisión de frontend es una decisión de producto, aunque nadie lo diga en la reunión
Poner un skeleton screen en vez de un spinner no es un detalle visual, es una apuesta sobre cómo percibe el tiempo un usuario ansioso. Decidir si una acción se muestra como exitosa antes de que el servidor confirme (actualización optimista) o si se espera la respuesta real, cambia directamente cuánta gente completa un flujo de checkout. Un error boundary mal pensado puede convertir un fallo menor en una pantalla en blanco que hace que alguien abandone la app para siempre.
Estas no son decisiones de estética. Son decisiones de producto con impacto directo en conversión, en retención, en cuánta gente se frustra lo suficiente como para no volver. El problema es que casi nunca se discuten en esos términos. Se tratan como implementación, algo que el frontend "resuelve" después de que producto ya definió lo importante. Cuando en realidad, cada una de esas decisiones está definiendo la experiencia tanto como cualquier feature nueva en el roadmap.
Tratar el desarrollo frontend como el paso de después del backend es la razón por la que la UI no escala
Acá está el patrón que se repite en empresa tras empresa: el frontend crece a los tirones porque nunca tuvo una arquitectura pensada de antemano, solo fue absorbiendo features hasta que cada cambio nuevo rompe tres cosas viejas. Nadie planificó la arquitectura de estado. Nadie decidió con criterio la estrategia de rendering. Nadie midió performance con datos reales hasta que empezaron a llegar quejas. Todo eso se fue postergando porque, en la cabeza del equipo, el frontend era la parte que se resuelve rápido al final.
Y cuando por fin explota, la solución que se propone casi siempre es una reescritura completa. No porque el frontend fuera imposible de arreglar, sino porque nunca se lo trató como un sistema con arquitectura propia, con decisiones que merecían el mismo nivel de discusión que cualquier definición de backend. Se acumuló deuda técnica en un lugar donde nadie estaba mirando con suficiente seriedad.
La jerarquía está mal puesta, no la tecnología
El problema de fondo no es técnico. Es que seguimos organizando equipos y conversaciones como si el frontend fuera un paso posterior, cuando en realidad es donde se decide si un producto se siente rápido, confiable y coherente, o si se siente roto aunque el backend responda perfecto. Un ingeniero senior de frontend no es alguien que domina mejor que nadie los selectores de CSS. Es alguien que entiende que cada línea de código en el cliente es una apuesta sobre cómo se comporta un sistema distribuido completo, con todas sus fallas de red, sus estados intermedios y sus usuarios reales usando hardware real. Mientras las empresas sigan asignando ese nivel de responsabilidad a quien "se encarga de que se vea bien", van a seguir pagando en producción el costo de una jerarquía que nunca tuvo sentido.
