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.
There are also a number of differences. The most obvious is that portlets are a server side component model (designed to execute on the server) and Widgets are client side component models (designed to run in the browser container). Portlets can bleed into the client as well in that more and more web interactions use AJAX for improved responsiveness, and also Portlets can emit markup that is basically a Widget to run in the browser container. But fundamentally the 'portlet spec' covers the server side APIs and services it uses and is not concerned with what HTML and Javascript is sent to the browser, and the 'Widget spec' covers the client side APIs and services and is not concerned with how the HTML and Javascript is generated on the server side.
So does that matter and what does it mean?
The first implication of this is one of skills. Is the team more comfortable with Java or Javascript?
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 third consideration is one of source code. The good and the bad of Widgets is that their source code is down loaded and visible in the browser. In many cases this just doesn't matter and doesn't need to be considered. In other cases, you might have some logic that you need to or want to hide (see the second consideration for that). Typically, exposing the source like this is a benefit especially in an environment where your users can learn from this and take Widgets they like and reuse and re-purpose them with minor tweaks. This is also a better model if you want non-trusted users creating Widgets since the widgets don't have to be deployed to a server where there is more potential for malicious attacks. The two cautions here is first, Javascript applications can sometimes be malicious, and so you want to do this only with an appropriate client side container such as IBM Mashup Center. Second, this light weight deployment is only valid when there isn't server side logic required. So this might not be true early on in a project, but there is an assumption that over time, more and more of the server side services will be directly consumable by Widgets.
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.
