It's funny how things come in sequences. Recently, on three separate occasions, I stumbled upon questions asking what people used for front-end tec...
For further actions, you may consider blocking this person and/or reporting abuse
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!