Are portlets dead? JSR168 and JSR286 versus reality.

Eric Spiegelberg, an experienced JEE and portlet developer, evaluates in his article JSR-286: The Edge of Irrelevance the changes brought to the portlet community by the "new" JSR 286 and comes to the sad conclusion that the portlet technology has missed its chance and is declining in interest and momentum and JSR 286 won't change that. Only rarely do the benefits of this technology outweigh the additional complexity, restricted programming model, and other drawbacks. He explains his opinions and gives reasons for them pretty well and I can only agree.

Some of the points we can make here are:

• The specification, when finally released, is already outdated. JSR168 needed nearly two years to reach the final release in Oct 2003, JSR286 released in Jan 2008 over two years. Add the time needed by portal vendors to implement it and to remove initial bugs and when you finally get to use it in production it lags like three years behind the present world. As Eric puts it: "Reading between the lines, this means that the stated primary goal of the recently released JSR-286 is to align itself with the latest and greatest Enterprise Java technology of 2003."
  
• Portlet developers are 2nd class citizens, all the progress goes on in the web application space and they always have to wait for the "goodies" like JSF, Ajax, GWT, and when they finally get them - maybe after a year or years of delay - their integration into portlets/portals is usually at least flawed.
• There is a portlet specification but no portal specification. If you want to build nontrivial (multi)portlet applications you will usually need to use your vendor's legacy portal API to do necessary things otherwise not possible, loosing the already uncertain benefit of portability.
• Portlets are more difficult to learn and develop and a developer is more restricted than in a standalone web application. Eric writes: "Professional hands-on experience along with the above research led me to the conclusion that the portal architecture lacks enough technical advantages and distinguishing features to warrant an increase in acceptance. In practice, few applications can constrain themselves to the isolated and disparate functionality of portlets, and relinquishing this degree of architectural control is unrealistic in enterprise-level software."
• Interest in portlets is clearly declining. As Eric finds out, "18 out of 24 (75 percent) organizations that officially supported JSR-168 in 2003 do not officially support JSR-286 today".

It's a pity that portals and portlets aren't easier to use and haven't made it into the mainstream, the abilities of content aggregation, personalization, uniform security etc. are promising and as we can see in the rise of personal mashups like iGoogle, the fundamental ideas behind portals are still valid and extremely attractive. I hope that some mashup technology will soon provide a viable, light-weight alternative to portals.

For the sake of completness I should say that I'm currently working on "portletization" of an application and that I spent some time on a JSR 168 portlet for WebSphere project.