Important Notice - Forums is archived
To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
vaadin performance auditing
Hi,
1) How does the vaadin team ensure that performance does not degrade from release to release, and how do you set your benchmark for what a base performance should be for something like a new widget?
2) What is everyone's take on the theoretical slow down one should experience using vaadin since everything is done on the server side vs doing the same thing on the client side? For example server side validation of a text field would definitely be slower than client side validation, due to the round trips.
Thanks!
Doug Doug: 1) How does the vaadin team ensure that performance does not degrade from release to release, and how do you set your benchmark for what a base performance should be for something like a new widget?
Our build / continuous integration system (TeamCity) makes builds every night (and on demand) and runs some 500+ regression tests. The tests are timed, so we get execution time for each test in milliseconds. TeamCity offers some nice statistics and execution time graphs about the tests. In addition, we follow the Jar size, DefaultWidgetSet size, and theme size.
This does not, by itself, ensure that performance never degrades, but at least we're more aware of any unexpected jumps. Some jumps are expected; for example, the Drag&Drop functionality caused some 20% jump in the size of DefaultWidgetset. It's unfortunate, but what can you do?
There's no particular benchmark for the performance of new widgets.
2) What is everyone's take on the theoretical slow down one should experience using vaadin since everything is done on the server side vs doing the same thing on the client side? For example server side validation of a text field would definitely be slower than client side validation, due to the round trips.
The answer depends mostly on network latency. On a fast network, a 10x jump from some 5 ms to 50 ms would not be noticeable. The problem is, of course, the slow networks, where the slowdown is significant. For example, a typical round-trip time in GPRS or EDGE is around 600 ms, so you'd get a 100x slowdown.
If server-side validation is an issue, you can use, for example, the CS Validation library, which offers a client-side validated TextField.
The slowdown also depends on programming practices. If you're worried about latency, avoid active validation with the immediate mode; only validate on commit clicks, etc.
As you pointed out server-side validation is one of the most common cases where server-side ria is more "chatty" than client-side ria. That said - one must also note that communication is asynchronous and server-side validation request doesn't block user for continue filling the next field even in the case of really slow networks. Thus real-world use-cases where there is a real difference in the responsiveness of client- and server-side ria are quite few. If one bumps into those use-cases, it is always possible to resolve them by moving those specific cases to client-side.
great thank you all for the input. this is what i was looking for.