El 19 de junio de 2025 fui a PiterJS #79 en San Petersburgo. La tarde giró en torno a un tema poco glamuroso, y precisamente por eso útil: no cómo lanzar la siguiente funcionalidad, sino cómo mantener lo que ya está construido — monitorización, despliegue y refactoring.
El programa encajaba muy bien con esa idea. Pavel Shlykov habló de cómo mejorar un monolito antiguo, Alexander Panfilov trató FrontOps e Igor Antonov habló de métricas de rendimiento de aplicaciones web. Me fui con notas prácticas de los tres temas.
La parte inesperada llegó en el Q&A. Terminé ganando dos premios por hacer las mejores preguntas durante las sesiones. Es un detalle pequeño, pero acabó siendo lo más memorable de la tarde porque reforzó una de las razones por las que sigo valorando los meetups técnicos presenciales: puedes hacer algo más que consumir una charla preparada. Puedes comprobar tu propia comprensión mientras las personas que presentaron el tema siguen allí.
Lo útil fue hablar de mantenimiento, no de novedades
Los eventos de frontend pueden convertirse fácilmente en un desfile de frameworks, APIs y abstracciones nuevas. PiterJS #79 fue más terrenal. Su tema anunciado era el mantenimiento del software que ya existe.
Eso importa porque gran parte del trabajo de ingeniería empieza después del primer lanzamiento exitoso. Un monolito legacy no es automáticamente un mal sistema, y “modernizar” no significa automáticamente reescribirlo todo. La pregunta práctica suele ser más concreta: ¿qué limitación está causando problemas ahora y qué cambio reduce ese dolor sin introducir más riesgo del que elimina?
Por eso las tres charlas encajaron bien entre sí. El refactoring cambia el código. FrontOps cambia cómo se construye, empaqueta, entrega y opera el frontend. El trabajo de rendimiento cambia cómo medimos el resultado. Son capas distintas del mismo problema: mantener un sistema real comprensible y controlable después de que haya crecido.
FrontOps es más amplio que un Dockerfile
Una de mis notas del meetup era sobre implementar FrontOps con Docker. La distinción importante es que Docker es una herramienta, no la definición de FrontOps.
La responsabilidad sobre el frontend no tiene por qué terminar cuando npm run build acaba correctamente. En producción alguien sigue teniendo que pensar en builds reproducibles, empaquetado de artefactos, configuración, rollback de versiones, comportamiento de la caché y observabilidad de fallos. Los contenedores pueden hacer parte de ese trabajo más predecible, pero no sustituyen las decisiones operativas.
Esto corrige un modelo mental bastante común: un build exitoso demuestra que el build terminó. No demuestra que la aplicación se vaya a desplegar correctamente, que se comporte bien en producción ni que sea fácil recuperarla cuando algo falle.
El rendimiento empieza por decidir qué significa “lento”
La charla de rendimiento fue especialmente práctica por cómo planteó la medición. Su descripción anunciada incluía los factores que afectan a la velocidad de carga, distintas métricas de rendimiento frontend, maneras de cuantificar lo “lento” e incluso por qué optimizar no siempre es necesario.
Ese último punto es fácil de infravalorar. “Hazlo más rápido” suena objetivo, pero sin una métrica y un problema visible para el usuario puede convertirse en una forma cara de adivinar. Un proceso útil de rendimiento empieza definiendo qué es realmente lento, midiéndolo, identificando el cuello de botella, cambiando algo relevante y midiendo de nuevo.
Una métrica no es por sí sola la experiencia de usuario, pero proporciona una unidad compartida para la discusión. Sin medición, el trabajo de rendimiento puede convertirse en una colección de cambios técnicamente impresionantes sin evidencia clara de que hayan mejorado el problema que importaba.
El Q&A cambió el valor del meetup para mí
Podría haber visto las grabaciones y guardado enlaces más tarde. Lo que no habría podido reproducir con tanta facilidad era la interacción alrededor de las charlas. Hacer una buena pregunta obliga a comprimir una incertidumbre hasta convertirla en algo suficientemente específico como para que otro ingeniero pueda responder.
Ganar dos premios fue divertido, pero la lección más útil fue más sencilla: ir preparado para participar hace que un meetup presencial tenga mucho más valor que tratarlo como una playlist de YouTube en directo.
Una buena pregunta técnica suele incluir contexto y una restricción. En lugar de “¿Cuál es la mejor arquitectura?”, puede ser más útil preguntar qué trade-off cambia si un equipo no puede reescribir un sistema legacy, si el despliegue debe seguir siendo compatible hacia atrás o si una métrica mejora sin un beneficio equivalente que los usuarios puedan percibir.
Eso no significa que cada pregunta tenga que ser brillante. Significa que debería ayudar a descubrir supuestos, límites o modos de fallo.
Qué me llevaría al próximo meetup técnico
- Saber por qué una charla me importa. Anotar antes de empezar un problema real o una incertidumbre relacionada.
- Separar la experiencia del ponente de mi propio sistema. Un buen caso práctico es evidencia, no una receta universal.
- Preguntar por los trade-offs. “¿Cuándo no usarías esto?” suele revelar más que “¿Qué herramienta es mejor?”
- Guardar una acción de seguimiento. Una nota vale más cuando apunta a algo que comprobar, probar o leer después del meetup.
- No confundir una charla convincente con una prueba de producción. Las decisiones de arquitectura, despliegue y rendimiento todavía deben validarse en el propio entorno.
Con qué me quedé
No quiero exagerar lo que puede cambiar un solo meetup. No salí de PiterJS con una receta universal de arquitectura, y una buena charla no sustituye documentación, profiling, tests ni datos de producción.
Lo que sí me llevé fue más concreto: notas útiles sobre modernización de un monolito legacy, FrontOps con Docker y medición de rendimiento web; dos premios del Q&A; y otro recordatorio de que merece la pena presentarse en persona en las comunidades locales de desarrolladores.
Las grabaciones pueden conservar la presentación. Lo más difícil de archivar es la conversación que ocurre alrededor.