Hello CUBA / JMIX team, this is really a big announcement!
I have another question regarding the porting of a CUBA application to JMIX or in general regarding JMIX architecture.
At the moment, with CUBA platform, when you write the screens using the generic UI, all the “client” application logic is written in Java because generic UI is based on Vaadin.
When you write the screens using the Frontend UI the “client” application logic is written in Javascript because here we use React JS (for services or API we continue to use Java).
With “client” application logic I intend the code you write, for example, to handle the click on a button on the user interface, enable/disable some field, etc…
With JMIX the architecture remains the same, so all the client React logic must be written in Javascript or Typescript? In this case the migration to JMIX of an “old” CUBA application that does not use React will be more difficult (migration of some Java code to Typescript).
Or did you architect some solution similar to Vaadin that allows you to write client logic in Java because the events are precessed server side?
Another question: I suppose the new architecture (Spring Boot + React + modularization) will facilitate the development of big applications splitting them in little pieces not only at server level but also at client level (micro frontends), right?
Thank you very much for your work!
Marco.
krivopustov
(Konstantin Krivopustov)
Split this topic
#16
Regarding the UI, currently Jmix is not different from CUBA: you can create either Backoffice UI in Java/XML, or Frontend UI in React/TypeScript, or both. It’s described here.
Regarding migration from CUBA, the compatibility module contains even the old screen API v.6, so it will be possible to migrate UI written for CUBA 6 without major rewriting.
[Backoffice UI] allows you to develop the rich web UI using just Java/Kotlin and XML. In this case, your UI components work in the same JVM as your backend, which simplifies working with data and invoking business logic. Also, you don’t have to be familiar with the modern JavaScript/HTML/CSS stack.
The good news is that it doesn’t look all that different to 7.2. The main difference is it now uses Spring Boot as a foundation, which is a good thing because Spring Boot is genius.
No Kotlin support as yet, so I’m sticking with 7.2 for an existing project.
It doesn’t look like they’ll be upgrading to a later version of Vaadin, which is a shame, but would be a lot of work, and with no easy upgrade route.
But another layer on top of Spring Boot … Not sure. I’m just thinking why not use Spring Boot, Spring Data and Vaadin.
Hi…
It was nice to see the Cuba Platform is evolving into JMIX… If possible can you please elaborate us the reason, why Cuba Team chosen Spring Boot instead of Quarkus…?
I personally feel Quarkus seems to be a better option than Spring boot… But i also presume that the might’ve did the benchmark comparison… It would be nice if you share the reason…
Thank you for your question - this is a good one. There is a list of different reasons , let me share some from the top of it:
Spring ecosystem is an absolute leader among enterprise developers. See this report. We build a product for the wide market and are trying to use mainstream tech.
Jmix as CUBA is targeted at business applications, but not headless microservices. The whole point of Quarkus, as well as Micronaut, is to minimize memory footprint and boot time. These two are not the case for business apps.
Quarkus introduces its own modules and not compatible with vast Spring Boot starters, which are even hard to compare…
Quarkus is a member of JavaEE family, while CUBA always used Spring. So, for the majority of CUBA community, it seems to be much easier to adopt Spring Boot and migrate their existing apps.
The 0.2.1 bugfix version of the Jmix plugin has been released to the JetBrains plugin repository.
If your IDE doesn’t see the update, please uninstall the plugin and install it back from the Plugins -> Marketplace tab.
List of fixes:
NoSuchFieldError in CubaKtClassOrObjectTreeNode when opening the CUBA project with Kotlin entities
Fix support of calculated properties in Entity Designer
Add quick fix for “Instance name is missing” inspection
ArrayIndexOfBoundException on the first page of project creation wizard
ClassNotFoundException during start when using plugin with IDEA Ultimate Edition
NoClassDefFoundError when using Jmix plugin while having Kotlin plugin disabled
Suggest additional data types for Calendar properties in Component Inspector panel
Unnecessary deletion of a unique constraint in the MySQL DB
Hi Cuba team
All this moves look very good to me. However, It’s not clear where we are heading to with current Vaadin 8, Are we upgrading it to 14 or moving completely to any other frameworks? Vaadin 14 looks very good and the PWA capability.
We are currently evaluating using CUBA/Jmix to rewrite one of our commercial applications. We are aiming for a release with a limited set of capabilities somewhere around Q2 - 2021(full release by the end of the year). Out of the top of my head, for the first part of the migration we would need a functional backoffice, a frontend UI and some business processes.
Would you say it is safe to start developing in Jmix or would you rather advise that we use the CUBA version?
In order to help you make a decision, I will tell you about our plans on Jmix releases.
In February 2021, we are going to release v.0.3.0, where all features planned for 1.0 will be implemented.
In March 2021, we are going to release 1.0.
After that, we are going to make feature releases (1.1, 1.2, etc) every 4 months, so 1.1 will be released in July 2021, 1.2 in November 2021.
Between feature releases we will make mainenance releases (1.0.1, 1.0.2, etc) with bugfixes, as we do for CUBA.
The dates are not set in stone of course, but it’s our firm intention at the moment.
Release 1.0 should be fine for creating new applications. In 1.1 we are going to introduce the support for migration from CUBA in Jmix Studio.
On the other hand, CUBA is now very stable and will be supported for 5 years since 7.2.0 (March 01, 2020) for free and 5 more years on commercial basis. We now make CUBA bugfix releases approx. every 2 months, perhaps the pace will be slower in the future.