Widgets are web pages embedded in larger web pages, generally using iFrames — the content comes via a separate HTTP connection and has its own CSS stylesheet, cookies, etc. Final composition takes place in the user’s browser.
Portlets are software modules that produce fragments of HTML markup that are assembled into a single HTML page, sharing common CSS stylesheet, cookies, etc. Final composition takes place on a portal server, and a single page is delivered to the client browser.
Portlets have a lot of features that iFrames don’t: they require fewer HTTP connections, they allow for common styling (one CSS stylesheet can style all the portlets on a page), and they can communicate with each other and take advantage of common authentication/authorization, etc. (so that a user doesn’t have to sign on to each portlet separately).
Portlets use a window-manager metaphor, allowing the portlet server to resize them, expand them etc. They also have modes, like edit and view, all of which can be accessed through a common interface. All of this happens on the server side.
iFrame-based widgets don’t normally do any of that, but they don’t require special portal servers, they can be embedded in more creative ways, and they offload the processing from the server to the client. They also introduce potential security holes, but only if they’re hosted somewhere that’s not under the original company’s control (the same applies to remote portlets using WSRP).
Portlets are used mainly in intranets, to provide a collection of enterprise apps on a single web page for employees (e.g. a news feed, calendar, expense forms, bug reports, etc.).
Widgets are used everywhere else (e.g. embedding Google maps, Facebook applications, etc.). While widget authors/consumers don’t tend to know (or care) much about portlets, the portlet people haven’t failed to notice the popularity of widgets — most (if not all) portal servers now have an iFrame portlet that does little more than wrap an iFrame and allow it to be resized, etc.
Are the extra features of portlets compelling enough to justify the extra cost and hassle of running a portlet server? Now that we have browser tabs, AJAX, etc., do enterprises really need to continue to squish all their apps into a single web page that looks like a 1995 Mac desktop gone bad?
My guess is that the only portlet feature with compelling benefits is common authentication/authorization — once the web community gets behind a solution to that problem (OpenID or something similar), widgets will probably push portlets out completely, even in the enterprise.
Portlets live in the same runtime. This opens the door for one portlet affecting the whole system due to memory leaks or other failure modes. It may also incur library versioning problems. There is no clean way to kick a portlet out of a running container. I find these points to be BIG counterarguments. Does WSRP solve this? Maybe. But I also see the way going towards widget based systems with integration in the browser level (how long will it take until we have integration nightmare there … ?)
As you said there is WSRP which allow runtime decoupling, so living in the same runtime is recommended for simplicity and performances but it is not mandatory!
Library versioning is solved in Java EE environments where different portlet applications can have their own version of the library.
Doing a portal in a browser using widgets will work fine if you stick to one component model, i.e all your widgets are Google widgets or whatever else. For instance iGoogle works fine because they defined their component model and they only work with it.
Once you start to mix technologies, you open the door to potential issues as the same DOM document is shared between the different widgets (toolkit versionning, prototype modifications done by toolkits, etc…).
Using a portlet container does not equals 1995 Mac desktop style, look at eXo WebOS which makes a different usage of the portlet technology (http://www.exoplatform.com/portal/public/en/product/webos/overview).
Pingback: Widgets will win the battle