What are the disadvantages of Apache Wicket?

Question

I've read a lot about the good things about Apache Wicket, but it's hard to find the bad things. Since no framework is always the right solution for every problem, what are the disadvantages of Wicket and in what type of projects you wouldn't use it?

Maybe not a popular question, but an important one I think.

Solution 1

Wicket demands some pretty solid coding practices. For example, if you store an IModel in your Component, but do not use it as the model of the component, it won't get detached automatically and can blow up your session size. This sort of management is not something most Java users are used to.

Wicket is active and frequently updated. This is good, but each time I update to a new version, I realize that I need to do a lot of refactoring to move to better coding practices (1.4 introduced generics, 1.4.x introduced onConfigure(), 1.5 has some different resource strategies). Again, all are good updates and pushing you toward better code, but I envy people coming to Wicket NOW instead of two years ago :)

Combining both above, I feel Wicket assumes some real programming skill once you get past the basic feature set. If you're a good developer, you will love what Wicket can do for you (and the code is pretty well documented in JavaDoc). If you're a beginner, you might get frustrated as you get deeper.

Also, while it "works" on Google App Engine, I found several issues that prevented it from working comfortably in that environment. That's for a different discussion.

My disclaimer is that I haven't used anything else, so perhaps other frameworks are worse.

Solution 2

In the real world, development speed is very slow with Wicket. If you do not have a pre-canned component to use like a factory worker on an assembly line than productivity grinds to a halt until you can make a new Panel. Code complexity increases and it is hard to read the code because you are effectively doubling the lines of code you have to write. You are constantly looking up how to do trivial things on the internet and in books. For example a simple reset button is one line of HTML but in Wicket it is requires Googling how to do this. It makes simple things hard and hard things impossible.

I have yet to see a really complicated UI built with Wicket. Only simple UIs composed of pre-canned components are possible with Wicket. Every UI I have seen built with Wicket could have had a cleaner code base if it was not done in Wicket and it would scale better by dropping Wicket. Wicket buys you nothing as nice UI widgets as well. Even the jQuery UI implementations of Wicket are inferior to just using jQuery UI directly.

After reading tens of thousands of lines of Wicket code at my work I can say that Wicket code is basically spaghetti code. If you like ulgy, inelegant, verbose, code with generics and anonymous inner classes all over the place than Wicket is your thing. The amount of line noise is very high. The code base becomes less maintainable because of this. This is especially true if you use the flawed Wicket AJAX implementation.

Solution 3

Several answer declare wicket to be unable to dynamically create a component tree. Seriously, I thing you guys are working with a different wicket there ;)

First of all: Wicket is component based, not a random HTML generator.

It's actually pretty darn easy to get a dynamic component tree:

Want to replace a component with another one? Use Component.replaceWith(Component) (Pretty useful in conjunction with an empty MarkupContainer)

Need a dynamically changing list of panels? Put them in a repeater.

Make a component disapear? Use Componente.setVisible()

And a ton more of ways of doing this.

So, those who think you can't do dynamic component trees, please provide some examples and I am happy to discuss on those.

(If you really need to be even more flexible you can make Wicket load markup from different sources. Something I NEVER did for sake of building dynamic trees but to be able to retrieve Markup from a database or via network)

Solution 4

I find wicket really useful, but these would be the disadvantages I've found so far:

• Sparse documentation: I have not yet found a definitive guide to wicket, even though there are great articles and a couple of books
• Wicket URLs are ugly by default
• You can't dynamically define component trees, as you have to define them both in the HTML layout and Java code

Solution 5

See my answer here:

https://stackoverflow.com/questions/5489712/why-would-someone-choose-wicket-over-struts-2-or-other-framework-or-viceversa/5491686#5491686

[EDIT] above question was deleted. Here is a quote of the answer:

First of all, Wicket is a lot more feature-rich than Struts. Of course you can graft a lot of other stuff on Struts, but the quality of these libraries is a bit hir and miss. Some people like this, others don't. Some prefer the modular approach, which is fair enough but I don't agree.

More importantly, Wicket templates are standard html files. Designers can edit them with whatever editing application they want, so long as it conforms to standards (specifically the part that says that any element or attribute not in the HTML namespace should be ignored but left untouched.)

The flow of control and data is a lot easier to follow. With Struts you often have to look at the jsp first, then a config file, then a tiles definitions file, then a Java file, optionally a taglib definition and then the taglib implementation class. And this is only to discover what a single page is exactly doing. With Wicket you just look at the Java file and that's it.

Which brings us to the next item: you don't need configuration files for wicket. Some say it's a drawback, because it's less flexible this way, but I'm a Java developer and I prefer Java code to bespoke XML formats.

And last but not least: Wicket offers you a higher level, thus more "natural" approach. This makes it easy to learn, and you get decent productivity while still maintaining good type safety and a lot of compile time checking. This is Wicket's biggest drawback too though: if yoy come from the Servlet/JSP/Struts direction, it takes a lot of unlearning to understand the way Wicket models things.

So these are the main differences between Struts and Wicket, and as you can see, it's not all black and white, it's more a matter of personal preferences. All I can say is you think about where you stand on these questions and if you're not absolutely opposed to the "Wicket way"", give it a try. There are really good online sample projects that show you the general features along with the source code.

Granted, I listed them as advantages, but it's easy to see why someone would feel the opposite.

While there's nothing you absolutely cannot do in Wicket, there are certain underlying concepts (I wouldn't call it a philosophy because I hate the overuse of this word) which you should follow. The further you stray from that concept, the harder it becomes to shoehorn it into Wicket.

View more solutions

Comments

[biziclop]

I found that Wicket in Action is as definitive as you need. What is it that you feel is missing from there? URL encoding strategies are so far the easiest solution I've seen to enforce sensible URL's across the board and of course you can define dynamic component trees by implementing your own components. Although you really shouldn't as there's no real need for them.

[martin-g]

AJAX calls are queued client-side by channel/queue name. I.e. you can make them asynchronous again by overriding AbstractAjaxBehavior#getChannelName().

[Costi Ciudatu]

+1 for the hint :). But that method is actually in the AbstractDefaultAjaxBehavior and it's completely undocumented.

[Costi Ciudatu]

I've been forced to use JSF once and hated it, I've always loved Spring MVC and I was very skeptical about Wicket at first. Now, wicket became the definite first choice for me as Java web framework, although I'm still a big Spring fan. So forget about any similarities between JSF and Wicket.

[Tom Anderson]

The THIS IS NOT PART OF THE PUBLIC API business is probably because they're splitting the code across multiple packages, and the only way for classes in different packages to talk to each other is through public methods, even though they are collaborators. It's a common problem in large projects. Really, this is down to the poverty of Java's access control mechanism. You're right that it's annoying, though.

[Costi Ciudatu]

Although this seems to be the obvious reason, it's not always the case: some methods are public although they are only used inside the class (see Component.markRendering(), for example), and it's not at all impossible to collocate closely coupled classes and/or make use of interfaces to expose only what needs to be seen by the client.

[tetsuo]

JSF != Wicket. Would you say that Spring MVC is the same as Struts 1, just because they are both action-based frameworks?

[tetsuo]

The documentation is not that great, but the books do fill that hole; URLs are ugly by default, but can be beautified very easily; You can dynamically define component trees, you just can't do it as ad hoc as you'd do in a JSP-like templating framework.

[digitaljoel]

Yep, I get where both of you are coming from, and that's why I started my post with "I've not used wicket" and was basing it on my only experience with a component based framework. Your point on Spring MVC vs. Struts 1 is very valid, and now that you say that, I have played with Struts 1 many years ago and it was a horrible, action-based experience.

[greenoldman]

What framework do you recommend then?

[HaMMeReD]

I think you might be shortsights on this. "I have yet to see a really complicated UI built in wicket" You do know the UI is typically HTML and Javascript. You could just have wicket populate that in various ways. I'm still a beginner to wicket, but your attitude towards this is that of a stubborn person making excuses. Spaghetti code? Not in the open source project, it seems to be very well structured and highly decoupled, well documented toolkit. If anyone is making the spaghetti code, it's you.

[user373201]

why not, he is clearing stating that there isn't much online help. That to me is a disadvantage and def a answer related to the question

[Volksman]

@Martin - really? I found wicket's terseness of coding to be it's biggest benefits. Sure if you're stuck in a JSP world where you like embedding Java code inside presentation layer artifacts you probably won't like Wicket and won't be understand why others do.

[Martin Wickman]

@Volksman I was comparing with modern approaches (REST + web client) where the separation of server and client exists for real.

[Rob Audenaerde]

I use wicket a lot, and we are building more complex UI with it. with complex I mean that we do drag and drop outside components, have rich interface elements like infinite lazy scrolling lists, SVG graphs and such. The learning curve for Wicket is rather steep, for this kind of stuff you need to know how it works inside too. I find Wicket very elegant, and the component tree, combined with the events and how Wicket encapsulates Ajax (currently based on the very popular jQuery framework), make it a very powerful tool to build complex UIs.

[Volksman]

The repeating complaint about Wicket seems to be "you need to be a strong/competent Java programmer". If your Java shop is hiring people who aren't that then you probably need to find another job ;). Wicket is unashamedly object oriented, typesafe and extremely powerful and, most of all, mega productive in the right hands. It's not designed for people who have realized PHP isn't quite cutting it for their enterprise apps and have learnt Java on the weekend and then want to start writing enterprise apps on Monday.

[Gonzalo Aguilar Delgado]

I agree that doing dynamically component tree can be done very well but's a lot trickier than with other frameworks. Keeping the id of the component different and addressable can make your design a mess if not done correctly. But for all other tasks wicket is really great. Specially when you have a good codebase of components.

[MichaelM]

This is completely false. I feel like this is based on either lack of understanding of code or framework. I fail to see how you get two times the code, two times compared to what? That's a blanket statement. Java is designed so the user can do whatever they want with the code, and not be stuck with bucket functions or methods, it's more flexible and using Wicket if used properly drastically reduces development time and LOC. The only time see issues with this is when I come across code tat someone wrote and didnt have must real world experience.

[Martijn Dashorst]

Wicket has since a couple of years an awesome, comprehensive user guide online without having to pay anything, maintained for all recent versions: wicket.apache.org/learn/#guide

[Martijn Dashorst]

Wicket has since a couple of years an awesome, comprehensive user guide online without having to pay anything, maintained for all recent versions: wicket.apache.org/learn/#guide

[Kristof Jozsa]

I have a completely opposite experience. We have built sites with Wicket as complex as a public netbank for a major bank with Wicket and our frontend code remained clean, readable and refactorable. In fact, complexity did not increase at all with additional pages and components as we went ahead.. loved that.

[John John Pichler]

I am really impressed with Wicket simplicity. @jbrookover could you explain better this IModel problem? Is there any article I can read?

[Quazi Irfan]

The link doesn't work.

[Clomez]

@Volksman times change, but it seems that now these 'java-shops' using wickets are unable to hire anyone born after start of 90's for anything less than senior price, we've been looking for anyone to do wicket, and every single jr web dev / or even full stack dev with +5y exp is not able to deal with this stuff effectively... very well played.. very good system.. just forget anyone with less than 7y of experience and payable salary.

[Volksman]

@Clomez I've contracted to non Wicket shops that use the "latest and greatest" JS UI frameworks and, trust me, with the burden they have with being two language "solutions" (duplicate all models: once in Java, once in JS and then get them talking to each other - all that effort completely unnecessary in Wicket) you could hire 4 "cheap" developers in that world and they still won't be as productive as a competent (doesn't necessarily mean 7+ years - just needs to be intelligent and have a good technical aptitude - not bad qualities for a dev BTW) Wicket dev at half the cost of 4x JS devs.

[Volksman]

"I have yet to see a really complicated UI built with Wicket": Evidently our experiences differ greatly. I've seen some incredibly powerful AJAX powered web apps written in Wicket and built many myself. The "onedev" open source git server management web UI is written entirely in Wicket with dashboards, interactive drop downs all over the place, etc., - quite an eye opener as to what is possible in Wicket and brings into question why you would bother building web apps in a JS framework and end up building a dual language, less productive "solution": onedev.io/projects/onedev-server/blob

[Rob Audenaerde]

@QuaziIrfan the original question was deleted.