DEV Community

Sami Ekblad
Sami Ekblad

Posted on • Updated on

What's the deal with Vaadin add-ons?

Vaadin is a framework for creating web applications in Java. It grew in the era when Java was the most popular programming language out there. But its benefits and popularity go more profound than the Java language. That is best visible in the way you extend Vaadin.

There are many UI widget libraries out there. Vaadin also offers a consistent set of widgets optimized for "desktop-like" applications. The difference is how those widgets or components are made and behave. Vaadin provides three kinds of add-on templates. They are not the only options you have, but they reflect the different use cases and benefits of the framework. Let's have a look at each of them.

Server-only add-on

This is the most "Vaadin-native" way of extending Vaadin. In this, the component is entirely composed of existing Vaadin components or other add-ons. It is good for making bigger logical UI composites like CRUDs and "micro-UIs" for e.g., editing certain types of data. Think of "person editor" instead of just a "form".

Vaadin Server Add-on

This is close to how you would typically build and divide the whole application UI in Vaadin. The component state resizes fully on the server side, and the framework for you renders the client side.

Pros:

  • Fully validated user input
  • No need to use HTML, CSS, JavaScript, or TypeScript.
  • Easy UI integration to any Java-library

Cons:

  • Requires all data sent to the server
  • Not optimal for creating pure UX improvements like animations

Template: addon-template

Client-server add-on

This unlocks the full potential of the web and Vaadin in your applications. You are building your reusable components and custom elements that implement a particular user experience combined with desired server-side logic.

Vaadin Client-Server Add-on

With this component architecture, you can build your client-side logic that is combined with server-side logic. The perfect approach both for creating new innovative UI widgets that securely validate user input, or just a simple yet cool presentation-only widgets. You can let the framework take care of all the communication and lifecycle things and focus on the UX.

Pros:

  • Full control of DOM combined secure server-side data validation
  • Utilize all browser APIs to build remarkable UX and styling
  • Validate the input on the server side to keep data consistent

Cons:

  • Needs knowledge of DOM, custom elements, JavaScript or TypeScript, and CSS.

Template: client-server-addon-template

Extension from 3rd party NPM package

Since Vaadin components on the client side are custom elements, you can use any other custom element with Vaadin. The framework gives you standard ways of interacting with the component using DOM events, attributes, and methods already; typically, that is all you need.

Vaadin NPM Add-on

This opens the vast world of client-side integrations. Further combined with a small client-side JavaScript or TypeScript adapter, you can fine-tune the logic to build a Vaadin component with a less server-side state.

Pros:

  • Create Java API for any existing custom element from npmjs.com
  • Minimal Vaadin-specific code to write and maintain

Cons:

  • Client-side-only logic is not secure and needs also server-side validation
  • Integrating 3rd party elements might create inconsistent UX

Template: npm-addon-template

The right tools for the use case

The goal is to build highly reusable components that utilize both the server and the client where they are the best. This follows the abstraction philosophy behind Vaadin:

  • The server is the place of secure business logic and validations
  • Client-side is for building awesome UX and cool visual effects
  • Build logical reusable components and widgets

You, whether a web or Java expert, know the best approach. With the Vaadin add-on, you can decide and build and deliver your web components in a highly maintainable way that is best for both worlds: Ever evolving APIs and critical Java backends.

What are your experiences with reusability and architecture on the UI layer?

Top comments (0)