Yesterday me and a friend were talking about the overuse of custom taglibs.

We create taglibs for everything. We create taglibs in order to wrap jQuery UI elements (tabs, button, etc), and other plugins elements as well. We often wrap them together in a single component. We use taglibs in a point that we almost have no pure html within the body tag.

Our question is: is this a healthy habit? Imagine two situations:

1) We hire an html designer and have the cost of a month for him to learn all this stuff.

2) We want to outsource the html development but no company would get our taglib library to learn, OR it become more expensive.

We love taglibs as its been a lovely shortcut for javascipt development as we write it only once. What would be the best practices in this sense, and what would you suggest? We are looking for a future-proof solution (or an argument that agrees with ours).

  • 3
    Those are 2 very good reasons to stop it now aren't they?
    – Rig
    Apr 4, 2012 at 0:23
  • Yes, @Rig! Thats the reason for this Q, the alternatives for reusable UI components Apr 4, 2012 at 1:20
  • 1
    @Renato Could you rephrase your question to specifically ask about alternatives for reusable UI components, instead of what you have (which to my mind answers itself)?
    – jcmeloni
    Apr 4, 2012 at 11:22

2 Answers 2


One of your uses of taglibs is to encapsulate JavaScript. Is it possible to do this with just a JavaScript file? (or a JavaScript file and a div so the JavaScript file can write out any HTML it needs. or a JavaScript file and a few regular HTML fields.)

JavaScript is very powerful. It has objects which let you avoid polluting the global namespace.

And no, as noted in the comments writing taglibs for everything is taking it too far. It's like you wrote your own JSF type language without the benefits of standardization.


"We are looking for a future-proof solution"

I would suggest you look into Web Components. That, with little doubt, would be the direction client side development is headed and it would enable easy creation of resuable client side functionalities. Although the Web Components standardization process is still far from finished, you have a couple of libraries out there, that serves as poly-fills that allows the usage of the principle of Web Components across browsers.

Polymer.js (by Google) is an example of this. You also have Brick from Mozilla and React by Facebook.

Also some of the currently leading Javascript framework provide the same idea, although implemented via different mechanism. In AngularJs, you have Directives. In EmberJs you have Components. But the good news is that, at least these two, plan to move their implementation to the official specification once it becomes a formal standard. As stated in the documentation for Embers component and for AngularJs, as announced in the Polymer.js group.

All in all, I would advice you play with Polymer.js. If you want client side functionality to be so decoupled that it is possible to outsource it easily, why not just completely cut the reliance on JSP's, and have that tier implemented using the technology much fitted for it. Am sure a company focused on HTML/Client Side development won't have any problem getting up to speed with it. It is a familiar terrain :)

You might want to check this cool tutorial: Getting Started With Web Components and polymer.js

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.