Concerns about the quality of Vaadin Flow

Flow
1

We are currently developing our first Vaadin 13 Application. We are a long time Vaadin 7/8 Pro user and were usually quite happy with the quality of the Vaadin Framework. Small bugs here and there but nothing major.

A couple of weeks ago we started a new Project which required a very small UI (basically CRUD for one Entity and a info view). So we thought this was a perfect opportunity to give the new Vaadin platform a try.

It turned out quite the horror show.

Here is the list of bugs we discovered

  • NumberField.setPattern and setPreventInvalidInput doesn’t work
  • Textfield.setPattern and setPreventInvalidInput doesn’t work when the field is marked as required
  • Required Textfields don’t show any error indicator (this was due to a bug #115 of vaadin-crud-flow)
  • Required Comboboxes cause a client side error
  • Required Indicators are completly missing. Binder.asRequired(), setRequired(), setRequiredIndicatorVisible() nothing causes the indicator to show up
  • vaadin-crud (pro component): A lot of scrollbars show up when the the window gets to large for the screen
  • vaadin-crud (pro component): Implementing a custom HasValue field doesn’t enable the “Save” Button when the value is changed, despite a valueChangedEvent is fired

Missing Features:

  • Grid column collapsing menu is gone. You need to add a Button with a context menu somewhere near the grid.
  • Missing support of ViewScoped beans for Spring
  • vaadin-crud (pro component): No simple way to change the styling of the window content

Also the code feels quite clunky. You motto is “Fight for simplicity” but for me Vaadin 8 feels a simpler than the new Vaadin platform in it’s current state.

For example, to get a scrolling layout you need to manually set “overflow-y:auto” on the element. Also with Vaadin-Crud instead of just recreating the input window for every new/edit action, you need to take care of reseting the old one. With Tabs you need to manually take care of showing/hiding the content of all tabs because the content of the tabs is independent from the Tab itself.

I’m deeply concerned about the maturity of the Vaadin platform. It is 9 month since the release of Vaadin 10 and still a lot of basics are buggy or missing. I can’t understand how bugs like the missing required indicators or error indicator can pass through your UI.

The problems also alienated my teamleader, with the result that we stay on Vaadin 8 with our existing projects for at least 1-2 years till hopefully the platform is mature enough or move to something else entirely.

2

I am very sorry to read about your bad experience with Vaadin 13. I thank you for your extensive list of feedback which we take very seriously and discuss this within product development how to quickly release fixes to the issues you listed.

3

Hi Sebastian. Thank you for the feedback. It is very unfortunate that your PoC was a failure due to numerous bugs, and you are absolutely right - the quality is not yet on the same level as with framework version 8.

All the components in FW 8 have been polished during a time period of more than 3 years (Grid is probably the newest component introduced in 2/2015), most even since Vaadin 6 era. There are still plenty of bugs, but as you well said, nothing major. It is a very mature product indeed. But not very modern and I’d argue it has reached its limits.

All the components in V10+ have been rebuilt both on the client and the server side. And they are less than one year old (since inception in 10). And the framework itself has been mostly rewritten, only keeping some concepts like Binder and DataProvider as-is. And there are still a lot of bugs to be fixed, and new components introduced in 13 like NumberField and Grid Pro have just seen the light.

Since the release of Vaadin 10, we have been fixing plenty of bugs, but I admit, on general level the focus has been in introducing more features, some which have been lacking compared to version 8. This has been a balancing act, and based on your feedback it is quite easy to say that we’ve not been doing a good job at that, and have focused too much on new features instead of fixing basic level issues. Sorry for that, I feel we’ve let you down.

Currently our focus is on wrapping up some long waited new features for Vaadin 14 beta (beginning of May) and then we will shift the most of our effort into fixing issues and improving the quality. I expect that it will take more time than just the one month beta period, and we need to make sure we don’t drop the ball with the quality even after that.

Now as Juha said, we’ll analyze the issues you’ve reported, and try to see if there are bug tickets open already or try to reproduce the bugs and then open tickets. I know this doesn’t bring much solace for you now, but we’ll do our best to fix those in the upcoming months.

4

Thanks, Juha and Pekka, for the clarifications.

I share the same Sebastian concerns: we moved one small application started with Vaadin 12 back to Vaadin 8 for similar issues.

For our main applications (now Vaadin 8) I’m waiting Vaadin 14 and its planned support for portlet/portal (we are on IBM WebSphere/Portal).

I understand that, from Vaadin 15 onwards, we should expect a better focus on open bugs fixing which is critical for production level applications.

5

Hi,

I need to throw in my comments too. I do share the same concerns as Sebastian. In fact, I just started a new V13 app last weekend and spotted many of the same issues and some more. I’d claim that I would have done the same app much faster with V8 (or V7 + Viritin). Just basic business needs, nothing fancy. We still have a lot to do to stabilize and complete the feature set, so that we can deliver all the power the new platform delivers for all users. We can’t do that only as a company, but we need all the help we can get from the Vaadin community too. So please, don’t hesitate to use GitHub: throw in new issues, comment and vote existing ones and create pull requests to donate actual code.

In the meantime, we do have the good old Vaadin 8 series that we still maintain. Vaadin 10+ has already proven to work for some projects, and especially for those who have no expectations on the quality based on the previous versions. Thus we currently guide all new users towards the latest version, but Vaadin 8 is still a valid choice for many applications. I probably would have taken V8 for my recent hobby app for business critical case, but I wanted to update my view of 10+ and its latest features. I wrote about this last summer and even though the Vaadin 10+ series has progressed a lot, the article is still valid. https://vaadin.com/blog/v8-vs-v10-two-maintained-vaadin-versions-which-one-to-choose-

I disagree with Pekka that “old Vaadin” reached its limits. There is a lot of things that could be improved in V8 series, like some things that are already working better in V10+ like modern mobile optimized theme and components. We could have improved the JS and web component integration support (without GWT) there too and drop features that were not needed anymore. But sometimes it is just easier to throw away everything old, of which some is not relevant anymore or written in a “wrong way”. But in this kind of rewrites, we just have to accept that we lose a lot of wisdom along the “legacy code” and it takes time to get to the same maturity level.

Let’s do it together, make Flow a tool that makes us all proud of!

cheers,
matti

6

Hi,

Pretty much the same experience here.

I’ve been developing with Vaadin 6/7/8 for years and took the opportunity of a very small project to migrate my skills to vaadin 10, and hopefully move on from Vaadin8 (which I still like, but lack of long term support and evolution is sadly a show stopper in my field).

The experience with flow is … not what I expected.

Aside from the bugs described below - which I can understand for a fresh start - the shift in mindset is what have me on the fence at the moment. I’m not a frontend developper. HTML, CSS and javascript are tools that I don’t have the time nor the drive to learn to professional levels. Vaadin used to be my option to throw pretty good UIs in a short time without having to dive in a complete new skillset. I could easily get away with a couple of CSS lines for basic theming and voila.

Now, as soon as I need anything that is not already in the core elements framework, it feels like I have to understand several frontend specific tools (bower, javascript, webcomponents…) and some hacky/fresh ways of doing things we used to do in a much simpler way (importing html to theme stuff ??) to tackle problems that neither me nor the teams I work with really felt we had.

I know I must have misunderstood a lot of what is going on on the frontend side of flow/elements, but that’s my point: I did not had to understand, now I need to, and I don’t have time/drive/necessity for it (or at least, I wish I had not).

Really hope I can adapt and get on with vaadin flow soon, but at the moment, I’ll stay on vaadin8, keep and eye on flow and re-evaluate some time later.

7

Now, as soon as I need anything that is not already in the core elements framework, it feels like I have to understand several frontend specific tools

Just out of curiosity, how would you have dealt with the same kind of situation with Vaadin 8?

8

Leif Åstrand:

Now, as soon as I need anything that is not already in the core elements framework, it feels like I have to understand several frontend specific tools

Just out of curiosity, how would you have dealt with the same kind of situation with Vaadin 8?

Mostly be developing components in plain java, the API allowed to do quite a lot without ever having to dig in HTML/javascript besides the occasional css theming.

I get that I probably created some nasty html layouts by programmatically combining some heavy layouts, but it got the job done and the code was pretty clean and straightforward on the java side.

Whenever I try the same approach with flow, I find it very hard to get what I need; specifically, I find that creating nice layouts is challenging without getting my hands in the css.

9

Mostly be developing components in plain java, the API allowed to do quite a lot without ever having to dig in HTML/javascript besides the occasional css theming.

So you created server-side compositions out of existing layout such as VerticalLayout? Why not do it in the same way with Flow? Those same layouts are still there with some exceptions (i.e. no GridLayout).

10

Leif Åstrand:

Mostly be developing components in plain java, the API allowed to do quite a lot without ever having to dig in HTML/javascript besides the occasional css theming.

So you created server-side compositions out of existing layout such as VerticalLayout? Why not do it in the same way with Flow? Those same layouts are still there with some exceptions (i.e. no GridLayout).

Because you can’t to all the things you could do before. For example: Coloring a row in a grid depending on some value of the undrrlying bean is either not working or I am too dumb to understand how to do it.

The decision to throw away tables was idiotic. You can’t to filtering very well with grids. You can’t to sorting well without weiting loads of boiler plate code.

I did a small project starting with bakery and boy is it cumbersome. I am starting to look for something different… Also the price hike for the pro/prime account… I don’t know if all your decisions regardin flow were good…

11

Leif Åstrand:
So you created server-side compositions out of existing layout such as VerticalLayout? Why not do it in the same way with Flow? Those same layouts are still there with some exceptions (i.e. no GridLayout).

That’s my point, I tried and it was not easy.
The API was similar enough that I would try to rely on developer-muscle-memory, but different enough that it would not work as I expected.

12

I want to chime in here as I think this is a very important topic.

A little background - I started using Vaadin 8 and used it for about 6 months before switching to V10 in February 2018. At that point in time it was in Alpha/Beta an obviously there were many bugs and issues. Now we’re in April 2019 and in just a few months Flow will have 1 year anniversary since GA.

I think that Flow is awesome and a big “Thank you” to everybody at Vaadin for creating Flow. The fact that you can make any HTML element appear on the client with just a few lines of server side code is quite frankly amazing. No need to deal with REST services and no need for clunky page-based HTML apps. With flow it can be as interactive as a native client app.

Missing components is one thing. 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.

Antoine Dumeige:
Aside from the bugs described below - which I can understand for a fresh start - the shift in mindset is what have me on the fence at the moment. I’m not a frontend developper. HTML, CSS and javascript are tools that I don’t have the time nor the drive to learn to professional levels. Vaadin used to be my option to throw pretty good UIs in a short time without having to dive in a complete new skillset. I could easily get away with a couple of CSS lines for basic theming and voila.

With Flow it’s super easy to create simple responsive apps. But if you want to create something a bit above that or if you’re looking to modify your app’s components to behave slightly different or look slightly different, from the out-of-the-box flow components, it can be really challenging and frustrating.

I think it can be a huge help to the Vaadin community if you overhaul the documentation and provide more clarity and examples around themes/styling and creating or extending components that are more complex than a simple label or textfield. Consolidate information and knowledge so users don’t have to wade through countless github pages to find out how to style a select component.

It would also be a great help if the website/forum search can be updated so we can limit results to a specific version/platform. Whenever I search for anything, I usually get mostly V7 anwers which doesn’t help much when I’m using flow.

13

It would also be a great help if the website/forum search can be updated so we can limit results to a specific version/platform. Whenever I search for anything, I usually get mostly V7 anwers which doesn’t help much when I’m using flow.

I totally agree !

14

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.

15

Here are my thoughts on Vaadin Flow. I went from Vaadin 7 then migrated my project to Vaadin 8 and after waiting for a year I am in the process of migrating my project to Vaadin Flow. The following is the application that I’m migrating which the front end is written in Vaadin and the back end is EJB (all my business rules): www.toolsfs.com. I am mostly a Java developer but I do know a little of css and html. I’m not afraid of learning JavaScipt and I can follow it a bit but I’m no expert in Polymer, ShadowDOM and some of your tutorials assume that we know them well. You should provide tutorials for these or provide us recommended links to where we should go if we wish to learn these so we can become a well rounded Vaadin Flow developer.

Anyways, here’s my journey so far: I started with the administration console portion so I can get used to the Vaadin Flow framework and any lessons learned I can use them when I do the main application. One of the annoying things was that a ComboBox had the “clear” or “X” on it and there was no api call to remove it. I was able to remove it with a custom style that I found and looking at a thread(long one) there was discussion as why the component is fine instead of just providing a setting to remove it to make it work as previous versions. You want to make developers happy then if it is not that difficult then you should provide it as it was in the previous version.

I am able to use a lot of the code that I previously had and just modify it a bit which is making the migration easier. I have been mostly testing with Chrome and Firefox but the other day I opened my application in Windows Edge and it slowed down to a crawl. I am using a TreeGrid and I looked it up and see that other people are having issues with it. It would be nice if the performance with the TreeGrid component is taken care of. When I do a refreshAll I can see it flicker as the refresh is happening.

RichTextArea was free with Vaadin 8 but it is a paid product under Vaadin Flow. I don’t know the business decision for taking what a free component was and then charging for it. I have two accounts currently a non paying one and a paying one. But even then I am not interested in using a component that was free and later you are charging for it when I use it in only two screens. I don’t mind paying for them but when I’m done with the development of those screens after paying for the component then anytime I’m updating the rest of my application I have to continue paying for a license where the development has been completed just so I can deploy my application.

I am patiently waiting that the performance will catch up as this is new framework and while I had my reservations I am liking it more than Vaadin 8 as it is more modern.

Anyways, I do appreciate all the hard work that Vaadin and the Vaadin community provide us Java developers with a framework to write web applications.

16

Martin Israelsen:
With Flow it’s super easy to create simple responsive apps. But if you want to create something a bit above that or if you’re looking to modify your app’s components to behave slightly different or look slightly different, from the out-of-the-box flow components, it can be really challenging and frustrating.

Thanks for your time highlighting issues for us. I’d like to know more about your expectations on modifying the components. What kind of behavioral changes you’d expect? What capabilities are missing with the current set of configuration capabilities within Lumo? We’d love to make our components more configurable but honestly we lack a bit guidance on where to focus with that effort. Meanwhile, please check out Lumo theme editor at https://demo.vaadin.com/lumo-editor/

17

Juha Seppänen:

Thanks for your time highlighting issues for us. I’d like to know more about your expectations on modifying the components. What kind of behavioral changes you’d expect? What capabilities are missing with the current set of configuration capabilities within Lumo? We’d love to make our components more configurable but honestly we lack a bit guidance on where to focus with that effort. Meanwhile, please check out Lumo theme editor at https://demo.vaadin.com/lumo-editor/

Hi Juha,

The majority of the components are really great!!

I think a big part of the challenge is the documentation. It is scattered in many places which makes it hard to find what you need.

Say for example that you have a combobox in the menubar and you want to style the background color, label/icon/text color and overlay to blend with the menu bar. In the regular HTML/CSS world, this would be super easy with a few lines of CSS, but this is very complex in Flow.

Starting from scratch, you look at https://cdn.vaadin.com/vaadin-lumo-styles/1.4.1/demo/customization.html, which directs to https://github.com/vaadin/vaadin-themable-mixin/wiki which then states that not all parts can be styled and eventually you end up having to look at the web component (e.g. https://cdn.vaadin.com/vaadin-combo-box/5.0.0/#/elements/vaadin-combo-box) and if that doesn’t give you all the answers you then have to dig into github. Not only for the combobox itself (https://github.com/vaadin/vaadin-combo-box), but also for components that the combobox is using (textfield and overlay etc).

That’s a lot to go through to find out how to style a component.

Also, the documentation tends to leave out things that can’t be done, even if you naturally would expect the functionality to be there.

An example is the NumberField which is one of the components Sebastian mentioned in the first post in this thread. Most business apps that deal with numbers in fields will a) require a formatting pattern such as 1,234.56 or 1.234,56 as well as right justification. Ideally it should also support localization. The examples (https://vaadin.com/components/vaadin-number-field/java-examples) do not show any of these.

So you look at the Java API and you’ll notice that there is a setPattern method. However, setPattern does not affect how values are displayed, but you wouldn’t know this without looking at the actual source code.

In all, it seems that if you need formatting and/or localization, you’d be better off with a TextField and a converter. Mentioning this in the examples and possibly also the JavaDoc would save time for developers trying to get the NumberField to work.

While I’m on it, here are a few other items/ideas that might be worthwhile to consider and I think might be helpful for other people in this group.

Documentation (https://vaadin.com/docs/v13/flow/Overview.html)

  • Views/components can be created using plain Java or as Polymer templates. The documentation does include information on how to create each type, but there is little guidance on why one should pick one over the other. It would be tremendously helpful with a clear comparison between the two. For example:
  • Benefits and drawbacks of creating views/components in plain Java vs. Polymer
  • Quantify server, memory and network overhead of using plain Java views/components over polymer templates. If I have a form with, say, 20 text fields and 5 comboboxes, what is the overhead of doing this in plain Java vs. a Polymer template?
  • The examples in the polymer documentation mostly deals with fairly simple subjects such as getting or setting string values. It would be helpful with an example that illustrates how to use a collection of items. A good example may be a polymer component that has a collection of checkboxes that also can be bound using the data binder.
  • Include an example of a Java component that uses an overlay to show additional selections. Example: a component that has a button and when button is clicked, an overlay opens revealing additional information that can be modified (I’m aware that this can be done using a dialog, but afaik there is no option to position the dialog where the component is).

Layout best practices.

  • List best practices for doing an app layout with header, footer and content.
  • Elaborate on flex box.
  • Include do’s and don’ts. (Like setting width or height to 100% seems to break flex box and scrollability on iOS)

Theming and styling.

  • Include more comprehensive examples, how to style background color, text color or label color for a Vaadin component

Component Documentation (https://vaadin.com/components)

  • Monitor forum and gitter for questions that show up repeatedly, it’s a good sign that the documentation for the component needs to be updated.
  • Consider adding a “Common Questions” section to the components - perhaps even with the ability for the community to add stuff. Some of the questions that have shown up multiple times include: How to remove the clear (X) on ComboBox or how to empty/remove the list of uploaded files in the upload component.
  • Consider “Known limitations” for stuff that is broken. For example, you can’t use @Id for tabs defined in polymer template, but the documentation makes no comment about that.

Bug Fixes

  • What is the priorities for fixing bugs? Bug fix priorities seems to be a black box. The 1.0 milestone which was created last summer doesn’t seem to have much traction (https://github.com/vaadin/flow/milestone/82). I’ve logged multiple bugs related to FormLayout, one of them going back to August of 2018. Without knowing whether the bugs will be fixed or not, I have no idea if I need to abandon FormLayout completely and roll my own. If we have more clarity on bug priorities, we can better determine how to work around.

Vaadin Forum

  • Make it possible to narrow search results by platform so we don’t get V7 responses when we’re looking for V10
  • Include more results in the search result. Seems to limited to 10 entries or so.
  • Consider adding component tags to the forum thread, so you easily can find all threads for “NumberField”. This will also help find topics between this Forum and the Component forum.
  • On “My Page” make it possible to see all threads that you have started as well as all thread that you have replied to.

Ok long list, but I hope at least some of the ideas will help.

Thanks for the link to the Lumo editor. I did see that a few weeks ago. Very nice tool. There is also https://labs.vaadin.com/project-wizard which seems very interesting.

18

Wow. I feel that thank you is not enough (virtually bowing on my knees) for your reply. But really big thanks Martin!

I’ve added these to the internal discussion thread that was already composing a list of improvements and fixes for Lumo separately but this naturally deals with Java framework side as well.

Thank you again,

Juha

19

\u0000Just adding my 2c as well, to indicate that we are at least listening to the feedback. Excellent feedback from Martin \uD83D\uDC4D

20

Juha and Jouni, you are welcome - and thanks for listening :slight_smile: