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.
Vaadin works nicely as long as you are happy with the components which are provided out-of-the-box. There are plenty of them, but god forbid you need to change one or create a new one. Then you're in for a lot of pain because integrating both client and server side into the vaadin framework is not easy.
Building the widgetset takes ages.
Extremely slow roundtrips for UI developers. In the worst case, you don't just have to restart your app but the entire webserver too. Then you need to navigate back to the page you were editing. It's a serious pain.
Page reloads. Vaadin does literally everything on the server side, so every click requires a server roundtrip. This has a negative impact on the user experience. Not vaadin's fault, just a general issue of server-side rendering.
Styling things is a pain as well, because the actual HTML DOM is generated, and the SASS you are editing generates a CSS, and in the end, you need to hope for both generated files to match. If I told you that I had "a hard time" with this it would be the understatement of the century.
Lack of backwards compatibility. Major version changes in Vaadin are always troublesome and upgrading is often non-trivial. What's more: the community-provided components are written for a specific Vaadin version, and when Vaadin releases a new major version, many of them are never upgraded, effectively making them useless.
You are not making use of client-side resources, at all. The server isn't really interested on which page a user currently is; it should focus on providing data for incoming requests. Client state should be handled at the client side - and you can't do that in vaadin. So if you have 1000+ concurrent users, then 1000+ concurrent user sessions are stored on the server, and next-to-nothing is done by those 1000 client devices. Not making use of those resources is quite a big loss.
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 ;)
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!