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

Question

Apart from the argument of Wicket's simplicity (that is, Wicket is a simpler system IMHO) and GWT's responsiveness in the client (GWT's client side state and JavaScript - potentially complex client side code) and GWT's greater potential for scaling, what is the argument for using GWT over Wicket?

Personally I've done a lot of Wicket development, but have only had a quick look at GWT a long time ago.

Tatum

Answer 1

The advantages are, basically, that GWT is a tool to build javascript-based client, thus, it's best suited if you want a javascript-based client.

Wicket centers on the server, and while it makes it quite easy to embed javascript into stateless pages, server-side state handling is the more natural approach.

One must note that the architectures are very different.

With GWT, your architecture turns into client-server, a thick client on the browser, making calls to 'procedures' (services) to the server, sending and receiving data.

With Wicket (and other server-side-centric component frameworks, like JSF and Tapestry), the architecture is a more 'traditional' 3-layer one, and what is sent and received are pages or fragments of the pages, not pure data.

While you can certainly blend both to adapt to the other architecture, it simply wouldn't be very natural.

People tend to focus on 'which is easier to use' (which is completely subjective, depending on your background), or 'which is more beautiful and has more components', but one should not underestimate the architectural difference, which affects the approach you have to take to handle aspects like security and scalability.

Sarraute

I think one common problem is that people do take scalability into account, but overestimate their requirements of the web tier, and overlook the security aspects of it. My experience at least. – Basseterre

I agree, most people just don't know how to handle security, and believe it will magically 'happen' with some configuration somewhere. About scalability, I think both technologies will handle 'non-facebook' scalability equally well, but the approaches will be different. And using the wrong approach will result in equally ugly issues. – Sarraute

It's funny how the definition of "traditional" has changed over time. Years ago it would mean a client-server (thick client) approach. Before that it was a dumb-terminal-and-server (thin client) one. Now that we're back to thick clients with JavaScript, I wonder what the next thin client architecture will look like. – Centrosphere

Answer 2

I've been involved in a GWT based project for the past few months. I was, having been part of the Wicket development team for years, looking forward to a change, and expected a lot from GWT (which I've always touted as another great Java framework).

Honestly, I am disappointed when it comes to working with GWT. I feel - my whole team in fact - that productivity took a big hit. Theoretically GWT is great. But when you factor in the quirks and limitations of the framework, mediocre error reporting (particularly when it comes to serialization errors), the long compile times (anywhere between 3 - 10 minutes, and our project isn't even that big yet), the fact that when all is said and done, you still need to test for all browsers and find tweaks and workarounds, the fact that it produces a huge initial download (almost an MB, which we're cutting back gradually, but with a lot of effort), etc, etc, I feel Wicket is much easier and quicker to work with.

I don't hate working with GWT. It's still a lot better than most Java frameworks. It's just that I expected a lot more from working with it; I even expected it to be possibly nicer than Wicket. But in the end, it is just not imho. Hopefully GWT 2.0 will improve a lot of things, and hopefully some of the quirks of the Eclipse plugin will be straightened out soon too.

Basseterre

Having had some (mostly indirect) experience with GWT 2.0 and UiBinder, I can confirm that things got better. I still feel like you need a lot of plumbing code to get things done that aren't hard to do using straight up JavaScript. – Basseterre

Answer 3

It's somewhat not fair to compare GWT with wicket (or likewise) since they are really coming from 2 different camps. The former is a framework for building JavaScript front-end applications while the latter is a classic Java web application framework.

So the points below are not as much as GWT vs. wicket but rather general list that was compiled when we decided to use GWT for advanced JavaScript/AJAX web application:

• hides drawbacks of JavaScript and cross-browser support by allowing to develop in Java and compiling to browser-specific flavor of JavaScript automatically (this is not completely true due to The Law of Leaky Abstractions but it's a major reason why GWT was created in first place - see Reveling in Constraints);
• Java is preferred by many Java developers when it gets down to advanced JavaScript/AJAX UI;
• Java development environment and tools are fully supported: Eclipse plugin, debugger, refactoring, hosted mode in Eclipse;
• JUnit tests are supported both with mock objects and in hosted mode;
• Clean integration with Java back-end (GWT-RPC);
• Relatively rich set of UI widgets with uniform look and feel;
• Availability of third-party widgets, frameworks, patterns, and examples (still limited and with a long wish list);
• Google support drives both wider acceptance/popularity and rapid advancement of the framework;
• maturing framework with 1.6+ and forthcoming 2.0 releases: (eventbus, event handlers, GUI architecture with MVP pattern, compiler optimization, etc.).

Ardussi

Answer 4

One advantage of Wicket over GWT would be that Wicket can handle the case where you want to provide a fallback for clients who don't have Javascript enabled. GWT is whole-hog for Javascript, Wicket allows you to gracefully degrade.

Association

Answer 5

In my opinion the biggest benefit of GWT is allowing you to work with one programming language - Java, with all the goodness that it brings.

Together with CSS, they form a powerful pair.

---

To put it another way, you can mostly forget Javascript and HTML.

Whether that's an advantage or not mostly depends on your skills and requirements. We've had this same debate internally and in the end one team chose Wicket and another GWT.

Grenada

You could make almost the exact same argument for coding in Wicket..? – Flores

No, you could not. Can you write rich client-sided apps in Wicket without Javascript? – Grenada

No - groups.google.com/group/google-appengine/msg/fe9792729081fc6d. ATM GWT compiles straight from the Java source, not from the byte code. So the compiler would have to extended to recognise the Scala syntax. – Tatum

Answer 6

I can think of several reasons why GWT is a better choice than Wicket, for typical business web apps:

1. GWT is from Google. This may be unfair, but having a big and respected software company behind a tool is a huge advantage (safer to bet on it, more books and online resources, more third-party support, better IDE support, ...).
2. Server-centric web frameworks like Wicket are outdated. Modern web browsers are very powerful and getting ever more so, therefore a modern web framework should help you take advantage of that.
3. Coding directly in HTML and Javascript can never be as productive as coding in Java (from my experience, at least). Also, there are better tools for Java code (debuggers, static analysis, unit testing and code coverage, etc.).

Goatsucker

I don't agree with GWT the 'huge' advantage. There are plenty of large companies who put out crappy frameworks (like was the case with JSF for instance). Granted, Google in general contributes nice frameworks, but the end of the day, it is more important who actually worked on it rather than the company they worked for. – Basseterre

In fact, when reading your other two points, I suspect you don't know much about Wicket and what it aims for. – Basseterre

"Server-centric web frameworks like Wicket are outdated." Have you ever tried to build a RESTful webapplication with HTML 4 and JavaScript (written with GWT or not)? HTML 5 will change some things that will make it easier (or possible in some cases). Wicket saves you a lot of headaches here. – Engels

"GWT is from Google. This may be unfair, but having a big and respected software company behind a tool is a huge advantage". I don't get this point? Wicket is from Apache, you know, the people that gave us Apache HTTP server, propaply the most used web server out there? Not to mention some other products like Tomcat, Ant, Maven, log4j, Apache Commons, just to name a few. – Cincinnati

Why are server side frameworks outdated? Can you back that statement up in any way? – Nathalienathan

Because the server-side frameworks were not designed with the modern web browser platform in mind. They assume that most UI code runs in the server, not in browser. This made sense in the past, since the JavaScript and HTML engines in browsers were much more limited and slower than they are today, not to mention the compatibility issues that are now mostly solved. My point is that in a modern web app, all the UI code can and should run in the browser, not the server. – Grane

Answer 7

The genius behind GWT is that you work solely with java. They did a great job with RPC making it almost transparent to the programmer. A lot of times you feel you're coding more like a desktop app instead of an application with a truly defined client and server side.

Consuela

This is very similar to the goals of wicket. – Arabela

Yes that's exactly how it feels when writing apps with Wicket - all the familiarity and ease of writing a desktop app. The benefit of Wicket over GWT IMHO is that, like in the desktop development world, binding the UI to domain model objects in Wicket is achieved by standard method calls and object references. In GWT when binding your UI to your domain model objects you have to get in bed with a very strange bed partner: 'object marshalling' - which is ok if you like doing things the hard way. – Fredrika

Answer 8

There are few other advantages of wicket over GWT that I find.

1. GWT will not work with a browser where javascript has been disabled . (this is rare though). Wicket always falls back to normal http requests if javascript is not available.
2. GWT applications are one page application this makes bookmarking and using browser tabs abit hard. With wicket you choose to create one page application or multiple page applications. You can make the pages bookmarkable if you wish.
3. In GWT, creating your own components is not always easy. In wicket, since you are working with raw html, css and even javascript making custom components is very flexible. You can even wrap an existing jquery or dojo component very easily.
4. Since GWT involves compiling java to javascript, you can only use the java classes that have been emulated by the GWT Compiler. This can be limiting. Wicket is a server side framework and you can use all the java you want.
5. Working with CSS and web designers is much easier with wicket that GWT.

Dichasium

Wicket doesn't always fall back to normal HTTP is Javascript is unavailable. Only components designed to fallback do. – Nathalienathan

Answer 9

I am newbie to GWT, but after some study I have found GWT is 'suitable' for my new project of web application for its client-focus that make me feel like coding a desktop application. Today we have high-performance client ready to run application at client side. My application can be done solely in Java, and OOP java class give a chance to build our own ready-to-use framework for our team.

Coterie