Thanks for another great video, Dan! Pro tip for creating the service at 11:44 - if you have the contents of a Java class in your clipboard, you can paste it onto the package in the IntelliJ sidebar and it'll create an appropriately named Java file with that content 🤯
@@joonaslehtinen5175 There is absolutely no misunderstanding. We were told multiple times (in emails and video conferencing) from our rep that it's $93K for 2024 if we stick with Vaadin 8. So we had to upgrade our apps to Vaadin 14 (which is EOL in 2025). I even told them multiple times that we do not even need support. We've never, not one time, ever asked Vaadin for any support. But we were told that the $93K does not even include support! We were told it's the "Extended Maintenance Plan" that only includes security updates, etc. I have all of the email chains going back 6-7 years. I'm telling you, that's what they told me on multiple occasions.
The programming model is pretty similar and will definitely feel familiar if you're coming from Swing. But the architecture is completely different with Vaadin Flow creating single-page apps running in a browser.
Vaadin has evolved quite a bit in those 10 years. Back then, it used GWT for widgets, now standard HTML web components. It's also more extensible if you want to create or use 3rd party components.
Some components like the DatePicker and ComboBox adapt to smaller viewports on mobile devices for improved UX. The layouts are CSS flexbox-based and you can define wrapping for responsiveness. Vaadin has great Spring Security support, check out the Vaadin docs for an example on how to set it up.
Thanks for the video! Can you do the same for a full stack application with front end being angular or react and backend with spring boot with authentication
I have done some videos on full stack Spring Boot with Vue in the past. I don't do a lot of Angular or React but I will add it to my list. Thanks for the suggestion.
Have you ever tried spring serving a vue 3 app, calling the vue components directly from the controller without using the vue router? I built it with Inertia integration and Vite and its quite interesting. Btw, thanks for the videos. Helped me a lot.
Thanks for interesting material. The framework seems promissing (in comparison to JSF it offers pure usage of Java for UI, however I wonder if dynamicity and AJAX on the pages could be achieved on UI). If it could support Java 8, I think, many projects could adopt it
So for example I have the list of blog posts... I could have easily had a button on the page that triggered the action to load those posts. I think we need as a community to move away from Java 8 and I'm happy Vaadin and Spring have a baseline of 17.
@@DanVega what about situation when it is needed to dynamically reload the grid when you added the post or imagine that you did the action on the other page that affects posts? For example you made posts using some kind of API (Facebook, Twitter, whatever else) or, for example, this page with List Grid of posts must be dynamic and listen for external changes (the posts, for example, might be added though web service call, might arrive from a message queue, ESBs, whatever else). Can Vaadin fulfill such requirements?
Concerning Java 17 ... For new projects (especially dev ones) it is simple to migrate to Java 17. But for existing enterprise projects, that might have years or tens of years of maintenance it is always a complicated decision to move Java 17 and usually comes with many issues and workarounds
@@Vityoube there are bunch of listeners - so you can add logic to update UI (e.g. grid data on some events). Regarding update from another page not sure - there is routing concept in Vaadin. But guess you can implement subscription on backend and trigger update on UI (if it's current route). If I understood question correctly.
@@Vityoube - yes, you can do all of that with Vaadin. Most of those can be handled by adding appropriate event listeners and updating components based on that. If you want the UI to automatically update based on data from an external system through a message queue or similar, you can enable a 2-way websocket connection with a @Push annotation (check docs), that allows you to push UI updates to the browser any time.
No. Instead of having many different themes out of the box, we instead have a customizable theme that you can configure with variables to match your needs.
As a server-driven framework, it will use a bit more server resources than a fully stateless framework. The main thing to keep in mind is not to save references to any large data sets in your components. In Dan's example, he used `grid.setItems(List)` to set the data. That's great for small data sets like this. But if you had hundreds of thousands of rows of data, you want to avoid loading them all into server memory at once. By changing the call to use `grid.setItems(query -> {})` you can page the data from your database and never keep more than about 10-20 rows of data in memory at once. I have a colleague who's running a popular public-facing energy price tracking site in Finland that's built with Vaadin Flow. It's very data-heavy with charts and price info. It has nearly 100k monthly visitors, often 3k+ concurrent users. It's running without a problem on a $10/month server.
This seems like such a poorly designed way to enable server-side to control the frontend rendering. It feels like we're pretending to write Java when we really are actually writing HTML divs and tables. I can't see the advantage of writing all these Vaadin-specific function calls which still requires us to know how it will translate to HTML instead of just letting us write HTML directly.
Vaadin Flow's Java API is on a higher level of abstraction than HTML. It's not the way to go if you need full control over the DOM. But if you are ok working on a higher level of abstraction, using components instead of elements, you'll be able to build UIs faster.
Thanks for another great video, Dan!
Pro tip for creating the service at 11:44 - if you have the contents of a Java class in your clipboard, you can paste it onto the package in the IntelliJ sidebar and it'll create an appropriately named Java file with that content 🤯
Never used it. Now my college projects will be vaadined. Thank you for this video.
Glad I could help introduce you to this amazing project!
I use Vaadin almost 6 years, its pity everybody use js frameworks and Vaadin only 1 percentage of devs, best framweork for me plus Hilla
I have a couple of years of experience with wicket 4, vaadin reminds me of it a lot.
Mi too big hommie
Used vaadin since version 6, lately not that much. Special indeed!
@@joonaslehtinen5175 There is absolutely no misunderstanding. We were told multiple times (in emails and video conferencing) from our rep that it's $93K for 2024 if we stick with Vaadin 8. So we had to upgrade our apps to Vaadin 14 (which is EOL in 2025). I even told them multiple times that we do not even need support. We've never, not one time, ever asked Vaadin for any support. But we were told that the $93K does not even include support! We were told it's the "Extended Maintenance Plan" that only includes security updates, etc. I have all of the email chains going back 6-7 years. I'm telling you, that's what they told me on multiple occasions.
Great video, many thanks, I didn't know there is an instrument that allows BE devs to be a little bit more independent of FE
It reminded me when I used to program in Swing
The programming model is pretty similar and will definitely feel familiar if you're coming from Swing. But the architecture is completely different with Vaadin Flow creating single-page apps running in a browser.
I tried Vaadin before it was introduced as a spring starter and it was frustrating. Great to know it can work seamlessly with spring now!
But it's been centuries, many years, since Spring has been integrated into Vaadin 😂
Been using it for years, love it!
What a wonderful tutorial, thank you infinitely ☺️
Thank you for this video. I did not know about Vaadin.
Vaadin is great, they also have another framework called Hilla you should checkout!
@@DanVega Sure. Vaadin is like Java Swing
Working with vaadin from 7 years :) So you can do miracles with it, for one specific reason, it`s stores the states on the server
Super fain Dane!
multumesc! Esti un adevarat prof!:)
de ce ai scris romaneste este roman?
dada
vaadin is (for better or worse) a declaration of war against rest paradigms in web apps
Wow, Is Vaadin still alive? It was rather nich 10 years ago, I thought its gone like jsf
Vaadin has evolved quite a bit in those 10 years. Back then, it used GWT for widgets, now standard HTML web components. It's also more extensible if you want to create or use 3rd party components.
That was my first thought too! Not sure if I should see what ever happened to moo tools.
Great job Very interesting. Can you tell me please what is the advantages and disadvantages compared to GWT toolkit
I would say the rich component library. I haven't used GWT in a long time, is that still be developed and maintained?
and now a java champion
Very interesting video, I learned interesting technology, thank you.❤
Glad you enjoyed it. Let me know if you have any questions about Vaadin
Thanks Dan. Great video. I would love to know if those UI Components are responsive. Also, how does Vaadin work with Spring Security.
Some components like the DatePicker and ComboBox adapt to smaller viewports on mobile devices for improved UX. The layouts are CSS flexbox-based and you can define wrapping for responsiveness. Vaadin has great Spring Security support, check out the Vaadin docs for an example on how to set it up.
Thanks....I will check it out.@@marcushellberg13
Thanks for the video! Can you do the same for a full stack application with front end being angular or react and backend with spring boot with authentication
I have done some videos on full stack Spring Boot with Vue in the past. I don't do a lot of Angular or React but I will add it to my list. Thanks for the suggestion.
Have you ever tried spring serving a vue 3 app, calling the vue components directly from the controller without using the vue router? I built it with Inertia integration and Vite and its quite interesting. Btw, thanks for the videos. Helped me a lot.
Thanks for interesting material. The framework seems promissing (in comparison to JSF it offers pure usage of Java for UI, however I wonder if dynamicity and AJAX on the pages could be achieved on UI). If it could support Java 8, I think, many projects could adopt it
So for example I have the list of blog posts... I could have easily had a button on the page that triggered the action to load those posts. I think we need as a community to move away from Java 8 and I'm happy Vaadin and Spring have a baseline of 17.
@@DanVega what about situation when it is needed to dynamically reload the grid when you added the post or imagine that you did the action on the other page that affects posts? For example you made posts using some kind of API (Facebook, Twitter, whatever else) or, for example, this page with List Grid of posts must be dynamic and listen for external changes (the posts, for example, might be added though web service call, might arrive from a message queue, ESBs, whatever else). Can Vaadin fulfill such requirements?
Concerning Java 17 ... For new projects (especially dev ones) it is simple to migrate to Java 17. But for existing enterprise projects, that might have years or tens of years of maintenance it is always a complicated decision to move Java 17 and usually comes with many issues and workarounds
@@Vityoube there are bunch of listeners - so you can add logic to update UI (e.g. grid data on some events). Regarding update from another page not sure - there is routing concept in Vaadin. But guess you can implement subscription on backend and trigger update on UI (if it's current route). If I understood question correctly.
@@Vityoube - yes, you can do all of that with Vaadin. Most of those can be handled by adding appropriate event listeners and updating components based on that. If you want the UI to automatically update based on data from an external system through a message queue or similar, you can enable a 2-way websocket connection with a @Push annotation (check docs), that allows you to push UI updates to the browser any time.
Great video, I prefer apache wicket.
What do you like about Wiket?
@@DanVega It's more familiar to me than Vaadin, just that.
It looks a little bit the same like GWT and GXT/ext-gwt (now Sencha) for me - have done this before....
Is there a old-style extjs theme available for Vaadin?
No. Instead of having many different themes out of the box, we instead have a customizable theme that you can configure with variables to match your needs.
I used old version of Vaadin a few years back, its quick to develop, but getting slow when the user base increased..
I would give it another look 🤩
As a server-driven framework, it will use a bit more server resources than a fully stateless framework. The main thing to keep in mind is not to save references to any large data sets in your components.
In Dan's example, he used `grid.setItems(List)` to set the data. That's great for small data sets like this. But if you had hundreds of thousands of rows of data, you want to avoid loading them all into server memory at once. By changing the call to use `grid.setItems(query -> {})` you can page the data from your database and never keep more than about 10-20 rows of data in memory at once.
I have a colleague who's running a popular public-facing energy price tracking site in Finland that's built with Vaadin Flow. It's very data-heavy with charts and price info. It has nearly 100k monthly visitors, often 3k+ concurrent users. It's running without a problem on a $10/month server.
This seems like such a poorly designed way to enable server-side to control the frontend rendering. It feels like we're pretending to write Java when we really are actually writing HTML divs and tables. I can't see the advantage of writing all these Vaadin-specific function calls which still requires us to know how it will translate to HTML instead of just letting us write HTML directly.
Vaadin Flow's Java API is on a higher level of abstraction than HTML. It's not the way to go if you need full control over the DOM. But if you are ok working on a higher level of abstraction, using components instead of elements, you'll be able to build UIs faster.