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

19

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.

Martin Josefsson
fuente
66
Los dos ni siquiera son remotamente comparables. Las conexiones del servidor X me permiten ejecutar una aplicación remota y ver su GUI localmente, que es un caso de uso completamente diferente de permitirme cargar recursos remotos en un cliente local.
Martijn Pieters
3
No estoy de acuerdo en que haya una diferencia. Cuando conecto mi cliente web (navegador) a un servidor (local o remoto) puedo ver la GUI de mi aplicación (web). Al igual que puedo ver la GUI de mi aplicación con una sesión X.
Martin Josefsson
44
Intente escribir un programa X11 y compárelo con una página HTML; también compare el ancho de banda necesario. Además, WWW no reemplazó a X11, reemplazó a Gopher.
2
Pieters: Claro, la página se representa en el cliente y JS se ejecuta en el cliente, pero eso no es más que tecnicismos. La mayoría de las veces, el código se ejecuta en el lado del servidor (php, java, .net, python, ruby, lo que sea). En la práctica, ambas son interfaces para que las aplicaciones se ejecuten en un servidor y se muestren en un cliente. X y la web lo hacen de diferentes maneras, pero eso es lo esencial.
Martin Josefsson
14
Debido a que la tecnología no pasó la validación por la industria del entretenimiento para adultos, un paso requerido en la adopción general de una tecnología (esa es una forma elegante de decir que las imágenes de mujeres desnudas no estuvieron disponibles en los sistemas X con la suficiente rapidez).
dasblinkenlight

Respuestas:

22

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.

Karl Bielefeldt
fuente
1
Esta puede muy bien ser la respuesta correcta. Además, los clientes web también se ejecutaban en los sistemas operativos Apple y Microsoft.
Martin Josefsson
El hipervínculo no fue una innovación de la World Wide Web. Se implementó muchas veces antes, como en Hypercard de Apple, un programa popular en los años 80 y 90 con muchas similitudes asombrosas con un navegador web. El concepto de hipertexto e hipervínculos se remonta a los años 60, con el Proyecto Xanadu, y se ha implementado muchas veces en muchos formatos antes de que Tim Berners-Lee finalmente creara su propia implementación de hipertexto basada en la red en el CERN a principios de los 90.
Charles Salvia
3
@CharlesSalvia: El avance de los hipervínculos HTML se debió a la URL. En particular, su aspecto Universal: global, con la autoridad central suficiente para trabajar, y no vinculado a un tipo de medio o tecnología específico. Sus tecnologías anteriores eran mucho, mucho menos universales.
MSalters
17

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.

Martin York
fuente
1
Asume que para escribir una aplicación que se utiliza sobre X necesita comprender la API X. Pero así como no necesita comprender HTTP para escribir una aplicación web, no necesita comprender X para escribir una aplicación que se ejecute bajo X. Puede escribirla en un idioma, el que prefiera, y solo tiene una biblioteca GTK en la parte superior. Mucho más fácil que aprender html y css y js y un lenguaje del lado del servidor. La esencia de esto: así como no necesita escribir un servidor http para publicar un sitio web, no necesita escribir un servidor X para servir una aplicación X.
Martin Josefsson
No estoy de acuerdo con tu análisis allí. Aunque tiene un punto en que escribir una aplicación web moderna ahora es casi tan complejo como escribir una aplicación X hace 10 años. Escribir una aplicación X todavía no es un proceso trivial. Es como escribir una aplicación de Windows. Mucho más allá de la capacidad de cualquiera que no haya realizado una experiencia de programación significativa. Por otro lado, poner una página HTML es trivial y se puede hacer en 10 minutos (incluso por un principiante). Por lo tanto, conduce a un refuerzo rápido y la capacidad de experimentar rápidamente. Esto hace que la barra de entrada sea mucho más baja.
Martin York
GTK no estuvo disponible hasta mucho después de que se estableció la web.
user16764
@ user16764: Eso no es cierto. Estaba usando GTK en 1997 (no estoy seguro de cuándo comenzaron, pero antes de eso). La web (como en HTML / HTTP) puede haber estado funcionando en ese momento, pero no tan bien establecida. Quiero decir, el navegador web solo se estaba incorporando a la transmisión principal en 92 (La primera vez que vi uno). Sin embargo, X tiene varios otros gestores de ventanas que antes eran utilizables. Recuerdo haber usado twm (Tom's Window Manager, creo) y otro nivel ligeramente superior (que me olvido), pero había mucho para elegir (demasiados) en 90 (y estaban disponibles antes de eso (creo)).
Martin York
@LokiAstari: Estás confundiendo a los administradores de ventanas y las bibliotecas GUI. Si bien hay una superposición definida (GNOME / Gtk, KDE / Qt), ciertamente no son idénticos. Incluso con los gestores de ventanas todavía tenías mundos de dolor.
MSalters
11

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.

Charles Salvia
fuente
3

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.

Eufórico
fuente
1
En el momento en que comenzó HTML, ya existía la informática del lado del servidor, con el servidor HTTP NSCA y su SGI. La mayoría de las aplicaciones entregaron texto, pero recuerdo una que fue capaz de representar mapas personalizados en B / N, un antepasado de los mapas de Google.
mouviciel
Los mapas de imágenes se remontan a los primeros años de la última década del siglo anterior.
MSalters
1

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.

Bryan Oakley
fuente
1

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.

ddyer
fuente