The year 2005 was a great year for web development. In that year, two technologies emerged: Ajax and Ruby on Rails. The advent of these two technologies changed the face of web development and even disrupted the progress of JavaEE. For many years, the designers of JavaEE had been intoxicated by the complex architecture they designed, which was supposed to cover everything. New buzzwords kept emerging, gaining widespread attention as soon as they appeared, and related books would sell like hotcakes. However, there were blind spots in the otherwise brilliant JavaEE landscape that the designers had never anticipated. In fact, they had never considered the browser's processing capabilities in the JavaEE architecture; for JavaEE, browsers were completely unintelligent thin clients. This design was understandable because they could only limit their design to areas controllable by Java. After the complete failure of Java Applets, the controllable area of Java retreated to the server side. There is no doubt that JavaEE achieved tremendous success, but this solution completely based on the server side was difficult to provide users with excellent interactive experiences and also struggled to achieve optimal scalability.
Ajax is a choice made by users and the market. This buzzword created by the masses often rang in the ears of JavaEE designers, making them very annoyed. Some even shouted the slogan "JavaEE without Ajax," echoing Rod Johnson's 2004 slogan "J2EE without EJB." But upon closer examination of this "without Ajax," we find that it does not mean the same thing as "without EJB." "Without EJB" means not using EJB, whereas "without Ajax" does not mean not using Ajax but rather trying to hide Ajax so that ordinary JavaEE developers do not need to learn it. In the JSF framework designed by the inventor of this slogan, an embedded Ajax component library ExtJS was used, indicating that they still needed Ajax's help. Therefore, "JavaEE without Ajax" is actually a false proposition, merely a gimmick to attract attention, mainly aimed at catering to those JavaEE developers who dislike Ajax and have no interest in browser-side script programming. In fact, whether developing web applications or B/S structured enterprise applications, the interactive experience is very important. Today, as interactive experiences are increasingly valued, it is almost impossible to exclude Ajax.
Although Ajax development is indeed important, there is no denying that Ajax development, especially DHTML development, remains a complex task requiring specialized skills. In addition to superb development skills, developers must also have sufficient understanding of web usability and interaction design. This goes beyond the capabilities of web page designers and producers; for server-side developers, these are clearly not their strengths (their strengths lie in handling business logic and database interactions, not interface development and interaction design). A huge gap has emerged between web page designers and server-side developers, making high-level Ajax developers suddenly highly sought after.
It is understandable for JavaEE designers to make efforts to simplify Ajax development. However, we need to discuss clearly one question: what exactly needs to be done to truly simplify Ajax development?
In my view, the efforts of the JavaEE community to simplify Ajax development have not been very successful. Embedding ExtJS into the JSF framework can indeed meet some simple interaction needs, but this approach essentially cripples Ajax’s main ability — directly handling user events on the browser side. The event model of JSF is entirely located on the server side; any change in the interface requires sending events to the server side for processing. Even with the introduction of ExtJS, this point cannot be changed. The use of taglib to integrate Ajax component libraries in Struts2/WebWork and jMaki will also feel clumsy and unnatural. The reason why the integration effect is not ideal is that the core architectural designs of traditional JavaEE frameworks and Ajax component libraries did not consider each other's requirements, leading to inherent conflicts in architectural design. The result of forced integration is predictable. These JavaEE presentation layer frameworks integrate Ajax component libraries hoping to transform them into obedient citizens of the JavaEE world, conforming to the architectural constraints of JavaEE frameworks, but doing so inevitably weakens the capabilities of Ajax component libraries. To simplify Ajax development and fully utilize Ajax technology, simply encapsulating Ajax component libraries with taglib is not enough. The server-side architecture must also be restructured, and even a whole new architecture may need to be designed, which traditional JavaEE presentation layer frameworks cannot achieve. Google's GWT, which has both browser-side and server-side components, seems like a good choice, but GWT is mainly designed for a class of one-page Ajax applications imitating desktop application interaction models, which most web applications cannot adopt. DWR is another framework spanning both browser-side and server-side, but I dislike its RPC-style API. The difference in scalability between RPC architecture and REST architecture is significant. The best architecture for Ajax applications is REST, not RPC, and REST also simplifies the programming model better than RPC.
To simplify Ajax development, I believe the following three requirements need to be met:
1. Professional DHTML developers should develop more comprehensive and powerful widget libraries. This part of the development should be done by professionals, thereby unloading the burden from ordinary web developers. Open-source software is the inevitable path for developing widget libraries.
2. Ajax component libraries need to be more tightly integrated with server-side frameworks. The architecture of server-side frameworks needs to be modified to adapt to the demands of Ajax and REST; one cannot expect to remain unchanged and handle all changes.
3. Simplified programming models. This includes two aspects: a) through tight integration with server-side frameworks, enabling server-side developers to meet some common Ajax needs using only server-side programming languages; b) if more complex interaction needs require DHTML development, the difficulty of DHTML development must be significantly reduced.
After turning my attention to Ruby on Rails, including Ajax development, everything became much easier. Rails integrates two Ajax component libraries, Prototype and script.aculo.us, through its RJS templates. The way Rails integrates these two component libraries feels very natural because these component libraries are products of the combination of Rails and Ajax, developed by core Rails developers who fully considered the architectural needs of Rails. Now these two component libraries have matured and can be independently applied in non-Rails environments. Rails + Prototype/script.aculo.us meets the aforementioned three requirements and is therefore currently the best combination for Ajax development. Of course, each of the three requirements still has room for significant improvement, but Rails + Prototype/script.aculo.us is on the right path and has a bright future.
With the popularization of Ajax technology, traditional DHTML component libraries have regained vitality and can be modified to meet new interaction needs. These DHTML components have gained a fashionable new name — Widget. Generally, I divide Ajax component libraries into three parts:
1. Basic libraries. Including: a) enhancements to the JavaScript language, providing support for object-oriented programming such as inheritance and package management for the currently supported JavaScript 1.x version in browsers; b) encapsulation of HTML DOM APIs, providing simplified programming model APIs.
2. Web Remoting libraries, interacting with servers through mechanisms such as XMLHttpRequest/IFrame/JSONP to obtain data from the server.
3. Rich Widget libraries, which can be used to implement various interaction needs and improve the user's interactive experience.
Prototype implements parts 1 and 2, while script.aculo.us implements part 3. Among these three parts, the Widget library involves the largest amount of development work. Due to the massive demand for Widget libraries in the market, 2007 saw the emergence of a large number of Widget libraries, including open-source ones such as script.aculo.us, Dojo, YUI, ExtJS, Mootools, jQuery UI, Spry, Tibco GI, Qooxdoo, and proprietary ones such as ASP.NET Ajax, Dorado, Zimbra, etc., totaling over twenty or thirty. Apple launched the iPhone that year, with all its Widgets developed using DHTML, reaching the pinnacle of interactive experience and showcasing the promising future of Widget development. Many people say that 2007 was the year of Widgets, and this statement makes sense. By 2008, Google launched Open Social, whose core was the Widget development API provided by Google and the deployment container for Widgets. Google refers to these Widgets as Google Gadgets, pushing the level of Widget development to new heights.
Whether implementing Ajax functions based on existing Widgets or developing new Widgets, Prototype/script.aculo.us is a powerful tool in our hands. Many online votes show that the Prototype/script.aculo.us combination is the most popular Ajax component library. Because Prototype is very popular, enthusiasts have developed many other component libraries based on Prototype, and the number of Prototype family members continues to grow. One of the biggest problems with many Ajax component libraries is the lack of detailed documentation; API references cannot replace documentation. In terms of quantity and quality of documentation, Prototype/script.aculo.us has the best documentation among all Ajax component libraries. The publication of this book provides great convenience for enthusiasts to delve deeper into these two component libraries. The subtitle of this book is "You Never Know JavaScript Could Do This!" Indeed, it is through these excellent Ajax component libraries and these top-tier Ajax explorers that we realize how brilliant the world of browser-side script programming is. Developing Ajax applications based on Prototype/script.aculo.us is a pleasant experience. The deeper you study, the stronger this pleasant feeling becomes. So, what are you waiting for?
Li Kun
Chief Architect at Shanghai Ink Guest Network
July 6, 2008, Shanghai