Just reflecting on Web technology

In 1980, computers still meant large main frames and hobby computers. There wasn't much consumer computing outside large companies or universities. Emails, Gopher, FTP and Telnet were main software we dealt with in those days. Network meant often modem connections to particular host sites, as Internet was not yet accessible for masses at that time.

As I recall, this landscape changed dramatically once WWW became available. This caused Internet to become available to more population in universities and eventually to the public. Probably in a large part telecommunications companies played a large role for this technology shift, because they saw a new profitable market in Internet.

Now our typical computing resources are typically on some hosts computers on the network. We communicate with them from our Desktop or Laptop computers. If it is a client-server model, in old days, we could use e.g. generic "terminal" software (e.g. serial terminal emulator, X-Server, etc.) or specialized client software (e.g. GenBank clients, Database clients, that are specific communication client software) on local user machines. These days, the use of Web client is a common place. Alternatively, we could use P2P model, if it does not require central host machines to provide storage for data and logic.

I started wondering how I can classify the systems and communication mechanisms.

Although generic "terminal" software paradigm is different from using custom-built client software, I guess that it can be still classified as client-server design pattern. There are hosts and clients, and the end users are on local clients to communicate with central hosts. The clients (GUI) are either provided by the servers or had to be installed on the local machines a priori.

Web browsers are along the line of the "generic" (or flexible?) client principle. It is like an extension of the old generic terminal software paradigm, which gets GUI from the server. However, different from something like X-application that presents more rigid GUIs on the "terminals", it uses the contents as GUI. In this case, the organization of the static or dynamic contents acts as GUI as well as information on which the end users must act. As the history proved, the explosion of Web deems this to be the big success factor. Obviously, providing information readily (than engaging in time-consuming activities to create customised client applications) was more beneficial and important.

I, however, always wondered about the validity of the use of Web Browser technology, as it became increasingly popular as though it were only a valid technological choice in distributed computing. Despite the advantages of the Web technology, traditional server-client seems more concrete in terms of functionality.

The advantage of using Web Browsers may be:
1) Various Web applications will be available to all platforms simply where Web browsers are installed.
2) There is no need to install design, create, and install specialized client software on individual machines, as long as the Web browsers are pre-installed on those machines.
3) Web applications may be delivered more readily than traditional server-client development cycle. Particularly if they are made of only static contents.

On the other hand, the weakness was said to be:
1) UI is more suited for presentation-oriented Web application.
2) It may not necessary be suited for data-centric applications.
3) It is not suited to build a "rich client" that behaves more like a real Desktop application.

Today, when it is needed, "rich" clients are typically built using Flash plugin. The Flash plugin hijacks a part of Web Browser page and provides its own UI capabilities and scriptability (ActionScript), whereas the Web Browsers are restricted to use HTML, DHTML, Java Applet and JavaScript. (Except that IE allows proprietary ActiveX).

Java Applet was a similar technology, but it did not take off as Flash. In my opinion, mainly because it was too unstable between different versions of Java used and on different browsers that implemented it. Also its GUI (AWT and Swing UI library) was not as easy to program as Flash.

DHTML had greate promises but it also was an unstable and unreliable technology. Perhaps many browsers did not implement it too well. Or, although DHTML was an "doable" engineering, probably it was inadequate technology. If this is a case, I hope that one day someone can prove this theoretically as an important lesson.

I think that the moral of the story is 1) what works wins and 2) technology that is easy to use wins.

If a Web application does not use HTML but it is made of Flash contents only, popularity of Flash seems to indicate that we could replace web browsers with Flash standalone application.

The success of Web seems to indicate, flexible client hosting application is preferred over custom-made specific client applications.

Flash code sent from the server describes to the client-side what GUI elements it uses and what actions they may perform. Although it is a proprietary code i.e. only understood by Flash client, in principle this is a remote UI definition language.

There are other types of remote GUI definition protocols or languages, such as, X-Window protocol and its Window Manager variants, VNC, OpenXUP, XUI, JSF. From these, I think that we could define a platform neutral model or meta-language for GUI. Such model or language may be useful for higher level design of GUIs and automated generation of GUI codes that are executable.

On the other hand, I have some reservation in whether such high level GUI definition language may be useful or beneficial for designing special purpose clients. It proved to be the case for JSF, since it was often found too generic or lacking some specific widgets. This may be also evidenced by the fact that many variants of X Window Managers and similar protocols had to be created in the past.

Recent trend in programmable "intelligent" mobile devices is the opposite. It likes to have least network traffic possible. Thus, it favours client software to be pre-installed on mobile devices with pre-defined GUI. It can show dynamic contents, but the base GUI "screens" are defined by the installed code. The network traffic is meant to be only the contents (data), not the GUI definitions or code. Much effort was spent to make it easy to discover and install client software.