GWT vs Apache Wicket

A

6

12

Both GWT and Wicket are stateful, java object oriented based. GWT is completely client based with features like javascript optimization, CSS optimization, and I'm pretty new to Apache Wicket.

The more I read about Wicket the more similar it feels to GWT.

So I guess the question is - What are the differences between GWT and Wicket? Or am I comparing apples to oranges?

Acanthaceous answered 4/1, 2011 at 22:27 Comment(1)

duplicate: https://mcmap.net/q/909708/-wicket-vs-gwt-advice-needed – Murrah 5/1, 2011 at 12:55

I

9

It is pretty much apples to oranges.

This wiki entry summarizes some of the similarities and differences, and the start of a strategy for using them together, which I think is an interesting idea.

Wicket is primarily a server-side technology with some built-in Ajax support and hooks for wiring in more Ajax. It does not translate Java to JavaScript like GWT. It maintains state server-side where GWT maintains state on the client.

Both are component-based and to me have something of the feeling of Swing development (though Wicket doesn't seem to feel like Swing to at least one other respondent).

Indorse answered 4/1, 2011 at 22:59 Comment(0)

H

27

I have been using both GWT (1.x and 2.x) and Wicket (1.4, 1.5) on a large project for several years now, and both frameworks have their advantages and drawbacks. Both of them are cool and nice, if they are used for what they have been designed for. But you can take the best of both by mixing them together easily.

Wicket is really nice and powerful for CRUD websites, with a good separation between the page design (HTML) and the Java code. As long as you do not need powerful client capabilities it's doing it's job very nicely, at the prize of being a bit code-verbose: but that's the prize to pay to be strongly typed: there's no "magic"; refactoring and componentization works like a charm. For large projects it can be easily decoupled and is well designed to work with large teams: people can focus on providing a nice set of core components, other on the presentation layer, etc... The only drawback is for complex behavior on client side, you still need to master Javascript and it can easily become rather complex to mix Wicket and Javascript yourself.
GWT is nice when you really need rich behavior capabilities on your client (GMail-like application). The main problem with GWT is that it look too nice on paper (the "everything in java" paradigm), but it does not fulfill it's promises. It does not scale well: GWT is nice for small modules providing a small set of functionalities, not for large applications. Code/compile/debug cycle is rather long, and when module size grows too large it becomes a burden. Also it does not support well large teams working concurrently on the same module.

To summarize, I would suggest people having to choose:

Use GWT sparingly when it's really needed, keeping module size small, and never try to build a whole big application entirely with it;
Use wicket for the rest (Wicket really rocks!).
To mix both together, use the powerful component capabilities of Wicket to modularize GWT code in a "wicket way" (GWT modules becoming a special kind of Wicket components), and again, keep GWT small.

Hush answered 16/3, 2012 at 14:2 Comment(4)

Sorry but I completely disagree about the stance of it does not scale well. We had a very large application and had not problems with scaling, over 1200 dynamic pages. We used the MVP pattern and used GWT.runAsync for speedy loading. I have used wicket also and it seems like more of a cobbled together framework than GWT. Things like getModel and getOriginalModel are annoying coupled with the inability to simply work with the DOM is what really turned me off about Wicket. IMHO Vaadin would be a better choice than Wicket since 7.0 gives the best of both worlds but I will stick with GWT. – Schwing 20/9, 2013 at 15:25

What I'm saying is that a GWT module does not scale well. By itself, GWT can scale by multiplying module count, if you keep module size constrained. But I confirm that having GWT module size growing too large is really painful for both technical and human reasons. Btw I do not see what is Wicket getOriginalModel()? – Esparto 23/9, 2013 at 10:47

Why is module size painful? Super Dev Mode eliminates having to compile everything during development, and even the older dev mode was great for that. If module size is painful for download times, there are plenty of options to reduce the download size. If GWT is good for the mobile GMAIL app (Android and iOS), I think we can conclude that it can handle large complex applications on its own. How Google Does Multi-Platform In Inbox – Symptom 10/4, 2015 at 20:47

It really depends on where you put the "large application" threshold. I would not call Gmail a "large" application; I'm talking about really big applications that can have dozen or hundreds of different pages, with lots of custom widgets, graphs, etc... The Gmail interface is, altough well designed, rather small and simple. As for the new Super Dev Mode, it may indeed have improved the performances. My post was relevant for the old dev mode. – Esparto 12/4, 2015 at 11:7

I

9

It is pretty much apples to oranges.

This wiki entry summarizes some of the similarities and differences, and the start of a strategy for using them together, which I think is an interesting idea.

Wicket is primarily a server-side technology with some built-in Ajax support and hooks for wiring in more Ajax. It does not translate Java to JavaScript like GWT. It maintains state server-side where GWT maintains state on the client.

Both are component-based and to me have something of the feeling of Swing development (though Wicket doesn't seem to feel like Swing to at least one other respondent).

Indorse answered 4/1, 2011 at 22:59 Comment(0)

J

2

Now with GWT 2, what are the advantages over wicket and likewise?

Jerkin answered 6/1, 2011 at 23:40 Comment(0)

P

1

It's been 6 years since this thread was active and GWT has mostly stagnated. Wicket seems to be much more actively developed and supported. Anyone have newer opinions about Wicket or other options?

Plight answered 13/10, 2017 at 18:43 Comment(0)

S

0

Wicket is server based framework.. It is much more similar to JSf than GWT. GWT is conceptually similar to Swing, I am ex-swing developer, it is very easy to migrate from swing to gwt. But I cant say same things for Wicket or JSF..

Schliemann answered 4/1, 2011 at 22:44 Comment(0)

G

0

Wicket is server framework. It allow to create html which you needed. It is possible separation of roles in project. (Web design->html/css->java).

If you consider to use GWT for you project, web designer probably not needed.
GWT generate javascript. Most logic can be executed on browser side. GWT better for scalable application.

Gheber answered 12/12, 2017 at 10:22 Comment(3)

Hi, why 'GWT better for scalable application'? – Promiscuous 12/12, 2017 at 12:0

With GWT is easy to move logic to browser . This require more computing power for client , but less computing power for server. With GWT possible to cache static js files. – Gheber 19/12, 2017 at 22:58

In certain cases, it is possible to create application completely from static js files. The best condition for scaling. – Gheber 19/12, 2017 at 23:6

Recommended topics

Hot tags