Pourquoi le web a-t-il gagné l'espace des applications distantes et X pas?

Le système X Window a 25 ans, il a fêté son anniversaire hier (le 15).

Comme vous le savez probablement, l'une de ses caractéristiques les plus importantes est la séparation du côté serveur et du côté client d'une manière que ni les systèmes de fenêtrage de Microsoft, Apples ou Wayland n'ont.

À l'époque (désolé pour le libellé ambigu), beaucoup pensaient que X dominerait les autres façons de créer des fenêtres en raison de cette séparation du serveur et du client, permettant à l'application d'être exécutée sur un serveur ailleurs pendant que l'utilisateur clique et tape sur elle propre ordinateur à la maison.

Cette utilisation existe évidemment toujours, mais est au mieux marginalisée. Lorsque nous écrivons et utilisons des programmes qui s'exécutent sur un serveur, nous utilisons presque toujours le Web avec son html / css / js.

Pourquoi le Web a-t-il gagné et X non? Les technologies utilisées pour le web (dites html / css / js) sont un gâchis. Combiné avec tous les frameworks back-end (Rails, Django et tout), c'est vraiment une jungle pour naviguer à travers. Pourtant, le Web prospère avec créativité et progrès, contrairement aux applications X distantes.

Cela semble tout à fait évident et fondamental maintenant, mais l'innovation la plus meurtrière du World Wide Web était l'hyperlien. Même si X n'était pas complètement inutilisable sur une liaison modem, son incapacité à lancer un processus complètement nouveau sur un serveur complètement nouveau via un seul clic entraverait son adoption pour ce type de cas d'utilisation.

Parce que X vous oblige à avoir un diplôme CS pour écrire une application. Alors que le Web exige que vous ayez la possibilité de taper (pas même cela).

Surtout au début, lorsque le Web n'était que du HTML. Vous pouvez ouvrir un terminal et créer un affichage fonctionnel en 10 minutes, puis l'améliorer de manière interactive avec un retour instantané. Cette barre d'entrée basse a stimulé l'adoption massive des utilisateurs. La construction d'une application X-Server, d'autre part, n'est pas une tâche triviale, même pour les programmeurs expérimentés.

Il a fallu 10 ans pour que le Web soit un concurrent direct de l'applicatif X en termes de fonctionnalités et fournisse les mêmes capacités de type GUI. Cette fonctionnalité a été ajoutée à la pile des langues au fil du temps, permettant aux développeurs de maîtriser un ensemble de fonctionnalités avant l'ajout du suivant; cette expansion progressive de la complexité technologique a donc maintenu la barre basse (pour les personnes qui sont déjà sur le terrain et il y en a beaucoup). Sauter sur le terrain est maintenant beaucoup plus difficile qu'il y a 10 ans, mais c'est toujours possible et le retour instantané du Web rend l'apprentissage plus gratifiant (les humains ont besoin d'une gratification rapide pour renforcer leurs lecteurs).

Le coût est un autre facteur. Le coût réel de l'apprentissage de suffisamment de compétences en programmation pour développer un X-Server est important. De plus, la disponibilité des serveurs sur lesquels exécuter votre application a fait grimper les coûts. Apprendre à écrire du HTML n'était pratiquement rien pour faire fonctionner la page "Hello World" et les fournisseurs de services Internet ont fourni un hébergement gratuit pour vous inciter à obtenir une connexion Web. Vous pouvez donc vous entraîner gratuitement. Lorsque vous avez finalement eu besoin d'une entreprise d'hébergement, la disponibilité des sociétés d'hébergement a augmenté et le coût a toujours été relativement bon marché.

La réponse est que «de nombreuses technologies sont adoptées pour des raisons historiques ou sociopolitiques arbitraires plutôt que pour des raisons techniques». La meilleure solution pour un problème donné ne devient pas toujours la technologie dominante. (En fait, c'est rarement le cas.)

En 2012, où les serveurs HTTP sont utilisés pour créer des applications interactives au même niveau que les applications de bureau, la comparaison entre HTTP et X est intéressante. Avec le recul, X est probablement une meilleure technologie pour développer des applications riches et interactives déployées en réseau. Les applications de type bureau interactif ne correspondent pas bien à une technologie sans état et orientée vers les documents comme HTTP, et cette incompatibilité a historiquement entraîné toutes sortes de solutions (hacks) pour créer un état, comme les cookies, les sessions, etc.

Mais l'objectif initial de HTTP n'était pas de développer des applications de type bureau avec état. Il s'agissait de récupérer des documents et d' afficher des informations - des informations pouvant être liées à d'autres documents pouvant également être affichées instantanément. L'idée d'une collection de documents liés remonte aux années 1960 avec le " Projet Xanadu " de Theodore Nelson . Le Web était censé être une implémentation du concept d' hypertexte de Nelson , qui était une tentative d'informatiser la page imprimée - comme l'encyclopédie ou le journal - permettant à l'utilisateur de "sauter" instantanément d'un article à un autre en un seul clic.

De nombreuses itérations de cette idée sont venues et ont disparu, comme Hypercard d'Apple , qui a mis en œuvre le concept d'hypertexte / hyperliens, mais n'a jamais été déployé sur les réseaux. Le World Wide Web était la mise en œuvre en réseau du CERN du concept d'hypertexte, et il a probablement décollé parce que Tim Berners-Lee a publié sa bibliothèque de codes de navigateur gratuitement, permettant à d'autres de l'expérimenter. Cela a finalement conduit au navigateur Mosaic de Marc Andreesen, le prédécesseur de Netscape. Et le reste est de l'histoire.

Mais ... comme avec tant de technologies, de nouvelles possibilités ont commencé à émerger auxquelles les concepteurs originaux de HTTP ou d'hypertexte n'ont pas vraiment pensé trop. Le Web a été commercialisé et les gens ont commencé à développer des sites Web qui présentaient une interactivité dynamique, comme des paniers d'achat et des connexions. Il est devenu de plus en plus évident que la nature sans état et orientée document de HTTP n'était pas très bien adaptée aux applications de type bureau. Mais à ce moment-là, c'était trop tard. Tout le monde utilisait déjà HTTP. Donc, nous sommes ici aujourd'hui, avec diverses applications piratées AJAX faisant de leur mieux pour prétendre qu'elles sont des applications de bureau.

Les technologies pourraient essayer de résoudre des problèmes similaires maintenant, mais elles ne l'ont certainement pas fait dans le passé.

La pile HTML actuelle a évolué au fil du temps, passant d'un transfert de documents texte très simple, à des documents "visuels" avec peu de scripts, en une plate-forme d'application complète.

Au moment où HTML a commencé, personne ne pouvait rêver de se connecter à un ordinateur distant et d'y exécuter des applications graphiques. Ce n'est qu'après qu'Internet a obtenu une meilleure latence et un meilleur débit, cela est devenu possible. Pourtant, à cette époque, le HTML était déjà omniprésent. Tout le monde savait que c'était un moyen de donner aux clients et aux utilisateurs l'accès à une application graphique, qui s'exécutait sur la machine distante.

Et comme avec tout système "gratuit", il est devenu impossible de "réinitialiser" le tout et de recommencer pour le faire mieux cette fois. C'est pourquoi nous devons fermer et utiliser HTML / CSS / JS et souhaiter seulement que les personnes qui le soutiennent se réveillent enfin et l'enterrent avec son héritage de plusieurs années.

Cela répond à la question "Pourquoi le Web a-t-il gagné?". Il n'y avait pas de compétition, le web a gagné avant même que tout ne commence.

Je suis d'accord que, en principe, les deux sont similaires. Si vous posez la question "comment pouvons-nous exécuter du code sur un serveur mais fournir une visualisation sur un client distant?", Il est raisonnable de penser que des équipes indépendantes pourraient proposer l'une ou l'autre solution.

Je soupçonne que la raison pour laquelle l'un est plus populaire que l'autre à certains égards est que les deux abordent le même problème sous des angles complètement différents. X est une solution technique à un problème technique, mais le Web a évolué en tant que besoin de résoudre un problème social - comment puis-je prendre des ressources d'un serveur distant et les afficher sur ma machine locale, et le faire d'une manière simple et pratique?

Le Web a "gagné" car il a résolu un problème rencontré par plus de personnes. Pensez à une analogie automobile: les berlines de luxe et les camions résolvent ostensiblement le même problème: comment transporter quelque chose d'un endroit à un autre.

Le camion a résolu le problème technique de littéralement comment transporter quelque chose d'un point A à un point B, et pour cela cela fonctionne assez bien. La voiture de tourisme a évolué comme un besoin pour que les gens soient à l'aise lors de leurs déplacements et transportent plus de personnes et moins de fumier. C'est devenu une nécessité qui nécessitait des commodités. Ainsi, au fil du temps, le nombre de voitures particulières a largement dépassé le nombre de camionnettes sur la route (je suppose, d'après l'observation du trafic de Chicago, c'est peut-être différent au Texas? :-)

Ainsi, comme l'analogie voiture / camion, le Web et le X11 résolvent tous deux le même problème technique, mais ils servent des objectifs complètement distincts.

Vous comparez des pommes et des poires. Les fenêtres X consistent à séparer le rendu du contenu de l'écran en un client local, qui pourrait être connecté par un mince fil à la source du contenu. C'est vraiment une extension du modèle de calcul de l'ère "glass tty" au domaine des graphismes de haute qualité. X est né à l'époque où les PC étaient encore assez faibles, et la plupart des calculs réels étaient effectués sur des boîtes Unix ou Mainframe. L'idée était d'exploiter la puissance de «terminaux X» relativement bon marché et de réseaux relativement lents pour rendre graphiquement disponibles ces sérieuses ressources de calcul.

La raison pour laquelle cela n'a pas gagné sur Mac et PC est que leur développement a toujours été motivé par le désir de prendre en charge les graphiques haut de gamme dans les applications locales , y compris les jeux, les éditeurs et les graphiques d'entreprise. La prise en charge des applications résidentes du réseau est une réflexion récente.