What I hate about Wicket Framework

This post describes my opinion about Wicket framework.

Wicket is a component-based Java web framework from Apache that is gaining some popularity. Like most component-based web frameworks, Wicket is harder to learn than controller-to-view frameworks (Request-based) like Grails, Stripes, Servlets/JSP, Rails etc., but it offers more features and is more focused on the state of HTML elements instead of the state of HTTP requests. (Update 7-July-2010: to be clear, I don’t think controller-to-view frameworks are better, I just think they are easier to learn. But when you need to develop a WebApp, I think component based frameworks make the development easier.)

It’s not that I hate Wicket, but there are some features that I don’t like:

Heavily based on sessions.

Although Wicket does offer a few stateless components and session-less features, it is heavily based on sessions. Without session, state-fullness is difficult. Sessions have two drawbacks: timeouts and memory consumption.
A timeout occurs when a user doesn’t respond within (usually) 30 minutes. When that happens, the state of the page the user visited is lost. There are some Ajax hacks around this, but they are cumbersome. An option is to increase the timeout, but then you will be limited by memory consumption of sessions.
Some argue that memory is cheap, but that depends on your situation. If you’re building some in-house Website/webapp for a  company running its own servers than memory is indeed cheap. If you are a student or a freelance developer that is deploying the website on some leased VPS (Virtual Private Server) or a dedicated server, than the memory usage can increase the costs a lot.
What I like is the solution of Microsofts ASP.NET framework. It uses viewstates instead of sessions, which stores state in hidden html elements that are submitted back to the server when the user triggers an event, by using Javascript. This approach also has some drawbacks, but it doesn’t depend on sessions.

Wicket team had plans of implementing “client-side models for zero-state scalability”, but unfortunately they dropped it.

High learning curve

Component-based frameworks (pull MVC) are more difficult to learn than controller-to-view based frameworks (push MVC). This makes documentation more important, but the recommended book Wicket in Action doesn’t provide much inside in about how Wicket exactly works. This makes it difficult to do a bit more than standard stuff, when after you have read it.

Wicket URLs

I hate it when URLs reveal the usage of a framework. Wicket has Url Coding Strategies to fix this, but when using statefull pages, these urls often reveal the Wicket framework, this because Wicket uses the url to track a version of a web page. For example, you might get URLs like:
http://example.com/product/abc/.1.2 and when you click on some component on that page that will let you stay on the page but which some updated components, then you get http://example.com/product/abc/.1.3
The unwanted part is .1.3. It should stay http://example.com/product/abc all the time.

When clicking a component, there also often is an unwanted extra HTTP redirect before fetching the final HTML.

HTML is not that pure

A philosophy in Wicket is that HTML should strictly be separated from code and component properties, so that a web designer can make the HTML, and the programmer can just code Java. I hate the idea of making it easier for a web designer (highly subjective opinion), since I’m a programmer that makes the HTML/CSS myself, but I like the idea of separating it cleanly. But when using Wicket you will get a lot of tags like this in your HTML when you  need to repeat components:
<wicket:container>……</wicket:container>
So the HTML isn’t that pure.
If you don’t use that container element, than you easily get two nested divs where only one div is needed.

Update 11-July-2010: the commenter “anonymous coward” showed unwanted divs can be prevented by using setRenderBodyOnly. Other not-pure HTML can occur when Wicket Fragments are used, but this scenario doesn’t happen often.

Static component tree

It would be nice if you can create a tree of components dynamically, but in Wicket you have to define the tree structure statically in both the HTML layout and the Java code. It is possible to switch subtrees, but those subtrees have to be defined upfront.

Very verbose

Because of the clean separation of html and Java, and because it’s a component based framework, code will be more verbose than standard push MVC framework. A feature of Wicket that makes it even more verbose is the use of “models”. Model objects can be used by components to retrieve data, so that there is a clear distinction between data and data retrieval. This becomes clear when using repeating elements in HTML. Then you usually need to define LoadableDetachableModel anonymous classes that are nothing more than packed method calls to your DAOs (Data Access Objects) to retrieve data.

What I do like

This blog post is focused on what I don’t like, but to give you a short idea of what I do like:

——————–

Update 7 July 2010: changed “complexity” to “high learning curve”. And wrote more explicitly that I do favor component based frameworks over controller-to-view/request based frameworks, like the commenters below also do.

Update 11 July 2010: changed my opinion about “Not pure HTML” after the post of the commenter “anonymous coward”.

24 thoughts on “What I hate about Wicket Framework”

  1. Fair enough, I agree with some though not all things. The primary thing I violently disagree with is that controller-to-view is simpler. Maybe when it comes to relatively simple page-by-page views, but definitively not for anything more complex. I stumbled upon Wicket by searching for a solution to that complexity, and Wicket has helped quite a bunch.

  2. I think that controller-to-view is simpler when it comes to learning the architecture/features/possibilities of a framework that implements it. But when it comes to programming complexer and stateful pages, than I think that controller-to-view is very limited, like you say.

  3. you forgot to mention another draw back of sessions: it is hard to load balance with (yes, i know there is sticky session handling out there, but depending on your network it can be impossible to do [particualy when you cannot re-encrypt a ssl connection)

  4. Well all things considered wicket has not clear published road map. And due to introduction of Servlet 3.0 and asynchronous methods many of the
    existing web frameworks for Java are doomed to go obsolete. Just wait and see and till then put up since we have no choice.

  5. In Wicket you have to put all HTML in your java project – the “strictly be separated” is not given. I want to get my templates from an CMS where the html producer manage here code.

  6. I don’t think Request-based frameworks are any easier once your *web application* starts getting complex. Within no time you start realizing that you need a multi-select here, a data table with checkboxes, Edit/Delete links etc there, AJAX in some other part and so on. Now, you quickly end up messing with request parameters, lots and lots of hidden fields, and all the bugs that come along with these.

    The thing is, for most non-trivial web applications, you need state. With component-based frameworks, this state is pretty much managed by individual components themselves. Also, since state is encapsulated within components, GC-ing becomes easier on the server side. With request-based frameworks, as has been amply clear with Struts, this becomes a royal pain within no time!

  7. You can’t be serious about viewstate. This has always been a major source of scalability problems with ASP and the newer ASP MVC doesn’t even use it by default now.

  8. “Wicket is harder to learn than controller-to-view frameworks like …, Servlets/JSP, ”

    I found Servlets/JSP easier to learn than Wicket, but harder to use. Consider the days before JSPs when Servlets were used for the view. You had to embed HTML in Java strings — encoding the special characters made the strings virtually unreadable. I don’t find HTML files all that readable to begin with, and now I have to look at code that combines lots of little fragments and have to imagine the intended result.

    JSPs were the solution; now your HTML looks like a regular HTML page — and you can embed Java code! The concept is trivially simple to learn … but Java code embedded in JSPs is hard to re-use and really really hard to debug. So just as good programming practice tells us not to embed HTML strings in our Servlet Java code, it also tells us not to embed Java code within the JSP’s HTML. But then how are are _supposed_ to code our view logic?

    Custom tag libraries were the solution to the JSP problem. But I had just as much trouble understanding the custom tag APIs as I had learning Wicket. The first three books I read left me befuddled; the rules seemed arbitrary and ad-hoc, and therefore incapable of being remembered. It was not until I read the SJCWD textbook which explained the internals that the tag-creation APIs made any sense. And even then, it was not obvious to me how to use them to create the functionality I needed. And even when I did solve the problem, guess what? The code that implemented my custom tags embedded HTML encoded as ugly Java strings filled with escape characters — the same problems I had with Servlets!

    To solve the custom tag problem people provided standard tag libraries which included functionality for conditionals, loops, etc. Of course, you’re never going to find a standard tag that encapsulates all of your needed view logic, so they give you programming language primitives encoded as tags for you to nest inside your JSP. Essentially, these tags defined a second programming language, a scripting language, to use in JSPs. Learning a standard tag library was much easier than learning Wicket. But guess what? My view logic implemented via standard tags was almost as difficult to debug — and just as difficult to reuse — as embedded Java code!

    Additional frameworks such as Struts allow you to bolt on common patterns used in web development, but do not solve the problem mentioned above; so we see framework piled upon framework. Is it any wonder that most web developers abandoned Java in favor of PHP, Ruby on Rails, or whatever? But what if I _want_ to use Java? What if my back end is in Java?

    No, I did not find Wicket easy to learn. The web tutorials (“How to create a simple HTML Form in Wicket!”) exhibited complexity with no special payoff. To learn Wicket, I had to run the online samples, download and study the code that implemented them, join the online forum, and, on occasion, read some of the source code behind Wicket. There are now some good books which make the basics simpler, but I still had to read Wicket implementation code and ask questions on the mailing list for anything not directly covered.

    However, Wicket in the only HTML-based Java web framework I know of which solve the problem of building web applications without either embedding unreusable and difficult-to-debug view-oriented programming logic into HTML or manipulating ugly escaped-HTML strings within Java code.

    Considering the frameworks that are most popular, I have to conclude that the vast majority of developers don’t care much about readability and reusability.

  9. @John,
    Why would Servlet 3.0 make other Java web frameworks obsolete? Java web frameworks use the infrastructure provided by Servlets, so those other frameworks use servlets instead of conflicting with it.

    @Kodeninja,
    I completely agree. Maybe I should mention that more explicitly in my post.

    @A. Lonescu,
    I have been looking at Click before. Looks interesting, I have to look further in it. But is doesn’t look very matured and popular yet.

    @Dan Howard,
    Viewstate is also used in JSF, which uses server sided viewstate by default, but also allows client sided viewstate. Yes, viewstate has drawbacks, so has session usage. The developer has to watch out that viewstate doesn’t become too large. The use of viewstate and sessions them depends on the requirements of the website. So you cannot say that one is better than the other without looking at websites requirements.
    Furthermore, I don’t belief that ASP.NET MVC is made as a replacement for ASP.NET Webforms. MVC was made as an alternative and as a Microsoft answer to frameworks like Rails, Grails, Django, Play etc.

    @Frank Silbermann
    I agree. About view logic: IMO tags like [c:if] are also logic. In Rails, special tags don’t even exist; in Rails you put view logic directly in the view using scriplets. So when I need view logic in the view, I just put it in the view, also in JSP. I only create custom tags when I need code reuse.
    Ofcourse, when I need data access logic, I use the controllers (and DAOs).
    I also agree that Wicket is great in view logic. In JSF there is a trend to use Facelets. In Facelets, scriptlets are banned, and the backing beans are very suited for view logic. That’s one of the things I hate about JSF, it feels too static. Wicket feels better.

  10. HEAVILY BASED ON SESSIONS

    This is theoretical bullshit. Why is it that everytime someone brings this up they never have any concrete numbers? I can play the same game.

    Memory:
    A Drupal instance I host on a VPS eats twice the RAM that an intranet Wicket app that is hosted on the same machine ever peaks, even though the Wicket app gets almost tripple the load. This just goes to show that you can write shitty code in any language or framework. Wicket only keeps one page in memory, the rest are swapped to disk. Even if you manage to completely screw up your code and all your pages end up taking 500KB each, how many users can you host concurrently on a 256MB heap? And before you answer “less then in a stateless framework”, think about what you are trading memory for, especially on a VPS; will your stateless MVC app become CPU-bound before it hits the same number of concurrent users.

    Clientside view state:
    This only seems good on a product comparison matrix. When every single click requires you to upload half a meg of data back to the server and redownload it in addition to the html no one will use your app anymore because it will be hopelessly slow. Not to mention all the CPU cycles you will spend decrypting and decoding the received state.

    HIGH LEARNING CURVE
    This is a highly subjective conjecture. I came from a Swing/SWT background and Wicket completely clicked while MVC frameworks made my eyes bleed. Sure, there is more to learn, but that is true because Wicket offers/does a lot more for you compared to its MVC predecessors.

    WICKET URLS
    And I suppose you prefer urls that are 2000 characters long better?

    As far as the redirects go, that “unwanted” redirect is called the “redirect after post” pattern, which is considered a Good Thing(tm). And, of course, you can easily turn it off by changing the default rendering strategy.

    HTML IS NOT THAT PURE
    When Wicket users talk about purity they are referring to the fact that markup does not contain logic.

    wicket:container is merely a shortcut for Component#setRenderBodyOnly(true), if you use that then you can have the two divs defined in markup but only one rendered at runtime. So, once again, you do not make a valid point.

    STATIC COMPONENT TREE
    This is a complete section is complete rubbish and shows you do not have even a moderate amount of experience with Wicket. Using any repeater and panels you can build a completely dynamic component hierarchy. There is the Wicket Web Beans project that demonstrates this by building forms dynamically based on your beans.

    You can argue that the atomic pieces inside the repeater, the panels, still contain predefined markup. This works fine for about 99.9% of the time, and for the very rare usecase it does not you can let your panel implement IMarkupResourceStreamProvider and write out its markup as a string that is pragmatically generated.

    But, this is just markup, the true power comes from the fact that you can, as you have briefly mentioned, swap any of these pieces dynamically at runtime. This is what truly makes the component hierarchy dynamic and makes Wicket so powerful. Show me another Java based component framework where you can swap components so freely?

    VERY VERBOSE
    LDMs are a lot more then packed calls to your daos, they are an indirection layer that leads to those calls. Once again, you miss the point.

    In real projects there are rarely anonymous LDMs, usually there is enough structure so that code looks like this:

    new UsersTable(“foo”, new QueryModel(new AllUsersQuery()));

    instead of

    new UsersTable(“foo”, new LoadableDetachableModel() { ….

    Anyways, the fact that you mention anonymous classes as being verbose only shows that you are not used to them, you are probably coming from an MVC background which means you have a lot of crap to unlearn.

    If you are going to bash something at least have the gull to mention that your opinions are highly subjective, unless you can bring some numbers to the table of course.

  11. Based on the title of the blog post I thought you were in it to slam Wicket. But I see it’s actually pretty fair “opinion” of Wicket, so good job.

    My only comment is the fact that Wicket lets you work with designers (the creative types that know photoshop/dreamweaver) throughout your development process and into maintenance. Try that would JSF, JSP, Grails, etc… If you do, you better hope your designer knows how to code and not be reliant on his design tools (ie. hack some html, load in a browser(s), tweak, repeat).

    I’d also add “makes AJAX dead simple”. You don’t have to touch JavaScript, the components take care of it.

  12. @”Anonymous Coward”
    Memory:
    Wicket creates session by default. When you have a high traffic site, than automatic session creation can increase memory usage a lot, even when you try to keep pages low in size. And on high traffic sites, you don’t want session to be swapped to disk, otherwise performance will suffer a lot.

    Stateless controller-to-view/action-based frameworks only keep user input data client sided (temporary send to server when sending a request), where a Wicket page keeps most/all data (not just user input, but also view objects/data etc) server sided, and thus uses more memory. Processing user input data send from a client hardly uses CPU more than a request send from a client to Wicket. Unless you’re talking about viewstate data.

    Clientside view state:
    Like I already said, both client-sided and server-sided state have drawbacks. If every single click sends half a meg of data back, than there clearly is something wrong with the design of the webapp; wrong design decisions have been made. But that doesn’t imply that client sided viewstate cannot have any advantages in some scenario’s. What I like to see is a framework that offers both.


    HIGH LEARNING CURVE:
    Like I said, I like component based frameworks. So I understand why you hate those other MVC frameworks. I also agree that Wicket offers more, and thus there is more to learn.
    But my point is that after I read the recommended Wicket book, I still didn’t have a clear picture in the way Wicket is architectured. This documentation aspect (and not just the API on it’s own) makes Wicket extra difficult.

    Wicket URLS:
    No, I don’t prefer 2000 char urls. What I do prefer, like I already said, are urls that don’t reveal any framework or technology. This makes the webapp more flexible to change from framework without loosing Search Engine indexed pages.
    I had some cases where some unwanted redirects occurred on first page hits, where the post-redirect-get pattern isn’t needed. But maybe I should change the rendering strategy like you say.

    HTML IS NOT THAT PURE:
    Good point. IMO setRenderBodyOnly than should be enabled by default when using repeaters. I’ll change the post.

    STATIC COMPONENT TREE
    “You can argue that the atomic pieces inside the repeater, the panels, still contain predefined markup.”

    That is exactly my point.
    I see these options to make a complete dynamic tree:
    -The combination of repeaters, panels in panels, and logic, and maybe fragments. When you create some generic panel that only contains either a repeater or a component, than you can create a tree which contains panels in repeaters in panels in repeaters in panels etc. But this is a hell to code, read and maintain.
    -Skip components/objects, and just write HTML directly. Which can be a lot easier than the first option, but it can also increases maintenance, and it skips the Wicket API.
    -Use IMarkupResourceStreamProvider to change the Markup stream. Which sounds difficult to me (I’m not a Wicket expert), and feels more like hacking it yourself to accomplish it.
    -Use some code written by someone else that supports it. Like Wicket Webbeans if you need to make HTML forms based on beans.

    So my conclusion now is, a complete dynamic tree structure is possible, but hard.

    “Show me another Java based component framework where you can swap components so freely?”

    Google Web Toolkit (GWT). In GWT it’s easy to create a complete full dynamic tree structure, because it doesn’t hav a dependency on predefined Markup. In GWT, you can do:
    VerticalPanel mainPanel = new VerticalPanel(); RootPanel.get(“…”).add(mainPanel); Button b = new Button(“….”); mainPanel.add(b);
    Without defining any HTML markup structure or placeholders upfront.
    (GWT has other big drawbacks, but that’s a different story.)

    VERY VERBOSE
    Can you show/point where I can find some more info about the QueryModel approach? (I’m not a Wicket expert. I use LoadableDetachableModel because it is the best approach that I see that is described in the book Wicket in Action.) Anyway, QueryModel itself is an extra layer if you follow the DAO pattern.

    It is a very commons practice to put all data access logic in DAOs, because of the Separation of Concerns principle. Putting any queries (like SQL, HQL or criteria API) in a Wicket WebPage subclass or Wicket component subclass violates the concept of using DAOs.

    If you follow the principle, then you need DAOs. Those DAOs need to be called via Wicket code. The data the DAOs return, cannot be used directly in Wicket components, because in Wicket that causes everything to be serialized, and causes sessions to be blown up. In Wicket, models are needed as an intermediate layer. This intermediate layer is extra verbosity, but needed due to the way Wicket is architectured. (There are also frameworks that don’t require such an extra layer.)

    —————————

    @Craig
    I have never worked with designers, but I’m wondering why a developer has to be directly involved in framework/Wicket mixed HTML markup. I would prefer to see it indirectly instead of directly, by letting the designer give you a 100% HTML/CSS (Without wicket ID’s and fragments), and that you (the developer) converts it to a Wicket mixed HTML markup. Than the designer doesn’t have a dependency on some particular framework markup. But I agree that if you let designers directly involve in framework mixed HTML markup, than Wicket is probably one of the most comfortable frameworks for designers.

    “Ajax dead simple”, is something I see as a benefit of most component frameworks. It’s one of the reasons why I like component based frameworks.

  13. >Some argue that memory is cheap.
    I can not believe that setting apart such giants as Google you may easily run out of memory in 2010. Except if you use it in some ridicules way, like keeping “state of HTML elements”.

    >Frank Silbermann says:
    >But what if I _want_ to use Java?
    According to what you wright what you want is 1:1 HybridJava.

  14. Regarding “HTML IS NOT THAT PURE”, add the following to your application#init and all wicket artifacts in the html disappear:

    getMarkupSettings().setStripWicketTags(true);

    IMHO this should have been the default.

  15. I see you was fair with your ideas and I agree just a little. Regarding “Session downsides” we all must know that everything can be changed. The “timeout” of sessions can be disabled (although generally not recommended) or changed. The “memory consumption” can be controlled in several ways, i.e. by using bookmarkable urls instead of session navigations. Which in turn can be used with restfull patterns. All this stuff is a matter of taste and requirements. About learning curve I agree with @kodeninja.

  16. I can fully agree on the “high learning curve” and the most of the rest. In fact I wrote a similar blog post here: http://www.grobmeier.de/apache-wicket-versus-apache-struts-2-04052011.html

    Wicket users usually say its easy and hey, its component oriented. But one can create good software even outside the Wicket world. You can even create components. In all the cases I had to work with Wicket, I needed HTML/CSS/JavaScript skills. And components… well, are there so much Components I actually reuse? I had not too much of them.

  17. Christian: “well, are there so much Components I actually reuse? I had not too much of them.”

    That probably reflects your style of program design. COBOL programmers also re-use code very rarely; their language makes doing so very difficult, and when COBOL programmers try more modern languages they often don’t appreciate what the newer modularization features can do for them.

    The trend in programming languages is to increase support for code re-use, going from macros in Assembler and include files in COBOL, to functions and procedures with local variables in Pascal and C, to abstract data types with local functions in Modula-2 and Ada, to object-oriented code with implementation inheritance in languages such as Java. Of course, making intelligent use of each innovation requires a new set of rules and heuristics for program design (loose coupling, high internal cohesion, the Liskov substitution principle, etc.).

    Most approaches to web programming make reuse of display code very difficult, so as with COBOL programmers, most web programmers don’t think to look for reuse opportunities. Likewise, just as all the variables in the typical COBOL program (in the WORKING STORAGE section of the DATA DIVISION) are global to all of the procedural code, in the typical web application all of a form’s data is in the HTTPRequest object — global to the entire front servlet. Re-use based on “include” files and template processing is like going back to the days of Assembler program macros again!

    A framework such as Wicket gives you much better opportunities for reuse of display code, information hiding, loose coupling, etc., but as with the COBOL programmer who learns Java, the developer still has to learn to make use of object orientation when coding the display. (Former fat-client Swing developers may have the advantage here.)

  18. I think controller-to-view is simpler to learn but when you have to develop complex stateful pages than you have to learn some javascript instead of starting crying “oh! my framework doesn’t code the javascript for me”. Grow up! Model-to-view frameworks are more popular because they are better, just it.

  19. Regarding the viewstate, there are indeed advantages to having it either client-side or server-side. JSF offers the user this choice, but unfortunately it’s a global setting in JSF. It would be even better if this could be chosen per view or for the true control freak even per fragment/component. (doesn’t the latest version of ASP.NET allows this?)

    One thing that does help with keeping the viewstate size down in JSF 2.0 is the so-called partial state saving. This only puts the delta changes in the viewstate, which can cause a massive reduction in size.

    Regarding the URLs, I noticed that some Wicket sites like ov-chipkaart.nl also put “wicket:interface” in the URL and multiple colons, e.g.

    https://www.ov-chipkaart.nl/?wicket:interface=:1:1:::

    This looks worse than http://example.com/product/abc/.1.2

    It seems to be a known problem: http://osdir.com/ml/users-wicket.apache.org/2011-05/msg00206.html

  20. Let’s the flame begin:
    It’s very funny to read all comments 🙂 The first thing that I can say about people who worship Wicket is they really do not know how to code HTML/JS – so, why are you trying to do things about you have no idea? Writing web apps is simply creating nothing more than HTML/CSS/JS – if you don’t know them, please start writing console/swing apps.
    You believe that session overhead isn’t thing that you should worry about? So write app, that gets hundred of tousands hits per day 🙂 I prefer to buy and keep my memory for cache, not for wicket developers :]
    And last thing: Rafael said that about non-wicketers “oh! my framework doesn’t code the javascript for me” – yeah, in my opinion this is how Wicket programmers behaves, others knows js and uses it in right way 😉

  21. I’ve used wicket in a proof of concept web app and the impression I got was (i) it complicated the familiar, tried and tested (standard) approach to web app development (html/css/js use is compromised) and (ii) I may be wrong, but I have this gut feeling that the idea of wicket abstracting views (markup) for designers to handle and the rest for developers to handle is not effective.

    On point (ii), a designer is creating a UX and having control of client-side technologies is part of their toolset. Giving a lot of this toolset to developers who are generally really poor at designing a good UX (look, usability, creativeness), is not great in my book. Designer versus Developer fights, I kind of feel you give the power in this fight to the developer with Wicket which is going to bad IMO.

    I agree with the view that if you are making web apps, you must know and use html, css, js and not wrap-up/produce this in “code behind” files. The wicket approach seems to buck the “standard” approach to web development, which will make introducing developer(s) to a project using this framework and expecting reasonable productivity unlikely. And, like most technologies, you get “rusty” when you don’t use it for a while. So swapping developers between projects that use “standard” approaches to web development versus wicket, you looking for lost productivity and probably a reluctance among developers to get into another project.

    Wicket is also

Leave a Reply

Your email address will not be published. Required fields are marked *