Why did the web win the space of remote applications and X not?

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.

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.

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.

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.

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.

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.

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.

Filed under: softwareengineering - @ 05:14

Thẻ: history, web

Thiết kế website giá rẻ

Danh mục

Why did the web win the space of remote applications and X not?