Jakarta EE and Quarkus support

[mrts]

Is your feature request related to a problem? Please describe.

Jakarta EE (previously Java EE) and Quarkus are fairly popular alternatives to Spring, but Hilla does not currently support them.

Describe the solution you'd like

Add support for Jakarta EE and Quarkus projects - like Flow has with the Vaadin CDI Add-On.

Both Jakarta EE and Quarkus can and should be supported with the same approach as they share many underlying technologies like CDI.

[mptyl]

SpringBoot is more then enough

[osenbg]

Quarkus Support is a must. Think about hybrid apps (Flow and Hilla) on the same server stack

[mkgl]

Hi there 👋,

Pretty interested in a decoupled deployment setup with a Quarkus backend, in particular using OpenAPI as source of truth. I find endpoint annotations tend to result in APIs designed in imperative programming style. Lots of boilerplate to take away with an archetype and opinionated tooling, giving atomic control over type-safe client generation, bundling, theme generation, etc. :)

[Legioth]

We don't have any plans for Jakarta EE or Quarkus support at this moment. We want to make Hilla really great for a single tech stack before we take on the additional technical complexity needed to support multiple runtime environments in parallel. With that "limitation", Spring Boot is the most natural alternative because of its very wide adoption.

We added Quarkus support for Flow a couple of years ago and we're still at a point where less than 1% of all Flow users use Quarkus. The usage percentage for CDI is in single-digit territory. While the philosophy behind Quarkus is more aligned with Hilla than with Flow, we have no reason to believe that the outcome with Hilla would significantly differ from what we've seen with Flow.

As a side note, we are indeed currently on another journey of adding support for multiple options in parallel by adding support for client-side templating with React in addition to the original Lit support. This is a slightly different situation since React has a similar defacto choice position as Spring Boot with very high general adoption (though Angular is putting up good competition specifically in combination with Java). Supporting multiple rendering libraries is also significantly simpler from a technical point of view since there are fewer integration points.

[mkgl]

Thank you Leif, appreciate the elaborate response and rationale. 👍 Then I think for the purpose I described, I should be able to wire Quarkus-based APIs to a plain Lit/Mobx frontend (or React for that matter), composed with Vaadin Components, theme (via DSP) + bundler config. Let's see how that goes!

[kyerise]

Please give us quarkus or jEE. Springboot has a lot of round holes its square pegs cannot fill. Especially since spring native is terrible an immature and spring produces these humongous artifacts that are very expensive in the cloud

[bkhoshbin]

quarkus+

[Dudeplayz]

@Legioth I think the reason that the quarkus usage is in an 1% range is, that it is not supported as first level like Spring Boot. So some APIs are neither or only later supported for Quarkus or some things are still not possible like this one. I often have issues, which come from the point that vaadin is focusing on spring boot and comes from spring boot. This situation also lets me think currently about switching to Spring Boot to get things done, even if I don't like it. If you start vaadin you get at first glance hinted at spring boot and all examples are done with it. So I assume, that only users who specifically search for the quarkus support use it and the necessary knowledge is also higher because the docs and examples are rare.

[Legioth]

You are right that it's to a certain extent at self-fulfilling prophecy that Spring is used by a majority of Vaadin users since we put that alternative in the spotlight for anyone without a strong opinion on what they want to use. We go the extra mile to provide a smooth experience specifically for Spring users but we also try our best to not put up any obstacles in the core use experience for other users (aside from explicitly Spring-only parts such as Hilla or SSO Kit that are peripheral to core Flow usage).

It doesn't significantly change the picture even if we exclude all Flow users that use the Spring integration since Quarkus is then still only at around 5%. Around three quarters of those that don't use Spring aren't using any framework integration at all (or using their own integration instead of something provided by Vaadin). Jakarta EE / CDI is the "winner" in the category but still only reaches around 17% of the non-Spring users.

[Gio-Ayiman]

We want Quarkus support please

[Dudeplayz]

Hi folks!

We have an exciting announcement today, we created a quarkus extension for hilla - Quarkus-Hilla !

If you're interested, you can read the full announcement or visit the repository.

Happy coding and have a great day!

[Legioth]

Great to hear about that announcement!

While I don't want to fully derail the discussion on the original topic here, I think it could still be meaningful to discuss two things related to the extension.

1. I understand that you have had to resort to some interesting hacks to be able to address the way the current Hilla implementation is tightly coupled to Spring APIs. Short of changing Hilla to use generic abstractions for all those cases, have you identified any low-hanging fruit that could be adjusted in Hilla to make the extension easier to maintain?
2. Would you be open to making the extension report itself to the regular usage statistics mechanism that is used by Hilla and everything else built by Vaadin? In that way, we could get a better understanding of how widely the extension is used compared to Hilla usage in general. I can help with the practical details in case you're open to the idea.

[lamtanloc512]

I was started working with Spring but now Im using Quarkus because it very simple to use and performance as well, so if Hilla support Quarkus this gonna be super cool.

+1 Quarkus

[Dudeplayz]

Great to hear about that announcement!

While I don't want to fully derail the discussion on the original topic here, I think it could still be meaningful to discuss two things related to the extension.

Thank you very much for your feedback and suggestions @Legioth !

1. I understand that you have had to resort to some interesting hacks to be able to address the way the current Hilla implementation is tightly coupled to Spring APIs. Short of changing Hilla to use generic abstractions for all those cases, have you identified any low-hanging fruit that could be adjusted in Hilla to make the extension easier to maintain?

There are probably many low hanging fruits, if not even all hacks represent those. We already discussed this and want to create an additional page in the wiki of the project, where we try to list and describe all hacks we've done. This should give the Hilla team some insights, we could also add some simple ranking how easily it can be adjusted.

2. Would you be open to making the extension report itself to the regular usage statistics mechanism that is used by Hilla and everything else built by Vaadin? In that way, we could get a better understanding of how widely the extension is used compared to Hilla usage in general. I can help with the practical details in case you're open to the idea.

We are basically open for this, as long we comply with the legal terms and that the user can opt-out. I think it would be interesting also for us to see. In the end we need some users, because probably the one or the other could not go with our extension because it's not official, then the statistics would be empty, even if there is some interest.

[Dudeplayz]

I was started working with Spring but now Im using Quarkus because it very simple to use and performance as well, so if Hilla support Quarkus this gonna be super cool.

+1 Quarkus

@lamtanloc512 then maybe you want to give our extension a try?

[lamtanloc512]

I was started working with Spring but now Im using Quarkus because it very simple to use and performance as well, so if Hilla support Quarkus this gonna be super cool.

+1 Quarkus

@lamtanloc512 then maybe you want to give our extension a try?

Oh, I gonna give that a try, thank you for introducing me 😍

[nimo23]

Don't forget that your stats stating that this project is or was underused by Jee/Quarkus developers can also be interpreted differently:

• Most users have opted out of being counted so they don't appear in your stats.
• The move from java ee to jakarta ee has put many on hold. But now everything is moving very quickly and "Java ee" users will switch to "Jakarta ee" and may therefore also be looking for a suitable web technology. Since "Hilla" officially does not currently exist for Jee, no new users can be generated here either.
• Most users can only be Spring users because most Jee and Quarkus developers didn't know about Hilla (or its predecessor) until now or in future. This could change if Hilla were available as an extension in https://github.com/quarkiverse.
• An extension for Jee and Quarkus would also potentially benefit Spring users as PR and issues around the project could lead to continuous improvement for the whole project. Imagine an abstraction layer of Hilla.
• In fact, at the moment it seems that Hilla is quite dependent on Spring as there are no specific interfaces that allow using other vendors (e.g. Jee, Quarkus). By the way, Spring and Quarkus should be considered more of a "special" Jee anyway, since both Spring and Quarkus have to integrate a lot of Jee.

I think, it would be good to realize an interface+abstraction layer of Hilla with different (overlapping) implementations spring, quarkus, jee. This could also make Hilla a new standard in this Java ecosystem..

[Legioth]

Most users have opted out of being counted so they don't appear in your stats

That would probably not matter when looking at percentages of those who have not opted out rather than looking at absolute numbers. The case where it would matter is if there's a theory for why Quarkus users would be significantly more eager to opt out than what Spring users are.

The move from java ee to jakarta ee has put many on hold

Same here as well since it's about relative usage rather than absolute numbers. Why would Quarkus users be more affected by this effect than Spring users?

Most users can only be Spring users because most Jee and Quarkus developers didn't know about Hilla

It's quite obvious that Hilla today won't have many Quarkus users since there is no support. The big question is how many users we could expect if it would be supported. If we assume that x% of all Spring users would use Hilla and y% of all Quarkus users would use Hilla, then is there any reason to expect that y would be significantly higher than x?

[nimo23]

If we assume that x% of all Spring users would use Hilla and y% of all Quarkus users would use Hilla, then is there any reason to expect that y would be significantly higher than x?

Why do you see this as a battle between Spring and Jee/Quarkus? Instead of seeing x > y + z, you should see it like this: x + y + z. Anyone looking for a viewing technology in Jee/Quarkus besides JSF may consider Hilla. Btw, what would Spring be without Jee? Spring is nothing else than a framework for Jee - nothing else.

An extension for Jee and Quarkus would also potentially benefit Spring users as PR and issues around the project could lead to continuous improvement for the whole project. Imagine an abstraction layer of Hilla. And that cannot be measured in advance, because it is not only a question of quantity, but also of quality.

[Legioth]

All else being equal, it would certainly be beneficial to also have Quarkus support. The gotcha is that it's not equal.

Every feature we choose to build means that all the other things we could build are postponed. With Quarkus support, we assume that its impact on Hilla usage would be relatively small based on the overall ratio between Spring Boot usage and Quarkus usage in the Java world. We have other features on the roadmap that we expect to have a higher impact for similar development effort.

Every feature also needs to be maintained in the long run. The abstractions needed for supporting an additional runtime environment are, based on our experience from Flow, among the features that are particularly expensive to maintain. The impact is especially high when it comes to testing since many cases would need to be tested separately with each runtime environment. We have other features on the roadmap that we expect to have lower maintenance overhead for similar impact.

potentially benefit Spring users as PR and issues around the project could lead to continuous improvement for the whole project

That benefit comes mainly from more eyeballs in general, unless someone presents a theory for why the average Quarkus user would be more eager to submit issues and PRs than the average Spring Boot user. A new feature that brings more eyeballs and directly improves the experience for existing users is more valuable than a new feature that only brings the same amount of eyeballs but no direct improvement for existing users.

Imagine an abstraction layer of Hilla. And that cannot be measured in advance, because it is not only a question of quantity, but also of quality.

That abstraction would probably also increase the maintenance burden and occasionally get in the way of building other new features.

[Legioth]

The Hilla experience is already good today, which is why Quarkus users want to be able to use it. But at the same time, we know so many things we want to do to make it even better. A nimble framework lets us rapidly explore those ideas so that we can quickly converge towards a truly awesome core experience. The work of adding an abstraction to support multiple runtime environments is a distraction from improving the core experience and the existence of that abstraction would make it slower to try out different alternatives.

What we need for the moment is to keep improving the experience for the existing user category (assuming it's sufficiently big to get enough feedback). Investing to reach new groups of users before that would be like pouring more water into a leaking bucket. Once the bucket is watertight, then it will start to make much more sense to work on pouring!

[bkhoshbin]

I am interested in Quarkus version too . +++

[ricardovm]

Hilla with Quarkus would be great. I create new Flow applications with Spring Boot because of the fast first delivery time. And then I migrate some parts (or the whole application) to Hilla. If I could do it with Quarkus, surely I would use it from the beginning.

[Dudeplayz]

@ricardovm maybe you checkout our quarkus-hilla extension. We are always up-to-date and doing nightly builds against the latest dev builds of vaadin. You can also start with it on quarkus codestart.

[jpinkham1]

One more point to consider - Trying to get multi-tenancy with keycloak using realm per tenant working, I found nothing for Spring security comparable to the support I found for multi-tenancy in Quarkus at https://quarkus.io/guides/security-openid-connect-multitenancy. This makes me tempted to try that extension.

But I also love what I'm seeing with Hilla (like the new fly.io deployment stuff). Coming from a Wicket background, you'd think I'd go more for the vaadin + flow, but I think that was back before I felt comfortable with javascript - now I think Hilla hits the productivity sweet spot for me, so I don't want Quarkus support to detract from that.