today morning I realized that you are going to discontinue hilla.
I read the article on your blog and honestly the consequences are not really clear to me.
As a hilla dev should I look for another web framework?
Lately i spent many hours on this product and I made good progresses with my personal project, really pitty you took such a decision.
If the product will be not manteined anymore could you please provide us with a guide to migrate the hilla apps to the alternatives (e.g. spring boot + vite + react)?
or at least you could list which are the best alternatives for minimizing the impacts in terms of rewriting.
We are still listening to feedback and working on defining exactly what to expect in the future.
On a high level, we plan to keep maintaining most of the existing functionality since that kind of functionality also makes sense for the use case of building offline-views for applications that are mainly based on Flow.
At the same time, we no longer aspire to have the best solution in the world for building Java applications with client-side views. We will no longer invest into building new functionality to serve such use cases.
In a different discussion, there was a suggestion to consider https://springdoc.org/ for generating OpenAPI descriptions based on regular Spring MVC controllers and openapi-zod-client to generate TypeScript based on those descriptions.
Ok
I was trying to estimate the impact of migrating to a plain vite react 19 stack. As I can get the vaadin react components by npm (use effect … grid and so on) I guess the only effort is to rewrite the endpoint services into real API. Am I right?
I mean you keep maintaining such npm packages… Right?
On the backend, you should be able to keep things like entities and repositories on the data access layer. Depending on your code structure, you should probably also be able to keep your services in the business logic layer, but depending on your use case, you probably need to re-implement common C.R.U.D. functionality, if you try to avoid things like the CrudRepositoryService from Hilla. On the presentation layer, you will have to add Spring Rest-Controllers for everything that is relevant for the frontend. As soon as you have implemented this new presentation layer, you can use OpenAPI to generate all the required TypeScript for the communication between the backend and the frontend.
On the frontend, you will have to find an alternative UI component library, because many of Hilla’s UI components, like AutoGrid or AutoForm expect a very specific communication with the backend. I recently migrated a simple React component that used the AutoForm component to a non-Hilla stack (Spring Boot, OpenAPI, openapi-zod-client, React, TypeScript, vite, React Router, shadcn, Tailwind, react-hook-form…) and the amount of code in the React component increased from roughly 60 lines of code to 260 lines of code - not including the configuration it takes to plug this non-Hilla stack together.
What does this mean for @Browsercallable ? Or views defined in frontend folder? Do we have to add those in Java flow?
That depends on what you want to achieve.
@Browsercallable and views in the frontend folder will continue to work in Vaadin 25, but afterwards they will probably be deprecated and at some point removed. If you want to stay with Vaadin on the long run, you will probably need to convert your app into a regular Vaadin Flow app.
Hilla as a stand-alone framework/product will disappear, but some of its functionality will be moved to Flow to enable better client-side support for things like offline-capabilities etc.
What does it mean? I cannot install any other npm packages? I think it’s too unclear to comment on right now.
From blog -
The current Hilla way will stay as the way to build offline and client-side implementations in Vaadin framework applications in the future as well. But the main way of building UIs for the web will be in pure Java.
So not sure what is going to change?
regarding hilla you do not get any further relaese after the version 25.
nothing is going to change and no new features will be released.
anyway you can keep using it as long as you like it.
hilla will be partially reused to manage the offline views in flow, but you are not supposed to write javascript for your normal views in flow.
which means that if you want to move to flow you have to rewrite all the frontend of your project.
Ok. we just add vaadin jar file in the pom right? There is no hilla jar being included now? And vaadin installs all npm packages. So going forward this won’t be done?
I don’t think so. We want to keep supporting client-side UI logic for cases that need that, e.g. offline views and views that need to support hundreds of thousands of users with minimal server requirements. Functionality like @BrowserCallable is essential for supporting that kind of use case which means that it is very likely to remain supported in the long run.
2 Likes
Thanks for clarification, Leif.
Let me give you an example: I have a stand-alone Hilla app/project with version 24.9.3. I will be able to update this app/project to version 25 and to all up-coming 25 minor and patch releases, right? Will I be able to update this stand-alone Hilla app/project to version 26?
We don’t have a roadmap for Vaadin 26 yet so I cannot tell. I’m relatively confident that @BrowserCallable and React APIs for all components will remain since they are so essential also for client-side views inside Flow applications.
The area with the biggest risk of changes might be routing since we might want to make that more Flow-centered. Client-side routing will be necessary especially for offline to work but it might look different in the future. But that’s also just speculation from my side rather than anything that would be confirmed on our roadmap.