Instead of using Google Windowing Toolkit, Rich Faces, Django, or any other server side technology to perform build the user interface, we should use Javascript and a client side library like JQuery.
The Graphical User Interface (GUI) is built as a stand alone application that talks to the Server via RESTful API on the server side, such that UI work and business logic are insulated from each other.
All integration between the database and server would be via web services. Both XML and JSON are acceptable, as is any other pure text format that we care to use.
Web services then become the gateway to the system,
The reasons I am driving this approach are:
- Javascript is a required language for web applications. Not knowing Javascript slows down development
- Server side generation of GUI code slows down development due to the need to deploy new code. Server side generation of GUI causes tight coupling between the GUI and the Business logic, making it tough to use the same code to support both a rich gui and a Command Line Interface (CLI)
- Server side generation of GUI limits us to the set of widgets that come with the toolkit, effectively tying the hands of the User Experience Design (UXD) team.
- Using Javascript as the only GUI language allows the same front end to talk to multiple backends, in whatever language that they are written in. Thus, an application that needs to talk to multiple servers, one in Java one in Python, one is some other language now becomes possible. So long as all of the web services are fronted via Apache, with the Java code behind mod_jk,we maintain web security and privilege.
- We can grow a team of UI developers that are agnostic of the Java vs LAMP divide so prevalent in the web world.
- We can develop a richer UI experience that is more consistant across multiple projects, regardless of the server side language.
I am not an evangelist for Javascript. Instead, I recognize that it is a language that has established itself in a key role for web based applications.
The basic structure of an application revolves around the Ajax message pump. Upon selecting an URL, the UI displays an unpopulated page. The Client side javascript makes Ajax requests to the server for content for the visible regions. For example, in a prototype for the Raw Configuration work for RHQ, The page downloads a list of the files that make up the raw configuration,and the contents of the first visible page. If desired, the other pages could also be preloaded in the background, or loaded upon clicking between tabs. The choice is a balance between the memory footprint in the browser and the responsiveness of the UI.
Potential Objections:
What about design by contract? One reason that the Java world likes to strictly control the Javascript is that, in scripting languages, you get no confirmation that you’ve coded correctly until you deploy, where as a compiled language gives you confirmation of, at a minimum, syntax correctness when you compile. Thus, you can take something as amorphous as Javascript and wrap it with Java classes to get compile time type checking and the like. Many Java APIs for user interface depend on reflection to do their work. Reflection basically turns type safe objects into a map. Between XML configuration and bindings, many Java UI APIs have no more compile time guarantees than the scripting languages with which it competes. The same level of confirmation between Java and HTML/Javascript can be done based on the XML schema used to communicate between the front and back ends. Code such as the Validators in JSF or other web tool kits often have code that asserts that a string is in a proper format, but then leaves it in a string form until converted into the Domain model. This style of validation can now move into the Javascript on the front end, and the back end can revert to doing only a single validation, during the conversion from string to domain model.
Browser incompatibility issues. While Rich Faces and other tool-kits that generate Javascript appear to remove browser compatibility issues from the UI developers problem set, Javascript tool-kits like JQuery evolved in part to solve the very same problems. JQuery works hard to provide a single API that works for a significant subset of the browsers out there.
Simple Data driven apps: Many applications are little more than displays of infomration fetched from the databse in a create-read-update-delete (CRUD) manner . Generating this code from the server side is trivial. However, nothing prevent you from doing the exact same logic in JQuery. Postgresql can spit out query results in HTML format, easily consumed by Javascript. A CGI style application that does CRUD logic doesn’t need a server side scripting language, but does need GUI logic.
Far more likely is that an application like this will start out strictly CRUD like and will morph into something requireing more business logic over time. Keeping the UI and the business logic separated by machines may actually simplify the refactoring and evolution process, but it shouldn’t make it any more complicated than if the whole thing were done as server side scripting in the first place.
Internationalisation (I18N) : Java has very strong support for message bundles as part of the internationalisation process. Thus, creating a web that supports multiple languagesis a “simple” as using token replacements instad of straight text, and providing message.properties files for each of the languages you want to support.
Again, this can be done client side using DHTML. Even if this solution doesn’t work completely, it shows you the start of an approach.
Ideally, the I18N code would itself be dynamic. Facebook has shown how quickly a site can evolve if you delegate the translation to the end users. While this might not be acceptable or appropriate for an app deployed in a more controlled manner, it still makes sense to separate the deployment of new text bundles from your general QA process, as the two processes are quite separate. Ideally, people can be working on language support that can be deployed on their own schedule, dependant only on the current set of I18N tokens in the web page.
Accessibility: The web browser comes with a lot of built in support for people with visual impairments. From the simple, like zooming by pressing ctrl-+ to screen scraping using text-to-speech-synthesis, much of the web has been preserved as a viable set of resources for people that do not have full use of their eyes. When a site depends overly on Javascript, it becomes unusable to people with visual disabilities. This is a significant issue. For a site that uses server side scripting exclusively, the page comes across as static html, and all of the tools for accessibility can do their job. However, If the site depends on DHTML, it is as good as broken for the visually impaired. This is an issue that the developers must face if they use DHTML, and not restricted to the JQuery approach.