Java-Based UI Frameworks

I was recently talking with a friend about UI development. He has also been a programmer since programming was considered an arcane art (when those of us that did it were considered like Gandalf the Grey facing the Balrog). Or maybe, we just saw ourselves that way. Regardless, both of us have been Java programmers for a great deal of that time.

We both lamented the fact that it was a context switch to go from coding most of our projects in Java, then needing to switch to JavaScript for the front end.

Based on conversations I’ve seen online, several readers are warming up their keyboards to chide me for complaining about having to code in JavaScript. Keep your keys cool, both of us and our co-workers are experienced in, and happy to write in, JavaScript and any of its frameworks for our clients. But using JavaScript isn’t always the best approach.

 In this post, we introduce two frameworks that allow you to code your user interface in Java: GWT and Vaadin.

When To Use Java For Your UI?

The conversation came back to me as I was speaking with a client — a small shop of only a couple of programmers and a software architect who also programmed. They had decided that they didn’t want to maintain their projects in two separate languages. Their company had standardized on Java, and they wanted to use the same tools and mindset to create powerful and modern user interfaces for their web applications.

I have noticed on larger teams that the team seems to separate themselves, some preferring to concentrate on the front-end, and others working mostly on the back-end or server-side code. When work get’s approved for development, often I see the same programmers either taking or being given the majority of the JavaScript front-end work, and others taking on the back-end.

I’m not saying this is a bad thing; actually, it appears to be just the opposite. Everyone seems to be more productive in their comfort zone, but everyone is also aware of what everyone else is doing and can step into that zone if or when needed. For smaller shops, this is not an option. Often, the same programmer will write the code an entire project from the user interface to the model.

Fortunately, there are choices if you wish to keep your user interface in the same language as your back-end if that language is Java. Let’s talk about a few of them now.

GWT

Google Web Toolkit, or GWT, is an excellent option.

I’ve had a lot of success with GWT on a project I started about 8 years ago and still maintain. GWT allowed me to build the view logic for a Single-Page Application completely in standard Java code. It comes with an Eclipse plugin. I didn’t use it because I used Netbeans for my development environment, but as Eclipse is the standard for most teams, this could be very handy.

I was able to break down the logic for widgets (such as a custom text box), into classes or helper methods, just as I would business logic on a server-side project. Through inheritance, I was able to create several widgets that had similar requirements easily. About the only real concept of change I had to deal with was that the UI is much more event-driven than most web services or other server-side code.

There are two primary downsides I see to GWT. One is the compile time. GWT adds a compile step to the process that does take some time. The GWT classes that have been built in Java must be compiled into JavaScript libraries. I have seen several complaints about the time this takes.

The second is that it has been quite a while since GWT has seen a significant update. As of this writing, 2.8.2 was released over a year ago in October 2017. Three years before, 2.7.0 was released, making it four years from the time of this writing. I see posts and comments about 3.0 coming out, including some from two years ago asking if the poster should wait for 3.0 to come out before implementing a big change (I hope the poster is not still waiting), but I cannot find any timelines as to when that release might be out.

Although I’m a big fan of the framework and consider it to be mature enough as is, I know this vagueness in the possibility of future releases makes some project managers rather nervous. No one wants to be tied to a framework that dead ends on them.

GWT is a library that I will continue to use and suggest to other teams to use if it meets their needs.

Vaadin

Vaadin is another great option.

I originally thought the GWT was my only choice for writing user interfaces in standard Java code. But when I talked with that small shop I mentioned above, they told me they had decided on using Vaadin for their projects. So, of course, I had to go take a look. And I am impressed.

I’ll be honest, as of this writing, I have not yet used Vaadin to create a project. But I am ramping up a couple personal projects I need front-ends for and intend to use this. If Vaadin delivers on its promises, it will be a perfect framework for these projects.

Vaadin promises to support languages that run in the JVM such as Kotlin and Scala. I hope that includes Groovy. If you read many of my previous posts, you’ll know I’m a fan of that language because you can quickly create code that can be easily maintained. These are important requirements for me, especially maintainability. Nothing destroys a project down the road more than not being able to easily maintain the code that has already been written.

Final Thoughts

You have many choices when architecting your web application when it comes to user interface technology. Whether you’re architecting a project or a production environment, you have so many requirements to keep in mind.

Two requirements you must keep in mind are ease of development and maintainability.

• A development environment that is difficult to work in will result in many cost overruns and make bring new programmers on very difficult.
• A project that is difficult to maintain will cause frustrations and waste more money in the future.

Based on your team’s needs and requirements, a full Java solution, from the user interface to model, is not only possible but a great choice for both rapid development and ease of maintenance.

Believe in good code.