Monday, March 19th, 2007

Case Study: Blog Article Composition User Interface

Category: Ajax

Peter Michaux has taken some time to writeup a Front-End Architecture Case Study: Blog Article Composition User Interface.

He plays with a couple of potential architectures for building a simple blog admin interface, such as:

  • Old school: Normal Request/Response
  • RJS Ajax Updates
  • Client-Side App


I have not considered degradation paths in details because I have not included the code in blogApp.js. Some users can cause real grief. For example, a user with Internet Explorer 6, JavaScript enabled but ActiveX disabled (and hence no Ajax) really throws a wrench in the works. The client-side app solution fairs much better in this situation then the RJS app.

You could argue that a solution like the second one presented, where all logic is on the server, should not return JavaScript but rather just data. This could be returned in the form of just the HTML to be inserted or XML or JSON. The client-side would know what to do with this data. I think that for the sake of this investigation the tradeoffs are the same for returning JavaScript remote procedure calls compared to HTML, XML or JSON data because the size of the requests and responses would be almost equal.

You could argue the user interface should be WYSIWYG like the FCKEditor. A WYSIWYG editor would fall in the full client-side app category. It is virtually the same for this discussion as the third solution presented above. The WYSIWYG editor would submit the HTML with bold tags that will be used for the blog article rather than form data with asterisks. As mentioned earlier, the client-side app presented in this article could also submit HTML generated for the preview rather than the form data.

Each of the three solutions presented is still appropriate today in particular situations. I am planning a big project that may use a full client-side app solution. There would still be times where I use a classic solution for a web page that isn’t commonly used and doesn’t need to be responsive. It all depends. What I have learned from this investigation is that RJS and similar solutions are probably too expensive for live previews. If the DRY principle is to be implemented and the logic must be on both the client and the server then some JavaScript should be used on the server.

Posted by Dion Almaer at 6:53 am
1 Comment

3.7 rating from 43 votes

1 Comment »

Comments feed TrackBack URI

cool one!

Comment by manelgarcia — April 25, 2007

Leave a comment

You must be logged in to post a comment.