It's funny how things come in sequences. Recently, on three separate occasions, I stumbled upon questions asking what people used for front-end technologies. Every time, my answer was Vaadin. Unfortunately, some places, e.g. Twitter, are too limiting to explain my answer in depth.
In this blog, I've no such limitations.
In one sentence, Vaadin is a framework to create GUI using plain Java, or any JVM-based language for that matter. One develop in Java, and the framework takes care of all the rest: this includes the generation of the client-side code, and the communication between the client-side code in the browser and the backend code on the server.
Benefits of using Vaadin
This architecture provides the following benefits.
Easy onboarding
The first and foremost characteristic of Vaadin is that there's no need to know other technologies. Let's think what skills are required for a "standard" app that consists of a REST API and a JavaScript front-end:
. Java
. Jakarta EE API, i.e. Servlets and JAX-RS or the Spring framework
. REST principles
. AJAX for browser-server inter-communication
. HTML
. CSS
. JavaScript (or TypeScript)
. A front-end framework: the most popular contenders are currently Angular, Vue.js or React.
That's no less than 8 completely unrelated technologies. And I'm particularly generous: I'll leave out any additional JavaScript libraries, as well as the build tool necessary to build the front-end artifact. Yet, the latter is required in order to transpile from TypeScript to JavaScript, or from the latest JS version to one that is supported by most browsers. With Vaadin, the list becomes limited to Java... and Vaadin.
If you read this, you might consider that it's not that a huge benefit, because you are surrounded by 10 times developers, whatever that means). My experience is quite different: I've worked more than 15 years as a contractor, for a lot of different customers. Most developers are regular people, happy to work from 9 to 5, and then go back home to live their lives. They have neither the will nor the time to learn yet-another-technology outside of office hours. With the premise that training needs to take place during office time, less technologies mean less training time, and more time dedicated to developing the app.
No integration phase
The simplicity that Vaadin provides has an additional benefit. If one app's architecture is separated into a front-end and a back-end that communicate via a REST API, there are two strategies to organize one's team:
- Development per layer This strategy is based on two specialized teams, the front-end team, and the back-end team. They are very good in their own stack. They both work in parallel, in their respective stack. After the slowest of them finishes, they integrate their respective work together. My experience has shown me that in the parallel phase, the work is done (quite) quickly. On the opposite, the integration phase takes a lot of time. My experience is that it takes up to the time spent in the first phase - effectively doubling the development time. The worst is that this second phase is underestimated by most teams, including project managers.
- Development per use-case This strategy is based on full-stack developers. This kind of developer is able to work on both ends, front and back. Each developer is assigned a use-case/user story, then needs to understand the business around it, and afterwards is able to develop the whole flow from the GUI to the database. I personally believe that the full-stack developer is a concept which was invented by managers to make developers interchangeable. That way, task planning becomes so much easier for them. Anyway, let's admit that such unicorns do exist. If one is skilled in that many technologies, one should have had time to learn them. That brings me back to the point made above: most developers have a life beside their job. Of course, there are geeks, but in that case they must be paid accordingly. Unfortunately, regular companies don't have enough budget: they might afford one, but not a complete team of unicorns. In that regard, Vaadin allows non-rockstar developers to develop the application using the 2nd strategy. It also allows them to spend more time on the business side of things, and less time on the technical issues.
Parallelization between backend and front-end development
By default, Vaadin lets developers who don't double as graphic designers to develop acceptable-looking GUIs. However, it happens that the product owner has requirements - and sometimes even budget - to customize the design.
With the traditional approach, designers achieve that with HTML and CSS. They will design specific HTML templates and CSS classes. Then, developers will be asked to use them.
If requirements change mid-way, developers will need to stop their work to integrate the changes required by designers: there's a high dependency between the workflow of developers and the one of designers. Some technologies such as JSP, JSF and Thymeleaf allow designers' artifacts to be reused as-is by developers. In that case, both will need to work on the same artifacts. Git merge conflicts are always fun when one doesn't completely grasp upstream changes.
Vaadin introduces two abstractions that decouple the work of developers and designers: themes and components.
- A theme is a collection of CSS (and Sass). Because Vaadin generates the HTML, designers know the structure to expect, and can design their CSS accordingly. The Lumo theme is applied by default. Another theme, Material is provided out-of-the-box. The ecosystem offers additional themes, each being available as a JAR that only needs to be added to the classpath. It's also possible for a designer to create one's own. Note that switching themes is possible through a simple method call.
- A component has both a HTML template, and a Java class that represents it on the server side. Such a component may place other components in a layout. While the Java class manages them as attributes, the HTML template is responsible to the layout. This way, the developer's work on the Java class - or any other class that uses it - and the designer's work on the template are completely isolated from each other: they can be fully executed in parallel.
Designed for "business" applications
Finally, Vaadin is designed at its core to develop business applications.
- On the UI side, components include widgets frequently used in such applications e.g. fields, combo boxes, forms, tables, etc.
- Most components display data. The design of those components introduce an abstraction between a component and its data. There are different concretions:
- For scalar values e.g. an email displayed in a field
- For collection values e.g. the list of countries displayed in a combo-box
- For two-dimensional values e.g. tabular data displayed in a table
Arguments I heard against using Vaadin
In all those years, I've heard quite a few arguments against using Vaadin.
They mostly all boil down to the following two.
"But does it scale?"
You might be interested in knowing that this question is part of the 10 tricks to appear smart in meetings (#6).
On a more serious tone, scaling definitely deserves some digging in. Vaadin stores the state of components server-side. With a huge number of components, and with the increase of the number of clients, this leads to an exponential consumption of memory. In that regard, traditional applications don't differ that much from Vaadin applications.
First, we need to understand that there's the vast majority of applications are stateful. However, the differentiating factor between them lies in where the state is stored. As I mentioned, Vaadin stores it on the server. There are only two other alternatives:
- Store it in the database. Do I need to detail why it's a bad idea?
- Store it on the client. I makes a lot of sense to store UI-related data on the client. There's one not no minor caveat though: if more than one tab is opened, it needs to be handled server-side somehow. Note that Vaadin manages multiple tabs by putting a hidden token when it renders the page initially. When the user interacts with the page, the token is checked, and then a new one is sent to the browser again.
While beyond ten thousands of concurrent users, I might start thinking about other alternatives than Vaadin, anything below that number is fair game. That's 99.99% of all applications.
Not API-first
Another argument I've heard against Vaadin is that it's not API-first. Good software developers/architects alway develop an API in order to let different kind of clients to use: browsers, but also native clients, and other services - whether internal or third-party.
Unfortunately, I think this is herd mentality. API-first is desirable in the context of multiple clients. Most business applications I've worked on are just CRUD applications with more or less business logic applied on top.
But what if additional clients become necessary in the future? YAGNI! If you do, remember that Twitter was able to rewrite its complete information system from Ruby on Rails to Java: migrating the GUI layer of an application is well within the bounds of the possible.
Boring
Finally, while I never heard anything like that, I believe one of the reasons Vaadin is not that popular nor widespread is because it's so boring. It has been around since more than 15 years, it works as expected, and most challenges around it have already been solved. Unfortunately, this doesn't fit developers who practice Résumé-/Hype-/Ego-Driven Development.
Conclusion
I discovered Vaadin a bit more than 10 years ago, and that was love at first sight. In fact, I immediately began to tinker with it, and tried to integrate it with another of my crush, the Spring framework.
Version 10 saw a massive rewrite of the framework. Product management steered it toward more web-y features, such as web components, the introduction of routes, etc. I believe this move was done in order to appeal more to web developers. To be fair, I'm not very happy with those changes.
However, that doesn't change the fact I'm still a huge fan of the framework. I admit it's not as hype as JavaScript frameworks. On the other side, it's a massive productivity boost when developing business applications compared to any other hype alternative.
Originally published at A Java Geek on June 7th, 2020.
Top comments (5)
I never gave Vaadin much of a chance because I was one of the "mindless drones" who considered that a front-end should be written in a "front-end framework" like Angular or React.
Having more experience in the consulting field now my view on that is shifting, rapidly.
I've seen too many projects slow down because of NPM issues, setup of yet another build tool (for Angular/React) and the endless discussion if the frontend should be "in the same repository or have it's own repository).
What slowed teams down the most is the context-switching between Java and Javascript. They are very alike (especially with Typescript) but different enough to be annoyed by little changes. That all is removed when switching to Vaadin.
That doesn't mean you won't struggle with Vaadin. You still need to learn THAT framework... and it's not always clear why you need to do certain things. (ex. you need to exclude the default ErrorMvcAutoconfiguration, as it messes with Vaadin..)... but at least you can do it all from the relative safety of your favorite IDE in your favorite JVM language.
I used Vaadin 7.x on a medium-sized project once back in the day. I still see its merits (first and foremost, you don't have to touch JavaScript!), but I wouldn't want to go back to it, for several reasons:
There is no strong separation between UI and server code which can lead to messy coding if you're not careful. It's just too tempting to use those hibernate beans directly as UI model. That's never a good idea.
I do have my issues with JavaScript and the web stack. They were never meant for application development, but for the display of static documents. This heritage is clearly showing through even today. The web is far away from a desktop experience, both for the developer as well as the end user (even though the vaadin folks try really hard to bridge this gap). But it's the way things "roll" today. But for me the go-to solution is still a dedicated stateless server-side API (REST or GraphQL) and the client can be anything, including (not limited to) a JavaScript frontend. I've left Vaadin behind, and to be honest I never looked back, not even once.
I agree with your points, yet for some to a lesser degree. For example, yes, building the widgetset takes ages, but you can configure the build for a single browser in development, and then it becomes bearable again. Also, note that GWT has been replaced by HTML elements for newer versions.
I do believe Vaadin has its place, but as you mentioned, some cons prevent it from being used in some contexts.
It was all GWT back when I used it. I didn't even know that this is no longer the case. Still, like I said, I never looked back. Even though I don't like JavaScript ;)
As long as it works in your context, this is perfectly fine!