Play and Wicket are both frameworks with a solid design and a great, active and responsive community. I used Wicket in a medium-sized project and whenever I asked a question on the Wicket mailing list, I got almost instant feedback.
One of the main differences between the two frameworks is the way they handle state: Wicket stores state on the server while Play follows the REST "state-less" principle very closely, favouring state on the client (or in the URL).
Consider for example a simple AJAX counter:
- In a typical Wicket implementation (see the Wicket Ajax Counter example), you would store the counter on the server (in a
Model[Integer]
). When you click the link, an AJAX call is made to the server, where the model is updated (i.e., the counter incremented) and the HTML markup for the updated counter sent back and displayed.
- A Play implementation would most likely store the counter on the client's web page and use something like jQuery to update the counter.
Storing state on the server has its advantages (e.g., easy of use for the programmer) and disadvantages (state loss on session timeout) so depending on your business requirements, one framework may be more suitable than the other.