30 años de la web vistos a través de la etiqueta `<br>`

• Un texto que repasa cómo ha evolucionado el desarrollo web, siguiendo los cambios desde la web estática de los años 90, pasando por la web centrada en JavaScript de los 2010, hasta la web de la era de la IA en los 2020
• La web, que comenzó con la etiqueta <br> y FTP, se expandió rápidamente hasta convertirse en una plataforma que cualquiera podía crear tras pasar por PHP y MySQL
• A partir de Rails, Git y Heroku en los 2000, el desarrollo web se reconfiguró como una industria centrada en la estructura, la automatización y la colaboración, sentando las bases de la era de la nube y los móviles
• La aparición de React, las cadenas de build, Docker y el ecosistema de Node en los 2010 consolidó la web no como un conjunto de documentos, sino como una verdadera plataforma de aplicaciones
• En los 2020, ChatGPT y Copilot cambiaron la forma de escribir código y se convirtieron en un nuevo punto de inflexión donde la IA multiplica la productividad del desarrollo
• Todos estos cambios, al costo de una mayor complejidad, llevaron a un proceso de democratización de la web que permite que más personas construyan cosas más grandes

---

The Static Web - La era de la web estática

> "View Source era como se aprendía"

• A finales de los 90 (late 90s), la web era una frontera en la que nadie sabía en qué se convertiría, y esa misma incertidumbre resultaba atractiva
• Los sitios web personales comenzaban no en empresas u organizaciones, sino a nivel de servidor personal y carpetas individuales
  • Con un directorio personal en un servidor Unix, archivos HTML y un cliente FTP, ya se podía tener un espacio en internet
  • Con un editor de texto simple como Notepad, era posible escribir y publicar de inmediato
• La web de esa época era un espacio de creación sin censores ni procesos de aprobación
  • Publicaciones libres centradas en intereses como cocina, dinosaurios o canciones
  • Una estructura donde podías subir de inmediato “lo que te interesaba esta semana”
• La forma de aprender era completamente ver y copiar directamente
  • No existían los tutoriales de YouTube ni Stack Overflow
  • Si te daba curiosidad otro sitio, hacías clic derecho → View Source y esa era la herramienta básica de aprendizaje
  • Para contenidos más profundos, se aprendía con libros físicos de verdad
• Era común estudiar con libros técnicos de cientos de páginas, como Core Java, alternando entre el código y el libro
  • Era lento, pero el conocimiento se quedaba por mucho tiempo
• HTML mezclaba estructura y estilo
  • Las etiquetas <table>, <font> y <center> se encargaban al mismo tiempo del layout y del estilo
  • Se ajustaban los espacios con GIF transparentes de 1x1 píxel (spacer GIF)
  • Era tosco e ineficiente, pero funcionaba
• CSS existía, pero en la práctica aún no era dominante
  • La mayoría de los estilos se resolvían con atributos inline o con las propias etiquetas HTML
  • El layout se resolvía con tablas anidadas
• Las funciones dinámicas tenían una barrera de entrada extremadamente alta
  • Incluso funciones básicas como libros de visitas o contadores requerían scripts CGI
  • Había que escribirlos en Perl o C, y hasta procesar un solo parámetro de URL requería mucho código
  • Esa complejidad limitó fuertemente la expansión de la web dinámica
• El problema de los layouts compartidos casi no tenía solución
  • Había que copiar y pegar el encabezado, la navegación y el pie de página en cada archivo HTML
  • Si algo cambiaba, había que modificar todos los archivos
  • También existía la opción de insertar elementos comunes con <iframe>, pero tenía muchos efectos secundarios
• La compatibilidad entre navegadores ya era un problema serio
  • Netscape Navigator (1994) e Internet Explorer (1995) mostraban resultados de renderizado distintos
  • De verdad hacían falta advertencias indicando un navegador y una resolución específicos
• Aun así, la web de esa época tenía un gran poder de atracción
  • Permitía publicar para todo el mundo sin necesidad de equipos de impresión o de transmisión
  • La web hizo realidad por primera vez la democratización de los medios de expresión
• Servicios de hosting gratuito como GeoCities (1994) y Angelfire (1996) ofrecieron espacios de creación a millones de personas
  • Los sitios de fans y las comunidades se conectaban mediante web rings
  • Se formó un ecosistema caótico, pero vivo
• En las empresas, todavía casi no existía el concepto de “equipo web”
  • Si había un sitio web, en la mayoría de los casos lo había hecho “la persona que sabía de computadoras”
  • Era la etapa justo antes de que el desarrollador web se consolidara como profesión
• Las herramientas eran primitivas y los sitios, rudimentarios, pero
  • Fue en esta época cuando echó raíces la idea central de un espacio donde cualquiera puede crear y compartir
• Esa era sostenida con la etiqueta <br> y pura pasión se convirtió en el punto de partida de toda la evolución posterior de la web

La pila LAMP y la Web 2.0

"Everything was PHP and MySQL"

• Incluso después del colapso de la burbuja puntocom en 2000, la web siguió creciendo, y este período se convirtió en un punto de inflexión en el que la barrera de entrada bajó drásticamente para quienes querían crear algo
• El mayor avance de la era de la web estática fue PHP (1995)
  • En una época en la que había que escribir cientos de líneas en C o Perl para CGI, poder leer parámetros de URL con una sola línea como $_GET['name'] fue un cambio decisivo
  • Funcionaba con solo guardar y recargar, sin compilación, gestión de memoria ni mensajes de error crípticos
  • XAMPP (2002) permitió instalar Apache, MySQL y PHP de una sola vez, simplificando de forma revolucionaria la creación de un entorno de desarrollo local
  • PHP fue el primero en resolver de verdad el problema de reutilización de layouts de la era de la web estática
    • Con una sola línea como include 'header.php' se podían gestionar encabezados y pies de página compartidos
    • La experiencia de cambiar todo el sitio con una sola modificación generaba una gran emoción
  • A pesar de sus defectos como lenguaje, la fortaleza de PHP era su accesibilidad
    • HTML y lógica se mezclaban, los nombres de funciones eran inconsistentes y las API de seguridad eran rudimentarias, pero
    • se podía aprender en un fin de semana y crear un servicio real
    • Con hosting compartido (US$5/mes), cPanel (1996) y phpMyAdmin (1998) incluidos por defecto, la barrera de entrada para publicar en línea cayó al nivel más bajo de la historia
• La base de datos que en la práctica venía en paquete con PHP era MySQL (1995)
  • Casi todos los tutoriales, hostings y CMS estaban construidos asumiendo MySQL
  • Funcionalmente era suficiente, pero el manejo de texto internacionalizado era un dolor constante
  • La codificación predeterminada era latin1, y para usar UTF-8 correctamente
    • había que hacer coincidir la configuración de la base de datos, la codificación de la conexión y la declaración de charset en HTML
  • El problema de “ä en lugar de ä” quedó como un trauma emblemático de esa época
• WordPress (2003) cambió la propia naturaleza de la web
  • Incluso sin saber programar, se podía instalar en 5 minutos y publicar de inmediato
  • Bastaba con elegir un tema y escribir entradas para operar un sitio
  • Hizo realidad, en la práctica, la democratización de la creación de sitios web
  • Para los usuarios no técnicos, WordPress fue una liberación
    • Blogueros, pequeños negocios, artistas y hasta restaurantes pudieron tener su propio sitio web
    • Surgió una nueva identidad: el "bloguero"
    • La expansión fue tal que el panel de administración de WordPress llegó a percibirse como el propio “editor de sitios web”
  • Para los desarrolladores, WordPress se volvió una herramienta casi universal
    • Blogs, portafolios, sitios corporativos, comunidades y comercio electrónico: todo se hacía con WordPress
    • Con WooCommerce (2011) absorbió también el e-commerce
    • A cambio de la rapidez de implementación, se acumuló deuda técnica basada en la proliferación de plugins y la personalización de temas
• El acontecimiento que redefinió de raíz las posibilidades de la web fue el lanzamiento de Gmail (2004)
  • En una época en la que Hotmail y Yahoo Mail ofrecían apenas unos pocos MB de almacenamiento
  • 1 GB de almacenamiento gratuito fue una cifra impactante
  • El mensaje de “no borres, busca” propuso una nueva forma de uso
  • La verdadera innovación de Gmail no era el almacenamiento, sino la experiencia
    • Una interfaz donde se podía leer, redactar y cambiar de correo sin recargar la página
    • Uso total de comunicación asíncrona basada en AJAX (XMLHttpRequest)
    • Demostró que la web podía ser una aplicación, no solo un documento
• Google Maps (2005) llevó esa posibilidad un paso más allá
  • Mover el mapa con clic y arrastre
  • Interacción natural cargando mosaicos en segundo plano
  • Fue en este momento cuando el término Web 2.0 se consolidó de verdad
  • Interfaces sin recarga, esquinas redondeadas, degradados y sombras se volvieron el lenguaje básico de la web
• También hubo cambios decisivos en medios y en el ámbito social
  • En video, YouTube (2005) cambió por completo el panorama
    • Se acabó el infierno de plugins como RealPlayer, QuickTime y Windows Media Player
    • Aunque estaba basado en Flash, ofrecía la experiencia de “hacer clic y reproducir de inmediato”
    • El video dejó de ser un problema técnico para convertirse en un medio de expresión
  • Twitter (2006) propuso una nueva forma de comunicación con el microblogging de 140 caracteres
  • Facebook (2006) se abrió a los usuarios generales, y las redes sociales pasaron al mainstream
  • La web pasó de ser un medio de consumo a una plataforma participativa
    • Se formó una estructura en la que cualquiera podía ser editor y creador
• A pesar de todos estos cambios, JavaScript seguía siendo doloroso
  • Debugging interminable por las diferencias entre navegadores en DOM, eventos y AJAX, además de los problemas de compatibilidad con IE6
  • jQuery (2006) prácticamente puso fin a ese caos
    • $('#el').hide() funcionaba igual en todos los navegadores
    • $.ajax() simplificó la comunicación asíncrona
    • Para muchos desarrolladores, jQuery era prácticamente JavaScript mismo
      • Al mismo tiempo, también cumplió el papel de amortiguador que evitaba entender directamente cómo funcionaban los navegadores
  • Los problemas de esta era solo después fueron reconocidos como problemas
    • SQL Injection y XSS estaban por todas partes incluso a nivel de tutoriales
    • Era común ver código que concatenaba directamente la entrada del usuario en las consultas
• En control de versiones, lo dominante era Subversion (2000)
  • Hacer commit era pesado y las ramas se evitaban
  • Nombres de carpetas como final_final_REAL eran cosa de todos los días
• No había estandarización del entorno de ejecución
  • En local: Windows + XAMPP
  • En servidor: Linux + otra versión de PHP
  • “works on my machine” se repetía una y otra vez
• Tampoco existía el concepto de package manager
  • En JS se descargaban ZIP y se administraban manualmente en la carpeta /js
  • Las librerías de PHP se copiaban archivo por archivo
• La estructura de los equipos y el proceso de desarrollo eran muy informales
  • Casi no existían roles de PM ni EM
  • No había code review
  • Se subía por FTP y se reflejaba directamente en producción
  • Si había una caída, se corregía sobre la marcha en el servidor de producción
• Aun así, la energía de esta era era intensa
  • Con PHP y hosting barato, cualquiera podía desplegar
  • Se extendió la sensación de que con AJAX se podían hacer “apps reales”
  • Con las plataformas sociales, cualquiera podía tener una audiencia
• Era el momento en que apenas comenzaban la profesionalización y estructuración del desarrollo web
  • Ruby on Rails (2004) anticipó una era más estructurada con “Convention over Configuration”
• Los desarrolladores de este período construían la web con la pila LAMP, plugins de jQuery y,
  • con la expectativa de "crear el próximo gran servicio"

La guerra de los frameworks

"Rails changed everything, then everyone copied it"

• Finales de los 2000 (late 2000s): a medida que las aplicaciones web crecían en escala, los scripts de PHP tradicionales y las estructuras centradas en trabajo manual llegaron a su límite.

• Como respuesta en esa época, empezó a ganar fuerza el desarrollo centrado en frameworks, y quien definió esa corriente fue Ruby on Rails (2004).

  • La influencia real de RoR empezó a sentirse de lleno alrededor de 2007–2008.
  • Con la filosofía de "Convention over Configuration", el framework decidía por defecto la estructura de archivos, los nombres y la forma de conectar las piezas.
  • El desarrollador solo tenía que seguir las reglas, y eso se percibía no como una restricción, sino como una liberación que daba velocidad.

• Rails presentó de una sola vez un conjunto de conceptos que después se volverían la gramática básica del desarrollo web.

  • Migraciones para gestionar cambios de base de datos mediante código.
  • ORM que reducía de forma importante la dependencia de SQL.
  • Un flujo de desarrollo con pruebas incluidas por defecto.
  • La estandarización práctica de la estructura MVC (Model–View–Controller).
  • MVC era un concepto originado en Smalltalk de los años 70, pero a través de Rails se consolidó como la forma base del desarrollo web.
  • Tras el éxito de Rails, casi todos los ecosistemas de lenguajes adoptaron esta fórmula.
    • Django (2005) en Python y Laravel (2011) en PHP establecieron una estructura al estilo Rails.
    • CakePHP (2005) y CodeIgniter (2006) también evolucionaron sobre la misma corriente.
  • El aumento de productividad no era una exageración.
    • Lo que antes correspondía a trabajo de equipo pasó a estar dentro de lo que un desarrollador individual podía construir en un fin de semana.
    • En el entorno startup, funcionó como una herramienta ideal para experimentar e iterar rápidamente.
  • De hecho, varios servicios representativos crecieron sobre Rails.
    • Basecamp (2004), Twitter (2006), GitHub (2008), Shopify (2006), Airbnb (2008)
    • Rails pronto empezó a verse como un símbolo de la velocidad startup.

• Los frameworks elevaron la productividad, pero el despliegue seguía siendo un cuello de botella.

  • En la era de PHP, desplegar por FTP era lo normal, y un solo error podía echar abajo el servicio.
  • Incluso en escenarios mejores, tareas como SSH + SVN pull + reinicio de Apache se hacían manualmente.
  • Separar directorios de release y cambiar enlaces simbólicos, entre otros pasos, hacía que todo el proceso fuera custom y frágil.

• Quien cambió este problema de raíz fue Heroku (2007), que empezó a expandirse de verdad alrededor de 2009–2010.

  • Ofrecía la experiencia de terminar un despliegue con una sola línea: git push heroku main.
  • La plataforma se encargaba de la configuración del servidor, el reinicio del servidor web y el escalado.
  • Heroku terminó consolidando en la práctica el concepto que después se llamaría PaaS (Platform as a Service).
    • Los desarrolladores pasaron a enfocarse en el código y no en la infraestructura.
    • Al popularizar los principios de Twelve-Factor App (2011), difundió una forma de pensar cloud-friendly basada en procesos stateless, configuración mediante variables de entorno y logs en forma de stream.

• Al mismo tiempo, también avanzó una gran transformación en la forma de colaborar.

  • Git (2005) introdujo un modelo de control de versiones distribuido que permitió commits, branches y merges libres en local, y como el costo de crear ramas era casi nulo, experimentar y revertir cambios se volvió algo cotidiano.
  • El anterior Subversion (2000) tenía una estructura centralizada, con ramas pesadas y merges temidos, por lo que muchos equipos dependían del desarrollo centrado en trunk.
  • Git fue una innovación a nivel de herramienta, pero GitHub (2008) lo convirtió en cultura al combinar exploración de repositorios públicos, desarrollo basado en forks y colaboración centrada en Pull Requests.
  • GitHub estandarizó la cultura del code review.
    • Antes de hacer merge de un PR, alguien tenía que revisar el código.
    • Esta práctica también se expandió al desarrollo interno de las empresas.
    • Fue el fin de la época en que el código iba directo a producción.
  • La forma de contribuir al open source pasó de enviar parches por mailing lists a mandar un PR con un clic, reduciendo mucho la barrera de entrada.

• En la parte final de este periodo también aparecieron cambios que sacudieron la identidad misma de la web.

  • El lanzamiento del iPhone (2007) y del App Store (2008) impulsó con fuerza las aplicaciones nativas.
  • La web móvil en ese momento era muy deficiente. La experiencia consistía en ver sitios de escritorio reducidos a la fuerza, con scroll horizontal y zoom constante.
    • Algunos construyeron sitios móviles separados como m.example.com, pero sus límites eran claros.
  • Las apps nativas eran rápidas, funcionaban offline, ofrecían notificaciones push y, con el lema "There’s an app for that", parecían el futuro.
  • Los desarrolladores web empezaron a pasar por una crisis de identidad: ¿había que seguir con la web?, ¿había que aprender Objective-C?, ¿la web iba a desaparecer?

• Como respuesta a esa confusión apareció Responsive Web Design (2010).

  • Ethan Marcotte (2010) propuso usar CSS media queries para ajustar el layout según el tamaño de pantalla, planteando una dirección que unificaba móvil y escritorio en una sola base de código.
  • Al principio, por la falta de madurez de las herramientas y la carga de trabajo adicional, su adopción fue lenta, pero quedó claro cuál debía ser el rumbo de la web.

• Bootstrap (2011) fue el detonante que hizo posible usar realmente la web responsiva en el campo.

  • Empezó como una herramienta interna de Twitter y ofrecía de una sola vez sistema de grid, tipografía base y estilos de formularios, dando una UI utilizable de inmediato incluso a desarrolladores sin diseñador.
  • Como resultado, la web empezó a verse cada vez más parecida, pero para muchos desarrolladores Bootstrap fue su primera experiencia con una librería de componentes y un sistema de diseño.
  • Esta corriente luego llevaría a la expansión de sistemas de diseño más estructurados, como Material Design (2014).

• La infraestructura también cambió con rapidez en esa misma época.

  • Se pasó de comprar o rentar servidores físicos por adelantado a una estructura centrada en servidores virtuales (VPS), lo que permitió crear recursos de servidor cuando hacían falta.
  • AWS (2006) fue el primero en aparecer, pero su complejidad y orientación enterprise lo hacían pesado para desarrolladores individuales.
  • DigitalOcean (2011) redujo mucho la barrera de acceso a infraestructura con droplets de $5, una UI intuitiva y una experiencia rápida de creación de servidores, dando a desarrolladores individuales una flexibilidad similar a la de grandes empresas.

• El problema del almacenamiento de archivos quedó prácticamente resuelto por Amazon S3 (2006).

  • Ofrecía un modelo simple: almacenamiento escalable sin importar la cantidad de servidores y devolución inmediata de una URL después de subir un archivo.
  • Los problemas de cargas de usuarios, respaldos y manejo de archivos en entornos con múltiples servidores quedaron ordenados de una sola vez.

• Node.js (2009) dio otro golpe de impacto a los desarrolladores web.

  • Al permitir ejecutar JavaScript en el servidor sobre el motor V8 de Chrome, parecía una opción atractiva para desarrolladores frontend, mientras que entre desarrolladores backend generaba escepticismo.
  • Su modelo de I/O no bloqueante mostraba fortalezas en aplicaciones en tiempo real, y la mayoría de los tutoriales terminaban usando una app de chat como ejemplo.
  • En ese momento, Node todavía era más una curiosidad que una tecnología mainstream de producción; los servicios reales seguían centrados en Rails, Django y PHP, y el ecosistema de npm aún estaba en una etapa temprana.
  • Aun así, la verdadera influencia de Node se haría notar primero no tanto en el servidor, sino en herramientas de build y como base de ejecución del entorno de desarrollo.

• En bases de datos, empezó a tomar fuerza la corriente NoSQL.

  • MongoDB (2009) llamó la atención por su modelo de datos orientado a documentos, flexibilidad de esquema y estructura amigable con JSON.
  • Mostraba fortalezas en prototipado rápido, escalabilidad y compatibilidad con stacks de JavaScript, pero no era adecuado para todos los servicios.
  • También eran comunes los casos en que se elegía porque “algún día tal vez escale”, y luego se descubrían límites de transacciones cuando el servicio apenas llegaba a unos miles de usuarios.

• El ecosistema startup entró en esta etapa en una fase de crecimiento pleno.

  • Con la declaración "Software is eating the world" de Marc Andreessen (2011) y la expansión de la metodología Lean Startup (2011), se consolidó el ciclo MVP → medición → iteración.

• La madurez de las herramientas empezó a hacer que la competitividad de los equipos pequeños realmente funcionara

• El proceso de desarrollo también cambió

  • Con la popularización del Agile Manifesto (2001) y Scrum, las reuniones diarias, los sprints y las retrospectivas se adoptaron casi como estándar
  • También aparecieron muchos equipos donde solo quedó la forma y no los principios
  • Las revisiones de código y las pruebas automatizadas pasaron de ser una recomendación a una expectativa básica, y los sistemas de CI ejecutaban pruebas con cada commit, acelerando la profesionalización y especialización del desarrollo de software

• Sin embargo, los roles que hoy se dan por sentados todavía no estaban establecidos

  • En 2012, era común que hubiera equipos sin engineering manager, product manager ni una gestión sistemática del backlog o de tickets
  • Los equipos pequeños y las estructuras organizativas horizontales eran lo normal, y no era raro que un “desarrollador sénior” tuviera apenas 3 años de experiencia

• Hacia 2013, la web ya tenía un aspecto completamente distinto

  • Al mismo tiempo coincidieron frameworks potentes, despliegue sencillo, colaboración social sobre código, adaptación móvil, infraestructura barata y la expansión total de JavaScript
  • La web, tras superar la crisis móvil, se volvió incluso más fuerte y terminó de prepararse para la siguiente etapa: la era en la que JavaScript lo dominaría todo

Renacimiento de JavaScript

"Everything is a SPA now"

• Hacia 2013, la web ya había demostrado, con casos como Gmail y Google Maps, que podía soportar “aplicaciones reales”, pero el enfoque tradicional de jQuery + renderizado del servidor empezó a toparse cada vez más con sus límites :contentReference[oaicite:0]{index=0}
• El problema central era la gestión del estado (state)
  • En una estructura donde el servidor genera HTML y jQuery agrega la interactividad, mantener datos e interfaz de forma coherente en varios lugares se volvía rápidamente muy difícil
  • A medida que un mismo estado debía reflejarse en varias partes de la UI, como comentarios, contadores o insignias de notificación, el código se enredaba y terminaba convertido en una estructura espagueti
• La conclusión compartida fue: movamos todo el renderizado al cliente
  • El servidor se redujo al papel de API que devuelve JSON
  • Empezó a ganar fuerza la arquitectura SPA (Single Page Application), donde JavaScript en el navegador gestiona toda la UI
• En esta etapa aparecieron los primeros frameworks SPA
  • Backbone.js (2010) ofrecía una estructura mínima con los conceptos de modelo y vista
  • Angular (2010) introdujo el data binding bidireccional y la inyección de dependencias, intentando un enfoque más empresarial
  • Ember.js (2011) propuso reglas fuertes con la meta de ser el “Rails de JavaScript”, incluyendo routing, datos y plantillas
  • Estos frameworks fueron un avance, pero en común no lograron resolver por completo el problema de la complejidad de sincronizar el DOM con los datos
    • En particular, el binding bidireccional hacía más difícil seguir el flujo de actualizaciones y aumentaba el costo de depuración
• El punto de inflexión llegó con React (2013)
  • Cuando Facebook lo publicó como open source, la sintaxis JSX provocó rechazo porque parecía invertir la separación de responsabilidades
  • Sin embargo, React propuso una nueva forma de pensar: en vez de manipular directamente el DOM, describir declarativamente el resultado de la UI según el estado
  • El núcleo de React era su modelo declarativo y el Virtual DOM
    • Cuando cambia el estado, React calcula y aplica solo los cambios mínimos necesarios en el DOM
    • El desarrollador podía concentrarse en gestionar el estado sin preocuparse por manipular el DOM
  • El concepto de componentes también fue decisivo
    • La UI se construía combinando unidades pequeñas como Button, UserAvatar o CommentList
    • Cada componente podía pensarse de forma independiente y reutilizarse
  • React se fue expandiendo poco a poco hasta convertirse en mainstream hacia 2015
    • Vue.js (2014) surgió como alternativa al ofrecer ideas similares con una sintaxis más familiar
    • La guerra de frameworks entró en una nueva fase
• La expansión de las SPA significó un aumento explosivo en la cantidad de JavaScript
  • El problema era que el JavaScript que los desarrolladores querían escribir y el que los navegadores entendían no era el mismo
• ES6 / ES2015 (2015) introdujo grandes mejoras al lenguaje, como arrow functions, clases, módulos y promesas
  • Al desaparecer el callback hell y el patrón var self = this, JavaScript por fin empezó a sentirse como un lenguaje moderno
• Pero el soporte de los navegadores iba rezagado, y desplegarlo tal cual era imposible
• Babel (2014) resolvió este problema como transpiler que convertía JavaScript moderno a ES5
  • El costo fue que la etapa de build se volvió un elemento obligatorio del desarrollo en JavaScript
  • Se terminó la era en que bastaba con modificar un archivo y recargar
• En este proceso, Node.js (2009) se apoderó de las máquinas de todos los desarrolladores no como servidor, sino como entorno de ejecución de herramientas de desarrollo
  • Incluso sin usar Node en el backend, instalar Node se volvió obligatorio por culpa de las build tools
• La cadena de herramientas de build también evolucionó rápidamente
  • Grunt (2012), como task runner, administraba pasos complejos de build mediante archivos de configuración
  • Gulp (2013) intentó simplificar eso con pipelines basados en código, pero seguía siendo complejo
• El cambio decisivo fue Webpack (2014)
  • No era solo un task runner, sino un module bundler capaz de entender el grafo de dependencias
  • Trataba JavaScript, CSS, imágenes y fuentes como módulos
  • Introdujo conceptos como code splitting y hot module replacement
  • El precio de su poder fue una configuración de fama terrible
    • La configuración de Webpack se volvió un meme, y en cada equipo existía “la única persona que entiende esto”
    • Si esa persona se iba, la configuración quedaba como una reliquia intocable que daba miedo tocar
• Al mismo tiempo, el ecosistema npm creció de forma explosiva
  • Se pasó de descargar librerías manualmente a un flujo centrado en npm install
  • Se empaquetó de todo: moment, lodash e incluso utilidades diminutas como left-pad
  • El incidente de left-pad (2016) dejó al descubierto la fragilidad del ecosistema
    • Al borrarse un paquete de apenas 11 líneas, falló al mismo tiempo el build de miles de proyectos
    • Incluso React y Babel quedaron en un estado en el que no se podían instalar
    • npm terminó restaurando por la fuerza el paquete, algo sin precedentes, para contener la crisis
  • La conveniencia se mantuvo, pero todos tomaron conciencia de la realidad del infierno de dependencias
• En 2016, la complejidad llegó a su punto máximo
  • Se difundió ampliamente el texto satírico “How it feels to learn JavaScript in 2016”
  • Se extendió el cansancio ante la idea de necesitar React, Webpack, Babel, Redux y muchas otras herramientas solo para hacer una página web simple
  • Los cambios en el ecosistema eran tan rápidos que lo aprendido quedaba obsoleto enseguida
  • Aun así, los resultados eran claros
    • Se podían crear aplicaciones web interactivas a un nivel que antes era imposible
    • La complejidad pasó a aceptarse como el costo de la ambición
• Por otro lado, Docker (2013) empezó a resolver un problema completamente distinto
  • Solucionó con contenedores el problema de “works on my machine”
  • Con un Dockerfile se definía el entorno de ejecución y podía correrse igual en cualquier lugar
  • Al principio no fue fácil adoptarlo por problemas de rendimiento en Mac y confusión con el networking
    • Docker Compose, Docker Swarm y después Kubernetes (2014) aparecieron, desatando la guerra de la orquestación
    • Hacia 2017, al menos ya estaba claro que los contenedores eran el futuro
• Junto con esto se expandió la tendencia de los microservicios
  • Ofrecían ventajas como separar servicios y permitir despliegues independientes
  • A cambio, aparecieron nuevas complejidades como service discovery, load balancing y distributed tracing
  • Muchos equipos reconocieron tarde que habían cambiado la complejidad del monolito por la complejidad de los sistemas distribuidos
• En esta etapa, la calidad de las aplicaciones web mejoró de forma visible
  • Slack (2013) reemplazó al correo electrónico como herramienta de colaboración rápida y con búsqueda
  • Figma (2016) invadió el terreno de las apps de escritorio como herramienta de diseño colaborativo basada en el navegador
  • Junto con Notion (2016) y otros casos, demostró que la web podía implementar software de nivel escritorio
  • Estos ejemplos sirvieron para justificar la complejidad de React, Webpack y la cadena de build
• La estructura organizacional también pasó a una etapa de madurez
  • Hacia 2016, los product managers y engineering managers se consolidaron como roles estándar
  • La estructura plana de los primeros tiempos fue transformándose poco a poco en organizaciones centradas en procesos
  • Scrum y los rituales ágiles se difundieron ampliamente, y según el equipo podían funcionar como herramienta o como formalidad
• En 2017, el ecosistema entró lentamente en una fase de estabilización
  • React se convirtió, en la práctica, en el ganador
  • ES6 pasó a ser la sintaxis base
  • Webpack y Docker, aunque dolorosos, fueron aceptados como estándares
• La siguiente etapa ya estaba anunciada
  • El ascenso de TypeScript
  • Los meta frameworks como Next.js
  • Una experiencia de despliegue más simple
• Pero había una condición previa
  • Solo quienes atravesaron el caos de este renacimiento de JavaScript pudieron avanzar a la siguiente etapa

La era de TypeScript

"Types are good, actually"

• Tras el renacimiento de JavaScript, la proliferación de herramientas se calmó y TypeScript ocupó un lugar clave en el punto de inflexión en que el ecosistema entró en una etapa de madurez
• TypeScript (2012) introdujo tipos estáticos en JavaScript, pero al principio fue ignorado durante mucho tiempo por la filosofía de los lenguajes dinámicos y la carga adicional de una etapa de build
  • A medida que las aplicaciones crecían, las limitaciones del tipado dinámico se hicieron cada vez más evidentes
    • Aumento del costo de rastrear los puntos de llamada tras cambiar la firma de una función
    • Problemas de legibilidad en código donde era difícil entender la forma de los objetos
    • Casos repetidos en los que un simple error tipográfico terminaba causando fallas en producción
  • A partir de 2017–2018, la adopción de TypeScript se expandió rápidamente
    • Mayor seguridad al refactorizar mediante autocompletado y análisis estático
    • Las interfaces pasaron a cumplir el papel de documentación obligatoria sincronizada con el código
  • La adopción por parte de los principales frameworks funcionó como punto de inflexión
    • Angular adoptó una estrategia prioritaria para TypeScript
    • La madurez de las definiciones de tipos de React y la reescritura de Vue 3 basada en TypeScript hicieron que se percibiera como el estándar de facto
    • Desde alrededor de 2020, casi ya no se elegía JavaScript puro para proyectos nuevos
  • TypeScript mejoró enormemente la accesibilidad de las bases de código
    • Quienes se incorporaban al equipo podían entender el modelo de dominio con solo leer las definiciones de tipos
    • Al reducir la dependencia del conocimiento implícito, bajó el costo de escalar los equipos
• La combinación con VS Code (2015) cambió de forma decisiva la experiencia de desarrollo
  • Ofrecía autocompletado inteligente, errores en línea y refactorizaciones confiables
  • Sublime Text y Atom fueron perdiendo influencia gradualmente
• Encima de React se formó otra capa de abstracción
  • Como biblioteca de UI, React no ofrecía una solución base para routing, data fetching ni SSR
• Next.js llenó ese vacío como un meta-framework que ofrecía por defecto routing basado en archivos, server-side rendering, rutas API y code splitting automático
  • Aparecieron distintos frameworks en respuesta, como Nuxt, Remix, SvelteKit y Gatsby
  • En el ecosistema de React, Next.js se consolidó como la opción predeterminada de facto
• La expansión de los meta-frameworks alivió en gran medida el cansancio por la fragmentación del tooling de la era anterior
  • El proceso de ensamblar manualmente configuraciones de webpack y Babel quedó absorbido por los valores por defecto
• El entorno de despliegue también se simplificó rápidamente
  • Vercel y Netlify ofrecían despliegues automáticos y entornos de preview con solo conectar GitHub
  • Diseñadores, PM y QA podían revisar cambios en un entorno real antes del merge
• La influencia de Heroku se debilitó, mientras surgían nuevas PaaS como Railway y Render
• El concepto de Serverless se expandió alrededor de AWS Lambda (2014)
  • Ofrecía cobro por uso y escalado automático
  • No era una solución universal debido a los cold starts, la gestión de estado y las limitaciones para depurar
  • Cloudflare Workers amplió esto con un modelo de ejecución en el edge
• En el área de CSS también avanzó una transición silenciosa
  • Después de Sass y Less, y tras pasar por CSS-in-JS, Tailwind CSS (2017) fue adoptado de forma masiva
  • El enfoque basado en clases utilitarias
    • eliminó la carga de nombrar clases
    • redujo los problemas de cascade y specificity
    • y, en consecuencia, permitió mantener hojas de estilo más pequeñas
• GraphQL (2015) llamó la atención como una solución potente para aplicaciones que manejaban estructuras de datos complejas
  • Ofrecía ventajas como consultas precisas de datos, esquemas basados en tipos y un buen ecosistema de herramientas
  • Pero por la complejidad de la capa de servidor y la dificultad del caching, resultaba una opción excesiva para CRUD simples
  • Algunos equipos mantuvieron REST o eligieron alternativas más simples como tRPC
• La competencia en orquestación de contenedores se resolvió alrededor de 2018 con la victoria de Kubernetes
  • Era potente, pero implicaba un alto costo de aprendizaje y complejidad operativa
  • Para muchos equipos era una solución excesiva, lo que ayudó al resurgimiento de las PaaS
• COVID (2020) expandió bruscamente la demanda de desarrollo web
  • El trabajo remoto, el comercio electrónico y las herramientas de colaboración se volvieron indispensables
  • Esto llevó a un aumento explosivo en la demanda de desarrolladores y al rápido crecimiento de empresas de herramientas para desarrollo
• En entornos remotos creció la importancia de la colaboración asíncrona y la documentación
  • La revisión de código, las descripciones de PR y la calidad de la documentación interna se volvieron elementos clave
• También a nivel organizacional avanzó la madurez
  • Se consolidaron los sistemas de niveles de ingeniería
  • Se legitimó la trayectoria de IC
  • Se diferenciaron los roles de PM, EM y tech lead
• Developer Experience (DX) pasó a ser vista como un objetivo de inversión independiente
  • Los equipos de plataforma interna, CI rápida y mejoras en onboarding surgieron como factores clave de productividad
• Hacia 2022, el desarrollo web llegó a ser complejo pero manejable
  • TypeScript como valor por defecto
  • Un ecosistema centrado en Next.js
  • Automatización de despliegues y un sistema de herramientas maduro
• Y entonces todo cambió: una empresa llamada OpenAI lanzó algo llamado ChatGPT

El momento de la IA

"Wait, I can just ask it to write the code?"

• Con el lanzamiento de ChatGPT (2022) apareció una experiencia en la que bastaba con escribir una pregunta para obtener explicaciones, código y resultados de depuración, y eso cambió las reglas del desarrollo
  • Podía hacer desde explicaciones de física cuántica hasta debugging en Python, y aunque no era perfecto, el hecho de que fuera lo suficientemente útil resultó impactante
  • Los desarrolladores empezaron a experimentar de inmediato, y escribir componentes de React, analizar la causa de errores o convertir código entre lenguajes pasó a ser posible en segundos, sin buscar documentación ni recorrer foros
• GitHub Copilot (2022) llevó la generación de código al editor en forma de autocompletado y expandió una experiencia de autocompletado ultrapotente capaz de proponer implementaciones solo a partir de comentarios
  • La nueva meta-habilidad de evaluar, aceptar, modificar o rechazar rápidamente sugerencias de IA pasó a ser una capacidad central del desarrollador
• Tareas como boilerplate repetitivo, escritura de tests y manejo de edge cases se aceleraron drásticamente, haciendo posible desarrollar sin romper el flujo
• Cursor (2023) integró la IA no como una función sino como una condición base del IDE, permitiendo seleccionar código y pedir refactorizaciones, modificar múltiples archivos a partir de descripciones en lenguaje natural y conversar con la base de código
• Este cambio sacudió el significado de la seniority, pero en realidad hizo aún más importante la capacidad de decidir qué construir y evaluar requisitos, restricciones y efectos secundarios
  • La IA puede escribir código, pero no puede definir el problema ni elegir la dirección correcta
• Hubo reacciones extremas, desde “el fin de la programación” hasta “una moda inútil”, pero el resultado real fue una amplificación de la productividad de los desarrolladores que usan IA
• La barrera de entrada para proyectos personales y side projects cayó drásticamente, y áreas que antes no se intentaban —como ML, juegos o nuevos frameworks— pasaron a ser accesibles mediante aprendizaje basado en conversación
• Esta tendencia funciona como una etapa que acelera la vieja dirección de la web: la democratización de la creación
  • El centro se mueve de saber programar a saber qué se quiere construir
• Incluso personas no desarrolladoras participan en la creación de prototipos, y PM, diseñadores y expertos de dominio crean herramientas por sí mismos, difuminando la frontera entre lo técnico y lo no técnico
• Aumentaron los indie hackers y los solo builders, y se volvió real un entorno en el que una sola persona puede crear un producto sustancial
• Al mismo tiempo, herramientas como React Server Components, htmx, la mejora de los estándares de CSS y JavaScript, y Bun reforzaron la idea de “usar la propia plataforma”
• Tras el gran boom de contrataciones de 2022–2023 y las posteriores reestructuraciones, el mercado se sacudió, pero la IA no reemplazó a los desarrolladores y la capacidad de aprovechar IA pasó a ser una expectativa básica
• En 2025, el desarrollo web está en el momento más rápido de su historia desde la idea hasta el despliegue, y
  • en un entorno donde se combinan la nube, los frameworks y la IA, las personas son más poderosas que nunca como creadoras
• La promesa de la web que empezó con la etiqueta <br>, “cualquiera puede crear y compartir”, sigue viva en una forma aún más fuerte en la era de la IA
• Ahora mismo es un muy buen momento para dedicarse al desarrollo web

[ethanhur]

Lo leí con gusto, como si fuera un libro de historia.

[zihado]

En aquella época contrataba un hosting de servidor en Cafe24, instalaba ZeroBoard y me divertía armando lo que a mi manera era una comunidad, jaja

[lethee]

Lo leí con gusto. Me dio una sensación como de flashazos que te pasan por la mente antes de morir, jaja.

[edunga1]

Lo leí con gusto.
Si nos vamos al entorno de desarrollo, aparecen VS Code y LSP. Y hasta podría conectarse con herramientas anteriores a la era de la IA de Tabnine.

[aer0700]

JavaScript의 간략한 역사
Creo que queda bien verlo junto con este artículo.

[GN⁺]

Comentarios de Hacker News

• No es del todo cierto decir que no había forma de compartir el mismo encabezado, navegación y pie de página en todas las páginas.
  Los servidores web tenían Server Side Includes (SSI), y si no querías usar eso, también se podía resolver simplemente con el comando cat header body > file.
  Documentación relacionada: tutorial de NCSA SSI (1997)

  • Como HTML se creó originalmente como un vocabulario basado en SGML, SGML y XML tenían funciones de entidades/macros de texto para referenciar fragmentos de documento como encabezados o pies de página comunes.
  • Supongo que el comentario original se refería solo a HTML puro.

• Pensé que habría sido bueno que el artículo terminara con una frase como: "...y en medio de todo ese proceso, la humilde etiqueta <br> sigue cumpliendo su función".

• En una empresa donde trabajé antes, usaban un sistema en el que se creaba una carpeta nueva en cada despliegue y se cambiaba el enlace simbólico a la versión más reciente.
  Era manual, pero me parecía una forma realmente elegante porque permitía una conmutación atómica en cada servidor y hacía muy fácil el rollback.
  Antes de eso, había que copiar archivos manualmente a decenas de servidores y ejecutar directamente entre 10 y 20 comandos, así que comparado con eso era mucho más seguro y simple.
  Más adelante probé herramientas de automatización, pero como la configuración era compleja y opaca, terminaban siendo un proceso de despliegue más frágil.

• Está eso de que “para usar scripts CGI había que aprender Perl o C”, pero me pregunté si de verdad hacían falta cientos de líneas.
  En la práctica, se pueden leer parámetros de URL incluso con una función simple en C.
  Hace poco hice un sitio web de encuestas en C puro, y fue bastante llevadero gracias a una biblioteca para generar HTML que había hecho antes.
  Reutilicé refactorizada la biblioteca CGI del sistema operativo y enlacé SQLite de forma estática para desplegarlo como un binario único.
  También se podía probar sin servidor web, usando stdin/stdout.
  En resumen, un sitio web CRUD también puede ser suficientemente fácil en C, y como HTML tiene una estructura de árbol, creo que la interpolación de cadenas (string interpolation) es un enfoque equivocado.

  • Como el código hace match con el primer parámetro que termina en <param>, puede que no coincida exactamente, y además no maneja el percent-encoding.
  • Estoy de acuerdo con la idea de que, como HTML representa una estructura de árbol, la interpolación de cadenas no es apropiada.
    Pero incluso 30 años después, sigue pareciendo que la interpolación de cadenas es la herramienta más común.

• Fue un artículo muy completo y muy bien escrito.
  El autor es optimista, pero a mí el desarrollo web me parece una torre inestable hecha de parches acumulados.
  Creo que, a medida que la estandarización web quedó dominada por unos pocos vendors de navegadores, el resultado fue seguir poniendo capas encima sin resolver los problemas de fondo.
  Las herramientas recientes de IA generativa también son solo soluciones temporales para esquivar esa complejidad.
  Al final, creo que esa torre se va a derrumbar algún día.

• Este artículo probablemente va a quedar como un clásico.
  Resume de forma concisa la historia de la tecnología web que muchos desarrolladores actuales se perdieron.

• Al leer la parte de “Virtual private servers changed this…”, me acordé de algo.
  En realidad, el primer proveedor de VPS fue JohnCompanies alrededor de 2001, y estaba basado en FreeBSD jail.
  Los clientes querían respaldos remotos y preferían rsync.
  Por eso, cuatro años después registré el dominio rsync.net (con permiso de los autores de rsync/samba).

• Hice desarrollo web desde 1998 hasta 2012, y leer esto fue como un viaje de nostalgia.
  También funciona como un resumen que deja ver de un vistazo los cambios posteriores.

• El contenido del artículo coincide casi por completo con cómo recuerdo la evolución de la tecnología web.
  El CGI antes de PHP era engorroso, pero con mod_perl y FastCGI era utilizable.
  Escribir CGI en un lenguaje compilado era casi masoquismo, y PHP en ese sentido era ligero y divertido.
  Yo dejé el desarrollo frontend justo antes de que despegara jQuery.

• Fue un texto realmente asombroso.
  No solo enumera una cronología tecnológica, sino que transmite con mucha viveza el zeitgeist de cada época.
  Me impresionó cómo logró plasmar por escrito el contexto humano que normalmente solo se transmite de forma oral.
  Más que criticar “por qué llegamos a este mundo tan complejo de la nube”, ayuda a entenderlo como un resultado histórico de decisiones racionales acumuladas en cada momento.
  Se puede sentir la ironía de la historia humana dentro de la historia de la tecnología.