Saturday, January 14, 2006
Ecmanaut
Ecmanaut, an excellent AJAX and DHTML blog that I follow, points to the Particletree post I entered today titled "Flash for us non-clickies." Check it out.
AJAX/DHTML Tutorial: Should I Render My UI On The Server or the Client?
I want to share a bit about the different kinds of AJAX/DHTML architectures that are involved in creating a large scale AJAX application, and the dangers of choosing an incorrect one.
In general, large scale AJAX applications involve a Model-View-Controller (MVC) architecture; the primary difference is where each of these pieces are rendered and live:
1) Thick Client - everything on the client - In this architecture, the client has a representation of the system (the model); has a way to generate a view using this model; and has a controller that can mediate instantiating and saving the model from remote web services. All of these pieces exist on the client, and are created using JavaScript, HTML, CSS, optional client-side XSLT, etc. The server-side becomes a simple set of APIs, exposed as RESTian endpoints, XML-RPC, etc., which can return XML, JSON, etc. Frameworks like Dojo and JSON can help with creating these kinds of systems.
2) Thin Client - simply a controller - In this architecture, the client side simply has a controller that can capture user events, like mouse clicks; as the user interacts with the UI, the controller fetches the rendered UI from the server. The server actually renders the appropriate UI, where the View and Model live, and returns HTML that is dynamically inserted into the UI using innerHTML. Ruby on Rails facilitates this kind of programming, as does Prototype.
The Thick Client approach moves most of the software engineering to the client; it's weaknesses are that it is a new environment for server-side programmers, many of whom don't respect JavaScript or the level of software engineering it can require to produce quality results. It is difficult to find DHTML programmers who know how to work within this environment. It's strengths are that if done right, it can create a far better, more performant UI experience than the Thin Client. Examples of UI's built as Thick Clients are the Google RSS Reader and Jot's Tracker.
The Thin Client approach can be used with server-side abstraction libraries, like Ruby on Rails, so it can be leveraged quicker. It's strength is that it builds on familiar and available server-side skills, and can sometimes be used to leverage an existing system. However, as your application becomes more sophisticated, it's performance will begin to degrade significantly, since every action will require a full round trip to the server to render the HTML, return it, and then insert it into the page.
The reason for this post was to highlight the dangers with the Thin Client, having the view and model rendered on the server side. If the reason you chose AJAX and DHTML in your project are to have something that feels blazing fast, and if your application is sophisticated, you would do well to stay away from the Thin Client approach.
I was recently playing around with News Alloy, a full featured RSS Aggregator and Reader built using AJAX/DHTML (Disclosure: I consult with a competitor, named Rojo). I was wondering why it felt so slow; every time I would click to a new section, such as clicking the Manage tab to add a new feed, a little red "Loading..." indicator would appear. Things felt sluggish.
I decided to boot up Live HTTP Headers to watch the network traffic, and quickly found that every UI action was forcing a call to the server to render the new UI.
For example, when I click the Manage tab, the News Alloy page does a silent background call to two URLs:
http://newsalloy.com/?act=js2&subact=loadsubs
http://newsalloy.com/?act=js&subact=store&key=activetab&val=subscribe&shift=0
If you go to these addresses yourself in your browser, if you are signed in, you will see that they actually return the rendered Manage tab as HTML, embedded in JavaScript. This is why the entire UI feels sluggish; it's almost like an X Windows UI, since every call forces the view to be rendered on the server side.
In general, if your UI is very simple (such as the one's produced by 37 Signals, like Ta-da List), then the Thin Client approach can be valid. However, once you pass beyond a certain threshold of application sophistication, if you don't take the Thick Client approach you will end up creating something that feels too slow.
Keep in mind, however, that the Thick Client is itself not magic pixie dust; you must still architect your application intelligently, choosing proper caching strategies and optimizing bottlenecks, in order to have good UI performance.
Also, there are no silver bullets; if you are in a situation where you have a simple UI with a minimal amount of AJAX, or where performance is less important than rapid application development or leveraging existing asserts, consider the Thin Client approach.
In general, large scale AJAX applications involve a Model-View-Controller (MVC) architecture; the primary difference is where each of these pieces are rendered and live:
1) Thick Client - everything on the client - In this architecture, the client has a representation of the system (the model); has a way to generate a view using this model; and has a controller that can mediate instantiating and saving the model from remote web services. All of these pieces exist on the client, and are created using JavaScript, HTML, CSS, optional client-side XSLT, etc. The server-side becomes a simple set of APIs, exposed as RESTian endpoints, XML-RPC, etc., which can return XML, JSON, etc. Frameworks like Dojo and JSON can help with creating these kinds of systems.
2) Thin Client - simply a controller - In this architecture, the client side simply has a controller that can capture user events, like mouse clicks; as the user interacts with the UI, the controller fetches the rendered UI from the server. The server actually renders the appropriate UI, where the View and Model live, and returns HTML that is dynamically inserted into the UI using innerHTML. Ruby on Rails facilitates this kind of programming, as does Prototype.
The Thick Client approach moves most of the software engineering to the client; it's weaknesses are that it is a new environment for server-side programmers, many of whom don't respect JavaScript or the level of software engineering it can require to produce quality results. It is difficult to find DHTML programmers who know how to work within this environment. It's strengths are that if done right, it can create a far better, more performant UI experience than the Thin Client. Examples of UI's built as Thick Clients are the Google RSS Reader and Jot's Tracker.
The Thin Client approach can be used with server-side abstraction libraries, like Ruby on Rails, so it can be leveraged quicker. It's strength is that it builds on familiar and available server-side skills, and can sometimes be used to leverage an existing system. However, as your application becomes more sophisticated, it's performance will begin to degrade significantly, since every action will require a full round trip to the server to render the HTML, return it, and then insert it into the page.
The reason for this post was to highlight the dangers with the Thin Client, having the view and model rendered on the server side. If the reason you chose AJAX and DHTML in your project are to have something that feels blazing fast, and if your application is sophisticated, you would do well to stay away from the Thin Client approach.
I was recently playing around with News Alloy, a full featured RSS Aggregator and Reader built using AJAX/DHTML (Disclosure: I consult with a competitor, named Rojo). I was wondering why it felt so slow; every time I would click to a new section, such as clicking the Manage tab to add a new feed, a little red "Loading..." indicator would appear. Things felt sluggish.
I decided to boot up Live HTTP Headers to watch the network traffic, and quickly found that every UI action was forcing a call to the server to render the new UI.
For example, when I click the Manage tab, the News Alloy page does a silent background call to two URLs:
http://newsalloy.com/?act=js2&subact=loadsubs
http://newsalloy.com/?act=js&subact=store&key=activetab&val=subscribe&shift=0
If you go to these addresses yourself in your browser, if you are signed in, you will see that they actually return the rendered Manage tab as HTML, embedded in JavaScript. This is why the entire UI feels sluggish; it's almost like an X Windows UI, since every call forces the view to be rendered on the server side.
In general, if your UI is very simple (such as the one's produced by 37 Signals, like Ta-da List), then the Thin Client approach can be valid. However, once you pass beyond a certain threshold of application sophistication, if you don't take the Thick Client approach you will end up creating something that feels too slow.
Keep in mind, however, that the Thick Client is itself not magic pixie dust; you must still architect your application intelligently, choosing proper caching strategies and optimizing bottlenecks, in order to have good UI performance.
Also, there are no silver bullets; if you are in a situation where you have a simple UI with a minimal amount of AJAX, or where performance is less important than rapid application development or leveraging existing asserts, consider the Thin Client approach.
Particletree: Using Flash as an Animation Underlayer
Particletree has an interesting and unique article on combining Flash and DHTML. They use Flash as a layer that they hide behind some HTML elements to do animation. Check out the demo.
Blog Post from Writely
This is a test fro m Writely, an AJAX/DHTML web based word processor.
Test comment -Bradneuberg 1/14/06, 5:13pm
Test comment -Bradneuberg 1/14/06, 5:13pm
Subscribe to Posts [Atom]
