However, that idea has stayed with me and I've been thinking about it a fair bit since that last post and I've come to the conclusion that what I'd made the focus of my post was merely a side-effect of other, larger trends we're seeing around web frameworks, the relevance of HTML and the way we do web development in general. Please bear with me while I put these ideas down and feel free to flame me to your heart's content in the comments section :-). I'm looking forward to the feedback on this.
First off, I want to get rid of the language baggage for the purposes of this post. I'm going to christen the two types of web applications I have in mind as the web based Information Publisher application and the web based State Interaction application.
An Information Publishing application is a web application whose primary focus is to serve content. The content can be video, audio, text, whatever, but the job of the application is to just serve content. A classic example would be something like Wikipedia or Google search. In both cases, there is information which needs to be served to an audience for consumption. The fact that content in Wikipedia is fairly static while that in Google search is highly dynamic doesn't change the fact that they still essentially publish information.
Contrast this with the web based State Interaction application where the objective of the application is to allow the users to interact with various entities and affect their state (again, Google docs and most enterprise applications). You may publish information as the end product (generate reports, say), but this is not to be confused with the act of creating that information by allowing user interactions with various entities.
The interesting thing is that many web applications have both types and you see one or the other depending on what you're doing with them. Any decent wiki is a good example - when you're in 'edit' mode, it's a State Interaction application (a developer would immediately see entities like
Historyetc.) and when you are viewing wiki content, it's an Information Publisher. The authentication functionality that many websites display is again an example of a State Interaction built into what is otherwise an Information Publisher.
Now, let me explain why I think this distinction is important.
The common underlying infrastructure available to both types of applications is the web browser, with rendering through HTML and communication with the server through gets, posts or AJAX.
In the case of an Information Publisher, this infrastructure is ideally suited to the task. HTML was, after all intended for precisely such uses. Communication with the server to request certain kinds of information can be handled easily and elegantly using name-value pairs (parameters) in a get or post request. A Google search request for the word 'hello' looks like this:
State Interaction applications on the other hand usually have a whole bunch of entities which the user needs to interact with and which usually also need to interact with each other. These live on the server and their interaction with the user is through a user interface rendered using HTML. Changes to the state of an entity or object happen, again, by sending name-value pairs or a json string containing data to the server where these are parsed and some action is taken to alter the states of various objects. To put it bluntly, you have a bunch of objects which demand a high degree of interactivity and we get our UI to talk to them by passing strings around! Not so nice.
The fact that this pain has been felt by developers can be seen in the evolution of web development over time. A bunch of frameworks and tools have been created which build abstractions over this infrastructure to make State Interaction application development easier. For example, ASP.Net 1.1 tried to bring in abstractions which mimicked those used in WinForms. However, attaching an event trigger to a check box (something we do routinely in thick clients) would result in a page reload every time that box was checked or un-checked. The abstraction was defeated by the limitations of infrastructure used (posts). You could develop the same way as you did in WinForms, but the results were far from satisfactory. Things like this made it obvious that while we did need an abstraction, it couldn't really mimic the desktop world where the UI and the model are a method call (or ten :-)) apart. Sure, you're still using a MVC, but very differently from how you would in a thick client. And a whole lot of web frameworks like Spring and Rails have sprung up to support this abstraction. However, these still failed to address the fundamental problem - that highly interactive UI's cannot effectively communicate with their models (data binding, anyone?) by passing strings around.
Therefore, I concluded that this lack of responsiveness has less to do with the rendering medium and is mostly because the communication pipe between the UI and its backing model in a web application is far less effective that that in a thick client.
Having said that, client side models are a fairly bad idea for a Information Publisher for the simple reason that they're quite unnecessary. The challenge, in my opinion, is to clearly identify which portions of a website require State Interactions and which are good old Information Publishers and implement them accordingly using the appropriate technologies. I'd gotten quite gung-ho about GWT and went and developed an Information Publisher type website using it, only to realise later that none of the content was available through a Google search (I did however fix that issue, but it was a hack which won't scale). You can imagine where this could be crucially important to some websites, especially those which sell products or services. AJAX and dynamic rendering are pretty cool, but should be used appropriately.
I'd originally titled this article 'Why things like the GWT and Jamal are going to help keep web developers sane' but changed it because it was rather vague.
You may also want to read: When should you choose Google's GWT for your web app?
Hey Sidu, I came across this blog post while digging for opinions on GWT. Then I saw that you work for ThoughtWorks, I company I have been considering applying for for a while, as I feel they align well with my interesting in software development. Please do not feel obligated but I would be very grateful if you can help. My email address is charles.finkel[at]gmail. My homepage is cmanfu.com.
Hi, really interesting post but I think you don't answer a kind of application mixing both "web based Information Publisher application" and "web based State Interaction application".
I work on Jalios JCMS, a CMS/Portal, so interaction and information, like you explain. But there is not "two world" with sometime one, sometime the other.
Because browsers are faster..., users needs to read/view, publish/update information at the same time.
- If you look at application like WebJam, users edit the portal they saw.
- In modern framework there is "EditInPlaceEditor", ...
- In wiki yes there is BackOffice and FrontOffice but modern software are more "Wysiwyg" mixing Back and Front office.
1. The power of web is flexibility, and ability to mix things easily. Designer might brings cool GUI without development knowledge.
2. GWT brings very good development's ideas but really frozen like desktop application (yon don't add your logo in MS Word Header).
So I think GWT can only be used for "desktop like" application ? But in the futur, web applications will mix more publishing/viewing/editing, in a collaborative way, applications. And GWT will not answer that ?
It would be great in GWT to be able to mix (natively) GWT module with HTML modules in the same HTML web page cleanly.
I am a developer based here in Bangalore with over 4yrs of experience. I am interested to be part of TWI. Do you mind if you can help me in forwarding my resume to concerned people.
>> Manjunath (manjunath.d a.t gmail.com)
It is a shame we cant some how stream the javaascript in behind the page load almost like a ajax back loader that marshals the page load component by component invisably as it were. And shifts priority of the loading threads if a user clicks a component that needs script that hasent loaded at that stage a working sign comes up and that component script gets force loaded and parsed. we perhaps could compress the script as well and decompress it on the client maybe. just random thoughts.
i have added further comment here :
I agree with you completely. GWT is my choice of technology if someone asks for RIA in Java. But as mentioned by Husain, the initial load time does play a factor especially in enterprise apps where most of the apps use secure protocol. We cant cache the page and hence every time user access the page, the script would be loaded again.
Post a Comment