Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


UI FrameworkLanguages / TechnologiesWidely Adopted?Ease of CustomizationResponsive web design supportHTML5 supportREST-friendlyFaceted/Filtered Search/Browse friendlyRapid Development friendlyThird-party plugin ecosystemNotes
Existing DSpace XMLUI Java, Apache Cocoon,XSLT, also leverages Spring WebMVCNoNot really (except maybe at Bootstrap level with Mirage2)

Mirage 2 theme = Yes

Other themes = No


Apache Cocoon has very little adoption and support these days, and hasn't had a new release in many years.

Apache Cocoon could be considered forked locally by most of the third party projects that utilize it.


Personal opinions on DSpace XMLUI:

  • Tim Donohue: My personal opinion is that, as it currently exists, the XMLUI should not be the choice going forward as it is based on an outdated, nearly obsolete framework (Apache Cocoon). In my opinion, it would require abandoning Apache Cocoon to be in consideration.
  • Graham Triggs Drawbacks are size of the framework, complexity of the framework, lack of adoption and support for Apache Cocoon.
  • Mark Diggory: Note, since DSpace 1.8 XMLUI also provides Spring WebMVC context and control (whose viewing technology is still Cocoon). I consider the points REST-friendly and Rapid Dev friendly to be subjective, we to rapid dev in Cocoon often, but it certainly is not a Rails, Grails, Play experience). Also note, Considerable parts of JSPUI were copied to XMLUI and placed into Cocoon Action, Matcher and Transformer classes, this UI logic could be compartmentalized separate from both UI and used across all web-applications including dspace-rest. Examples include authentication session management, request management, context management, resource resolution, even parts of Submission and Workflow ( jspui   , xmlui ) . An ideal path forward would migrate these features out of xmlui/jspui, where possible, make them UI agnostic, and place them into dspace-api.
Existing DSpace JSPUI Java, JSPsNoNot really (again, except maybe at Bootstrap level with Mirage2)YesA few areas (e.g .HTML5 upload), but not overallNoYesNoNoThe JSPUI codebase is approximately 13+ years old, despite some recent work to update it to use Bootstrap.

Personal opinions on DSpace JSPUI:

  • Tim Donohue : My personal opinion is that, as it currently exists, the JSPUI should not be the choice going forward, as its codebase is extremely dated and not easy to work with (despite the recent UI redesign). In my opinion, it would require a major overhaul to be in consideration. To be clear, this doesn't mean JSPUI is "dead", just that it would need a lot of cleanup work / redesign if we want to go this route.
  • Graham Triggs : A rewrite would be essential - preferably moving away from JSP to a templating engine, even if not using a recognized MVC framework. However, the benefits of being based on a widely known technology and having a small footprint are apparent.
  • Mark Diggory : Any move to repurpose or evolve of JSPUI should include a rewrite of certain features: the DSpace JSP tag lib should not include html, beans and JSTL should be leveraged instead. See comments regarding XMLUI/JSPUI consolidation above.
Spring WebMVCJava, Many View Technologies (JSP,FreeMarker, Groovy, etc) YesYesDependent on View technology Dependent on View technology Dependent on View technology Dependent on View technology Dependent on Framework choices NoMany java based frameworks utilize Spring MVC under the hood,

Personal opinions on Spring MVC Framework:

  • Mark Diggory : As a core technology of many of the frameworks below, Spring MVC has a strong uptake. As with many of the frameworks below, we are not necessarily locked into the view technology choices for all our user base. We may set the stage for a migration to frameworks below by first adopting a practice of using Spring MVC in both the XMLUI and JSPUI. See comments above in XMLUI

Play! Framework Java, ScalaYes, some major sites use it according to Wikipedia Yes, can be used with Bootstrap   YesYes, has a modules repository 

Personal opinions on Play Framework:

  • Graham Triggs I had a brief play with it a while ago. It's a neat technology, but has drawbacks in being more tailored to Scala than Java, and lacking documentation. It's also very dependent on using the Play toolset, even though in the background it can use Maven to manage dependencies, there would be a lack of synergy between front end and back end development, which might be an issue.
Spring Boot Java

Not yet. It's still very new (1.0.0 released in 2014).

However, the Spring IO platform itself is very widely used, and Spring Boot seems to have a lot of activity on GitHub, Stackoverflow, etc.

Note, Grails is part of the Spring I/O application stack. Appears to run directly on Boot in this case.

     Yes, it's built as a rapid development friendly version of SpringBuilt on Spring, so you can use other Spring projects 

Personal opinions on Spring Boot:

  • Graham Triggs Initial tests are quite positive. Obviously integrates very well with the Spring ecosystem, yet you can easily create a 'standard' Maven project for the application. Uses many templating engines (my preference is for Freemarker).
  • Mark Diggory   : Mostly a Spring runtime container, will support other views, does not directly addresses the two UI problem. Introduces a larger scale re-architecture project than just UI consolidation.
Ruby on Rails RubyYes Yes, has a Rails Bootstrap app, plus many gems   YesYes, in form of Rails plugins & Ruby gems 

Personal opinions on Ruby on Rails:

  • Graham Triggs Clean separation of front end and back end (via REST calls), will add latency and may cause problems for switching between front and back end development. Also, hosting concerns (JRuby vs separate Ruby and Java containers)
  • Mark Diggory   : Much more than a UI framework, opens the door to large questions concerning rewriting DSpace, takes us away from a single java technology stack
Hydra Framework Ruby on Rails, Fedora, Blacklight

Not worldwide, but has a growing following in libraries, etc.

The base technology, Ruby on Rails is widely adopted

 Yes (well, Sufia uses Bootstrap) Yes (uses REST to communicate with Fedora)Yes (Blacklight)YesYes, because it's Ruby on Rails, you often can use Rails plugins and/or Ruby gems

Hydra doesn't currently "work" with DSpace.

It would likely be a major endeavor to either migrate DSpace into a "Hydra Head" web application or "port" Hydra as a UI on top of DSpace's underlying architecture.

However, if we decided on the former (create a DSpace-like Hydra Head), there are members of the Hydra Community who are currently striving to do that same thing.


Personal opinions on Hydra:

  • Mark Diggory  : Much more than a UI framework, in either case its a larger migration path and endeavor than consolidating DSpace onto a single UI technology. In either of the proposed cases it does not solve the immediate need for a single UI.
Grails Groovy (based on Java), Also based on Spring WebMVCYes, large number of sites using Grails listed on website Yes, has several Bootstrap plugins Yes YesYes, has a plugins repository 

Personal opinions on Grails:

  • Graham Triggs Pivotal (the main commercial developer) has recently announced that it is no longer sponsoring Groovy / Grails. This is apparently because of an increasing amount of community support, however, it may point to concerns in the future.
  • Mark Diggory  : Grails has its own DispatchServlet (much like XMLUI did with Cocoon prior our modifications) I
  • To grok grails as quickly as possible its Ruby on Rails for Java: This means its more than a UI technology, we would be rewriting much of DSpace in the process. Example of Grails application in three pages, you generate the entire application stack, from Hibernate to UI in several commands. Again, this leverages WebMVC and the UI technology shown in the example is Spring WebMVC+JSP, but it supports other view technologies like Grails Server Pages. Seems to be REST/AJAX friendly. However, IMO, we are back to rewriting core DSpace to implement DSpace as a Grails App.
JQuery UI JavascriptYes Yes, e.g. there is a JQuery UI theme for Bootstrap Yes  Yes, has a plugin repository 

Personal opinions on JQuery UI:

  • Mark Diggory   : Does not address the Server side functionality that is needed to maintain use of this technology, I would exclude from list as a supporting library of functionality found in UI technology stacks in other technologies in this list.


(Javascript with RESTful JSON interface & Model-View-Presenter)

JavascriptYes, large number of major sites listed on Wikipedia & their homepage Yes, or at least you can use it in conjunction with Bootstrap. Yes YesYes, has plugins and extensionsDesigned for developing "single page web applications". It could prove difficult to use with DSpace because of the complexity of a repository system.

Personal opinions on Backbone.js:

  • Art Lowel (Atmire) Backbone is too low level imo. You still have to write a lot of boilerplate code yourself. We should probably replace it with one of the more modern JS MV* frameworks as alternatives to ember js, like angular, knockout or react
  • Mark Diggory  : Does not address the Server side functionality that is needed for persistence, a full suite of REST services would need to be present, questions would need to be answered regarding if workflows are managed as client side activities or server side activities.


(Client-side Javascript web application using MVC)

JavascriptYes, see their list of users on website Yes, can use in conjunction with Bootstrap, e.g. Yes YesYes, there's an "addon" repositoryUses Grunt, Bower, NPM (all of which are also in use by Mirage 2 theme)

Personal opinions on Ember.js:

  • Art Lowel (Atmire) Ember is very "opinionated" which is great to guide you in to using best practices to solve common problems. But it can get tricky if you need to solve an uncommon problem and you have to fight the system to make it work. However I'd like to add a +1 for ember.
  • Mark Diggory  : Does not address the Server side functionality that is needed for persistence, a full suite of REST services would need to be present, questions would need to be answered regarding if workflows are managed as client side activities or server side activities.
Vaadin JavaUnsure, their Community page has a tagline which exhorts you to "join 150,000 devs"Yes, they seem to prioritize working with plugins/addins, and has have a large component repositoryYesYesYesYesYesYes, see their component repositorySeems to have a large community, and many freely-available learning resources. Seems a good fit for existing DSpace development practices (empahsis on working with Maven, plugins for working in the major IDEs), it has a free book.
 Personal opinions on Vaadin: