Warum hat das Web den Platz von Remote-Anwendungen gewonnen und X nicht?

19

Das X Window System ist 25 Jahre alt und hatte gestern (am 15.) Geburtstag.

Wie Sie wahrscheinlich wissen, ist eine der wichtigsten Funktionen die Trennung von Server- und Client-Seite in einer Weise, die weder Microsoft noch Apples oder Waylands Fenstersysteme aufweisen.

Früher (Entschuldigung für die mehrdeutige Formulierung) glaubten viele, dass X aufgrund dieser Trennung von Server und Client die anderen Möglichkeiten zur Erstellung von Fenstern dominieren würde, sodass die Anwendung auf einem anderen Server ausgeführt werden konnte, während der Benutzer auf sie klickte und sie tippte eigenen Computer zu Hause.

Diese Verwendung existiert offensichtlich immer noch, ist aber bestenfalls marginalisiert. Wenn wir Programme schreiben und verwenden, die auf einem Server laufen, verwenden wir fast immer das Web mit dem Namen html / css / js.

Warum hat das Web gewonnen und X nicht? Die für das Web verwendeten Technologien (html / css / js) sind ein Durcheinander. Kombiniert mit allen Back-End-Frameworks (Rails, Django und allem) ist es wirklich ein Dschungel, durch den man navigieren kann. Trotzdem lebt das Web von Kreativität und Fortschritt, während Remote-X-Apps dies nicht tun.

Martin Josefsson
quelle
6
Die beiden sind nicht einmal annähernd vergleichbar. Mit X-Server-Verbindungen kann ich eine Remoteanwendung ausführen und die GUI lokal anzeigen. Dies ist ein völlig anderer Anwendungsfall als das Laden von Remoteressourcen in einen lokalen Client.
Martijn Pieters
3
Ich stimme nicht zu, dass es einen Unterschied gibt. Wenn ich meinen Web-Client (Browser) mit einem Server (lokal oder remote) verbinde, kann ich die GUI meiner (Web-) App anzeigen. Genauso wie ich die GUI meiner App mit einer X-Sitzung anzeigen kann.
Martin Josefsson
4
Schreiben Sie ein X11-Programm und vergleichen Sie es mit einer HTML-Seite. Vergleichen Sie auch die benötigte Bandbreite. Außerdem ersetzte WWW X11 nicht, sondern Gopher.
2
Pieters: Sicher, die Seite wird auf dem Client gerendert und JS wird auf dem Client ausgeführt, aber das sind nur technische Aspekte. Meist läuft der Code auf dem Server (PHP, Java, .NET, Python, Ruby, was auch immer). In der Praxis sind sie beide Schnittstellen, über die Apps auf einem Server ausgeführt und auf einem Client angezeigt werden können. X und web machen das auf unterschiedliche Art und Weise, aber das ist das Wesentliche.
Martin Josefsson
14
Da die Technologie die Validierung durch die Unterhaltungsbranche für Erwachsene nicht bestanden hat, ist dies ein notwendiger Schritt bei der Einführung einer Technologie durch den Mainstream (so könnte man sagen, dass Bilder von nackten Frauen nicht schnell genug auf X-Systemen verfügbar wurden).
dasblinkenlight

Antworten:

22

Es scheint jetzt völlig offensichtlich und grundlegend, aber die Killer-Innovation des World Wide Web war der Hyperlink. Selbst wenn X über eine Modemverbindung nicht vollständig unbrauchbar wäre, würde die Unfähigkeit, einen vollständig neuen Prozess auf einem vollständig neuen Server mit einem einzigen Klick zu starten, die Übernahme für diese Art von Anwendungsfall erschweren.

Karl Bielefeldt
quelle
1
Dies kann sehr wohl die richtige Antwort sein. Auch die Web-Clients liefen unter Apple und Microsoft OS.
Martin Josefsson
Der Hyperlink war keine Innovation des World Wide Web. Es wurde bereits mehrmals implementiert, beispielsweise in Apples Hypercard, einem beliebten Programm in den 80er und 90er Jahren mit vielen unheimlichen Ähnlichkeiten zu einem Webbrowser. Das Konzept von Hypertext und Hyperlinks reicht mit Project Xanadu bis in die 60er Jahre zurück und wurde viele Male in vielen Formaten implementiert, bevor Tim Berners-Lee in den frühen 90er Jahren seine eigene netzwerkbasierte Implementierung von Hypertext am CERN schuf.
Charles Salvia
3
@CharlesSalvia: Der Durchbruch von HTML-Hyperlinks lag an der URL. Insbesondere sein universeller Aspekt: ​​global, mit gerade genug zentraler Berechtigung zum Arbeiten und nicht an einen bestimmten Medientyp oder eine bestimmte Medientechnologie gebunden. Ihre bisherigen Technologien waren weitaus weniger universell.
MSalters
17

Weil X einen CS-Abschluss voraussetzt, um eine Bewerbung zu schreiben. Während Web erfordert, dass Sie die Fähigkeit zum Tippen haben (nicht einmal das).

Besonders in den frühen Tagen, als das Web nur HTML war. Sie könnten in 10 Minuten ein Terminal öffnen und ein funktionierendes Display erstellen und es dann interaktiv mit sofortigem Feedback verbessern. Diese niedrige Einstiegsschwelle führte zu einer massiven Benutzerakzeptanz. Das Erstellen einer X-Server-Anwendung ist jedoch selbst für erfahrene Programmierer keine einfache Aufgabe.

Es hat 10 Jahre gedauert, bis das Web ein direkter Konkurrent für X-Anwendungen in Bezug auf Funktionalität und die gleichen GUI-ähnlichen Fähigkeiten war. Diese Funktionalität wurde im Laufe der Zeit zum Sprachpaket hinzugefügt, sodass Entwickler einen Satz von Funktionen beherrschen können, bevor der nächste hinzugefügt wird. Diese schrittweise Ausweitung der technologischen Komplexität hat also die niedrige Messlatte beibehalten (für Menschen, die bereits im Feld sind und von denen es viele gibt). Es ist jetzt viel schwieriger als noch vor 10 Jahren, ins Feld zu springen, aber es ist immer noch möglich und das sofortige Feedback des Webs macht das Lernen erfreulicher (Menschen brauchen eine schnelle Befriedigung, um ihre Antriebe zu stärken).

Kosten ist ein weiterer Treiber. Die tatsächlichen Kosten für das Erlernen ausreichender Programmierkenntnisse zur Entwicklung eines X-Servers sind erheblich. Die Verfügbarkeit von Servern, auf denen Ihre Anwendung ausgeführt werden kann, hat die Kosten zusätzlich in die Höhe getrieben. Das Erlernen von HTML war praktisch nichts, um die "Hello World" -Seite zum Laufen zu bringen, und Internetdienstanbieter boten kostenloses Hosting an, um Sie zu einer Webverbindung zu inspirieren. Sie können also kostenlos üben. Wenn Sie schließlich ein Business-Hosting benötigen, ist die Verfügbarkeit von Hosting-Unternehmen gestiegen und die Kosten waren immer relativ niedrig.

Martin York
quelle
1
Sie gehen davon aus, dass Sie die X-API verstehen müssen, um eine App zu schreiben, die über X verwendet wird. Aber genau so, wie Sie HTTP nicht verstehen müssen, um eine Web-App zu schreiben, müssen Sie X nicht verstehen, um eine App zu schreiben, die unter X ausgeführt wird Habe nur eine GTK-Bibliothek an der Spitze. Viel einfacher als HTML und CSS und JS und eine serverseitige Sprache zu lernen. Das Wichtigste dabei: So wie Sie keinen HTTP-Server schreiben müssen, um eine Website zu veröffentlichen, müssen Sie auch keinen X-Server schreiben, um eine X-App bereitzustellen.
Martin Josefsson
Ich bin mit Ihrer Analyse dort nicht einverstanden. Sie haben jedoch den Punkt, dass das Schreiben einer modernen Webanwendung fast so komplex ist wie das Schreiben einer X-Anwendung vor 10 Jahren. Eine X-Applikation zu schreiben ist noch kein trivialer Vorgang. Es ist wie beim Schreiben einer Windows-Anwendung. Weit jenseits der Fähigkeiten von jemandem, der keine signifikanten Programmiererfahrungen gemacht hat. Auf der anderen Seite ist das Erstellen einer HTML-Seite trivial und in 10 Minuten erledigt (auch für Anfänger). Dies führt zu einer schnellen Durchsetzung und der Fähigkeit, schnell zu experimentieren. Dies macht es viel niedriger bar zum Eintritt.
Martin York
GTK war erst verfügbar, nachdem das Web eingerichtet worden war.
user16764
@ user16764: Das stimmt nicht. Ich habe GTK 1997 benutzt (ich bin mir nicht sicher, wann sie angefangen haben, aber davor). Das Web (wie in HTML / HTTP) war damals vielleicht in Betrieb, aber nicht so gut etabliert. Ich meine, Webbrowser wurden erst im Jahr 92 in den Hauptstream gebracht (das erste Mal, dass ich einen gesehen habe). X verfügt jedoch über mehrere andere Fenstermanager, die zuvor verwendet werden konnten. Ich erinnere mich, dass ich twm (glaube ich, Toms Fenstermanager) und einen etwas höheren Level (den ich vergesse) verwendet habe, aber in 90 gab es eine große Auswahl (zu viele) (und die waren vorher verfügbar (glaube ich)).
Martin York
@LokiAstari: Sie verwechseln Window Manager und GUI-Bibliotheken. Es gibt zwar eine eindeutige Überlappung (GNOME / Gtk, KDE / Qt), aber sie sind sicherlich nicht identisch. Selbst mit Fenstermanagern hattest du immer noch Schmerzenswelten.
MSalters
11

Die Antwort lautet: "Viele Technologien werden eher aus willkürlichen historischen oder gesellschaftspolitischen als aus technischen Gründen übernommen." Die beste Lösung für ein bestimmtes Problem wird nicht immer zur vorherrschenden Technologie. (Tatsächlich tut es selten.)

2012, wo HTTP-Server verwendet werden, um interaktive Anwendungen zu erstellen, die mit Desktop-Anwendungen vergleichbar sind, ist der Vergleich zwischen HTTP und X interessant. Im Nachhinein ist X wahrscheinlich die bessere Technologie für die Entwicklung umfangreicher interaktiver Anwendungen, die im Netzwerk bereitgestellt werden. Interaktive Desktop-ähnliche Anwendungen lassen sich nicht gut auf eine zustandslose, dokumentenorientierte Technologie wie HTTP abbilden, und diese Nichtübereinstimmung hat in der Vergangenheit zu allen möglichen Workarounds (Hacks) geführt, um einen Status wie Cookies, Sitzungen usw. zu erstellen.

Der ursprüngliche Zweck von HTTP bestand jedoch nicht darin, statusbehaftete Desktop-ähnliche Apps zu entwickeln. Es sollte Dokumente abrufen und Informationen anzeigen - Informationen, die mit anderen Dokumenten verknüpft werden konnten, die auch sofort angezeigt werden konnten. Die Idee einer verknüpften Dokumentensammlung reicht mit Theodore Nelsons " Project Xanadu " bis in die 1960er Jahre zurück . Das Web sollte eine Implementierung von Nelsons Hypertext -Konzept sein , bei dem versucht wurde, die gedruckte Seite - wie die Enzyklopädie oder die Zeitung - zu computerisieren, damit der Benutzer mit einem einzigen Klick von einem Artikel zum nächsten "springen" kann.

Viele Wiederholungen dieser Idee sind vorbeigegangen, wie z. B. Apples Hypercard , die das Konzept von Hypertext / Hyperlinks implementierte, jedoch nie über Netzwerke bereitgestellt wurde. Das World Wide Web war die netzwerkbasierte Implementierung des Hypertext-Konzepts durch das CERN und hat sich wahrscheinlich durchgesetzt, weil Tim Berners-Lee seine Browser-Codebibliothek kostenlos freigegeben hat, damit andere damit experimentieren können. Dies führte schließlich zu Marc Andresens Mosaic-Browser, dem Vorgänger von Netscape. Und der Rest ist Geschichte.


Aber ... wie bei so vielen Technologien entstanden neue Möglichkeiten, über die die ursprünglichen Designer von HTTP oder Hypertext nicht wirklich nachdachten. Das Web wurde kommerzialisiert und die Leute begannen, Websites zu entwickeln, die sich durch Stateful-Interaktivität auszeichneten, wie Einkaufswagen und Logins. Es stellte sich immer deutlicher heraus, dass der zustandslose und dokumentenorientierte Charakter von HTTP für Desktop-ähnliche Anwendungen nicht sehr gut geeignet war. Aber zu diesem Zeitpunkt war es einfach zu spät. Jeder benutzte bereits HTTP. So, hier sind wir heute, mit verschiedenen hackigen AJAX-Anwendungen, die ihr Bestes geben, um so zu tun, als wären sie Desktop-Apps.

Charles Salvia
quelle
3

Die Technologien könnten jetzt versuchen, ähnliche Probleme zu lösen, aber das war in der Vergangenheit sicher nicht der Fall.

Der aktuelle HTML-Stapel hat sich im Laufe der Zeit von einer wirklich einfachen Übertragung von Textdokumenten über "visuelle" Dokumente mit wenigen Skripten zu einer voll funktionsfähigen Anwendungsplattform entwickelt.

Zu der Zeit, als HTML begann, konnte niemand davon träumen, sich mit einem Remote-Computer zu verbinden und dort grafische Anwendungen auszuführen. Erst nachdem das Internet eine bessere Latenz und einen besseren Durchsatz hatte, wurde dies möglich. Zu dieser Zeit war HTML jedoch bereits allgegenwärtig. Jeder wusste, dass Kunden und Benutzer auf diese Weise Zugang zu grafischen Anwendungen erhalten, die auf dem Remote-Computer ausgeführt werden.

Und wie bei jedem "freien" System wurde es unmöglich, das Ganze "zurückzusetzen" und neu anzufangen, um es diesmal besser zu machen. Deshalb müssen wir HTML / CSS / JS zum Schweigen bringen und nur wünschen, dass die Leute, die es unterstützen, es endlich verstehen und zusammen mit seinem jahrelangen Erbe begraben.

Dies beantwortet die Frage "Warum hat das Web gewonnen?". Es gab keinen Wettbewerb, das Web hat gewonnen, bevor alles angefangen hat.

Euphorisch
quelle
1
Zu Beginn von HTML gab es bereits Server-Side-Computing mit dem NSCA-HTTP-Server und dessen SGI. Die meisten Anwendungen lieferten Text, aber ich erinnere mich an einen, der in der Lage war, benutzerdefinierte Schwarzweißkarten zu rendern, ein Vorläufer von Google Maps.
Mouviciel
Imagemaps stammen tatsächlich aus den Anfangsjahren des letzten Jahrzehnts des vorigen Jahrhunderts.
MSalters
1

Ich stimme zu, dass die beiden im Prinzip ähnlich sind. Wenn Sie die Frage "Wie können wir Code auf einem Server ausführen, aber auf einem Remote-Client eine Visualisierung bereitstellen?" Stellen, können unabhängige Teams beide Lösungen in Betracht ziehen.

Ich vermute, der Grund, warum einer in bestimmten Aspekten populärer ist als der andere, ist, dass die beiden das gleiche Problem aus völlig unterschiedlichen Perspektiven angehen. X ist eine technische Lösung für ein technisches Problem. Das Web hat sich jedoch zu einem Bedürfnis entwickelt, ein soziales Problem zu lösen. Wie kann ich Ressourcen von einem Remote-Server auf meinem lokalen Computer anzeigen und auf eine einfache Weise ausführen? und bequem?

Das Web "gewann", weil es ein Problem löste, das von mehr Leuten erfahren wurde. Stellen Sie sich eine Auto-Analogie vor: Sowohl Luxuslimousinen als auch Lastwagen lösen scheinbar dasselbe Problem: Wie transportiert man etwas von einem Ort zum anderen?

Der Lkw löste das technische Problem, etwas buchstäblich von Punkt A nach Punkt B zu transportieren, und dafür funktioniert er recht gut. Der Pkw wurde als Bedürfnis entwickelt, dass die Menschen sich auf Reisen wohl fühlen und mehr Menschen und weniger Dünger transportieren müssen. Es wurde eine Notwendigkeit, die Bequemlichkeiten erforderte. Im Laufe der Zeit überwog die Anzahl der Pkws die Anzahl der Pick-ups auf der Straße bei weitem

Wie die Auto / LKW-Analogie lösen Web und X11 also wohl dasselbe technische Problem, dienen aber völlig unterschiedlichen Zwecken.

Bryan Oakley
quelle
1

Sie vergleichen Äpfel mit Birnen. Bei X-Fenstern geht es darum, das Rendern von Bildschirminhalten in einen lokalen Client zu unterteilen, der über einen dünnen Draht mit der Quelle des Inhalts verbunden sein kann. Es ist wirklich eine Erweiterung des Rechenmodells von der "glass tty" -Ära bis zur Domäne hochwertiger Grafiken. X entstand in einer Zeit, in der PCs noch recht schwach waren und der Großteil der eigentlichen Berechnungen auf Unix- oder Mainframe-Boxen erfolgte. Die Idee war, die Leistung von relativ billigen "X-Terminals" und relativ langsamen Netzwerken zu nutzen, um diese seriösen Rechenressourcen grafisch verfügbar zu machen.

Der Grund, warum dies auf Macs und PCs nicht gelang, ist, dass ihre Entwicklung immer von dem Wunsch getrieben wurde, High-End-Grafiken in lokalen Anwendungen, einschließlich Spielen, Editoren und Geschäftsgrafiken, zu unterstützen. Die Unterstützung netzwerkspezifischer Anwendungen wurde kürzlich erörtert.

ddyer
quelle