We often get asked what is the difference between a portlet and a widget and so I thought it would be a good idea to provide a post that explains some of this. Portlets and Widgets both provide a UI component model and as such have a lot of similarities. They also have some differences. Lets start with the similarities.
Both Portlets and Widgets are mostly concerned with the applications UI vs. the applications logic. So they both assume that there is some useful service on some 'back end' system and they provide a user interaction with that service. We say they are 'mostly concernced with UI' because it isn't always clear what is UI and what is logic, and there are certainly cases where some logic is performed in the Portlet or Widget.
Both Portlets and Widgets can pass information/context to other Portlets or Widgets, and they can also both consume context from other components on the page. There are a number of techniques for doing this context sharing and they have pros and cons, but those pros and cons will rarely enter into the decision of which component model to choose.
End users and administrators can put portlets or Widgets onto a page and re-arrange them on the page, and customize their behaviors based on global settings that impact all users in the case of administrators as well as personal settings that only impact that one user.
So does that matter and what does it mean?
The second consideration is how much augmentation of the back end services is likely needed? If there is a lot of logic or data manipulation required, then using a language like Java, or doing that processing on a server vs. on a client is probably a good idea. Or alternatively, you might want to deploy some server logic on a Java server or PHP server or sMash server to do the necessary processing and then use an Widget for the display. Purists can argue whether or not this is an 'Widget' scenario, but that isn't important. We'll just refer to it as a Widget hybrid scenario. The important consideration is to determine whether or not your back end services are ready to use or need additional server side logic. If they need additional logic, portlets are a good model for that if you are comfortable with Java and the portlet spec. Otherwise, you should consider what language you do want to write these services in and look at Widgets to create the UI components.
The fourth consideration is responsiveness. This is a tricky one. In the purest sense, Widgets are independent browser calls to server side services and will be, or will feel, more responsive than the standard portal pattern of rendering all the portlets before returning the page. Where this is a bit tricky now is because you have more options for rendering individual portlets as well as the portlets using AJAX for improved responsiveness. There are also cases where it is best not to independently render parts of the page. So you want to consider your bandwidth, the 'chattiness' of the user interactions, what the right kind of page(s) make the most sense.
The fifth consideration is standards and investment protection. Portlets are the most mature of the choices and is covered by second versions of widely adopted Java and Oasis standards. Widgets are relatively new and you should expect some amount of evolution and possible churn as the industry moves to standardization.
The sixth consideration is that you probably will have some additional testing against different browser types based on how much logic you put into the browser. For intranets, you can often minimize this by specifying one or two supported browsers. This is not really just and Widget vs. Portlet consideration however. As already mentioned, you can put a lot of client side logic into portlets as well, and so it is a general consideration as you put logic into the browser.
And finally, client side aggregation (whether portlet based or Widget based) causes issues with most search engines and so you should consider having an alternate rendering for search engines. For public facing web sites with external crawlers, that is probably most easily accomplished in the near term via Portal and Portlets. For intranets, there are more options for indexing sites and search.
The WebSphere Portal Blog
Matching: widgets X