An Ajax framework is a framework that helps to develop web applications that use Ajax, a collection of technologies used to build dynamic web pages on the client side. Data is read from the server or sent to the server by JavaScript requests. However, some processing at the server side may be required to handle requests, such as finding and storing the data. This is accomplished more easily with the use of a framework dedicated to process Ajax requests. The goal of the framework is to provide the Ajax engine and associated server and client-side functions.
Benefits of a framework
In the article that coined the "Ajax" term, J.J. Garrett describes the technology as "an intermediary...between the user and the server."[1] This Ajax engine is intended to suppress the delays perceived by the user when a page attempts to access the server. A framework eases the work of the Ajax programmer at two levels: on the client side, it offers JavaScript functions to send requests to the server. On the server side, it processes the requests, searches for the data, and transmits them to the browser. Some frameworks are very elaborate and provide a complete library to build web applications.
Types of frameworks
Ajax frameworks can be loosely grouped into categories according to the features they offer and the skills required of the user:
Direct Ajax frameworks
These frameworks require HTML, CSS and Ajax expertise: a developer is expected to author pages directly in HTML, and framework APIs deal directly with HTML elements. Cross-browser APIs are provided for a variety of purposes, commonly including communications, DOM manipulation, event handling, and sizing/moving/animating HTML elements.
These frameworks are generally smaller. They are commonly used for a web site such as a shopping experience, but not for a web application such as web-based email, at least not without further frameworks layered on top.
Indirect Ajax frameworks
These frameworks are based on compiler technology, where, instead of writing direct Ajax and Javascript, a high-level language is used instead, along with a compiler that turns the high-level language into Javascript. Indirect frameworks therefore require knowledge of the high-level language, CSS and HTML, and do not necessarily require a great deal of Ajax or Javascript expertise. The Indirect frameworks are typically accompanied by convenient libraries, modules and classes (written in the high-level language) that take care of communications, DOM manipulation including HTML element manipulation, and event handling.
The advantages of Indirect Ajax frameworks - compilation to Javascript - are:
- the developer can effectively create their own Ajax framework using programming concepts and techniques appropriate to the high-level language (e.g. modules and classes) which are simply not present in the Javascript language.
- the to-javascript compiler can enforce strong type-checking and definition rules that standalone javascript does not
- a developer can program the web front-end in the same programming language as that which the server-side code is written in. For example, programming the front-end with Pyjamas is easier if the developer is familiar with Django (web framework); or programming with GWT is easier if the developer is familiar with Apache Tomcat.
- the high-level web widget sets of the Indirect Ajax frameworks have far more in common with Desktop widgets than they do with "traditional" web development.
- the framework, through the compiler, can create code that takes care of browser incompatibilities at run-time, and thus can present a common browser-independent API to the developer.
Indirect Ajax frameworks have distinct and significant advantages:
- Compared to Ajax component frameworks, the developer can use the available base class widgets to create their own widgets, in the high-level language with which they are familiar, instead of trying to get to grips with javascript.
- The developer is therefore neither burdened by the bloat of Ajax component frameworks nor bound by their rigidity.
- The developer has both the advantages of the Ajax component frameworks, and their associated widgets, as well as the advantages of the freedom of Direct Ajax frameworks.
- Indirect Ajax frameworks can be used to even greater effect in combination with a Server-driven framework (typically using JSONRPC or XMLRPC).
Interestingly, Python and Ruby are a good match for compilation to Javascript, and a far better match than Java, because Java (and Java Virtual Machines) lack some of the run-time dynamic capabilities of Javascript, Python and Ruby. Fortunately for Java (and for GWT), it's Java that is less dynamically capable than Javascript. The "class" capability of these high-level languages can be emulated using Javascript "prototype".
Ajax component frameworks
These frameworks offer pre-built components, such as tabbed panes, which automatically create and manage their own HTML. Components are generally created via JavaScript or XML tags, or by adding special attributes to normal HTML elements. These frameworks are generally larger, and intended for web applications rather than web sites.
Some component frameworks require the developer to have extensive HTML/CSS/Ajax experience and to do cross-browser testing. For example, grids, tabs, and buttons may be provided, but user input forms are expected to be authored directly in HTML/CSS and manipulated via Ajax techniques. Other frameworks provide a complete component suite such that only general XML and/or JavaScript abilities are required.
Ajax component frameworks can enable more rapid development than direct Ajax frameworks, but with less control, hence it is key that an Ajax component framework provides the following:
- customization APIs, e.g., an event that fires when the user stops editing within a grid
- skinning facilities, where appearance can be changed without affecting behavior or layout
- programmatic control, e.g., dynamically adding tabs or dynamically creating components based on user data
- extensibility—creation of new components based on other components, so that the benefits of a component-based framework are not lost
Server-driven Ajax frameworks
Several frameworks offer a server-side component-based development model with some degree of Ajax support.
Components are created and manipulated on the server using a server-side programming language. Pages are then rendered by a combination of server-side and client-side HTML generation and manipulation. User actions are communicated to the server via Ajax techniques, server-side code manipulates a server-side component model, and changes to the server component model are reflected on the client automatically.
These frameworks offer familiarity and efficiency for server-side developers at the possible expense of power and performance. Ajax frameworks that handle presentation completely within the browser may offer greater responsiveness if they handle more user interactions without server involvement. In a server-driven model, some UI interactions can react slowly, for example when an input field is dynamically enabled based on server-requests. Furthermore, server-dependent Ajax frameworks can not offer offline support. The approach is still popular for situations where the benefits of a full Ajax architecture can't be captured or where server interaction is needed anyway.
Extending a framework may require the developer to understand which parts of the presentation are handled on the client vs on the server, and to code in JavaScript/Ajax as well as server-side code (an issue which can be overcome through the use of an Indirect Ajax framework, by choosing an Indirect Ajax framework with a compiler that accepts the same language as the server-side code).
See also
References
External links
- Listing of Ajax Libraries hosted by the Open Source Applications Foundation