25

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.
MrSmith42
  • 9,961
  • 6
  • 38
  • 49
wassimans
  • 8,382
  • 10
  • 47
  • 58

4 Answers4

51

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.

DaGGeRRz
  • 1,611
  • 1
  • 12
  • 13
18

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.

David Winslow
  • 8,472
  • 1
  • 31
  • 27
  • 1
    Nice response. An MVC like Play will obviously be more familiar to users of other MVC's. Although I have to say that once you learn the Wicket way of life, you will never want to see an MVC again! The object-oriented, event-driven nature of Wicket, along with its built-in AJAX support, let's you do some really complex stuff that would be brutally messy and unmaintainable in an MVC. Internationalization is also great in Wicket and not using JSP's is also a plus. :) – spaaarky21 Dec 31 '11 at 21:17
7

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

smallufo
  • 11,516
  • 20
  • 73
  • 111
  • could you elaborate a bit more about cache's inconsistencies and how wicket handles them? I'd like to know how could play improve it's cache management. thanks. – opensas Aug 31 '11 at 12:15
  • Hi , you can refer to my slideshare : http://www.slideshare.net/smallufo/play-framework-for-javaee-developers . Starting from page 40 . – smallufo Sep 06 '11 at 13:43
  • excellent material, smallufo. btw, the approach on page 61 works ok??? there should be a setting in application.conf to achieve this... I had a similar problem and I handled it with my own cache system, adding "dependencies". I would make both cached items depend on "user", and everytime any user is modified (or added or deleted) I would invalidate every entry depending on user. Unfortunately, having such a dependency system is not so easy with ehcache. – opensas Sep 08 '11 at 11:44
  • Well , in fact , it works (in PROD mode) . BUT it's not practical. Because it will behave very strange in DEV mode. In dev mode , you will very often modify code and refresh browser. With Criteria.setCacheable(true) , you'll often get NPE after modifying code. IF you can make sure your code is perfect , do not need modifying/refreshing , you can try this way. Otherwise , please think it as fully stateless, useing scripting language's skills to face the cache's problem. – smallufo Sep 10 '11 at 19:42
3

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.

eriq
  • 1,524
  • 3
  • 13
  • 22
  • 1
    Famous last words! Akka also supports both Scala and Java API but believe me Java API is "the guest in the house", i.e. it is not that well supported as Scala one. Maybe Play! will love their Java users more ... – martin-g Jan 18 '12 at 14:28