Hi, On Wed, Feb 4, 2026 at 6:38 AM Korbinian Bachl < [email protected]> wrote:
> Hi all, > > I had a closer look at what it would mean to base Wicket 11 Ajax on htmx, > and I wanted to share some early thoughts and open questions. > > A possible technical starting point could be something like a > HtmxPartialPageUpdate extends PartialPageUpdate, > since Wicket already funnels Ajax rendering through PartialPageUpdate. > Conceptually, that feels like the right extension point. > > However, I’m currently unclear how Wicket would reliably detect an htmx > request versus a regular request. > > According to the htmx documentation (https://htmx.org/docs/#requests) > htmx issues regular HTTP requests (GET/POST/etc.) and identifies itself > via a fixed set of request headers. > As far as I understand, these headers cannot be freely customized (and how > do we differ from our "wicket htmx" requests and some of the implementing > developer requests?). > > In contrast, Wicket Ajax currently relies heavily on its own custom > headers and the AjaxRequestTarget abstraction to clearly distinguish Ajax > requests from normal ones and to control the response format and > client-side processing. > > Another structural concern is partial page updates. > Wicket allows updating an arbitrary number of components per request. To > achieve the same with htmx, hx-swap-oob would likely be required almost > everywhere. While technically feasible, this would fundamentally change how > responses are rendered and composed. > > On top of that, there is the whole ecosystem of: > > Ajax behaviors and event bindings > > AjaxFormSubmitBehavior and related form-processing semantics > > Even if all of this could be reimplemented on top of htmx, there is a > bigger compatibility question. > > How would existing code—especially from wicketstuff, third-party > components, and private component registries—continue to work? > > A lot of existing components rely directly or indirectly on: > > Wicket.Ajax client-side code > the XML-based Ajax response format > JavaScript callbacks injected via AjaxRequestTarget > > Requiring all of that to be rewritten would be a very disruptive change > for the ecosystem. > > This makes me wonder whether a more incremental approach might be > preferable. > > For example: > > First, remove the dependency on jQuery and modernize the existing Wicket > Ajax JavaScript. > This is already implemented in Wicket 11. > Then evaluate the size, complexity, and responsibilities of the remaining > Wicket JS layer. > Based on that, explore htmx more deeply and evaluate whether a > compatibility layer (some form of Wicket.Ajax glue on top of htmx) could > realistically preserve backward compatibility. > > That might give a clearer picture of how much change is actually needed, > and where htmx genuinely helps versus where it introduces new challenges. > > I’m very interested in hearing thoughts on whether such a staged approach > would make sense, or if people see a cleaner path forward that I’m missing. > > Best, > Korbinian > > > > > > > ----- Ursprüngliche Mail ----- > > Von: "Martijn Dashorst" > > An: "dev" <[email protected]> > > Gesendet: Montag, 2. Februar 2026 16:15:39 > > Betreff: Re: Master branch set for Wicket 11 > > > I have no concrete plans, but a wishful thinking list: > > > > I am considering a marriage between HTMX for client side and Wicket for > > backend. But nothing concrete (or even in a proof of concept, just an > idea > > in my head). > > > > There are some hurdles to overcome with that approach: > > - wicket component identifiers and generated markup ids will prevent most > > of the currently used morphing algorithms to work properly, and probably > > also be a blocker for htmx > > - using htmx as front end assumes htmx is in the lead for issuing > requests > > to the backend and wants to have a HTML response (which is not Wicket's > way) > > - using hx-swap="append" or similar is not compatible with wicket's > > listview/dataview components that render everything > > - using idiomorph for replacing markup in an ajax swap will probably not > > work due to the new markup ids for components > > > > I also want to look to modernise the API and internals, using builders, > > automatic parameter resolving similar to JAXRS, etc. > > > > Make the renderer easier to embed in JAXRS > > > > Make Wicket and Quarkus work better together (and native compilation) > > > > Make Wicket's stateless support first class. > > > > And probably more than I can manage :D > > > > Martijn > > > > > > > > On Mon, Feb 2, 2026 at 1:22 PM Korbinian Bachl < > > [email protected]> wrote: > > > >> Hi, > >> > >> is there any kind of ideas/ roadmap already? > >> > >> What serlvet level ist planned? 6.0? or 6.1? > >> > >> Will CDI be seen as core requirement? > >> > >> What about jQuery dependency and ajax? > >> > >> > >> > >> > >> > >> > >> ----- Ursprüngliche Mail ----- > >> > Von: "Andrea Del Bene" > >> > An: "dev" <[email protected]> > >> > Gesendet: Samstag, 31. Januar 2026 19:49:17 > >> > Betreff: Master branch set for Wicket 11 > >> > >> > Hi! > >> > > >> > I've set master branch to start working on Wicket 11. I've set java > 21 > >> > as codebase version and I updated Spring and Junit respectively to > >> > version 7 and 6. The new branch wicket-10.x will host the code for > >> > Wicket 10. Github CI are ok for Java 21 and 25, but apache CI needs to > >> > update Java to 21. > >> > Please let me know if everything is ok with this. > >> > > >> > Thank you! > >> > > > > > > -- > > Become a Wicket expert, learn from the best: http://wicketinaction.com > -- Regards - Ernesto Reinaldo Barreiro Apache Wicket Committer Emerging artist https://www.instagram.com/reinaldo.barreiro.art/
