I used to rather like X back in the early 90's but I think we've moved on a bit since. The introduction of hardware accelerated graphics and the decline of the old "network application" model have pretty much killed the model it was built on.
I'd like to see things such as Wayland succeed in the future.
I strongly agree with that sentiment. Strangely perhaps, I expect many of the original X advocates probably would as well. X was created at a time when computers had 1/50,000th the power they do today by inverse Moore's law reasoning 2^(25/1.5). From a graphics performance perspective its probably closer to one five-millionth the equivalent power by the reasoning that a full frame (1920 x 1080) specularly lit frame can be rendered in 16 mS today vs 86400000 mS 25 years ago. So you had a choice, you could either render a UI, or you could do computation, but not both.
On top of that the only way to control a complex remote application was something like X because having 15 80x25 terminals wasn't cutting it.
The web browser and markup, combined with the advancement in local processing/rendering ability completely destroyed one of the fundamental problems X was trying to solve. That it didn't kill X right then and there was, in my opinion, an artifact of the implementation as a glorified telnet session for the HTTP server.
We've not killed it yet because the protocol was/is extensible enough that things like XRender and DRI could be slotted in and fundamentally alter what X "is" to clients without breaking older clients.
The rendering model for most apps is totally different.
Perhaps more acutely, the web browser and increased network performance killed it. When you think of the X11 model of separating server side processing with GUI, that's more or less what web applications do nowadays. Nowadays there's very little advantage (if any) to using X11.
There are some important fundamental differences between X apps and Web apps.
The "display side" of Web apps can do a lot of useful processing which cannot be done on the "display side" of X apps. JavaScript is not my favorite technology, and the performance is, at best, mediocre, but you can perform useful computations with it.
Also, well written Web apps can reduce network activity to a minimum.
Consider, for a moment, if ten thousand people were using HN via an X app. HN would need monster servers and monster bandwidth to handle all that load, even if the users were only scrolling through comments or spending minutes typing up replies.
During the time I've been typing this reply, the Web app side of HN is making no network calls and putting no demand on HN's servers at all.
I've seen people vaguely equate X apps and Web apps before, and I'm always bothered by it since they have such important fundamental differences that change everything.
While I lack the experience and real historical context to judge, I rather like the comparison to present day web apps. Especially for new developers, which 'side' to take (or at least start, since it has to be somewhere) can seem to split your head when looking at the pros/cons and applications of either.
Comments
And we've not killed it yet.
I used to rather like X back in the early 90's but I think we've moved on a bit since. The introduction of hardware accelerated graphics and the decline of the old "network application" model have pretty much killed the model it was built on.
I'd like to see things such as Wayland succeed in the future.
I strongly agree with that sentiment. Strangely perhaps, I expect many of the original X advocates probably would as well. X was created at a time when computers had 1/50,000th the power they do today by inverse Moore's law reasoning 2^(25/1.5). From a graphics performance perspective its probably closer to one five-millionth the equivalent power by the reasoning that a full frame (1920 x 1080) specularly lit frame can be rendered in 16 mS today vs 86400000 mS 25 years ago. So you had a choice, you could either render a UI, or you could do computation, but not both.
On top of that the only way to control a complex remote application was something like X because having 15 80x25 terminals wasn't cutting it.
The web browser and markup, combined with the advancement in local processing/rendering ability completely destroyed one of the fundamental problems X was trying to solve. That it didn't kill X right then and there was, in my opinion, an artifact of the implementation as a glorified telnet session for the HTTP server.
We've not killed it yet because the protocol was/is extensible enough that things like XRender and DRI could be slotted in and fundamentally alter what X "is" to clients without breaking older clients.
The rendering model for most apps is totally different.
Perhaps more acutely, the web browser and increased network performance killed it. When you think of the X11 model of separating server side processing with GUI, that's more or less what web applications do nowadays. Nowadays there's very little advantage (if any) to using X11.
There are some important fundamental differences between X apps and Web apps.
The "display side" of Web apps can do a lot of useful processing which cannot be done on the "display side" of X apps. JavaScript is not my favorite technology, and the performance is, at best, mediocre, but you can perform useful computations with it.
Also, well written Web apps can reduce network activity to a minimum.
Consider, for a moment, if ten thousand people were using HN via an X app. HN would need monster servers and monster bandwidth to handle all that load, even if the users were only scrolling through comments or spending minutes typing up replies.
During the time I've been typing this reply, the Web app side of HN is making no network calls and putting no demand on HN's servers at all.
I've seen people vaguely equate X apps and Web apps before, and I'm always bothered by it since they have such important fundamental differences that change everything.
While I lack the experience and real historical context to judge, I rather like the comparison to present day web apps. Especially for new developers, which 'side' to take (or at least start, since it has to be somewhere) can seem to split your head when looking at the pros/cons and applications of either.