Java and the Frontend - what to choose?

What technology to choose for developing the user interface?

I get this question a lot: what technology to utilize for building user interfaces? Java has a long running hate-love affair with developing front-ends. We have seen it evolve from its 20th century desktop-based Swing/AWT clients from JSP/Servlet technology all the way to the Aspect-Oriented powered ROO framework where you Question/Answer your way to crafting a web frontend. No, developing the user interface has not been a walk in the park with Java. As a result we have evolved some paradigms that work for us.


As a specialist in the Java world, we basically have three answers. You can choose the suitable answer yourself on the basis of your requirements:




  • Wicket, Component-based framework

  • Spring MVC, Action- (or request-)based framework, also possible in the form of GWT, Grails or ROO

  • Separated front- and backend using Spring MVC / REST for the backend and, for example, Groovy / Grails for the frontend



The first, and default, option would be Wicket. Wicket is a component-based framework. This means that it will be possible to develop the application using a toolsuite of pre-developed components, all the while adhering to object-oriented standards. As component-based frameworks go, Wicket is top of the bill, beating competitors such as JSF and Tapestry hands down.



The second option is to employ an action-based framework such as Spring MVC. A lot of the arrangements which are in place for Wicket, are no longer available. On the upside, Spring MVC is easy and it allows a much clearer separation between the responsibilities of the Java developer and the HTML / CSS / JavaScript specialist.



The third option would be any action-based framework sitting on top of a REST- or SOAP-based architecture. For this we make use of Spring MVC / REST to implement the API and, for example, but not restricted to, Groovy / Grails for the frontend.



So let us dive into the three options.



Wicket


Wicket is an excellent framework, if:




  • your applications have similar look-and-feel, allowing more reuse of Wicket components. The project must be sufficiently large to justify the cost of custom-made Wicket components

  • the user interface demands are low, ie most of the interaction will be Web 1.0 or at best the usual Web 2.0 suspects

  • you can call on Java developers skilled in the Ways of Wicket

  • you are experienced with developing old-school desktop clients and want to go web-based—Wicket will be very similar to what you already know

  • you have limited access to HTML / CSS / JavaScript expertise and development capacity



If some or all of these constraints hold true, your project is a more eligible candidate for the utilization of Wicket.



Now, the catch: Wicket wants to be in charge of the HTML, it is generally one-step-behind when it comes to incorporating the latest and greatest and it is relatively hard to learn compared to action-based frameworks.



HTML templates largely exist in the Wicket domain. Wicket takes over many aspects of managing the frontend. In a way, Wicket’s need to be in charge is steering it onto a crash course with the demands of modern user interface design. CSS, HTML and JavaScript professionals will have to closely interoperate with the Wicket developer—or worse, actually dive into Wicket itself—to make this work. If the demands on the user interface are extensive, for example for a consumer site, the project will be placed in a precarious situation. Wicket’s advertised advantage of a clear separation between HTML and code only materializes for pure HTML/CSS. It is the modern application of JavaScript in a web application which Wicket has a hard time dealing with.



Wicket has some pre-fab options to make use of modern user interface innovations. However, the Wicket community has to pro-actively keep up with the innovations, or risk losing out on the new stuff. Since innovations in this field are moving at high speed, the overwhelming feeling is that Wicket is generally one step behind what is out there. This means you will either have to wait for someone to unlock new user interface technology for Wicket, or build it yourself.



Last, but not least, Wicket is not easy. It is a high-end framework, which is hard to learn and even harder to master. Truth be said, this is a trait more of component-based frameworks than Wicket in particular. At 42, we know the business of Wicket very well. That said, it might be a challenge to externally acquire Wicket resources for maintaining your applications. Check out those possibilities first before saddling your organization with a technology that it cannot support.



None of these items have to be an issue if your user interface demands are light (for example, for administrative tooling) and you can reliably call on the right development resources. Be sure to carefully check those preconditions first. Wicket delivers fast for a good price, if handled correctly, that is.



Spring MVC


The second option would be to develop your application on the basis of Spring MVC. Spring MVC is an action-based framework, in the same vein as Struts, though much more streamlined and—Spring-style—made by developers for developers. The application will be deployed as a single deployment unit, similar to the Wicket option.



There are some situations where it would be justified to choose this approach over Wicket, such as:




  • you are building a consumer site which puts focus on user experience

  • you would like to make use of readily available Java expertise and need a low treshold technology which developers can grow into relatively fast

  • your team consists of HTML / CSS / Javascript experts that need to be assigned to tasks as well



The main drawbacks of Spring MVC as a standalone application are the following:




  • there is still no clear separation of responsibilities with regards to backend and frontend

  • views tend to get cluttered and degrade into unmaintainable code quickly

  • there is no such thing as a component library which you can use to quickly assemble the application



Generally, we do not advise using Spring MVC for standalone applications, even though we love it for powering a REST-based architecture. For larger applications, the resulting mess is too much to handle. Wicket offers better ways to manage user interface. If you are considering employing Spring MVC in this way, it is worthwhile to also check the possibilities for employing Spring Roo (+GWT), GWT or Grails—at least these tools give you a heady start in the field of setting up the user experience.



Spring MVC / REST and Grails


This brings us to the third and last option. Basically, we have decoupled the architecture into two parts, backend and frontend.



The first part, the backend, is responsible for the business logic, security, validations, transactionality and integration with the repository (by default through JPA / Hibernate) and other backend systems. It opens itself to the frontend through an interface, mostly the pragmatic Amazon-style REST API. The backend is written completely in Java and quality demands are at the highest possible level. Since REST is based on the time-proven HTTP protocol, it has high longevity, especially when combined with high quality standards. This gives us a solid backend that can be unlocked to various types of clients, not necessarily view-based.



The second part, the frontend, has only one dedicated responsibility, which is the user experience. Nothing else. Everything which matters to the data is dealt with in the backend.



A simplified architecture overview looks like this:
Overview of separated frontend/backend architecture




What we found out, is that this allows us to be very flexible in the kind of technology we use to drive the user experience. We have tried it with Ruby on Rails, Groovy / Grails and Java / Spring MVC. We have not yet tried it with .NET or PHP, but there is no reason why that would not work.



There are a couple of advantages to this approach:




  • the sky is the limit with regards to the user experience demands that can be made on the user interface

  • the frontend specialists have more freedom to impose the design that they drew up because of a clear separation of concerns

  • the frontend itself is fundamentally less complex, leading to better support possibilities, both in-house and outsourced

  • replacing the user interface with a new user interface suddenly is a real option. The backend is built to last, whereas the frontend is built for change

  • the backend is available to other clients as well, possibly other user interfaces, but also other kinds, such as command-line interfaces, batch processes



Of course, this approach has its own catches. The most important one is that it requires something akin to a service-oriented architecture, which is no trivial undertaking. This also is something 42 is skilled in and can support.



To summarize, if you have low demands on the user experience and can call on Wicket expertise, Wicket is the choice for you. If the application is relatively stand-alone, yet requires maneuver room for the frontend specialists, consider something different than Wicket, such as Spring MVC or Grails. However, if you run a consumer site, represent a mid-sized or larger organization, have several underlying services that need to be unlocked and have high demands on the user experience, you might be better served with a frontend / backend separation, with your backend powered by Spring MVC / REST and your frontend being implemented in, for example, Groovy / Grails.