Leif Åstrand

Current handling starts here: https://github.com/vaadin/hilla/blob/fd5e8b1d9ba438de0bce7ce162ffdab9eb0bbc51/packages/ts/frontend/src/FluxConnection.ts#L109 Hilla handles these events: `onClose`, `onError`, `onMessage`, `onOpen`, `onReopen`. This means that some events defined by Atmosphere are not handled at all even though there...

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...

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...

> 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...

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 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...

My ideas on "full stack state" might also fit into this problem somehow. I imagine it being something like this: ``` const todos = useSharedList(TodoService.findAll); ``` where `todos` has the...

The API has explicitly been designed to allow introducing this feature, but those plans have not been realized since there hasn't been enough time to make any component implementation work...

I'm not sure how this could be implemented without breaking `getValueProviders()` since the names of the available properties would only be known after running the new type of value provider...

> * I logout > * I try to login again > * BOOOM. This sounds like there's something with the security configuration that causes messages to be eaten after...