¿Cuál es la historia técnica del desarrollo web?

Los viejos tiempos (ish)

En los viejos tiempos (alrededor de 1993), no teníamos un servidor de fondo. Todo era solo * el servidor web *. Tiene un navegador y un servidor, y si puede conectarse al servidor antes de que su módem de 14.4k agote el tiempo de espera para descargar una página web de 150 bytes, entonces tendrá suerte ese día, siempre que alguien no trató de hacer una llamada telefónica y desconecté su conexión. ¡Uy!

¿Quieres un viaje por el carril de la nostalgia? Aquí hay un video de YouTube del sonido de un módem que se configura a sí mismo mientras se conecta al ISP:

No había código involucrado en el desarrollo web en este momento. JavaScript en el navegador no existía. CGI no existía. Solo páginas HTML. ¡Eso es! Fue un momento muy simple, pero extraordinariamente difícil de poner en funcionamiento incluso un servidor básico y servir su código. Realmente hemos recorrido un largo camino desde esta vez.

Mosaic fue el primer navegador gráfico de la época, lo que significa que podía usar la etiqueta IMG. Aquí está Marc Andreesen (¿lo reconoce, el capitalista de riesgo?) Hablando de una nueva etiqueta IMG propuesta en febrero de 1993: nueva etiqueta propuesta: IMG.


Aparición

Alrededor de 1994 y 1995, surgieron más comentarios sobre cómo mejorar el comercio electrónico en lugar de WWW. Netscape presenta SSL, que cifra las transacciones seguras. Amazon y eBay se lanzan alrededor de este tiempo, junto con muchos otros. En algún momento alrededor de 1992 o 1993 fue cuando aparecieron las primeras tiendas, pero eran pasos pequeños y apenas reconocibles por los estándares actuales de comercio electrónico.

Entonces, 1994-ish es cuando comenzamos a ver que los servidores backend realmente se hicieron populares. CGI ha existido durante aproximadamente un año en este punto, y realmente era un poco del salvaje oeste. La gente escribía sus propios servidores web personalizados que ejecutaban un script que podía responder a cualquier solicitud del navegador y generar el HTML requerido.

Entienda, CGI es muy simple, pero define información muy importante como un estándar que todavía usamos hoy, como las variables del servidor. Esencialmente, CGI toma una solicitud HTTP sin procesar, analiza algunos de sus datos, proporciona datos del servidor al entorno y envía HTML de vuelta dentro de una respuesta HTTP al navegador. En su mayor parte, las aplicaciones CGI se escribieron en Perl porque fue el primer motor y ya era un lenguaje conocido para los hackers de Linux en ese momento, pero no había una definición estricta al respecto. Podrías haberlos escrito en C o en cualquier otro lenguaje que se pudiera llamar como ejecutable.

¿El problema principal? Cada solicitud web a su servidor inicia el ejecutable. No vive en la memoria, tiene que comenzar de nuevo cada vez. Hoy en día probablemente puedas salirte con la tuya. Entonces, era costoso para la CPU, y la única razón por la que no importó tanto es porque solo había unas 12 personas en la WWW 🙂

Entonces, CGI es el primer motor en este espacio. Proporciona lo más poderoso que conocen las computadoras: la capacidad de procesar. Recuerde, anteriormente solo teníamos entrada y salida, pero ningún procesamiento intermedio. CGI colmó esta brecha y permitió a los programadores definir comúnmente cómo se iba a interactuar con el trabajo, por el bien de la estandarización (y la facilidad de resolución de problemas).


PHP y ASP arruinan Internet. Además, JavaScript.

PHP se lanzó inicialmente, para el placer y posterior disgusto de los programadores de todo el mundo. ASP pronto sigue. Es 1995/96. La WWW se está dando cuenta. Se están escribiendo artículos sobre la autopista de la información. Los medios de comunicación despiertan un frenesí sobre lo aterrador y sorprendente que es al mismo tiempo Internet. Todavía están vendiendo la misma historia 2 décadas después.

No estoy seguro de cuál es la peor abominación, PHP o ASP. Ambos fomentaron el código de espagueti, HTML mezclado con estilos de programación declarativos y basados ​​en objetos (y no orientados a objetos), y fue terrible. Fue uno de los peores momentos para ser desarrollador en muchos sentidos, porque todos (incluido yo mismo) escribían basura absoluta y creaban un software web increíblemente grande y poderoso.

Logré migrar mi sitio web de emulación de Super Nintendo de páginas HTML estáticas en Geocities (¿recuerdas esa atrocidad?) A una página ASP dinámica en esta época. ¡Incluso funcionó a veces! También escribí mi propio sitio web y blog, a pesar de que no valía la pena escribir el mío, porque software como Movable Type y Blogspot comenzaban a salir de la carpintería.

JavaScript es inventado y lanzado como parte del navegador Netscape. A pesar de ser un estándar, Microsoft se supera a sí mismo una vez más y lanza una versión incompatible de JavaScript llamada JScript que apesta totalmente, pero finalmente se apodera del mercado porque monopolizaron el mercado de los navegadores hacia el final del siglo.


Construcción principios de siglo

Finalmente, la gente comenzó a darse cuenta de que Rasmus Lerdorf probablemente no es demasiado bueno para diseñar lenguajes de programación y tuvo otra mirada al estado de la web. Los navegadores básicamente apestaban en este punto en el tiempo, por lo que a pesar de que JavaScript existía, la mayor parte de la funcionalidad que puedes hacer hoy realmente no existía. En cambio, comenzamos a usar Flash. Yay Flash!

Casi todos hoy en día odian Flash porque ha tenido algunos problemas de estabilidad y rendimiento a lo largo de los años debido a la mala gestión del producto. Sin embargo, en 2000-2001, fue un salvador. ¡No solo podría ejecutar animaciones en la web, sino que también podría escribir aplicaciones de una sola página! Ajax y otras tecnologías todavía tenían algunos años de descanso, pero con Flash en realidad podría escribir una aplicación real en vivo en la web y hacerla interactiva, animada, interesante y divertida. Si Flash hubiera sido mejor administrado e integrado en el navegador, posiblemente podría haber sido un motor de diseño en lugar de los que tenemos ahora.

Desarrollé una gran cantidad de software divertido en Flash en esta época, incluido el proceso de solicitud en línea para mi universidad. Estábamos a la vanguardia en ese momento, y pagó dividendos para la escuela y para mi carrera.

En cualquier caso, la gente comenzó a pasar de ASP en esta época porque era realmente difícil hacer aplicaciones orientadas a bases de datos. Estaba prácticamente garantizado que destruiría su servidor MySQL, y si tuviera la suerte de poder permitirse el lujo de SQL Server, en realidad podría hacer algo de trabajo.

Apache estaba luchando contra el IIS de Microsoft para compartir el servidor, y aquí es cuando la división de desarrolladores más grande comenzó a suceder: los nuevos desarrolladores tendían a convertirse en defensores de código abierto y ejecutaban pilas de LAMP, o seguían la ruta de Microsoft y usaban herramientas basadas en Windows, incluido el nuevo ASP.NET prometedor.

Hablemos de .NET. Probablemente fue la mejor y más completa cadena de herramientas de programación que podría obtener en ese momento. Manejo sólido de XML, que fue el status quo del día. Bibliotecas principales fáciles de usar y extremadamente completas, con una manera fácil de obtener más y, finalmente, la capacidad de escribir código de la misma manera para la web y el escritorio. Si bien no puede simplemente ejecutar el mismo código todo el tiempo, definitivamente puede crear bibliotecas que se ejecuten en ambos, lo cual es importante en el software empresarial y en la creación de una intranet o extranet.

La primera versión de ASP.NET fue bastante apegada por los estándares modernos, pero no fue demasiado horrible de usar en ese momento, y fue una gran mejora en muchos sentidos para los desarrolladores. Era pesado, y mantenía el estado de visualización por defecto, y no era apátrida como la gente estaba acostumbrada a desarrollar en la web. Esto fue un gran problema, y ​​desde entonces se han alejado de este modelo, pero fue enorme poder almacenar rápida y fácilmente datos complejos de usuarios en el estado de visualización y guiarlos a través de una sesión o una compra de manera segura, sin almacenar todo en sesión en el servidor. Desventajas? El ancho de banda era una bestia. Algunos desarrolladores decidieron almacenar todo en el estado de vista y terminarían con una página HTML de 1 MB. Ups


web 2.0

Hasta este momento, hemos estado peleando guerras de navegador. No tenemos muy buen soporte multiplataforma en HTML, CSS y JavaScript. Internet Explorer no se ha actualizado en años y hay un gran movimiento vocal por parte de los desarrolladores web para impulsar. Los estándares web son una gran cosa. Los marcos de JavaScript comienzan a aparecer. jQuery, Dojo y Prototype se lanzan y hacen que sea fácil para todos escribir JS una vez y ejecutarlo en cualquier navegador. No estoy seguro de poder expresar lo PODEROSO que es esto para los desarrolladores web. Puso de cabeza a toda la industria.

Antes, si tenía algún trabajo que hacer, lo hacía todo en el servidor y cada pequeña cosa que hacía en la página requería una actualización completa. Después de alrededor de 2004/05, todos intentaron ver cuánto podían hacer con JavaScript del lado del cliente. Este cambio probablemente hizo que muchas tecnologías web potenciales fueran relativamente obsoletas. Tenga en cuenta que Microsoft está lanzando .NET, y todavía están bombeando la mentalidad de estado de vista constantemente refrescante. Esto era algo completamente diferente, y MS tuvo que reescribir realmente toda su estrategia web debido a eso.

CSS se avanza mucho en este período de tiempo gracias a Firefox y Opera. Internet Explorer 6 sigue pasando el rato muriendo lentamente, pero la gente todavía se ve obligada a apoyarlo. Se lanzan cantidades masivas de hacks para admitir navegadores antiguos y superar los límites, particularmente en A List Apart y otros sitios.

En el backend, somos testigos del nacimiento de algunos marcos que también destruyen la participación de mercado de Microsoft. Ruby on Rails, Django, CodeIgniter y otros frameworks de código abierto se lanzan, y se centran primero en el usuario final, sin embargo, facilitan la integración con los sistemas existentes y crean algo nuevo muy fácilmente. Los andamios y los ORM se vuelven comunes básicamente de la noche a la mañana.

Si estamos hablando de que la comunidad de desarrollo web está subiendo de nivel, este es probablemente el momento más influyente en su historia hasta ahora. Tenemos navegadores que son cada vez mejores para apoyar a más personas. Los servidores web se están separando de los servidores de aplicaciones, por lo que puede ejecutar su aplicación en segundo plano y simplemente hacer que interactúe con su servidor web, lo que aumenta drásticamente el rendimiento. Los marcos de back-end ahora se centran en un desarrollo rápido y pruebas automatizadas. Los desarrolladores lo tienen más fácil que nunca en este momento.

Esta es la era en la que tenemos muchos desarrollos fantásticos que se volvieron comunes, gracias a los esfuerzos de estos marcos:

  • Pruebas automatizadas estandarizadas
  • Desarrollo rápido a través de andamios UI
  • Interacción nativa con Ajax en el backend
  • Las interfaces web RESTful conducen a arquitecturas más orientadas al servicio
  • Las manipulaciones en el navegador se sincronizan automáticamente con el servidor

Plataformas y Devops

¿Estás perezoso?; Eres perezoso? Estoy. Me gusta encontrar las formas más fáciles de hacer las cosas, y realmente no me gusta tener que jugar con las configuraciones básicas del proyecto una y otra vez. Es por eso que otros desarrolladores perezosos decidieron hacer excelentes herramientas de plataforma como Heroku, que fue uno de los primeros proveedores de PaaS que facilitó la creación y el lanzamiento de una aplicación. Vagabundo y otras herramientas de virtualización similares crearon una forma de ejecutar programáticamente toda su pila sin configuración. Amazon lanzó AWS en medio de muchos otros seguidores, y ahora tenemos todas estas herramientas a nuestro alcance que nos permiten crear software casi de inmediato.

Piense en esto: si tiene una idea de software en 1999, probablemente necesite unos meses para adquirir su servidor y conectarlo, instalar todos sus requisitos de software en él, recompilar Linux sin cesar, escribir su código, actualizar su esquema de base de datos 100 veces, y luego ejecuta tu código. Estás buscando meses de trabajo para algo básico, tal vez semanas en el mejor de los casos para algo simple como una aplicación de lista de tareas. Cientos de horas hombre.

Hoy puedo hacer una aplicación completa en menos de 10 horas y tenerla implementada en mi servidor casi al instante. Eso es increíble.

Este es el poder de subir de nivel, y lo vemos mucho en el desarrollo web.

Por supuesto, ahora hay algunos nuevos lenguajes y marcos que también deberían mencionarse. Node es nuevo, Angular and React y otros frameworks del lado del cliente han dejado obsoletos muchos frameworks de back-end. También se han producido grandes cambios en Microsoftland, con nuevos lanzamientos de MVC que luchan por mantenerse al día con la industria (IMO), pero que, sin embargo, son muy buenos productos.

Uno de los logros más destacados hasta ahora es npm, el administrador de paquetes de Node. Simplemente muestra cómo incluso el software mal hecho y mal administrado puede ser exitoso. Para pasar un buen rato, juegue un juego de bebida en el que dispara cada vez que sueltan accidentalmente y vuelven a lanzar algo que no deberían tener.


La mayor parte de la innovación en el desarrollo web se produjo al centrarse en las herramientas de desarrollo. Hace dos décadas, no teníamos muchas herramientas suficientes para el desarrollo web. Teníamos editores de texto y teníamos la esperanza de que las cosas funcionaran. Ahora, tenemos plataformas y servicios completos dedicados a simplificar la construcción, implementación y ejecución de software. Es realmente sorprendente lo lejos que hemos llegado, incluso en los últimos 10 años, ahora que la atención y el enfoque no se centran tanto en lo que los navegadores pueden y no pueden soportar. Todos son tan buenos hoy en día que ya ni siquiera es un foco. Y los servidores web y los marcos son tan completos y maduros que prácticamente no hay nada que no puedas hacer, sin importar el marco que elijas.

Me sorprende lo increíble que es nuestra tecnología y cuánto ha progresado. Bueno para nosotros.

Realmente no hay un solo historial de desarrollo web. El “desarrollo web” no fue una progresión lineal de tecnologías donde una tecnología fue reemplazada unilateralmente por una tecnología mejor y más nueva. La web es inherentemente un lugar descentralizado en el que cada uno hace lo suyo con su propia combinación de opciones tecnológicas.

No progresó como Perl -> PHP -> Ruby on Rails -> Python -> Node.js, etc. En cambio, todas esas tecnologías coexistieron en diferentes momentos superpuestos, cada uno de los cuales se desarrolló en paralelo y tomaron prestadas ideas entre sí y mejorando sobre ellos.

La historia de la web comienza con Tim Berners Lee, quien inventó el protocolo HTTP que simplemente permite que un cliente web (que finalmente se convirtió comúnmente en lo que llamamos un navegador) solicite información de un servidor web (todavía los llamamos servidores web) y servidor para responder a la solicitud con la información deseada.

Al principio, muchas páginas web eran solo páginas HTML estáticas editadas a mano y servidas por servidores web sin realizar ningún cambio real. A medida que pasaba el tiempo, los programadores, siendo las personas perezosas que eran, decidieron que querían poder escribir programas de computadora para generar nuevas páginas automáticamente sobre la marcha, dependiendo de lo que se solicitó, por lo que se inventó CGI como una forma de entregar un mensaje entrante solicitar a un programa externo, a menudo Perl, para que se pueda generar un nuevo documento o “página web” y luego devolverlo al servidor para entregarlo al cliente.

Con el tiempo, las bases de datos se convirtieron en un método cada vez más popular para almacenar información en sitios web y permitir que se personalizaran para cada usuario individual. (Piense en Quora. La información sobre cada usuario y sus intereses e interacciones se almacena en una base de datos y es analizada por un programa cuando inicia sesión para proporcionarle una lista individualizada de preguntas que le interesaría más leer). Básicamente, muchas aplicaciones web se convirtieron en aplicaciones de bases de datos con una interfaz basada en web. Después de un tiempo, el software de bases de datos utilizado se convirtió en importación, si no más, que el lenguaje de programación utilizado. Esto provocó la idea de una “pila” de desarrollo web que era básicamente una lista de todas las tecnologías utilizadas en un sitio web en particular. Por ejemplo, una pila popular era LAMP (sistema operativo Linux, servidor web Apache, servidor de base de datos MySQL y lenguaje de programación PHP). Había y sigue habiendo muchas combinaciones de diferentes tecnologías en cada capa para elegir.

En el lado del lenguaje de programación, Perl fue muy popular desde el principio, pero con el tiempo fue eclipsado en gran medida por PHP. No es que PHP pueda hacer nada que Perl no pueda, pero se integró mejor con Apache, el servidor web más popular, lo que facilitó la tarea de comenzar a trabajar de inmediato. Debido a esto, a menudo las compañías de alojamiento web lo ofrecían por defecto y, a veces, serían las únicas opciones para las soluciones de alojamiento de bajo costo.

Al mismo tiempo, había una pila común de Microsoft con ASP incluido y el servidor web IIS de Microsoft ejecutándose en Windows. También Java siempre ha sido bastante popular en la web y, más recientemente, Python ha sido ampliamente adoptado.

Más tarde, Ruby on Rails entró en escena con algunas ideas nuevas. Ruby, el lenguaje de programación ha existido durante mucho tiempo, probablemente al menos tanto como PHP, pero no se usó realmente en la web mucho antes de que se creara el marco de la aplicación web Rails. Fue escrito en Ruby, por lo tanto, “Ruby on Rails”. Lo que hizo el marco de Rails fue forzar al desarrollador a usar un modelo MVC que, aunque no era una idea nueva, no se usaba comúnmente en el desarrollo web. El modelo MVC funcionó bastante bien para muchas aplicaciones web, por lo que fue rápidamente adoptado por muchos desarrolladores web que crearon sus propios marcos MVC en sus propios idiomas de elección. Por ejemplo, “Cake PHP” fue un marco MVC temprano popular para PHP.

Más recientemente, los desarrolladores web se enfrentan comúnmente a problemas de escalabilidad, tratando de proporcionar servicios a más y más personas a la vez, piensen en Twitter o Facebook con sus cientos de millones o incluso miles de millones de usuarios. Por lo tanto, las nuevas tecnologías más livianas han aparecido en gran medida, como los servidores de bases de datos NoSQL, que tienden a hacer su trabajo más rápido pero con menos funciones y lenguajes de programación asincrónicos como javascript que se ejecuta en Node.js. Si bien estas tecnologías son nuevas y brillantes, no son un sustituto de todo lo que se les ha presentado antes. Son solo algunas herramientas nuevas que se agregarán a una larga lista de herramientas existentes y excelentes que vinieron antes que ellas.

Entonces, realmente no hay una historia lineal de desarrollo web, sino una red complicada, orgánica y enredada de herramientas de enclavamiento, muy parecida a la composición de la web.

Mi interés en codificar mis diseños se perdió en el momento en que me di cuenta de cuánto truco había que hacer para que sucediera. Problemas aparentemente simples podrían resolverse de muchas maneras. Sin embargo, todavía podría no haber funcionado en algunos navegadores.
Una cosa que siempre me hizo preguntarme es por qué hay una división entre diseño y código. ¿Por qué las cosas difíciles se vuelven más simples, pero las cosas simples se vuelven más difíciles?
Entonces, en lugar de debatir si los diseñadores deberían aprender el código o los desarrolladores deberían aprender el diseño, establezcamos una base común sobre cómo evolucionó el diseño para la web y cómo podríamos cerrar la brecha entre el código y el diseño.

El navegador mosaico

Mosaic no fue el primer navegador, pero fue el que popularizó Internet para muchos. Lanzado en 1993, soportaba marcadores e imagen en línea. Antes, las imágenes de mosaico debían descargarse y verse por separado del contenido de la página. Mosaic era, en ese momento, el navegador más fácil de usar disponible hasta cierto punto. Permitió a los usuarios no técnicos comprender la web por primera vez.

Galletas

El soporte para cookies, pequeños archivos que pueden almacenar las preferencias de los usuarios de la web, fue respaldado por lo que entonces era el navegador Mosaic Netscape en 1994. Si bien a lo largo de los años han ganado una mala reputación por rastrear la actividad del usuario en línea, en realidad han jugado un gran papel en agregar una capa de sofisticación programática a la web. Tal ha sido su impacto que solo ahora estamos implementando métodos mejorados de almacenamiento web para reemplazar su uso.

CSS

CSS, tal como lo conocemos hoy, apareció en 1994. Fue propuesto por el CTO del navegador Opera Hakon Wium Lie. Como pionero de la web, Hakon ha desempeñado desde entonces papeles clave en la adopción de las fuentes descargables y la etiqueta HTML. Si bien la separación de la presentación y el contenido que CCS facilita es algo que ahora damos por sentado, aquellos que recuerden el desorden de las tablas HTML hechas en la web siempre estarán agradecidos por el día en que el W3C aprobó el ‘Nivel 1 de CSS’

PHP

Es difícil imaginar una World Wide Web sin PHP, pero antes de 1996 eso era exactamente lo que teníamos. Adoptado rápidamente después de su lanzamiento como un lenguaje web central (se ejecuta en un servidor, puede integrarse en HTML y es compatible con bases de datos SQL, el lenguaje ahora se usa en más del 80% de todos los sitios web.

AJAX

No es frecuente que se atribuya a Microsoft el cambio de la web para mejorar, pero con AJAX eso es exactamente lo que hicieron. Su implementación de una técnica llamada XMLHTTP en la aplicación web de Outlook allanó el camino para lo que ahora llamamos AJAX. Esta técnica permite a los navegadores web obtener nuevos datos sin actualizar la página, lo que les da a las aplicaciones web la capacidad de actuar mucho más como sus contrapartes de escritorio.

Aquí hay una publicación de blog que podría ayudarlo a responder esta pregunta: Historia del desarrollo web de un vistazo | Correlsense