Hi,
Yes, the UI changes are quite significant indeed. This is why in this example I also went down the delete & recreate approach (you’ll see it in the next videos). You can also see that by the fact that even Vaadin itself does not have a good upgrade story to “easily go from 8 to 24”. In the first video I also talk about the version incompatibilities, which makes running it side-by-side in the same app impossible.
In a recent bigger production app that I migrated we went the lazy migration approach with parallel deployments. This made the migration quite smooth, as we could replace UI piece by piece. But of course this only works in certain scenarios where it is possible to have multiple apps running and when you anyways utilize some form of SSO.
I don’t see a magic bullet here to “automagically” migrate the UIs. It is a combination of various things, but mainly that Vaadin 24 is a very different framework over Vaadin 8. Jmix the did not really significantly contributed here. If you have a big enough project, normally also project specific abstractions (in production & testing code) are introduced. This means the possible options of what source code sits in a random Jmix app is almost endless. Thus creating a magic machine that is capable of reading arbitrary Java code and transform it is theoretically possible but practically very very hard and expensive. If you look at the broader industry and how it is tackled there, you’ll find something like https://docs.openrewrite.org/. But even those project mainly do only “trivial” source code / AST transformations (example Spring Boot 2.x to Spring Boot 3.x migration).
With the move from CUBA to Jmix it was mainly about enabling to have a migration option at all. Additionally when Jmix 1 would have immediately forced migration to Vaadin 23, it would have probably excluded a lot more migration scenarios, forcing to rewrite the complete app.
In general migrations are always part of our developers life and it is also independent of the technologies used. When you leave a React application from 2019 as is, in 2024 you can also rewrite huge chunks of it as “redux is out of fashion”, “hooks did not exists” and it might have “used flow instead of typescript”.
With a Meta Framework like Jmix, it is theoretically possible to hide a couple of those “implementation frameworks” away, but if I understand correctly, this was one big learning from CUBA, that it is not really ideal to hide those things away. It mainly means that the meta framework has to create mirrored APIs, which is problematic as they are not widely known & it always has catch up with all the options of the underlying frameworks to not lose flexibility for app devs.
Thus with Jmix the approach was more to create abstractions only where needed, but as the default expose the underlying tech to overcome those challenges. Examples: Vaadin 24 - which is now exposed almost 1:1 without any changes, Liquibase, Spring Boot. So it is now more a very good arrangement of standard frameworks instead of trying to reinvent the wheel.
I can remember from Grails 2 - 3 Migration it was an even worse migration as the required jump was even more extreme and they had a huge plugin ecosystem that slowed down transition furthermore.
Ultimately source code is not only an asset, it is also a liability. The only way to avoid that is by using even higher level abstractions like No-Code tooling. But these normally take away a lot of flexibility.
As a last thought: the only way I could think of that being solved in the future is by using LLMs to do migration tasks. I haven’t tried, but I’d assume when creating a custom GPT today with a lot of examples on the API differences and then asking about migrating a Vaadin 8 → Vaadin 24 might go into a direction and be a good start. But for this to be reliable & production ready I think there is more time & more mature products required in the industry.
I hope this explanation helps you a little bit.
