Before I worked on the service publishing AP project and having the course in massively distributed systems, I had never taken JavaScript seriously. In fact, I always tried to omit the use of JavaScript whenever possible preferring heavy UI interaction with the server (i.e., the server manages every single button that the user clicks) because each browser has its own quirks and it breaks accessibility. Moreover, the language is pretty much lenient unlike C so that combined with the quirks, I really didn't like to do JavaScript programming. And, I had the sense of insecurity in using JavaScript because it could be modified by a malicious user to send invalid data. But, through the project, I came to appreciate the use of JavaScript.

The service publishing AP project requires a UI that allows the AP owner to manage the service offering. If I were to develop the UI in C, I would develop a simple client-server program that exchanges data through TCP. But, first, this requires the AP owner to install an additional precompiled program in his/her computing device. This is infeasible because then the client-server program needs to be precompiled for all possible computing devices that the AP owner may use. Distributing the program as source code so that the AP owner can compile the program to his/her specific computing device is also a "no-no" because compilation is not a trivial task when it comes to gadgets. Therefore, an interpreted program is the solution (now I can understand why people choose to provide UI through a web browser instead of a standalone GUI that requires compilation). This means either Java or DHTML with JavaScript. Since Java requires JVM that might not be available in a particular gadget, the lowest common denominator is DHTML.

Secondly, having a TCP client-server program requires additional memory space for maintaining the communication state. Through the massively distributed system course I learned that the client-server paradigm does not scale well because the server needs to handle each interacting client by allocating processing time and memory space while memory and processing power are limited and come at a price. Well, yes, a service publishing AP does not handle a massive number of owners that want to manage the offered services at once. But, the point is that an AP already has a very limited memory space and processing power, and therefore, it is desirable that the AP should not try to be stateful using cookie or session to manage the UI. Being stateless also reduces the complexity of the program in the AP. So, I developed the JavaScript to completely manage the UI aspect in the user's own computing device.

As for the quirks of web browsers, many resources now are available on the Internet to resolve the quirks from articles to frameworks. So, the quirks presents no problem to me since while working on the service publishing AP project, I could solve all JavaScript problems by simply googling.

Regarding breaking accessibility, well, if the UI is designed for those who are not disabled, let it be designed in that way. And, if JavaScript helps the goal of the UI to provide the most effective means for normal people to interact with the application, let JavaScript helps in that way. For those who are disabled, of course another UI design should be employed. In short, there is no single design that can be effective for all types of audience, and we should not use a common denominator in designing a UI if it is not necessary to do so just like in my service publishing AP project although designing with a common denominator is correct for a government site that should serve all types of audience.

As for getting invalid data, with or without the use of JavaScript, you should never trust a user input as the saying goes. In other words, with or without JavaScript, the server should always validate the data. But, the use of JavaScript will reduce the server load, and better than that, JavaScript will give the users a better UI experience, which is a very important aspect in selling an application. So, I am done with my false sense of insecurity.

In short, now I really understand how JavaScript can be useful in providing richer UI experience and reducing the server load since the server does not need to manage the UI aspect of the application.