Last Thursday, together with Leif Åstrand from our product management, we held a webinar about our roadmap. The idea for the webinar was sparked by the changes we recently did for how we work in our R&D teams. Work is now split into 6-week projects, which are chosen relatively close to the beginning of the projects. We no longer have our plans drawn on a Gantt chart for the next year or so, but for sure we also have long-term plans. Now we just need to start communicating them more than before.
Missed the webinar? No worries! Access the live recording with the link below.
As roadmap questions are traditionally so interesting for the community, I wrote this recap of the content we discussed in the webinar – and tried to clarify some points.
Focus is on the pure Java experience
We started by discussing the essence of Vaadin and how that has been changing. In Vaadin 10 and Vaadin 14, a lot of R&D focus was on template usage and in mixing Java with modern front-end technologies: first Polymer, then Lit and TS. While these technologies helped us to rebuild our component set with the latest tooling and provided flexibility for some power users, we saw some architectural problems when the UI code was being split on both server and the client. And a lot of people had chosen Vaadin because of the promise that you only need to work with Java. Even though the pure Java approach was never going away, there were concerns within our core community about our direction. Now it should be very clear: our main focus is to continuously improve the best pure-Java experience to build web apps.
For developers who want to express their UI in HTML and execute their UI logic in the browser, we now recommend Hilla, which is the culmination of our template-based experiments. We won’t be dropping the current Lit template support in Vaadin Flow in the foreseeable future, but don’t expect us to invest a lot in that area. And to be clear: Hilla is not replacing Vaadin Flow, and our Lit-based framework was not split out to Hilla to die. They are different approaches to building web apps, with different strengths and weaknesses, and they both deserve their own brand. They share the same components and, like pretty much all frameworks, they can in some cases be used together to supplement each other.
Minors can be more significant than majors
We recently simplified our release model. Instead of pushing out a major every three months, we are now making new major releases only if there are actual breaking changes that really force you to make some changes in your application. This means that most of the interesting new features will be coming out in minors, which we plan to push out four times a year. Also brand-new features, whose API may still be in flux or that can still contain severe bugs, or that could even cause your LCD display to melt. These “beta” quality features will be behind a “feature flag”, so that you know for sure that you are using an experimental part of the platform.
The release model change means that major releases can actually become less significant than minors, containing removals of deprecated APIs and major dependency updates. For example, the Vaadin 24 release is currently expected to contain almost no new functional changes, but to be centered around dependency updates to Servlet 5 and Spring Boot 3. In your actual Vaadin UI code, almost nothing changes and there might be no new cool UI features you can deliver for your end users.
For those afraid of increasing maintenance costs – don’t be. Vaadin 23 will be maintained for years, and the architecture of Vaadin in general will protect you well from the rapid changes in both the Java ecosystem and web apps.
Recently finished or coming out soon
Our short-term goals and ongoing work can be followed pretty well from our public roadmap board. Notable things that we have recently finished or which are coming out soonish:
- New release model with new features in minors and disruptive changes in majors
- Using feature flags for testing new features in stable versions
- Fusion extracted into a separate framework and renamed to “Hilla”
- New runtime environments: Quarkus and Liferay
- Improved frontend build using Vite
- New components: Map, Spreadsheet, multi-select combo box
- Unit testing for UI logic
- Too many small improvements to count them all
Bigger things on the horizon
In longer-term goals, the horizon is fuzzier. We have a bunch of enhancements that we are definitely going to do, but the order and exact time is in flux. For these, we are constantly looking for input from the community. In the webinar, we did some polls to get insights from the attendees, but don’t hesitate to contact us via GitHub, comments on this blog post, social media or directly through your sales representative.
One thing is super-clear: we want to further improve our current components and framework features. Since the rewrite of components in Vaadin 10, we have been catching up with the huge feature set we had in Vaadin 8. In certain areas, we are already ahead, and we’re catching up on the remaining parts, but we want to level up and provide a wider and cleaner API for Java developers than we have ever had. We want to make it a very rare exception that you need to drop your shields and shift down a level to hack with JavaScript and HTML. These improvements are realized in a large amount of relatively small changes that can be shipped incrementally in minor releases.
A bigger change we want to get done before the end of the year is related to the Servlet 5/Jakarta EE 9 specification. When Oracle moved the ownership of the Java EE specifications to the Eclipse Foundation, they required new versions to move from the javax namespace to something else. This is affecting a lot of Java web developers and libraries out there, including Vaadin and Spring. Spring is moving to the new namespace in Spring Framework 6 and Spring Boot 3. General availability of Spring Boot 3 is planned for late November and we want to be ready for it. These will be mostly find-and-replace-style changes but, as so many libraries and servers need to change, not just Vaadin, and all at once, it might get nasty. Thus, in the webinar, we started to joke about giving Vaadin 24 the code name: “the nasty release”.
In practice, the abstraction that Vaadin provides will actually protect you exceptionally well in the transition to the new jakarta namespace. If you check your Vaadin UI code, you won’t see that many javax imports in your actual UI classes, if any. But your server or Spring Boot version needs to be updated and, if you have also exposed some REST endpoints or used JPA for the persistence layer, there will be a lot of changes in your Java files.
Other potential roadmap items we discussed in the webinar are listed below, in no particular order.
Development
- Reactive UI logic
- Benefit from new Java features
- Simplify theming
- Frontend build improvements
User experience
- Continue refining accessibility support
- Collaborative UI experiences
- More UI components for all imaginable use cases
Share your thoughts
In addition to sharing our plans, the idea of the webinar was to ignite discussions with the community. We ran out of time in the webinar, but we won't run out of characters discussing existing and new roadmap ideas. Please share your ideas, questions and concerns below!