Wicket或Playframework？

Question

I'm totally new to Java web development and I would like to choose a good Java web framework to learn. I've found some really good echoes regarding the Apache Wicket framework and the Playframework . I decided to go for one of 'em; but I need to choose ;-)

So, what to choose and why?

EDIT

My requirements:

• I had a good experience developing with Django, so a similar framework would be great,
• I need a framework that can interact with other mainstream Java goodies (libraries, tools ..etc) so I can take advantage of what Java does really offer.

Answer 1

Wicket and Play are two very different types of frameworks.

Play is a MVC framework which you probably will feel familiar with coming from Django. Like Django, it offers more than just the web bits and provides a JPA based ORM framework, scaffolding tools and probably a lot more (I have no practical experience with it). They have a great tutorial on their site, and you'll probably see the Django similarities there.

Wicket is a component oriented framework (like JSF and Tapestry) and focuses heavily on object oriented design. It's also MVC, per se, but pages are usually built by composing self-contained and reusable components (View and Controller, pluggable Models). These components can be extended by standard inheritance and composition and markup is very cleanly separated from code and easily modified.

Wicket can manage event callbacks and state automatically, so that you don't have to think urls at all, no matter how complex your page is. A quick example for a clickable button that goes a away when it's clicked (very useful):

  // In a page constructor
  add(new Link("link") {
        public void onClick() {
          setVisible(false);
        }
    });

I want to emphasize that you don't have to use server-side state, and that it's quite possible to use Wicket as a "normal" MVC framework if you want to (and yes, it's easy to get pretty urls).

The Wicket project focuses only on the core web framework and there are no extra "niceties" such as special ORM support or scaffolding. I personally agree with the Wicket project's philosophy here, but for new developers coming to the framework, doing "simple" stuff such as a sortable and pageable table can be a bit daunting as pre-built components are a bit scarce. The learning and productivity curve for Wicket can be a bit steep, but the upside is that once you've made components (and "behaviours" - longer story) that fit your needs, they are extremely reusable.

Although I personally love Wicket, I have a hunch that you probably will be best off with Play. Your question indicates that you want a "Django" with access to Java libs, and in that case I think Play (or some other Java MVC) is the safe choice. On the other hand, maybe you've been using Django because you didn't know how incredibly powerful Wicket is. ;) If you give some more info on your project, we'll be able to give a more qualified response.

As a side-node: As Play is not very mainstream (at least for now), I'd also consider Grails which has strong commercial backing and even more out-of-the-box modules.

Answer 2

Play! is designed to be comfortable for developers coming from scripting languages like Python and PHP. It provides its own build system and management scripts, somewhat like Rails or Django would. Existing build tools and infrastructure (like the Maven repositories commonly used for dependency management in Java-land) will not integrate well with Play.

Wicket will be more comfortable for developers coming from desktop development in Java. It doesn't provide special tooling, so it will be easier to integrate into a specific build tool if you have a preference (and there are many build tools providing things like automated dependency retrieval available in the Java ecosystem.)

So there's quite some difference between the two options :) If you can figure out which experience would benefit you most, the decision should be pretty clear from there.

Answer 3

If your system is only for Web tier , Play! framework is very suitable. But , if your data models are not just for web , maybe exported as REST by Spring with CXF , and consumed by GWT or other web services , and you want to make sure the consistent states with web tier , Wicket (with Spring/hibernate) is a good choice.

Something I don't feel so good about Play! is the caching mechanism. You have to manually naming/insert/retrieve/invalidate/purge cache . This will make the whole architecture error-prone. While wicket with spring/JPA(hibernate)/ehcache(or other providers) , you can define consistent caching/dao layer for upper layer (web/REST...) , which will not impose state inconsistencies.

Another advantage with wicket is it has built-in AJAX support backed by Java . Although these AJAX's states are maintained in the server side (and maybe a little sluggish) , if you don't want to learn JavaScript , you can still build a 'not-so-bad' AJAX page .

With Play! , If you don't know about JS , and don't want to learn it , don't want to manipulate cumbersome DOMs , you can only build an 'average' site. OTOH , if you are skilled with JS / jQuery , you can choose Play! .

Answer 4

I'm using PLay! a lot and have used Wicket for a bit of evaluation. My experience is, that you have to write a lot more code to get the same work done with Wicket. You have more "indirection" with Wicket. I personally prefer code that has as little as possible "ceremony" and that is easy to follow.

The Play! architects are also adding Scala support to Play!, which I think is a great idea, since Scala is fully interoperable with Java code and libraries but by far more advanced then Java.