We published a traditional recap of the year and our plans for the next one. Your comments on the article are most welcome here!
3 Likes
As a customer, I appreciate your post with the recap of current year and new plans for next year because help to increase trust in the company and your products.
Congratulations for the right decision to invest in R&D and increase the workforce. Haulmont has created an extraordinary product that, without marketing activities, has you grown by over 20%. With more investment in marketing strategies, like the new website launched in december that release success cases in the customer stories section, will position your product in a good place in the software development platform market.
About the recent price change, I already expressed my opinion about it. I believe that the entire community will support the decision in its own interest to continue developing software through a quality platform, technologically updated and supported by a professional team.
I find the decision on the new front-end technologies correct, Vaadin as the primary client and the work on upgrading to the latest Vaadin 23 LTS release, especially with the future goal on making Jmix and React Buddy work together.
Finally, my wishes to all JMIX community that we have a great New Year full of new JMIX features.
6 Likes
Hi Xavier! Wow. Great to hear that you think we’re on the right track! We’ll do our best to make it a great year!
1 Like
I think this is the 1st time you have posted such and in-depth review and roadmap (the have been some roadmaps before, but not to that detail).
Particularly the clarification on the direction the Generic UI is taking (emphasis mine):
Initially, we planned that the new React client would be a 1:1 alternative for Vaadin over generic GraphQL API. However, as we progressed with R&D, we realized that support for two equal UI clients turns Jmix into a mess: double documentation, different APIs, etc. Moreover, Jmix’s generic API approach encountered reservations among web developers, who are used to working with dedicated endpoints. (…) we started work on upgrading to the latest Vaadin 23 LTS release.
Up until that point it was unclear if one day the Vaadin UI (Java/Kotlin) would be dropped in favor or React (JS); or even what Vaading version was the next to be available.
Now we now:
- Java/Kotlin centric development is still in Jmix DNA
- Vaadin UI is here to stay and will be updated to the latest LTS!
- Javascript can stay ver much out of sight for some of us
THANK YOU
Going back to the Roadmap:
(…) Flutter mobile client on the back of the same GraphQL API.
Given the rise of Jetpack Compose on Android, and the fast pace at which Jetbrains is improving Compose Multiplatform which is all Kotlin top to bottom; has that been consired instead of Flutter?
if so, a side of the fact that Jetbrains has not said anything yet about adding iOS as a target for Compose Multiplatform, what other things motivated to go with Flutter?
Thanks Marc!
With regards to Flutter, our logic is simple:
-it is the most popular cross-platform technology to date
-it is very mature and well supported, and it is truly crossplatform - running anywhere from browser to Android to iOs.
-it is more familiar for Java developers compared to React Native - no css/html, everything is in the code.
-we like it 
Compose Multiplatform 1.0 has just been released, and considering there is no support for iOs, it just does not fit for purpose. We keep watching, but we will only bet on a technology which is widespread and mature.
I hope this answers your question!
4 Likes
I am new to Flutter and would say, it’s easy to learn when someone is coming from java experience. I fully agree with you @ag1 , that’s a good decision to go for Flutter. When do you think the preview version will be available?
Hi Mortoza!
Same feeling, I personally love Flutter coming from Java background.
But as I mentioned in the recap Flutter work is currently on hold due to other priorities.
So I cannot promise anything at this point of time. Perhaps we can come back to this question at the end of year.
Andrey.
1 Like
Looking at the Roadmap, it looks like the project was going down duplicate paths with a front-end web UI.
Unfortunately, in the past, I have seen other products that tried to go down duplicate paths and ended up going out of business. They had many choices that were all unusable.
While I do understand some people wanting a variety of “modern” web app front ends to choose from, I would prefer the JMix Team simply picks one and only one and focuses on making it stable and very usable.
The way I see JMix, it is an “all in one solution” that can be used right out of the box. It needs to be able to do everything end to end without having hand code a significant portion of a web application. Hand coding would take away 99% of the value for me.
In the end, I’m glad to see the focus is on getting the Vaadin 23 LTS nailed down before “branching out” to duplicate technologies.
1 Like
Hi Richard,
First of all: welcome to the forum 
I think your concerns are valid and to a certain degree there were similar attempts in the past to support multiple UI technologies (there was even for CUBA 6 a front end module with different JS stacks over time if I recall correctly).
Looking at what @ag1 wrote there from my understanding the team came to the same realization you did:
Another key direction of our work has been the new front-end technologies. Initially, we planned that the new React client would be a 1:1 alternative for Vaadin over generic GraphQL API. However, as we progressed with R&D, we realized that support for two equal UI clients turns Jmix into a mess: double documentation, different APIs, etc. Moreover, Jmix’s generic API approach encountered reservations among web developers, who are used to working with dedicated endpoints.
The above made us reconsider our strategy. Jmix will retain Vaadin as the primary client and focus on seamless, pure Java/Kotlin full-stack development.
I personally also like to have opinionated solutions as they boost productivity if the use-case matches. Therefore I really appreciate modernizing the Vaadin solution, as Vaadin itself has this focus on business apps while still not entirely close its eyes from the JavaScript world (at least for Vaadin 10+).
From my interpretation Jmix will remain focus on Vaadin and make the react support more detached. Which will help in positioning something like reactbuddy, but also Jmix itself.
I’m not what I’m particular you are referring you when you say “before branching out”. Currently from the outside I don’t see such attempts for Jmix itself. Perhaps you can elaborate?
Cheers
Mario
Mario,
I wrote:
“I’m glad to see the focus is on getting the Vaadin 23 LTS nailed down before “branching out” to duplicate technologies.”
What I meant was I’m glad that the team is focusing on Vaadin 23 LTS as the one and only “modern” web front end technology.
By branching out, I meant adding on React or Flutter as another duplicate “modern” web front end technology option.
If I were running the JMix project, I’d offer other options as Add-Ons so resources can be allocated as revenue comes in for each. This would keep each Add-On as a self-contained “mini businesses” that would not be a financial drain on the JMix project itself.
In the end, I’d always like to see Vaadin 23 LTS as the focus.
Take Care,
Rich
Hi,
By branching out, I meant adding on React or Flutter as another duplicate “modern” web front end technology option.
Today you can do almost everything in Jmix in a Browser but if you need to go Desktop Native or Mobile for some reason you only have REST API addon to build upon.
If I recall properly (not sure if from the latest Roadmap post or the previous one):
I think the idea here regarding Flutter is more in the lines of leveraging Jmix as a backend technology. Not to provide an alternative Frontend/UI technology (like we had in CUBA with Swing/Desktop) but to make sure the building blocks are there for people having special needs.
Maybe this ends up in an addon like REST API, or builtin; Who knows. But I’m almost certain it will not be much more than an utility library on the Flutter side to ease consumption of Jmix APIs, and a REST / GraphQL addon on the server.