I finally have the time to come back to the discussion.
First I want to thank Vaadin for there open and honest feedback. For me that meant a lot because usually companies don’t admit mistakes in the “public”.
Our application is at the first customer site now and we sticked with Vaadin 13, but it was a very close call. We basically shipped it with known bugs instead of rewriting the UI in Vaadin 8, because at this point only our staff will see the UI.
I think a major challenge for Flow is the expectation of the developer’s skillset. As Antoine also pointed out, you’ll be flying in V8 with just Java and some HTML/CSS knowledge. To be flying in Flow you need to be strong in Java, CSS, ShadowDOM, Polymer, Javascript and Flow structure.
I think it is not possible to undervalue this quite from Martin Israelsen. Besides fixing the numerous bugs the developer experience needs to get better. Compared to the current Vaadin Platform the Vaadin 8 developer experience was a lot better. The main benefit for me was always that I didn’t need to take care about the details. But now I also need to be an expert on Polymer, ShadowDom and CSS (I’m still not 100% sure what :host() does exactly and when to use it). Today all the Vaadin 8 developers/experts who switch to Vaadin 10 will have to learn a lot of new things, which is a lot harder than it sounds like in the documentation. It’s basically “Rewrite your complete UI with a Framework thats 80% new”. It’s nice to have more control over the rendered elements, but to be honest I don’t want to work with div, span, etc. on a daily basis. Vaadin always took care of that for me.
Some component design decisions are also quite strange. For example, Tabs. I suspected this is a drop-in replacement for Tabsheet. But it is missing one essential feature. The changing of tabs. It’s basically just a styled Button bar and you need to take care of it yourself. It’s hard to image a use case for a Tabbar without tabs.
After working with vaadin-crud I also have one additional fear. Webcomponents where just the basic functionality gets wrapped in Java classes but nothing more. In vaadin-crud I can customize the main parts (grid, form and binding) but when I want to do more I’m screwed. For example, we don’t have any tertiary buttons in our application, but I can’t remove the tertery style from the buttons. Also I can’t access any of the windows from the java side. The vaadin-crud-flow implementation seems more like it was done just to strike it of the checklist. Which is very sad for a pro component.
I really hope after the Vaadin 14 release you will find more time to focus more on the developer experience. Also it would be nice to have a first class support of gradle. John Ahlroos always did a great job but for a side project I think it’s just too much, to do it all by himself.