http://qs321.pair.com?node_id=415919


in reply to GUI with HTTP::Daemon

Since about 1996 some were convinced that a Web Browser could serve as the ideal 'cross platform solution' for generating language-agnostic GUI front-ends. Ironically, it was about that time that several companies sprang up, offering 'virtual desktop' software that you could run over the internet, complete with DHTML-based widgets that looked just as good as (and in some cases even better) than the GUI components your typical Windows (TM) user has come to expect. (you might be very surprised by what can be rendered in a typical browser, see eg http://www.bindows.net/ )

The dotBomb explosion and browser incompatibility hassles helped to wipe most of these ventures off the map, but the fundamental idea is still feasible, and still remains critically overlooked by *most* developers:

The 'web' browser sitting on most computers is perhaps the most flexible and most amazingly underused component for GUI-based development.

The single most enduring circumstance that prevents serious progress in this area is the lack of a language-neutral and credible mechanism for interprocess communication between the browser GUI front-end and perl. (or whatever your language of choice is).

OOP enthusiasts will parrot the virtues of "loose coupling" until they are blue in the face, but the sad fact is, we are still in the archaic "stone age" when it comes to options for GUI development. We shall not emerge from this primitive state until it is possible for a GUI developer to create a front-end with absolutely *no need to know what 'language' will be used for the 'back end'*. The technology exists to make this possible today, but not enough people 'get it'. That is especially sad since great programming skills and great design skills tend to be mutually incompatible skill sets.

HTTP: ubiquitous but too limited by the stateless 'request - response' model. WebServices: as bad as HTTP. OLE::COM: way too complicated, and not platform independent. CORBA: same problem as OLE. XPCOM: complicated, and does not seem to be catching on.