Hi,
I notice that there is no mention of “mobile” in the New Version 8.0 roadmap.
Simplified data binding for Forms, Fields and lazy loading
Compatibility updated Browser support (IE11+, Edge, Firefox, Chrome, Safari 9+, iOS9, Chrome for Android)
Java 8 (GWT 2.8)
Enhancements and bugfixes
Is this a change in stragegy.
Yes. Want to be able to release 8.0 asap and thus had to postpone mobile enhacements to 8.1 that hopefully would follow soon after 8.0. Other alternative would have been to wait for getting everything done and only then releasing 8.0.
With the introduction of GWT 2.8, leaving aside the faster compilation of the widgetset, should we expect a perceivable improvement in its actual performance in the browser because of faster computations in complex layouts and such?
The focus of GWT 2.8 has been more on developer productivity and not so much on runtime performance, so I wouldn’t anticipate any general improvements on that account.
I’m seeing a noticeable improvement in some layouting benchmarks when comparing 7.7.0 to the current 8.0 development branch, but I cannot attribute that improvement to GWT 2.8 since Framework 7.7 has the same performance regardless of which GWT version is used.
The perforance improvement I’m seeing with 8.0 is something of a mystery right now since I’m not aware of us doing any other changes that might affect layouting performance. It might just as well be some effect of the way I’m measuring things…
Hello all,
Does it make sene to develop already with the 8.0 Beta version or stay on 7.x? How stable is the version?
Is it hard to upgrade to Vaadin 8?
Best Regards,
Thomas
Hi,
We currently have released alpha1 and alpha2 of Vaadin Framework 8.0. They are still named “alpha” to indicate that the API will change based on feedback and because they are not feature complete. The versions work (all tests pass) but e.g. the new versions of many select components are still missing. Some features are also missing, mainly in Grid and the new data source implementation.
I would not start any real project with an
alpha
version unless you are ok with waiting for remaining components to be implemented, you are ok with fixing and tweaking your code when new alpha versions are released and API changes, and you are ok with some things breaking in some release.
You can see what we are actively working on at
https://waffle.io/vaadin/framework8-issues
–
Regarding upgrading, the initial step should be very easy: All Vaadin 7 components are included in the Vaadin 8 packages (see e.g.
https://github.com/vaadin/vaadin/releases/tag/8.0.0.alpha1
) so you more or less change dependencies and imports and it works.
For the real migration you would want to
Form migration should be straight forward as the same concepts exist but much has been moved from component implementations (AbstractField) in Vaadin Framework 7 to Binder in Vaadin Framework 8.
Data source migration depends on what kind of data source you are using.
For in memory data, you have a BeanItemContainer in Vaadin 7 which you replace with a ListDataSource in Vaadin 8, or just use e.g.
ComboBox.setItems(List<MyBeans> items)
IndexedContainer can be replaced by e.g. ListDataSource<String>, ListDataSource or similar.
If you are using something like LazyQueryContainer and a separate service layer, migration should be straight forward by implementing the only needed “getItems” and “count” methods in a new DataSource.
If you are using SQLContainer or JPAContainer, there is currently no direct replacement. It should be simple though to do JPA or JDBC or JOOQ or any other type of queries in a custom DataSource implementation.
If you try out an alpha version, we are more than happy to hear about your experience and receive any feedback you might have!
Hello! Thanks for the fast reply! I will try the next weeks Vaadin 8 and let you know 
I’m using the React javascript library to make JS components which we use in our Vaadin application (using AbstractJavaScriptComponent). Does Vaadin 8 have any improvements for me in that regard?
Hi Herman,
nothing major is expected in that part. We are focusing on the new data binding in 8.0. Is there anything particular that you would be hoping for?
Well, I’d like to at least see some issues fixed in Vaadin 8:
whenever you call a JS function from java (not modifying any shared state), the component’s full shared state is transferred and onStateChange is triggered in the JS connector. The open ticket for this is #19837.
even when actually changing the shared state, one would not expect to see the full shared state transferred, but only the diff, as is done for regular non-JS components. In my case the shared state is sometimes quite big, so sending it on each event that is handled in the server and modifies the state is very inefficient. I don’t think there is a ticket in the tracker but there is a stackoverflow question & answer where it is mentioned where in the code the diffing mechanism is disabled for JS components:
http://stackoverflow.com/questions/36253541/partial-state-changes-for-vaadins-abstractjavascriptcomponent
The combination of the two issues above leads me to conclude that at this moment (pre-Vaadin 8) the statement about JS being a “first class” extension language for Vaadin is not entirely true yet.
Thank you for directing our attention towards those issues. It seems like both the problems are caused by being overly optimistic with keeping the JS support “simple”, which unfortunately causes problems in more complex cases. I’ve created
https://dev.vaadin.com/ticket/20335
about the root cause of the problems you describe.
I’m the main champion of the JS support that was intorduced in Framework 7 and I’d like to ensure it’s actualy useful. It seems like it wouldn’t be too tricky to fix that issue, so I’ll try to get it in as a minor enhancement for Framework 8.
That would be great!
Concerning the regular diffstate tracking mechanism, I’m actually not very familiar with it: does it work only on a field-by-field basis or does it do diffs of collections as well? For example if a field holds a List of objects, and an element is added to the List, would only the added element get sent? Same question for a Map where a new key/value pair was added or an existing key got a new value.
Thanks again for the quick response and creating that ticket!
The diffstate tracking always resends the entire field if anything in it has changed. Updating one item in a List or Map causes all contents of the list or map to be sent again.
#12983
is the enhancement request for improving on this, but it has so far not been a high enough priority to actually get implemented.
The data binding features that we’re working on for Framework 8 will provide a unified way of synchronizing “container” data to the client. This won’t be in the form of a List field in the shared state, but it might still help achieve the same results in many cases.
Hi,
since our new application is mostly about showing data in tables and forms we are looking forward to your improvements in Vaadin 8. Is there already a timeline regarding the release of version 8? I have seen that there is already a alpha-7 version and an due date for the Vaadin 8 book for 31.12.16. So I am wondering if you have already more details about the new version.
As with any software development project, there’s of always a risk of discovering something that causes unforeseen delays. With that said, we are currently aiming for a beta release around the end of this year.
We consider the form binding part feature complete as of 8.0.0.alpha6 that was released around two weeks ago. We are especially eager to hear any feedback from your about that part of the new functionality. There are still some pending changes to the other part of the feature set, i.e. how items are fetched from a backend and shown in e.g. Grid or ComboBox.
New binder framework in Vaadin 8, will it be easier to implement the Field interface, for example with a custom Javascript component? That would be awesome. I haven’t looked at the new API yet but I guess some AbstractField methods could be implemented as default methods on Field so they can be reused without extending AbstractField.
You are right in your assumption. Much complexity and state tracking is now handled by Binder instead of in individual field instances. This means that the number of methods and concepts to implement in a completely custom field implementation is significantly reduced compared to the situation in previous versions.