Portlet vs Widget

I got this question a lot, specially after the javascript frameworks start to show up in the enterprise applications, what is better, portlets or widgets? why?

-The most obvious different between portlet and widgets 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) but  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.
Also Widgets do have a problem if you are trying to create a more enterprise type portlet. Most of the organizations have lot of backend data processing and 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 a better choice.

-The bad of Widgets is that their source code is downloaded and visible in the browser. sometimes this is can be a security problem as you expose the logic of your applications to the public.

- 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.
Moreover, Portlet spec is continually being defined and current.  Portlet 3.0 aka JSR-362 (https://jcp.org/en/jsr/detail?id=362) is being worked on actively by the likes of IBM, Oracle, Apache, Liferay, Red Hat, Vaadin, and others in the expert group listed on that JCP page.

- with widgets, as all the logic in on the browser, you probable will spend more time testing against different browser types based on how much logic you put into the browser.

- Portlets work best when you have interaction between portlets and pages. That’s not to say that widgets don’t pass data parameters around but portal and JSR 286 have matured enough to make it much easier to user.

- Liferay portlets have better UI interaction like mobile responsive design (redesign the UI to fit into a mobile), drag and drop it on the page or move it around. iGoogle doesnt even have this at the level that Liferay have and it is much “clunkier” feeling. Here are some blog posts with some good screenshots:

 

https://www.liferay.com/web/pmesotten/blog/-/blogs/liferay-6-2-what-s-new-under-the-hood-

https://www.liferay.com/web/juan.fernandez/blog/-/blogs/liferay-6-2-new-mobile-features-pt-1-

https://www.liferay.com/web/juan.fernandez/blog/-/blogs/liferay-6-2-new-mobile-features-pt-2-

 

Hope that will help you :-)

[Troy Griffitts]

Fady, your blog post should be renamed: Why Not To Use Widgets.

But really, you listed absolutely no positives for widgets. (and also iGoogle hasn't been around for over a year)

Liferay's support for OpenSocial Gadgets allows a Widget to be dropped and organized on a page by a user in exactly the same manner as a portlet.

Widget programming enables a wider range of developer. All web developers understand JavaScript-- not all web developers understand Java and JSR-286/168.

Widgets are remoteable. i.e., I can use widgets from 5 different servers in my portal and don't need to install any software on my server.

Widgets can still (and most all complex widgets do) use ajax to hit backend services which process data and hide business logic. These services are platform and programming language agnostic-- my python weenies can write in python if they desire.

My Widgets can run in other containers besides Liferay (sorry guys.) This might not sound as attractive to someone already committed to Liferay, but it is a wonderful tagline when building a widget suite and gaining buy-in from other institutions to use your tools, "If you like Liferay as we recommend, fine, but if not, you can try any other portal which supports the OpenSocial specification." It makes your customer feel like they have options.

Hope this gives a little more 'vs.' to your blog

[Fady Hakim]

Hey Troy, thank you for your reply.

For the title, I believe you are right . Actually I don't believe that Widgets are mature enough now to compete against portlets specially for enterprise application level. Widgets can do the job for small application on a small environment with no high security requirements but when it comes to high transactional serious enterprise level application, I don't think Widgets is a good choice.

Regarding your point about " All web developers understand JavaScript-- not all web developers understand Java and JSR-286/168." it's always depend on what layer of development you are talking about. backend developers are all about java, spring, struts...web designer are the one who like javascripts. Ofcourse it's a great way to do your interface with less calls to the server but for every javascript line you add on your page, you pay more for the testing process among different browsers, more processing on the browser side (sometimes that's not good because some clients have very old computers and their browsers hang when they access any page with lot of javascripts...)...more time to load the page for 1st time and more code to expose to the public.

Also think about a big enterprise who have developers who want to use Javascripts to build their portlets and another who want to use JSF or JSP tags with springs or struts on the backend, with widgets you can't do that, you are stuck with only javascript. With portlets, you are free to choose which framework you want to use. I did before some portlets using angularJS and moreover, you have a standard way to make portlets that use different frameworks to communication on your page.

Regarding "Widgets are remoteable. i.e., I can use widgets from 5 different servers in my portal and don't need to install any software on my server." portlets can work remote too. WSRP protocol can support a secure communication to consume portlets on a portal from a remote servers. If anyone have a heavy processing portlet, we always recommend to add this portlet on a different server and use WSRP to consume it on the portal.

For the last point, Liferay always gives the freedom of development to their clients, we don't lock our clients to any technology. you don't need to learn any new development framework to develop any application, you can use any standard J2EE framework (spring, struts, JSF, JSP, or any javascript framework like AngularJS...).
if our clients still believe that widgets is better for them, they can always use OpenSocial Gadgets with liferay: https://www.liferay.com/documentation/liferay-portal/6.2/development/-/ai/creating-and-integrating-with-opensocial-liferay-portal-6-2-dev-guide-08-en

Moreover, we never lock our clients to any application server, web server, database... we support wide range of infrastructure to integrate easily in our client environment.
https://www.liferay.com/documents/14/21598941/Liferay+Support+Matrix+6.2.pdf/f2f587a4-73e1-4b69-b8cd-4badc4f32e95

Thanks