This post is my personal reflection on eight years of building and refining Vaadin components across major versions, and the lessons learned along the way.
The journey behind major versions from 10 to 25
Working on building a Java framework is quite an interesting challenge… And even more so if you are a frontend engineer who joined Vaadin without any prior Java knowledge, which was exactly the case for me. While my vision of events may differ from that of my colleagues, overall it’s been a great experience so far, and I’ve been part of the Vaadin development team for 8 years. So I’d like to use this blog post as an opportunity to share some of my personal memories.
Today, you will have a chance to take a sneak peek at certain important processes that were ongoing behind the scenes over the past few years, while we were working on developing new Vaadin major versions. I’ll start with Vaadin 10 released in 2018, and then explore the journey from there onwards - through Vaadin 14 and Vaadin 22, and up until Vaadin 25 coming by the end of this year. Each of these versions has its highlights that deserve to be mentioned.
Vaadin 10: driving innovation
When I joined the company back in late 2017, there were many things going on. Vaadin 7 had been mature for years and actively used by many companies, with its successor Vaadin 8 increasingly gaining traction. However, most of the Engineering team at the time was busy with development of the next Vaadin version - the one aiming to bring stability for years to come. And I felt really proud (and responsible) for being able to contribute to Vaadin’s transition to Web Components.
What we did well: regardless of the tight schedule and a certain pressure of expectations, the Vaadin Elements team (and the whole Engineering team) managed to deliver a stable Vaadin 10 release based on the set of high quality web components, despite some challenges related to polyfilled browsers (IE11, legacy Edge) and older iOS versions (Safari 9). My colleagues worked hard to improve the performance of Grid, ComboBox, DatePicker and other components.
We also paid a lot of attention to user experience and developer experience (something that I especially appreciate about working at Vaadin after almost 8 years). For me it wasn’t easy, but still pleasant and sometimes even funny, to participate in UX and DX test sessions with my colleagues from other teams and departments at Vaadin. That was only a few months after I moved to Finland (without a prior experience of working in an English speaking company).
What we learned: choosing a front-end stack to build upon has to be considered very carefully. Vaadin 10 relied heavily on the Polymer library and its JS tooling. While it was a decent choice for a set of web components (and still works great in Vaadin 24), some aspects weren’t suitable for long term stability: especially, sophisticated frontend building tools needed to support the HTML imports proposal, one that never gained cross-browser support.
After receiving user feedback, we realized that we also went a bit too far with shifting focus from writing UI in pure Java (the core foundational part of Vaadin vision) towards HTML and Polymer templates. While quite a few users appreciated the productivity of building views using Vaadin Designer, there was still a certain pushback in the community. Finally, Vaadin 10 still had room for improvement despite years of development, and we knew that next time we'd do better.
What we improved: code ownership over the set of Vaadin components. When I joined, the Vaadin Elements team was working purely on the web components part, while the Flow team developed both the framework and Java counterparts for most of our components. Also, Pro components were maintained by a separate team. This changed over the next year, and since then a single team has maintained all our web components and their Flow counterparts.
Personal highlights: investigating a Chrome issue caused by the Grid component - specifically, many levels of superclasses it used internally. The resulting “prototype chain” (the way classes are implemented in JS) caused Chrome to crash. The Google Chrome team fixed it quickly, while mentioning that the <vaadin-grid> custom element was “the most popular custom element out there, excluding elements vended by our team”. Quite a recognition!
Vaadin 14: reaching maturity
While Vaadin 10 was a very important milestone for us, it was just the beginning of the road ahead. During the next year, we worked on building a new Vaadin version that would really reach maturity. Our main focus was on polishing and stability, adding new components and improving productivity for Java developers. And the results followed: even in 2025 - 6 years after the Vaadin 14 release - there are many enterprise-grade apps using it in production.
What we did well: in Vaadin 14, we delivered many new web components - in fact, quite a few of them landed in previous intermediate major releases: Vaadin 12 and Vaadin 13. On top of that, we added the Material theme as an alternative to Lumo, as there had been some demand for it back in the day. Most importantly, we managed to organize our internal workflow and tooling to deliver them through npm in addition to Bower and provided Polymer 3 support.
What we learned: one thing that became clear during Vaadin 14 beta is that certain ambitious projects can only be completed thanks to coordinated effort. In particular, adding npm support in Flow required our most talented colleagues to join forces, who had to deal with Node.js, npm, webpack and other JS tooling. We also realized that in the long run, gradually adding new value is a must, and since then we have added many new features to Vaadin 14 minor versions.
What we improved: starting from Vaadin 14, all of our Flow components have been placed in the multi-module monorepository. Individual repositories have been migrated there while preserving Git history. The new repository was originally introduced in more recent Vaadin versions, but then backported to 14.x branches. This change resulted in such a productivity boost for us that for Vaadin 20, we moved all our web components to their own monorepository as well.
Personal highlights: working in close collaboration with the Polymer team while implementing Polymer 3 support in Vaadin web components. Our team was among the early adopters of the polymer-modulizer conversion tool and provided important feedback, including a few PRs to the polymer tools repository. Despite some challenges, we completed the project successfully, and Vaadin deserved a special mention at Google I/O 2018 talk by the Polymer core team.
Vaadin 22: going accessible
While Vaadin 14 was already future-proof thanks to using Web Components standards, namely custom elements and shadow DOM, it had certain caveats related to the accessibility. This topic started to become important over the years and was mentioned many times, both in our internal discussions and with customers. So in 2021, we invested significant effort into making sure that Vaadin web components met the accessibility requirements, such as WCAG criteria.
What we did well: during early 2021, we prototyped a new DOM structure for many of the Vaadin web components. Our main focus at the time was getting the basics right, so we started with such components as Button, Checkbox, TextField and all field components. One notable component that had some tricky parts was ComboBox. We had some long conversations and got some valuable feedback from customers as we proceeded with the implementation.
What we learned: while working on this project, we realized how important it is to preserve the existing codebase as much as possible, especially if the project is ambitious and takes months to implement. Due to some internal changes and factoring out shared JS logic to be reused by all field web components, parts of the Git diff were lost. We also renamed our npm packages along the way - which ultimately helped us keep things simpler, but there was some friction, too.
What we improved: in Vaadin 22, there were quite a lot of breaking changes related to the underlying web components implementation. However, we managed to keep the Flow API mostly the same to provide a better developer experience for Java users. This is one of our core principles that we aim to follow in recent major versions of Vaadin. Also, nowadays we maintain cleaner lists of expected breaking changes and make them publicly available on GitHub.
Personal highlights: very warm feedback regarding our accessibility improvements shared by one of our customers already during the alpha stage. We are always eager to get any kind of feedback - this is what really motivates us and helps us improve. But it’s especially important when shared early enough, as sometimes we do need to make further adjustments and certain behavior-altering changes. That’s exactly why we ship alpha and beta versions, after all!
Vaadin 25: back to simplicity
As I’m writing this post, Vaadin 25 is still in the beta stage. However, at this point I can already share some lessons from developing it. It’s especially important because in terms of changes to our components set, this is going to be the most significant milestone since Vaadin 10. But after all these years, we stick to one of our core principles: fighting for simplicity. The upcoming major release will bring quite a few improvements, including an easier way to handle application styling.
What we did well: this time, we planned the most significant internal changes well in advance. As an example of such changes that some of our users expected for years, in Vaadin 25 we finally migrated all of our web components to Lit and removed Polymer dependency. We also improved all of our overlays to use native browser Popover API instead of the “teleportation” mechanism, which helps to simplify certain things in terms of styling and accessibility.
What we learned: long-lasting projects that affect multiple areas of the codebase require a very careful approach. While developing new base styles for Vaadin web components, we realized how seemingly trivial things such as maintaining up-to-date Git branches, proper testing, file names, and folder structuring can either help us move faster or turn into challenges, depending on the situation. We also learned how important it is to address all unknowns in advance.
What we improved: while working on Vaadin 25, we carefully assessed the potential impact of certain breaking changes (e.g. moving Lumo from JS files to CSS). And already at this stage, we started to address the beta feedback from our colleagues and customers. In particular, we invested some time into upgrading certain Vaadin add-ons to the new version. This helped us a lot in identifying changes that needed better documentation and to improve our upgrading guide.
Personal highlights: actually, I’m expecting more of them to come as Vaadin 25 reaches the stable release! However, speaking about our team’s achievements, I’d really like to emphasize the importance of switching all web components to use Lit. This concluded a years-long internal refactoring project that only became possible thanks to a joint team effort. With a solid foundation for years to come, we can now focus on adding new features and improving stability.
Final words
I hope this blog post sheds some light on the amount of work we put in making sure that every new Vaadin major version gets better - especially in terms of the high-quality components that are essential for enterprise applications. As you can hopefully see, all these challenges and internal changes we went through eventually helped us ensure that our constantly growing codebase remains a decent piece of software - something that I’m personally proud of.
So if you haven’t had a chance to give Vaadin 25 a try yet, please go ahead and let us know how it works for you! As this is probably our biggest major release since Vaadin 10 in terms of components, we are eager to hear your feedback, and we will focus on addressing it during the upcoming months. Please reach out to us at the Forum or create issues to let us know about any comments - and help us make the upcoming Vaadin 25 release even better!