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