There has been some discussion about what the recently announced Vaadin 10 platform means in the context of GWT. I'll summarise some background about the direction we're taking here. I want to bring up two central themes: component models and freedom of choice.
UI development platforms such as Vaadin, GWT, Angular or jQuery are based on the idea of creating an application by combining reusable UI components. Each platform has its own way of defining and using such components. The different approaches have lots in common, but they are in general not directly compatible with each other. Versions 5 - 8 of Vaadin have been based on controlling GWT Widgets through UI logic running as server-side Java, but it has been cumbersome to use components implemented for other platforms.
Along comes the Web Components initiative that has defined yet another component model. What sets this component model apart is that it's a web platform standard backed by all major browser vendors. This has the promise of actually working interoperability between different application development platforms. The compatibility overview at custom-elements-everywhere.com shows that significant progress has been made on this front.
Our Web Component implementations were originally independent from our server-side Java platform that was still using GWT Widgets as the client-side component model. We had from the get-go planned that the next generation of our platform (i.e. Vaadin 10) would be based on universally usable Web Components, but it took us a while to actually get there. In the mean time, there has been some confusion about the role of our Web Components since there was no really easy way of using them from our own server-side Java platform.
Freedom of choice
Vaadin Flow is the core of the server-side aspect of Vaadin 10. It gives direct access to the entire DOM, i.e. any Web Component, from Java running on the server. This means that you can use any Web Component when building the UI of your application. We provide Java APIs for our own Web Component implementations, but we also make it easy to use any other implementations. At the same time, we realise that implementing the application's UI logic as Java running on the server isn't always the best approach. Therefore, we also encourage using our Web Component implementations with any other tech stack that supports Web Components.
One consequence of using Web Components instead of GWT Widgets as the client side component model is that we can offer more choice to our server-side Java users. With previous versions, the only way of doing many low-level customisations was to use GWT. For developers already familiar with GWT, this was of course a perfect match. But for many other developers, it was a huge learning curve. From their perspective, they would have been forced to use GWT, not allowed to use GWT.
This turned out to be a longer description than what I thought I would be writing. I hope it still helps you understand what we're trying to achieve with Vaadin 10 and how the different pieces fit together. If there's something that still feels unclear, then don't hesitate to post a comment below!