¿Por qué la web ganó el espacio de las aplicaciones remotas y X no?

El sistema X Window tiene 25 años, ayer cumplió años (el día 15).

Como probablemente sepa, una de sus características más importantes es la separación del lado del servidor y del lado del cliente de una manera que ni los sistemas de ventanas de Microsoft, Apple o Wayland tienen.

En el pasado (perdón por la redacción ambigua), muchos creían que X dominaría sobre otras formas de hacer ventanas debido a esta separación de servidor y cliente, lo que permite que la aplicación se ejecute en un servidor en otro lugar mientras el usuario hace clic y escribe en ella computadora propia en casa.

Obviamente, este uso todavía existe, pero en el mejor de los casos está marginado. Cuando escribimos y usamos programas que se ejecutan en un servidor, casi siempre usamos la web con html / css / js.

¿Por qué ganó la web y X no? Las tecnologías utilizadas para la web (dicho html / css / js) son un desastre. Combinado con todos los marcos de back-end (Rails, Django y todos), es realmente una jungla para navegar. Aún así, la web prospera con creatividad y progreso, mientras que las aplicaciones X remotas no.

Parece completamente obvio y fundamental ahora, pero la innovación asesina de la red mundial fue el hipervínculo. Incluso si X no fuera completamente inutilizable a través de un enlace de módem, su incapacidad para iniciar un proceso completamente nuevo en un servidor completamente nuevo a través de un solo clic dificultaría su adopción para ese tipo de casos de uso.

Porque X requiere que tengas un título de CS para escribir una solicitud. Si bien la Web requiere que tengas la capacidad de escribir (ni siquiera eso).

Especialmente en los primeros días cuando la web era solo html. Puede abrir una terminal y construir una pantalla de trabajo en 10 minutos y luego mejorarla interactivamente con comentarios instantáneos. Esta barra de entrada baja estimuló la captación masiva de usuarios. Por otro lado, crear una aplicación X-Server es una tarea no trivial incluso para programadores experimentados.

La Web ha tardado 10 años en ser un competidor directo de la aplicación X en términos de funcionalidad y proporcionar las mismas capacidades de interfaz gráfica de usuario. Esta funcionalidad se ha agregado a la pila de idiomas a lo largo del tiempo, lo que permite a los desarrolladores dominar un conjunto de características antes de agregar el siguiente; Por lo tanto, esta expansión gradual de la complejidad tecnológica ha mantenido la barra baja (para las personas que ya están en el campo y hay muchas). Saltar al campo ahora es mucho más difícil que hace 10 años, pero aún es posible y la retroalimentación instantánea de la web hace que el aprendizaje sea más gratificante (los humanos necesitan una gratificación rápida para reforzar sus impulsos).

El costo es otro conductor. El costo real de aprender suficientes habilidades de programación para desarrollar un X-Server es significativo. Además, la disponibilidad de servidores para ejecutar su aplicación ha aumentado el costo. Aprender a escribir HTML no era prácticamente nada para poner en funcionamiento la página "Hello World" y los proveedores de servicios de Internet proporcionaron alojamiento gratuito para inspirarte a obtener una conexión web. Para que puedas practicar gratis. Cuando eventualmente necesitabas hospedaje empresarial, la disponibilidad de empresas de hospedaje creció y el costo siempre ha sido relativamente barato.

La respuesta es que "muchas tecnologías se adoptan por razones arbitrarias históricas o sociopolíticas en lugar de razones técnicas". La mejor solución para un problema dado no siempre se convierte en la tecnología dominante. (De hecho, rara vez lo hace).

En 2012, donde los servidores HTTP se utilizan para crear aplicaciones interactivas a la par con las aplicaciones de escritorio, la comparación entre HTTP y X es interesante. En retrospectiva, X es probablemente una mejor tecnología para desarrollar aplicaciones ricas e interactivas implementadas en red. Las aplicaciones de escritorio interactivas no se asignan bien a una tecnología orientada a documentos sin estado como HTTP, y esta falta de coincidencia históricamente ha resultado en todo tipo de soluciones (hacks) para crear estados, como cookies, sesiones, etc.

Pero el propósito original de HTTP no era desarrollar aplicaciones con estado de escritorio. Fue para recuperar documentos y mostrar información , información que podría vincularse a otros documentos que también podrían mostrarse instantáneamente. La idea de una colección vinculada de documentos se remonta a la década de 1960 con el " Proyecto Xanadu " de Theodore Nelson . Se suponía que la Web era una implementación del concepto de hipertexto de Nelson , que era un intento de informatizar la página impresa, como la enciclopedia o el periódico, permitiendo al usuario "saltar" instantáneamente de un artículo a otro con un solo clic.

Muchas iteraciones de esta idea han ido y venido, como la Hypercard de Apple , que implementó el concepto de hipertexto / hipervínculos, pero nunca se implementó en las redes. La World Wide Web fue la implementación del concepto de hipertexto basada en la red del CERN, y probablemente despegó porque Tim Berners-Lee lanzó su biblioteca de códigos de navegador de forma gratuita, lo que permitió a otros experimentar con ella. Esto eventualmente llevó al navegador Mosaic de Marc Andreesen, el predecesor de Netscape. Y el resto es historia.

Pero ... como con tantas tecnologías, comenzaron a surgir nuevas posibilidades que los diseñadores originales de HTTP o hipertexto realmente no pensaron demasiado. La web se comercializó y la gente comenzó a desarrollar sitios web que presentaban interactividad con estado, como carritos de compras e inicios de sesión. Se hizo cada vez más evidente que la naturaleza sin estado y orientada a documentos de HTTP no se adaptaba muy bien a las aplicaciones de escritorio. Pero en ese punto, ya era demasiado tarde. Todos ya estaban usando HTTP. Entonces, aquí estamos hoy, con varias aplicaciones AJAX hacky haciendo todo lo posible para fingir que son aplicaciones de escritorio.

Las tecnologías podrían intentar resolver problemas similares ahora, pero seguro que no lo hicieron en el pasado.

La pila HTML actual evolucionó con el tiempo desde la transferencia de documentos de texto realmente simple, a través de documentos "visuales" con pocas secuencias de comandos, a una plataforma de aplicaciones con todas las funciones.

En el momento en que comenzó HTML, nadie podía soñar con conectarse a una computadora remota y ejecutar aplicaciones gráficas allí. Solo después de que Internet obtuvo una mejor latencia y rendimiento, esto se hizo posible. Sin embargo, en ese momento, el HTML ya estaba siempre presente. Todos sabían que esta era una forma de dar a los clientes y usuarios acceso a la aplicación gráfica, que se ejecuta en la máquina remota.

Y como con todos los sistemas "gratuitos", se volvió imposible "reiniciar" todo y comenzar de nuevo para hacerlo mejor esta vez. Es por eso que necesitamos callarnos y usar HTML / CSS / JS y solo deseamos que las personas que lo apoyan finalmente lo entiendan y lo entierren junto con su legado de años.

Esto responde a la pregunta "¿Por qué ganó la web?". No hubo competencia, la web ganó antes de que todo comenzara.

Estoy de acuerdo en que, en principio, los dos son similares. Si hace la pregunta "¿cómo podemos ejecutar código en un servidor pero proporcionar visualización en un cliente remoto?", Es razonable pensar que equipos independientes podrían encontrar cualquiera de las soluciones.

Sospecho que la razón por la cual uno es más popular que el otro en ciertos aspectos es porque los dos abordan el mismo problema desde perspectivas completamente diferentes. X es una solución técnica a un problema técnico, pero la web evolucionó como una necesidad de resolver un problema social : ¿cómo puedo tomar recursos de un servidor remoto y mostrarlos en mi máquina local, y hacerlo de una manera fácil? y conveniente?

La web "ganó" porque resolvió un problema experimentado por más personas. Piense en la analogía de un automóvil: tanto los sedanes de lujo como los camiones aparentemente resuelven el mismo problema: cómo transportar algo de un lugar a otro.

El camión resolvió el problema técnico de literalmente cómo transportar algo del punto A al punto B, y para eso funciona bastante bien. El automóvil de pasajeros evolucionó como una necesidad para que las personas se sintieran cómodas mientras viajaban y para transportar más personas y menos estiércol. Se convirtió en una necesidad que requería comodidades. Por lo tanto, con el tiempo, la cantidad de automóviles de pasajeros superó con creces la cantidad de camionetas en la carretera (supongo que, según la observación del tráfico de Chicago, ¿tal vez sea diferente en Texas? :-)

Entonces, al igual que la analogía del automóvil / camión, la web y el X11 pueden resolver el mismo problema técnico, pero tienen propósitos completamente separados.

Estás comparando manzanas con peras. X windows se trata de separar la representación del contenido de la pantalla en un cliente local, que podría conectarse mediante un cable delgado a la fuente del contenido. Realmente es una extensión del modelo computacional desde la era "glass tty" hasta el dominio de los gráficos de alta calidad. X se originó en la época en que las PC todavía eran bastante débiles, y la mayor parte del cómputo real se hacía en cajas Unix o mainframe. La idea era aprovechar el poder de los "terminales X" relativamente baratos y las redes relativamente lentas para hacer que estos recursos computacionales serios estén disponibles gráficamente.

La razón por la que esto no ganó en Mac y PC es que su desarrollo siempre fue impulsado por el deseo de admitir gráficos de alta gama en aplicaciones locales , incluidos juegos, editores y gráficos comerciales. El soporte de aplicaciones residentes de la red es una ocurrencia reciente.