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.
Component models
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.
Vaadin has implemented its own set of Web Components. These were initially implemented by taking our existing GWT Widgets and exporting those as Web Components. Among the feedback we got based on those components, one quite common theme was that the Java implementation made usage difficult for a majority of the frontend developers out there who know how to debug and enhance JavaScript but not GWT. To maximise the utility of our components, the next generation of our Web Components were instead implemented as JavaScript.
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.
Vaadin Flow improves that situation in two ways. First, adoption of the very flexible Web Component model gives more power to server-side Java users. There are many types of customisations that no longer require the developer to even switch over to writing client-side code – the same can already be done directly from the server. For the cases that still need custom frontend logic, the developer is now free to use their favourite frontend language such as JavaScript, TypeScript, Scala.js, GWT, or any other solution that can be run as JS in the browser.
We are still working hard on the fundamentals that are based on the lowest common denominator, i.e. JavaScript. Once we are happy with that, we will start looking into how to expand the capabilities. Many of those would not be directly related to GWT, but I see two related opportunities that we might pursue. One is to provide language bindings for a smooth workflow with different frontend toolchains, such as GWT. Another potential direction might to to somehow integrate J2CL to make it possible to seamlessly extract selected parts of the application's UI logic and execute that code in the browser for improved responsiveness.
Summary
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!