20

The X Window System is 25 years old, it had it's birthday yesterday (on the 15'th).

As you probably are aware of, one of it's most important features is the separation of the server side and the client side in a way that neither Microsoft's, Apples or Wayland's windowing systems have.

Back in the days (sorry for the ambiguous phrasing) many believed X would dominate over other ways to make windows because of this separation of server and client, allowing the application to be ran on a server somewhere else while the user clicks and types on her own computer at home.

This use obviously still exists, but is marginalized at best. When we write and use programs that run on a server we almost always use the web with it's html/css/js.

Why did the web win, and X not? The technologies used for the web (said html/css/js) are a mess. Combined with all the back-end-frameworks (Rails, Django and all) it really is a jungle to navigate thru. Still the web thrives with creativity and progress, while remote X apps do not.

Improve this question
20
  • 7
    The two are not even remotely comparable. X-server connections allow me to run a remote application, and view it's GUI locally, which is a completely different use-case from allowing me to load remote resources into a local client.
    – Martijn Pieters
    Sep 16, 2012 at 11:27
  • 3
    I don't agree that there is a difference. When I connect my web client (browser) to a server (locally or remote) I can view the GUI of my (web-)app. Just like I can view the GUI of my app with an X session.
    – Martin Josefsson
    Sep 16, 2012 at 11:33
  • 4
    Try writing an X11 program and compare it with an HTML page - also compare bandwidth needed. Additionally, WWW did not replace X11, it replaced Gopher.
    – user1249
    Sep 16, 2012 at 11:34
  • 2
    Pieters: Sure, the page is rendered on the client, and JS runs on the client, but that is merely technicalities. More often than not, code runs on the server side (php, java, .net, python, ruby, whatever). In practice they are both interfaces for apps to run on a server and be showed on a client. X and web does it in different ways, but that is the gist of it.
    – Martin Josefsson
    Sep 16, 2012 at 11:39
  • 15
    Because the technology did not pass validation by the adult entertainment industry, a required step in mainstream adoption of a technology (that's a fancy way of saying that pictures of naked women did not become available on X systems quickly enough).
    – Sergey Kalinichenko
    Sep 16, 2012 at 12:02

6 Answers 6

Reset to default
23

It seems utterly obvious and fundamental now, but the killer innovation of the world wide web was the hyperlink. Even if X wasn't completely unusable over a modem link, its inability to launch a completely new process on a completely new server via a single click would hamper its adoption for that sort of use case.

Improve this answer
3
  • 1
    This may very well be the correct answer. Also that web clients ran on Apple and Microsoft OS's too.
    – Martin Josefsson
    Sep 16, 2012 at 21:33
  • The hyperlink wasn't an innovation of the World Wide Web. It was implemented many times before, such as in Apple's Hypercard, a popular program in the 80s and 90s with many uncanny similarities to a Web Browser. The concept of hypertext and hyperlinks goes back to the 60s, with Project Xanadu, and it has been implemented many times in many formats before Tim Berners-Lee finally created his own network-based implementation of hypertext at CERN in the early 90s.
    – Charles Salvia
    Sep 16, 2012 at 23:04
  • 3
    @CharlesSalvia: The breakthrough of HTML hyperlinks was due to the URL. In particular its Universal aspect: global, with just enough central authority to work, and not tied to one specific media type or technology. Your previous technologies were far, far less universal.
    – MSalters
    Sep 17, 2012 at 13:10
18

Because X requires you to have a CS degree to write an application. While Web requires that you have the ability to type (not even that).

Especially in the early days when web was just html. You could open a terminal and build a working display in 10 minutes and then interactively improve it with instant feedback. This low bar of entry spurred massive user uptake. Building a X-Server application on the other hand is non-trivial task even for experienced programmers.

It has taken 10 years for the Web to be a direct competitor to X applicatoin in terms of functionality and provide the same GUI like abilities. This functionality has been added to the language stack over time allowing developers to master one set of features before the next was added; so this gradual expansion of technological complexity has maintained the low bar (for people who are already in the field and there are lots of them). Jumping into the field now is a lot harder than it was 10 years ago but it is still possible and the instant feedback of the web makes learning more gratifying (humans need quick gratification to reinforce their drives).

Cost is another driver. The actually cost of learning enough programming skills to develop a X-Server is significant. Then additionally the availability of servers to run your application on has driven the cost up. Learning to write HTML was practically nothing to get "Hello World" page up and running and internet service providers provided free hosting to inspire you to get a web connection. So you could practice for free. When you eventually needed business hosting the availability of hosting companies has grown and the cost has always been relatively cheap.

Improve this answer
6
  • 1
    You assume that in order to write an app that is used over X you need to understand the X api. But just as you don't need to understand HTTP in order to write a web app, you don't need to understand X to write an app that runs under X. You could write it in one language, the one you preferred, and just have a GTK library on top. Way easier than to learn html and css and js and a serverside language. The gist of it: just as you don't need to write a http server to publish a web site, you don't need to write a X server to serve a X app.
    – Martin Josefsson
    Sep 16, 2012 at 17:59
  • I disagree with your analysis there. Though you have a point in that writing a modern web application is now nearly as complex as writing X application was 10 years ago. To write an X-Application is still not a trivial processes. Its just like writing a windows application. Well beyond the ability of anybody that has not done significant programming experience. On the other hand putting up an HTML page is trivial and can be done in 10 minutes (even by a beginner). Thus leads to quick re-enforcement and the ability to quickly experiment. This makes it much lower bar to entry.
    – Martin York
    Sep 16, 2012 at 19:31
  • GTK wasn't available until well after the web was established.
    – user16764
    Sep 16, 2012 at 19:33
  • @user16764: That's not true. I was using GTK in 1997 (not sure when they first started but before that). The web (as in HTML/HTTP) may have been up then but well established not so much. I mean web browser were only just being brought into the main stream in 92 (The first time I saw one). X has several other window managers that were usable before that though. I remember using twm (tom's window manager I believe) and one other slightly higher level one (which I forget) but there were plenty to choose from (too many) in 90 (and they were available before that (I think)).
    – Martin York
    Sep 16, 2012 at 19:42
  • @LokiAstari: You're confusing Window Managers and GUI libs. While there's a definite overlap (GNOME/Gtk, KDE/Qt) they're certainly not identical. Even with window managers you still had worlds of pain.
    – MSalters
    Sep 17, 2012 at 13:08
13

The answer is that "many technologies are adopted for arbitrary historical or socio-political reasons rather than technical reasons." The best solution for a given problem does not always become the dominant technology. (In fact, it rarely does.)

In 2012, where HTTP servers are being used to create interactive applications on par with Desktop applications, the comparison between HTTP and X is interesting. In hindsight, X is probably a better technology to develop rich, interactive network-deployed applications. Interactive Desktop-like applications don't map well to a stateless, document-oriented technology like HTTP, and this mismatch has historically resulted in all sorts of work-arounds (hacks) to create state, like cookies, sessions, etc.

But the original purpose of HTTP wasn't to develop stateful Desktop-like apps. It was to retrieve documents and display information - information which could link to other documents that could also be instantly displayed. The idea of a linked collection of documents goes way back to the 1960s with Theodore Nelson's "Project Xanadu". The Web was supposed to be an implementation of Nelson's concept of hypertext, which was an attempt to computerize the printed page - like the encyclopedia or the newspaper - allowing the user to instantly "jump" from one article to another with a single click.

Many iterations of this idea have come and gone, such as Apple's Hypercard, which implemented the concept of hypertext/hyperlinks, but was never deployed over networks. The World Wide Web was CERN's network-based implementation of the concept of hypertext, and it likely took off because Tim Berners-Lee released his browser code library for free, allowing others to experiment with it. This eventually led to Marc Andreesen's Mosaic browser, the predecessor of Netscape. And the rest is history.


But... as with so many technologies, new possibilities began to emerge that the original designers of HTTP or hypertext didn't really think about too much. The web became commercialized and people started to develop websites that featured stateful interactivity, like shopping carts and logins. It became more and more apparent that the stateless and document-oriented nature of HTTP wasn't very well suited to Desktop-like applications. But at that point, it was just too late. Everyone was already using HTTP. So, here we are today, with various hacky AJAX applications trying their best to pretend they are Desktop apps.

Improve this answer
0
4

The technologies might try to solve similar problems now, but they sure didn't in the past.

Current HTML stack evolved over time from really simple text-document transfer, through "visual" documents with little scripting, into full-featured application platform.

At the time when HTML began, no one could ever dream about connecting to remote computer and running graphical applications there. Only after internet got better latency and throughput this became possible. Yet at that time, HTML was already ever-present. Everyone knew that this was way to give customers and users access to graphical application, that run on the remote machine.

And as with every "free" system, It became impossible to "reset" the whole thing and start anew to do it better this time. That's why we need to shut up and use HTML/CSS/JS and only wish people supporting it will finally wisen and bury it along with it's years long legacy.

This answers the question "Why did web win?". There wasn't any competition, web won before everything even started.

Improve this answer
2
  • 1
    At the time when HTML began, there was already server-side computing, with the NSCA HTTP server and its SGI. Most applications delivered text but I remember one that was able to render B/W custom maps, an ancestor of google maps.
    – mouviciel
    Sep 16, 2012 at 13:01
  • Image maps indeed date back to early years of the last decade of the previous century.
    – MSalters
    Sep 17, 2012 at 13:14
1

I agree that, in principle, the two are similar. If you ask the question "how can we run code on a server but provide visualization on a remote client?", it's reasonable to think that independent teams could come up with either solution.

I suspect the reason one is more popular than the other in certain aspects is because the two approach the same problem from completely different perspectives. X is a technical solution to a technical problem, but the web evolved as a need to solve a social problem -- how can I take resources from a remote server and display it on my local machine, and do it in a way that is easy and convenient?

The web "won" because it solved a problem experienced by more people. Think of a car analogy: both luxury sedans and trucks ostensibly solve the same problem: how to transport something from one place to another.

The truck solved the technical problem of literally how to haul something from point A to point B, and for that it works quite well. The passenger car evolved as a need for people to be comfortable as they travel, and to carry more people and less manure. It became a necessity that required conveniences. Thus, over time, the number of passenger cars far, far outweighed the number of pickup trucks on the road (I'm guessing, based on observation of Chicago traffic, maybe it's different in Texas? :-)

So, like the car/truck analogy, the web and X11 both arguably solve the same technical problem, but they serve completely separate purposes.

Improve this answer
1

You are comparing apples to pears. X windows are about separating the rendering of screen content into a local client, which could be connected by a thin wire to the source of the content. It's really an extension of the computational model from the "glass tty" era to the domain of high quality graphics. X originated in the era when PCs were still pretty wimpy, and most of the real computation was done on unix or mainframe boxes. The idea was to harness the power of relatively cheap "X terminals" and relatively slow networks to make these serious computational reasources available graphically.

The reasons this didn't win on Macs and PCs is that their development was always driven by the desire to support high end graphics in local applications, including games, editors and business graphics. Supporting network resident applications is a recent afterthought.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.