Hace unas semanas, al revisar la newsletter de TLDR Dev, me encontré con el artículo de Alvin Sng en Twitter, que habla de cómo en Factory han prohibido el uso de useEffect(). Al principio lo empecé a leer con escepticismo, pero profundizando vi que hasta la propia documentación de React tiene una guía al respecto.

Según la documentación oficial, deberíamos usar useEffect solo para cosas muy específicas:

• Sincronizar con sistemas externos: Para conectar nuestros componentes con elementos que React no controla.
  • Ejemplos: Manipular el DOM directamente, integrar bibliotecas de terceros (como un mapa), o establecer suscripciones a redes (como un WebSocket).
• Ejecutar lógica “detonada” por la aparición del componente: Para código que debe ejecutarse exclusivamente porque el componente se mostró en la pantalla.
  • Ejemplo: Enviar un evento de analíticas (como registrar una visita o acción).
• Obtener datos: Para pedir datos a un servidor.
  • Ejemplo: Hacer una petición a una API cada vez que cambian los parámetros de búsqueda. (Nota: React aclara que esto es válido, pero hoy en día recomiendan usar herramientas especializadas para el fetching de datos).

Y la verdad es que solemos (me incluyo el primero) usar el useEffect() por encima de nuestras posibilidades, más allá de para lo que fue pensado. Es una herramienta súper útil, pero al usarla para todo provocamos una serie de errores que van desde loops infinitos hasta re-renderizados que no son necesarios y me propuse mejorar un pequeño proyecto que tengo.

Una tarde lluviosa de octubre, después de trabajar, recibí la llamada de un amigo. Me dijo: “Me ha entrado un trabajo y te necesito”, así que quedamos y me explicó en qué consistía el tema.

Era una plataforma algo antigua, pero aun así sólida, que necesitaba un refactor de pies a cabeza. No puedo decir nombres, he firmado cosas, pero es un líder a nivel nacional en eventos, con decenas de miles de asistentes a sus eventos.

Normalmente no suelo jugar contenido emulado, pero hay veces que me da pereza sacar la vieja Game Boy del cajón. Además, se me ha quedado sin pila el Pokémon Amarillo, así que tampoco voy a poder guardar la partida, y me da más pereza aún sacar el estaño, el soldador y cambiarle la pila.

Así que en esos momentos a lo mejor sí que tiro de emulador para jugar a mis juegos. Y claro, lo tengo todo hecho un desastre: a veces no encuentro el emulador, otras he formateado y he perdido mis queridas ROMS. Así que para mantener una colección ordenada y potable, he empezado a usar Romm.

Hoy he hablado con un amigo de un tema la mar de interesante, y no es nada más ni nada menos que la regla de los 14 KB. Y ahora estarás pensando: ¿Pero qué coj… es eso?

La regla de los 14 KB es una de las cosas que más pueden ayudar a una web a ser percibida como “rápida”. Y te explico en un momento en qué consiste.

El tema está en que el servidor no sabe si tenemos 256 kbps o 10 GB simétricos de conexión, así que no se va a arriesgar a enviarnos todo el contenido de golpe, porque eso podría saturar la conexión.

Siempre he hecho la broma de que salen Day 0 hasta en el CSS; que ya nada es seguro y que cada semana hay leaks de información y vulnerabilidades a cascoporro.

Pues bien, ya ha llegado el día. El día en el que estamos todos jodidos. Hoy es el día en el que os vengo a decir que se ha cumplido: hay un Day 0 en el CSS.

Y encima es una vulnerabilidad activa y explotada en la actualidad: la CVE-2026–2441. Afecta a cómo Chrome parsea los CSS. Mientras vas actualizándolo, o pasándote a Firefox, o a cualquier otra cosa, te voy explicando cómo funciona el tema:

Últimamente estoy bastante harto de que, por cada chorrada que quiero probar, me toque añadir medio GB de node_modules. Es el pan nuestro de cada día, lo sé, pero a veces uno echa de menos la sencillez de antes.

Buscando cómo hacer cuatro pruebas rápidas sin depender de Tailwind, di con OAT UI. Básicamente es una librería de HTML y CSS ultra ligera, con componentes semánticos y lo que más me interesa: ni una puñetera dependencia.