Migrating a legacy GWT frontend to Vaadin without server-side framework

I was asked to put this topic here after meeting at the Vaadin booth at Devoxx 2026 in Antwerp on the 7th October 2026.

The case we have is as follows:

  • We have an old GWT frontend, with a Java Servlets backend, using REST
  • The backend is completely stateless
  • The GWT frontend calls the backend using embedded JavaScript inside the Java code (fetch).
  • The GWT frontend is deployed and served statically after compilation
  • Since GWT is no longer maintained, we need to migrate, especially regarding security vulnerabilities

We were considering to move to Vaadin as the successor of GWT, which would make the migration path easier. But we have some concerns about the way Vaadin uses both a client-side model and a server-side model. The server-side especially requires a session, and our backend is fully stateless, which we would like to keep that way.

Ideally, we wanted to match the old frontend to Vaadin by using the equivalent components, compile it and deploy it statically on an Nginx (like we do currently). Adding the server-side model would require us to deploy additional infrastructure with session affinity configured, which we would like to avoid.

Would you have any tips that can help us decide if Vaadin would be a good fit?

1 Like

I don’t think there’s one simple answer here because it’s an architectural question and the details depend on your exact non-functional requirements and infrastructure. For example, using Hilla-based views would enable you to have a stateless server, but then your client-side development model would switch to React (using Vaadin web components potentially); the backend would still be in Java. This would allow you to get rid of the separate REST API; the communication would be handled by the framework.

1 Like

I’m not sure where you read that GWT is no longer maintained? From what I can see, the last commit was made 4 days ago and version 2.13.1 was released in June 2026. It is true that activity has slowed down over the years but I haven’t seen any announcement about ending maintenance.

Do you really need a stateless server? A typical stateful Vaadin application uses between 100 KB and 1 MB per concurrently active user session. You can get a 32 GB server for around $80 per month on AWS EC2 and that should be good for at least 20 000 users. Multiply the user amount by 10 and you’d need a 256 GB instance for around $600 per month which is probably still orders of magnitude less than the cost of developing and maintaining the application.

Finally, I could mention that we’re currently prototyping a slightly different server-side Java architecture which should bring down memory consumption of server-side Vaadin by around 100x compared to today, leaving you between 100 bytes and 1 KB for the typical application. In this scenario, the remaining state can easly be passed back and forth in each request and response or stored in a separate distributed cache such as Redis. I plan to present the initial details about this prototype at Vaadin Create in a couple of weeks and more information will follow after that.

2 Likes