Part I – Memory and CPU usage is centralized to the server

Easy Swing to Web with Vaadin

Matti Tahvonen
Movement image via Shutterstock

In the first part of JAXenter’s series on Vaadin-based web apps, Matti Tahvonen shows us why every architectural decision has its pros and cons, and why the same goes for switching from Swing to Vaadin in your UI layer.

As expressed by Pete Hunt (Facebook, React JS) in JavaOne 2014 Web Framework Smackdown, if you would be creating a UI toolkit, from a scratch, it would look nothing like a DOM. Web technologies indeed are not designed for application development, but for rich text presentation. A markup based presentation has proven to be superior for more static content, like web sites, but applications are a bit different story. During the early stages of graphical UIs on computers, UI frameworks didn’t by accident form into “component based” libraries. Those UI libraries have developed during the decades, but the the basic concept of component based UI framework is still the most powerful way to create applications.

But Swing, SWT, Qt and similar desktop UI frameworks have one major problem compared to web apps: they require you to install special software on your client machine. As we have learned during the internet era, this can be big problem. Users have lots of different kinds of applications that they use nowadays and installing all of them, and especially maintaining those, will become a burden for your IT department.

Browser plugins like Java’s Applet/Java WebStart support (and there Swing or JavaFX) and Flash are the traditional workarounds to avoid installing the actual software to workstations. But famous security holes in those, especially with outdated software, may become a huge problem and your IT department is nowadays most likely against installing any kind of third party browser plugins. For them, it is much easier to just maintain one browser application. This is one of the fundamental reasons why pure web apps are conquering even most complex application domains nowadays.

Welcome to the “wonderful” world of web apps

Even for experienced desktop developers it may be a huge jump from the desktop world to the web development. Developing web applications is much trickier than developing basic desktop apps. There are lots of things that makes things complicated, such as client-server communication, the markup language and CSS used for display, new programming language (JavaScript) for the client side and client-server communication in many different forms (basic http, ajax style requests, long polling, web sockets etc.). The fact is, that even with the most modern web app frameworks, web development is not as easy as building desktop apps.

Vaadin Framework is an open source Java framework and is the closest thing to the component based Swing UI development in the mainstream web app world. Vaadin is a component based UI framework that tries to make web development as easy as traditional desktop development, maximizing developers’ productivity and the quality of the produced end user experience. In a Vaadin application the actual UI logic, written by you, lives in the server’s JVM. Instead of browser plugins, Vaadin has a built-in “thin client” that renders the UI efficiently in browsers with raw browser technologies. The highly optimized communication channel sends only the stuff that is really visible on user’s screen to thin client. Once the initial rendering has been done, only deltas, in both way, are transferred between the client and the server.

The architecture of Vaadin Framework provides you an abstraction for the web development challenges, and most of the time you can forget that your are building a web application. Vaadin takes care of handling all the communication, html markup, css and browser differences – you can concentrate all your energy on your domain problems with clean Java approach and take advantage of your experience from the desktop applications.

Vaadin uses GWT to implement its “thin client” running in the browser. GWT is another bit similar tool for web development, and its heart is its Java to JavaScript “compiler”. GWT also has a Swing like UI component library, but in GWT the Java code is compiled into JavaScript and executed in the browser. The compiler supports only a subset of Java and the fact that it is not running in JVM causes some other limitations, but the concepts are the same in it as well. Running your code in the browser as a white box also has some security implications.

Architectural differences you should notice

Every architectural decision has its pros and consequences and so does switching from Swing to Vaadin in your UI layer.

One application instance, many users

The first thing you’ll notice is that you are now developing your UI right next to your data. Pretty much all modern business apps, both web and desktop apps, save their data somehow to a central server. Often the data is “shielded” with a business logic layer, implemented with for example EJBs. Now that you start to use Vaadin UI, the EJB, or whatever the technology you use in your “backend”, is “closer” to the the UI. It can often be run in the very same vaadin architectureapplication server as your Vaadin UI, making some previously hard problems trivial. Using a local EJB is both efficient and secure.


Even if you’d still use a separate application server for your EJBs, they are most probably connected to UI servers using a fast network that can handle the connection between UI and business layers more efficiently than a typical client-server communication – the network requirements by the Vaadin thin client are in most cases less demanding, so your application can be used over e.g. mobile networks.

Another thing developers arriving from desktop Java to Vaadin will soon notice is that fields with “static” keyword are quite different in the server side world. Many desktop applications use static fields as “user global” variables. In applications running in the server, they are “application global”, which is a big difference. Application servers generally use a class loader per web application (.war file), not class loader per user session. For “user global” variables you should use fields in your UI class, VaadinSession, HttpSession or for example @SessionScoped CDI bean.

Web applications in general will be much cheaper for IT departments to maintain. They have been traditionally run in company’s internal servers, but the trend of the era is hosting them in PaaS services or more generally in the “cloud”. Instead of maintaining the application in each users’ workstation, updates and changes only need to be applied to the server. Also all data, not just the shared parts, is saved on the server whose backups are much easier to handle. When your user’s workstation breaks, you can just give him/her a replacement devices and they can continue with their work.

Memory and CPU usage is centralized to the server

On the negative side is the fact that some of the computing previously done by your users workstation is now moved to the server. The CPU hit is typically negligible, but you might face some memory constraints without taking this fact into account. On the other hand, the fact that the application memory and processing happens now mostly on the server, might be a good thing. The server side approach makes it possible to handle really complex computing tasks, even with really modest handheld devices. This is naturally possible with Swing and central server as well, but with the Vaadin approach this comes a free bonus feature.

A typical Vaadin business app consumes 50-500kB of server memory per user, depending on your application characteristics. If you have a very small application you can do with smaller number and if you reference a lot of data from your UI, which usually makes things both faster and simpler, you might need even more memory per user.

The per user memory usage is in line with for example Java EE standard JSF. If you do some basic math you can understand this isn’t an issue for most typical applications and modern application servers. But, in case you create an accidental memory leak in your application code or a carelessly load the whole database table into memory, the memory consumption may become an issue earlier than with desktop applications. Accidentally referencing million basic database entities from a user session will easily consume 100-200MB of memory per session. This might still be tolerable in desktop applications, but if you have several concurrent users doing this in a server application, you’ll soon be in trouble.

The memory issues can usually be rather easily solved by using paging or by lazy loading the data from the backend to UI. Server capacity is also really cheap nowadays, so buying a more efficient server or clustering your application to multiple application servers is most likely be much cheaper than spending hours to optimize your application or making compromises in its architectural design. But in case each of your application users need to do some heavy analysis with huge in-memory data sets, web applications are still not the way to go for your use case.

If your application’s memory usage is much more important than its development cost (read: you are trying to write next GMail), Vaadin framework might not be the right tool for your. If you still want to go to web applications, in this scenario you should strive for completely (server) stateless application and keep your UI logic in browsers. GWT (also embedded in Vaadin and supported by Vaadin Ltd) is a great library for this kind of applications.

Part II on building a web application with Vaadin will appear on JAXenter next week

Matti Tahvonen
Matti Tahvonen has a long history in Vaadin R&D: developing the core framework from the dark ages of pure JS client side to the GWT era and creating number of official and unofficial Vaadin add-ons. His current responsibility is to keep you up to date with latest and greatest Vaadin related technologies.

Inline Feedbacks
View all comments