En 1999, cuando publiqué mi primera página web para un cliente, el panorama no se parecía en nada a lo que enseñan los tutoriales actuales. HTML5 no existía, los navegadores no compartían reglas comunes y, aunque CSS ya tenía una especificación oficial, su implementación era tan divergente entre Netscape Navigator e Internet Explorer que, en la práctica, era como si no existiera. Para que un sitio se visualizara de forma aceptable, no bastaba con escribir código ordenado: había que detectar el
user-agent, aislar Netscape de IE6 y, en muchos casos, ajustar la lógica en el servidor para forzar una salida que el navegador no rechazara.El resultado era lo que se conocia como código espagueti: estilos incrustados directamente en etiquetas con
style="..." o atributos como bgcolor, align y valign; scripts mezclados con la estructura; y cuando necesitabas replicar un bloque en otra página, la solución era Ctrl+C, Ctrl+V. Pero eso no era desorden por falta de criterio, era la única forma pragmática de que algo funcionara en una plataforma que aún no había definido sus propias reglas.1. 1999–2005: Cuando la plataforma obligaba a mezclarlo todo (y por qué el SAT requería IE6)
Quizás el recuerdo más fiel de esa época no es el código, sino la realidad operativa de mantener sistemas críticos. Yo mismo pasé horas configurando Internet Explorer 6, ajustando zonas de seguridad y instalando complementos de ActiveX solo para que la página del SAT procesara un archivo XML o validara la FIEL. Si no lo hacías, el sitio simplemente fallaba en silencio. No era que la pagina del SAT fuera “mala”; era que la web aún no tenía estándares para criptografía en el navegador, ni APIs para manejo seguro de certificados digitales, ni siquiera un
fetch() o WebCrypto. La única vía estable era depender del motor de Microsoft y sus controles propietarios.Limitar la compatibilidad a un solo navegador no era una elección de diseño. Era una decisión de viabilidad. Depurar para Netscape 4, IE5 e IE6 simultáneamente significaba mantener tres ramas de código, usar
document.all en un motor y document.layers en otro, y pelear con un box-model que interpretaba padding y border de forma distinta era un caos. No existían herramientas de depuración, no había transpiladores, ni polyfills, ni siquiera un estándar de referencia estable. Si el navegador no soportaba algo, el desarrollador asumía el costo de la inconsistencia.El código spaghetti, los estilos inline y la duplicación manual no eran vicios: eran la única forma de que un sistema no colapsara en producción cuando el tiempo de entrega era finito y el presupuesto no cubría tres equipos de testing. La web era un territorio en disputa, y nosotros éramos los topógrafos improvisados.
2. 2006–2015: La separación que nos dio aire
La llegada de CSS2/3 usable, la normalización parcial del DOM en los navegadores y la popularización de
include/require en PHP cambiaron la ecuación. Por primera vez, podías separar presentación, lógica y contenido. Un archivo .css externo, una carpeta /js/, y de pronto un cambio visual se reflejaba en decenas de páginas sin tocar el HTML. Aparecieron los primeros resets, los grids manuales basados en float, y los patrones de layout que intentaban simular lo que hoy resuelven flexbox y grid.La web dejó de ser una colección de documentos sueltos para convertirse en un sistema. Pero la abstracción aún era manual: si querías un modal, un calendario o una validación de formularios, lo escribías desde cero o adaptabas scripts de foros y repositorios tempranos. La productividad mejoró, pero la superficie de error seguía siendo amplia. Cada dependencia externa era un punto ciego hasta que no la auditaras línea por línea.
3. 2015–2023: Frameworks y estandarización, el costo invisible
Cuando el ecosistema maduró, llegaron las herramientas que normalizaron la entrega de interfaces profesionales. Bootstrap no solo trajo una rejilla responsiva; estandarizó la forma en que equipos pequeños colaboraban, reduciendo la fricción entre diseño, frontend y backend. SweetAlert reemplazó los
alert() bloqueantes por diálogos accesibles, personalizables y consistentes. FullCalendar abstrajo semanas de lógica de renderizado, navegación por fechas y gestión de eventos en una API predecible.El beneficio fue innegable: velocidad de entrega, coherencia visual y menor carga cognitiva. Pero el costo, que muchos ignoraron durante años, fue estructural: dependencias pesadas, superficie de ataque ampliada, y la tentación de cargar “por si acaso” funcionalidades que nunca se usaban. Mientras tanto, el navegador maduraba en silencio.
flexbox, grid, <dialog>, constraint validation API, :has(), @layer y variables CSS resolvieron directamente problemas que antes justificaban librerías de muchas lineas.Hoy, muchas de esas herramientas siguen siendo válidas, pero su uso debe ser estratégico, no automático. Bootstrap acelera un dashboard interno; SweetAlert mejora flujos críticos de confirmación; FullCalendar resuelve gestión compleja de turnos. Pero para un catálogo estático, un formulario de contacto o un hero informativo, los estándares nativos ya cubren el 80% del caso con menos código, mejor rendimiento y menor superficie de mantenimiento.
4. 2024–2026: La IA no reemplaza el criterio, solo acelera la ejecución
Hoy, herramientas de IA generan componentes, validaciones y layouts en segundos. Pero la web sigue siendo un sistema de restricciones, no un lienzo infinito. La IA no aplica hashes de integridad (
integrity) por defecto, no configura Content-Security-Policy restrictivas, no audita dependencias comprometidas, ni prioriza la simplicidad estructural sobre la acumulación de features. Tampoco responde por el mantenimiento a 3 años, la compatibilidad con navegadores legacy o el impacto en Core Web Vitals.Mi rol ya no es “escribir más rápido”. Es verificar, estructurar y retirar lo que sobra. Por eso integro scripts ligeros en Python que validan cabeceras, hashes y recursos externos, por eso prefiero soluciones nativas cuando cubren el caso y por eso documento límites, no solo ventajas.
La IA es un multiplicador de productividad, pero la responsabilidad de la sigue siendo humana. Un prompt bien redactado no sustituye un código de manifiesto de integridad, una CSP explícita ni una política de actualización de dependencias.
Conclusión: la evolución no es descarte, es criterio
No abandoné los estilos inline porque fueran “malos”. Los abandoné cuando
@layer y variables CSS resolvieron el mismo problema con menos acoplamiento. No rechazo Bootstrap por principio; lo rechazo cuando añade 2500 lineas para un bloque que se resuelve con min-height: 100dvh y object-fit. Y no confío ciegamente en la IA, porque la velocidad de generación no equivale a estabilidad estructural.Para una PyME en CDMX o Hidalgo, la diferencia entre un sitio que convierte y uno que solo “se ve moderno” rara vez está en la cantidad de librerías instaladas. Está en la capacidad de elegir lo que resuelve un problema real, medir su impacto en rendimiento y mantenimiento, y retirar lo que ya no aporta valor. La web ya maduró. Los estándares nativos cierran brechas que antes justificaban abstracciones masivas. Ahora nos toca usarlos con criterio, verificar lo que se despliega y recordar que la simplicidad no es primitiva: es el resultado de haber eliminado lo superfluo.