Wicket and GWT compared with code
September 4, 2008 94 Comments
I have been using Wicket for a while now and I’ve occasionally wondered if GWT provides any kind of advantage over Wicket. Recently I got a chance to do a comparison and instead of coding a simple “Hello World” kind of example, I decided to try something a little more complex. Hopefully this brings out the differences between Wicket and GWT more clearly.
Functionality
The target functionality is a one-page application that shows data in a single table. Item counts are displayed categorized under multiple “spaces” (workspaces). There is a summary row. The user can click on a space to expand the count of items grouped by status. The screenshots below show how the table looks when fully collapsed and then when one or more spaces are expanded.
It may look simple, but some of the tricky parts are:
- The number and names of the possible status types can be different for different spaces. For example, the first space above has 3 status types and the second 2. This means that we can’t use different columns to group this data. Multiple rows are used instead to display the break-up when expanded.
- Some of the table cells have to be merged to represent the grouping by space and then by status. In HTML terms, this requires some careful control of TD “colspan” and “rowspan” attributes.
- In addition to the cell merging described above, the style / color of the different cells has to be controlled to differentiate the total count from that grouped by status. For example, the grand total on the last row is in bold. In HTML terms, this requires control over the CSS “class” attribute, coordinated with a style-sheet.
First, let us look at the Java code common to the GWT and Wicket implementations.
The “Space” Domain Object
The class above represents a “space” and it internally uses a Map to hold status names and corresponding counts. There is a method that calculates the total count, a getter for the space name and list of states, and helper methods to add and get status data.
DashrService.java
As the functionality is kind of a ‘dashboard’ view – and inspired by the “Cheesr” example that the Wicket In Action book uses, I decided to call this application “Dashr”. “DashrService.java” is a singleton that returns a list of spaces with dummy data. The relevant code is shown below:
So on to the comparison then. In the side-by-side layouts below, GWT is on the left and Wicket is on the right.
Project Structure
Although it is not really a domain class, “DashrService.java” has been kept in the “domain” package along with “Space.java” to keep things simple.
On the GWT side, the recommended package structure and naming conventions (“client”, “public”, etc.) are being used. Our example is a pure client-side application and server-side communication or RPC is not being used at all. All the client-side code and behavior is in “DashrEntryPoint.java” itself. “Dashr.html” simply serves as a placeholder for the rendered application.
It may first appear that Wicket requires more files than GWT but one difference is that the GWT code is not communicating with any server-side functionality at all. Wicket would feel more natural to Java web-app developers familiar with web.xml and the like, and integrating additional server side code or frameworks such as Spring or Hibernate would be much more straightforward.
Another thing is that the Wicket application has been modularized into multiple Java components and corresponding HTML files. It was not really possible to do something similar for the GWT application which has all the UI code in a single file. The reasons for this difference will become clear when we look at the code in detail.
Framework Configuration
GWT needs to be told where to find the Java classes that have to be converted into JavaScript. If this path is not explicitly set using an XML element called “source” it defaults to “client” – which is the GWT recommended convention. Our main module config file “Dashr.gwt.xml” does not have the source path declared. So this means that all the Java code in the directory “dashr/gwt/client” (and any sub-directories) will be processed by the GWT Java to JavaScript compiler.
Since “Space.java” and “DashrService.java” are dependencies for our GWT based UI code, we need to ensure that they are included in the Java to JavaScript conversion as well. So in addition to the “User” core framework module that all GWT apps must inherit, we have a reference to a custom module – “dashr.domain.DashrDomain”. “DashrDomain.gwt.xml” declares the source path to be an empty string which in relative-path terms works out to be the same folder the XML file is in – and this is how the “dashr/domain” directory is included for our example. Those who intend to use GWT to connect to server-side Java code would need to do something like this – i.e. include all dependencies needed by UI code, typically domain objects that happen to already exist – like in our example.
The UI class that acts as the “entry point” has to be configured for a GWT application. In our example we have only one UI class and this itself will be the entry point.
One more thing the main GWT config does is declare “Dashr.css” as the CSS file for our application. A GWT convention-over-configuration rule applies here as well which is that resources like CSS files and images are looked for in the “public” folder relative to the XML file by default.
For Wicket, there is no XML configuration but an “application” class that can hold configuration in Java code. The web.xml file is not really Wicket configuration but it is shown above for completeness and it names the Wicket “application” class used by the framework servlet / filter. In our example, “DashrApplication.java” is just pointing to the designated “home page”. Our home page is “DashrPage.java” for which the HTML markup is in “DashrPage.html”. The Wicket “home page” can be considered equivalent to the GWT “entry point”.
UI Implementation
Because of the differences between GWT and Wicket – the code below does not really line up side by side. To make it easier to see how the code compares – some key sections from the GWT side have been mapped to the Wicket side using blue arrows. I have not mapped every possible thing because then the picture would be out of control! You can click on the picture to view a bigger version
Observations:
- Wicket gives you complete control over the HTML. To render a table we use a “ListView” repeater control [DashrPage.java:18] which manipulates a <TR> section. In the case of GWT however, we have to use an abstraction over an HTML table either HTMLTable or FlexTable. Since we require control over the table “colspan” and “rowspan” attributes, we have to use the GWT “FlexTable” as the basic “HTMLTable” does not support this. What I experienced is that having to use the GWT API to output HTML limits you in certain ways, for example on the Wicket side I was able to freely include <TH> cells with <TD> cells but within the GWT table I could not mix <TH> cells. This may explain why the GWT “Dashr.css” file has an extra CSS class called “header” defined to compensate.
- Using Wicket’s built-in Ajax support, getting the expand / collapse functionality to work was very easy. It was a simple matter of replacing one (or more) rows of the HTML table over Ajax [RowCollapsedPanel.java:19, RowExpandedPanel:29]. Trying to do the same thing using GWT turned out to be quite a puzzle-solving exercise. To dynamically add or remove rows on a GWT table you have to know the row index and in our case the number of rows in the table changes dynamically. I ended up using a HashMap [DashrEntryPoint.java:21] to track the table row for each Space. This explains the mysterious code you see at lines 98 and 124 in DashrEntryPoint.java to update the Map when the table is changed.
- To dynamically set the contents of a table cell in GWT, you have to explicitly get a reference to the cell using the row-index and column-index. But in Wicket it is very easy to add or replace text as long as you know the wicket:id of the HTML element and it works fine for <TD> as well.
- One of the biggest problems I found with GWT is the poor separation of concerns. You can see a lot of code in DashrEntryPoint.java doing CSS styling on the HTML table and cells, for e.g. the calls to getRowFormatter() and getCellFormatter(). GWT does allow you to use a standard CSS file but you have to programmatically set the styles on your widgets in Java code. You can see for example how lines 42-43 in DashrEntryPoint.java map cleanly to markup and code on the Wicket side. The Wicket implementation does not have any CSS mixed in the Java code at all – it is all in the HTML where it belongs, and where web-designers can work freely. Most GWT widgets make use of pre-defined CSS names so this may not be a big problem for simple applications, but the web-designer would still need to know which CSS class names to use.
- This example only has a single widget on one page, but when you place multiple widgets on a screen, you have to think in terms of layout managers just like Swing. I have not gone into what GWT provides in detail but it looks suspiciously like the days of struggling with GridBagLayout :) I prefer the much simpler and effective Wicket approach of managing layout using standard HTML and I personally feel that web-designers need to be able to work directly with the HTML (and CSS) and have better control over things like cross-browser rendering quirks.
- On the GWT side Dashr.html is just a placeholder for all the JavaScript stuff that will happen at run-time. So when testing or debugging, if you do “view source” you see nothing, just the skeletal Dashr.html! This was a real pain when I was trying to tweak things like the CSS styling by trial and error. Especially when you are using hosted mode you can say goodbye to things like the web developer FireFox extension. When it comes to Wicket, you are dealing with a “normal” web-app and being able to look at the rendered HTML or DOM at any time is something you take for granted.
- One of Wicket’s strong points is that you can take chunks of HTML and model them as reusable panels. This makes the code modular and easier to read and it is obvious what the intent of “RowCollapsedPanel” and “RowExpandedPanel” is. Maybe with some more thinking and effort on the GWT side I could have had the inner classes ExpandClickListener and CollapseClickListener in separate files. But the code in the “onClick” event handlers is tightly coupled to the “table” and “spaceRowMap” properties of the enclosing class. I considered passing these as parameters in the constructor but decided it wasn’t worth the extra complexity and that the readability of the GWT code would reduce even more.
- The big difference between GWT and Wicket is of course that at run-time, all the GWT code becomes JavaScript and executes on the client browser. This may require the developer to think a little more about the implications of certain design choices. For example on lines 51 and 83 of DashrEntryPoint.java, a new instance of a ClickListener is being instantiated for each Space. On the server side, I wouldn’t think twice about dynamically instantiating many objects to render a page but in GWT I would have to start thinking about the impact this would have especially when everything ultimately becomes client-side JavaScript. The GWT tutorial also has some recommendations regarding this.
- The GWT host HTML page Dashr.html contains a hidden IFRAME to support use of the browser back-button. To be able to use this feature properly requires some extra effort as detailed in this page of the GWT documentation. I did not spend time trying to understand this and I simply used null for the “state token” on lines 50 and 82 of DashrEntryPoint.java. The Wicket application transparently supports the browser back-button. If you really need bookmarkable URLs, you then need to do some extra work in Wicket just like you have to do in GWT.
- The conversion to JavaScript takes more time than normal Java compilation. I found a mention of a real-life project experiencing GWT compile times of up to 18 minutes.
- On a more positive note, I used the latest GWT 1.5 and whatever little Java 5 features I used (generics, enhanced for loop) worked fine. You still need to be aware of some gotchas though.
- The GWT code does not communicate with the server at all which can indeed be considered one of the advantages of GWT because of performance. But it depends. What if I really wanted the data to come from the server? Then I would need to understand how to make server calls and perhaps even GWT serialization. The “Dashr” requirement is not something I cooked up and I am using something similar in an actual project. In the real-life requirement when a Space is expanded, the data has to come from the server (over Ajax) because it is an expensive “count (*)” kind of query in the database. In other words, the expanded data for all spaces cannot be loaded upfront in one go. Handling this kind of stuff in Wicket comes naturally, you *are* on the server all the time. And if you use Hibernate you have to be aware of certain issues with GWT. I hope to expand this example with RPC into another blog post soon and also explain why I think concepts like SOFEA have drawbacks that need to be taken into consideration.
- A few other points worth noting that are not addressed in the example, I personally find GWT’s approach to JavaScript integration, unit testing and especially internationalization more complicated than Wicket.
Overall, a perception of GWT I couldn’t get rid of while working with it is that it feels like a hack – but of course, a very well engineered hack. Maybe if you really have a lot of stuff you want to do on only the client side, it is fine. From the perspective of someone used to Java server-side programming, there are too many things about the unique approach that leak through – not being able to do “view-source” and the added complexity of RPC being some of them. And for example here below is a screen-shot of what I get when I “compile” the GWT application into JavaScript:
It is quite weird to see a one-page application result in a bunch of files like this. There is one JavaScript file but even the HTML files contain almost nothing but JavaScript. All the JavaScript is mini-fied and heavily obfuscated. I guess one can get used to it :P
You can’t do this using Adobe Flex!
I initially had an ambitious plan to include Adobe Flex and make this a three-way comparison. But as far as I can tell, there is simply no way to get the exact table grid behavior we require using Flex! Simple things like “rowspan” are simply out of the question. Some more recent Flex widgets like the Advanced Data Grid support grouping of data and expanding grouped items etc. – but come nowhere close to the requirement outlined at the beginning of this post.
I may have missed something, so do let me know in the comments.
Related previous blog post: A Wicket User Tries JSF – comparison of Wicket and JSF using a simpler example.
About Peter Thomas
Incremental Operations 
Can you also perform some analysis of the same code from a unit testing perspective?
Which framework produces more testable code? What types of tools would be required to test which implementation (e.g. java only, htmlunit, selenium/webtest/mercury)…etc
Once again, a post Thomas!
Btw, personally I believe Wicket is as much of a hack as GWT is, just in different areas, with different trade-offs. I do like parts of GWT, even in this article. The largest show stopper to use GWT for me right now is the inability to dynamically add components; the system I’m working on is pretty much a container for such components, and I just can’t see – admittedly with limited knowledge – how that would work with GWT.
I have no experience at all with Wicket. But I have alot with GWT, and I think the preference for one or the other comes down to what you are used to working in. I come from a standalone application background, and am accustomed to writing apps where the code defines both behaviour & look of the UI. As I had almost no web app experience, writing apps in GWT felt very natural to me. Working with Wicket, it seems from your example, is more about making sure various bits from various files all line up correctly.
Personally I never found GWT to be limiting, and while there were quirks and some workarounds needed, in the end it did everything I needed it to do.
I can’t comment on your Wicket code, but I can see many ways your GWT code could be improved.
I never had any difficultly debugging the GWT page in Firefox using Firebug, tho i only used it for tweaking the styles. The javascript is pretty much opaque. Which was fine with me.
When you get down to it, HTML, HTTP and JS are ugly hacks that were not designed for building applications. I will accept that it’s not perfect, but within such a hacky deployment environment, I think Wicket actually does a lot to make things LESS hacky.
That should be: once again a *nice* post Thomas :-)
@b at comment #3
Completely agree that what works best for you depends on various factors. This blog post is indeed written from the point of view of someone who has done more web-app development than for e.g. Swing development. And this someone genuinely believes that HTML driven development for various reasons is simpler than the alternatives. I agree with Eelco and Jonathan, ultimately all web-frameworks are nothing but ‘hacks’ to bridge stateless HTML / HTTP and the server-side. The question is indeed, which is *less* hacky :)
It would be great if you can point out some examples of where the code can be improved. That would really help me and others understand GWT better. As of now I really can’t see how the code can be improved much.
Excellent Post !!
Pingback: From The Web : à propos de Wicket… | NooCodeCommit
Hi,
IMHO it would also interesting to compare the performance and scalability of both solutions.
I would be expect GWT to scale much better because it should need less state per user on the server.
Regards,
Markus
@Markus
Yes, I may attempt this after including RPC on the GWT side. Having worked with JMeter a bit, I have a hunch that getting it to work with GWT is going to be a little tricky because it works at the HTTP level. Hmm, is it possible to load test the complete GWT stack at all?
Maybe you can only load test the RPC services that GWT depends on. But then it now depends on the scalability of your services and nothing to do with GWT. True, Wicket would hold more state on the server but memory is cheap nowadays and I expect the overhead of RPC data serialization (especially if you use XML or JSON) as something to be considered.
I guess there is only one way to find out for sure :)
I see that you manually add/remove cells, and sets its row spans in the click handlers.
that is not a good way to use gwt, as you did not abstract yourself from html, but is just writing “html” in java.
what you could do is instead define two more widgets – one widget for the collapsed state view, and another for the open state view. how you implement these widgets is up to you, but i would just have another table in there.
then, in each cell of the flex-table you would add in the correct widget when the click happens.
that way, you dont get bogged down in the click handler with table manipulation code.
@Chii
Ah, but isn’t that the most crucial part. How easy is it to create custom widgets in GWT? Aren’t you forced to programmatically “write HTML” at that point anyway? Can I really create a custom widget that is just a piece of a single HTML table?
It all depends …
Business web apps which run on an intranet are usually addressing a small (hundreds, maybe thousands, but not more) users, of which only a small part are using the app concurrently. Such apps tend to be a lot more write intensive than extranet apps, and tend to run complex operations, which need a lot of data, and are therefore inqdequate to run on the client side.
Public web apps like an online shop or google maps are used concurrently by maybe tens of thousands of people. Such apps are mostly only reading data, and reading data which isn’t updated often on the server.
So it’s really two different worlds, in terms of requirements from a framework. I think Wicket is better than GWT for intranet business apps, and GWT is better for typical web apps.
I don’t agree with the generalization that GWT is better for non-intranet apps.
Like you said it all depends. IMHO one should do a performance test instead of prematurely optimizing the architecture.
COOL !
Pingback: Peter Thomas: Wicket versus GWT | A Wicket Diary
Hi
This is my comments to the article. I wanted to give my “side of the story :-) I think the article is great. Having used Wicket in the past and was very glad about it.
It is some time since I used wicket, so bear it in mind
I have been developing GWT last couple of month, so this is my comments for the article.
I think:
#1 Ok, but you can build whatever html structure you want by Using the DOM class. boring, but it can be done.
#2 Agree :-)
#3 The benefit looking from GWT is that you are able to change everything. You dont have to have wicket:id´s all over you html, and keeping it in sync with the java code. (how would wicket react to a change in the hierarchi of wicket:id´s ?)
#4 That is really not how it works in wicket! In a real world app, I believe you do have css names in wicket also. (simple example is altering row color in table)
#5 This is a valid point, but I believe there is nothing in GWT that prevent you from doing the same in GWT. E.g (RootPanel.get(“wicket:id”).add (..) ). It is not the preferred way, but it is possible.
But the benefit of layoutmanagers is that you are the able to react to changes e.g when the user changes the browser windows size. You can either change layoutmanager, or “change the layout” of single components to the 4 column table is now 3 column. (how would you do that in wicket?)
#6 Valid! but with “oophm” coming, the hosted mode is supported under FF, safari IE abd chrome :-)
#7 valid, I would also do the “table” as an entire component.
#8
“I wouldn’t think twice about dynamically instantiating many objects..”, I think the Detachable Models are exactly created because you need to think about instantiating many objects, so I dont quite understand you point here?
In the end I believe the there is more memory in 10 client machine that 1 server, so why not use the client machine memory to “keep/execute” the application?
I also think the Listener design-pattern is much easier to use that the “target.addComponent(component)” doing ajax-call. Especially if the component is “far away” in the wicket hierarchy.
#9 Wicket do support back button, but not for ajax call, or has it been added?
#10 TRUE! but that is part of the deploy process at my project, so I really dont care how long it takes. :-)
#11 TRUE, I find the worst part being that not all JDK SE classes can be used because the conversion to javascript is not possible or has been made by Google
#12 Integrate hibernate and GWT do add some extra thinking….BUT I believe that is the same for Wicket. (Models and lazyloading?)
#13 TRUE, junit in GWT is NO GO :-) takes to long time. And i18n is much more easy in Wicket. GWT prefers properties file and at work we have a database solution, so we need to do coding ourselves :-( (we also did in wicket however :-)
Now at the end.. Why use GWT over Wicket?
#1 Compentences. Everybody can do swing, AWT or SWT. So getting people started in GWT is very easy. You dont know you are doing a application executed in a browser og a thick client. Sofar our development of javascript in the project is 0 lines of javascript, even though we do also have calculations in the clientside.
#2 Our application is more a “desktop application” than a “normal” webapp. Therefor GWT do present a nice development environment.
#3 Ready made GUI-component library to buy (GXT).
#4 We cant ignore the momentum of GWT. (Google effect :-) Just yesterday the GWT-Adobe AIR framework was published..
So what are the down side. Well the are hidden in the above.. but lets point some of them out.
# Hosted mode is not superfast as the wicket development cycle.
# i18n when not using property files.
# Doing a normal webapp, (read not desktop like app) GWT is not suited! Can be done, but I think wicket is much much suited.
# Getting used to the async-remote calling. Sound very likeable but you will be supprised, before you say “arrhhh, now I know how to use it correctly” :-)
This was my humble comments. Hope you can use them to possible decide for you next project.
/Flemming
I have done development in both frameworks, and think GWT is just terrible.
To me the big problems with GWT isn’t with the mechanics of how you do certain page-level manipulations and produce widgets and layouts. As some earlier posters have alluded to, it may even be stronger in some ways
No, the problem with GWT is that that is _all_ it provides the answer for. It does not attempt to address any of the _hard_ problems of modeling web applications, which come down to the issues of binding data to presentation and vice versa, validating user input, and transitioning users around the application.
Wicket has the best Model-View-Controller implementation I’ve seen in any framework. GWT is a presentation-only framework. It gives you nothing to solve these problems. You have to build that framework yourself.
And worse, it encourages a style of development which pushes logic into the client-side, but there is no official client-side reflection abilities to allow you to write abstract model-property to view element binding. So there is literally way to write the GWT equivalent of, say, Wicket’s “PropertyColumnModel” facility for data grids without invoking server-side facilities, which typically involves making RPC calls.
A similar story applies to validation — Wicket gives you a generic way of adding validation to entry forms. GWT does not.
After working with GWT 1.4 and 1.5 for a long time now, as well as having written applications in Wicket, I just don’t think GWT scales to writing serious _applications_, which are almost always _data_ driven, the way Wicket does. I do think GWT is great for presentation-driven websites, but that doesn’t describe many real world problems that I am involved with.
I think this post is like comparing “Apples and Oranges”, not very useful.
GWT’s primary purpose is for client-side RIAs which use RPC to talk to the server.
Wicket’s primary is for server-side Web applications (which, of course, may include AJAX components).
Any you nearly admit it yourself:
“Maybe if you really have a lot of stuff you want to do on only the client side, it [GWT] is fine. From the perspective of someone used to Java server-side programming, there are too many things about the unique approach that leak through”
Just drop the “maybe.”
This is not to say that GWT is the best approach for RIA, just that you would have compared Wicket with other server-side Web application frameworks or GWT with other RIA frameworks (e.g. Echo3).
Cheers,
Ashley.
@Ashley
Not a very useful post? Heh. Yes, GWT is certainly acceptable for client side RIA, I said it clearly, no question of having to “admit” it. But I know many people considering GWT for front-ending server-side logic, so I’m sure that this post will be helpful.
No, I won’t drop the “maybe” because the post makes the drawbacks of GWT clear. The GWT side of the example does not even use RPC. Are you saying that if I extended the example to use RPC it would be an “apples to apples” comparison?
Pingback: Blog bookmarks 09/06/2008 « My Diigo bookmarks
Thanks for the rather thorough comparison, really informative. Though it shows that you have more experience with Wicket :) As they are both tools that give the full power of OO to the developer, I think you can work around a number of kinks you lined out.
And I think you’re dead right about GWT being more for client-side RIA development. The good thing about GWT is that it doesn’t depend on java at runtime, you can develop your nice rich javascript gmail replacement and drop it on any old php-serving apache.
A delayed reply to Flemming at comment #17:
Thanks, this will really help others and I appreciate your thoughtful analysis though I don’t fully agree with some points. And I can’t help pointing out that you concur with most of the points I raised ;)
@Lev at comment #1:
I think Flemmings response to point (13) answers your question on unit-testability. My comment at #10 suggests that load testing would be a challenge with GWT as well.
Clearly, you’re better at using Wicket than GWT :-). I’ve developed applications using the GWT before, and I don’t think the code looked that bad :-p. GWT works really well if you think it terms of components using a bottom up (ie, which is the smallest level component for the UI problem at hand?). In this particular case, the FlexTable would certainly not be my pick for the lowest level. I would probably look at embedding a CollapsiblePanel component within the FlexTable, for example.
You’d mentioned composing UIs in Wicket – you can actually do this very easily in GWT, by creating a UI out of components. Check out this page: http://gwt.components.googlepages.com/ for a few examples.
@Sander
I just had a quick look at CollapsiblePanel and I don’t think that would work. Also looks like this is in the incubator and not in core. Sorry :P
Pingback: Wicket Impressions, moving from Spring MVC / WebFlow « Incremental Operations
Pingback: Blog Xebia France - Revue de Presse Xebia
@MrHatken
If you’re comparing frameworks to build a web UI, regardless of how buzzword compliant it will be, these technologies are interchangeable. Of course it depends on your needs, which is why you’re comparing them :-)
Pingback: Weekly GWT Links For 9/6/08 | GWT Site
Interesting post, if a little one sided.
Sander (comment 24) is entirely correct, you are clearly a better wicket developer than a GWT one.
Again, Sander is correct in stating you wouldn’t use FlexTable directly, but rather wrap it within a custom widget, which is provided with the space objects to display. Also the implementation you have provided for the GWT code is remarkably complex for such a simple problem. I’ll see if I can post an improvement shortly.
In response to comment 12, creating custom widgets is more simple in GWT than wicket, as you only need to create one file, not two. Also you do not write ANY html – it’s all java code… GWT generates pages using the browsers DOM directly.
In general I quite like wicket too, however I just hate writing HTML + having to modify more than one file to make a change… hence my preference is GWT.
Cheers!
@Stuart
I agree that for some, the fact that you do *everything* in Java code can be considered an advantage, you indeed work with only one file instead of two.
But the downside is that web-developers used to working with HTML / CSS cannot be fully productive on a GWT project. This *is* a big deal for many development shops. Another thing is that if you are used to creating HTML mock-ups during the requirements phase, you won’t be able to re-use them at all if you use GWT.
Whatever you and Sander say, it is still not clear if and how a custom widget will make the GWT side simpler. So I’m afraid I have to reject any accusations of this post being “one sided”. How do you know for sure that I’m better at Wicket that in GWT ;)
@Peter
In response to GWT versus Wicket experience, it’s clear from the way you’ve constructed the GWT code – and the lack of using a custom widget/s.
In response to the HTML mock up – I think that speaks for itself – it’s a mock up, hence shouldn’t be used for production, as it’s probably been developed with short cuts being taken. Personally I prefer to draw things on a whiteboard / bit of paper (which may seem simple – but that’s what I like), alternatively Photoshop / Fireworks is your friend.
I agree ‘web developers’ who write HTML and CSS will find it a lot different. But that’s because we’re now moving into coding Java – hence you want Java developers, not HTML & CSS guys (and I’ve recently had to deal with this at a client – the web guys really didn’t like GWT, but the Java guys loved it).
So I’ll agree, use wicket if you like HTML & CSS and want to have different people coding those – or you’ve got a lot of guys employed you don’t want to fire. However if you have a load of java guys who maybe have some Swing experience – the learning curve is a lot more friendly in GWT.
Oh well, at least it’s not Struts, Tapestry or Webwork!
Enough. Before anyone else comments using this same bogus argument – please point out how exactly you would have done it differently. I really would like to improve my GWT skills.
Of course it shouldn’t be used in production directly, what do you take me for :P
Let me put it another way. When screens are available mocked-up or prototyped or whatever in HTML form, the amount of reuse possible would be something like this:
Wicket: 60 – 80 %
GWT: 0 %
Ok… check out http://www.mattboyd.com/gwt/TreeTableExample.html
and here’s how to use it:
http://www.mattboyd.com/?page_id=7
That seems to pretty much do most of what you want. I’ll code something myself to show you how to do it – if I have time (lame excuse, but I am quite busy at the minute).
I still think a whiteboard is better for designing UIs as they are much easier to change when the user is there. Plus ideas can quickly be drawn up – and erased.
@Stuart
I had a quick look at the TreeTableExample, but it still has a long way to go. For example, the rowspan / colspan requirement and the styling of the cells is not addressed. No summary row for each node either.
But the key thing you conveniently ignore is how much effort and lines of code have gone into creating the widget itself. Those interested can extract the JAR file linked and see for themselves. Compare this with the Wicket implementation.
This actually proves one of the things that sets Wicket apart from GWT, JSF, Flex etc. Creating a re-usable custom widget is so easy that in practice, you find yourself creating what your specific project requires on-the-fly. You don’t have to depend on what the core framework offers or like in the example you provided – a component by a third party, the license and maintenance of which is suspect – and which still does not meet the *exact* requirement.
And a last word on HTML vs whiteboard / wireframes. For teams not yet lucky enough to be practicing agile, HTML prototypes are perfect for getting a requirements sign-off from the end-user – and I have seen many projects that do this.
Pingback: Le Touilleur Express » Revue de presse (agrume)
Well, i’v worked with Wicket and GWT, and i have to say that I disagree with most fo the things pointed by Peter here to compare Wicket and GWT.
First of all, take note of this: GWT is NOT a framework… is a TOOLKIT. GWT was made for a specific purpouse: to be able to make RIA by java developers easily using ajax feature. Thats why u put the client code on the clients pc (to use it, and to not overload the server), thats why u use RPC to comunicate with the server, to use services, like any JEE aplication.
In the other side u have Wicket which is a web-app framework that use java to manage the server side of the entire application. Every time u ask for a change on the client side, there’s a call (ajax call) to the server to refresh some portion of the client ui, so dont tell me the RPC thing is awfull…
Again (as others here) u could separate the code in the entry point class in 2 more clases creating composite widgets… comeon.. its not so complicated to make the same separation u made for the Wicket code.
Finaly, I have to repeat myself, GWT is not for a web team to make web applications, it is a toolkit to let java developers make RIA applications easily, so please dont compare both as different ways to do the same by the same people.
@Pipe above:
So? I shouldn’t compare GWT and Wicket code for the *exact* same functionality?
Please see comment #33
I think you have a misconception of what GWT is, it is not just about widgets. GWT consists of the compiler, hosted mode, and the libraries.
See my presentation GWT Extreme, http://www.youtube.com/watch?v=2ScPbu8ga1Q for a look at what you can do with GWT that a) you can’t do with Wicket and b) none of it has anything to do with Widgets.
If GWT had a raison d’etre, it would be to reduce latency as much as possible, reduce the number of HTTP invocations as much as possible. Reducing HTTP requests has massive benefits on startup time, app latency, hosting requirements, etc The Widgets provided are really meant to be barebones, and not a full blown MVC library, and the GWT authors would tell you as much. They expect those things to be provided in separate libraries.
1) You can have complete control over HTML (see GwtQuery or the GWT UI Template language)
5) No, you don’t need layout managers. It is a fallacy that in a GWT application, everything has to be done via single root and that “view source” shows nothing. You place as many widgets as you like in separate HTML elements.
6) Same as #5, you don’t need to have an empty HTML host page. Secondly, Hosted Mode has a DOM inspector (WebKit) or Firebug (or Firebug like). For AJAX apps, View Source isn’t as important as DOM inspection, because the source isn’t static. Moreover, you can use Firebug on generated GWT Javascript (I routinely do this), but most of the time I prefer Hosted Mode. Why? My Java debugger is far superior to Firebug, and I can *step from client to server*. Can you step through a remote procedure call in Wicket?
8. Seems to me you’ve got it backwards. I’d be more concerned about instantiating an object on the server than on the client. Every object you instantiate on the server puts pressure on GC, and this goes up with the load you have to concurrently handle. In my Chronoscope application, I instantiate huge arrays in GWT with no problem, a technique which would choke a Wicket server trying to do something similar with JFreeChart.
I’d say that attempts to compare GWT and Wicket are just wrong headed. GWT is better compared to pure client side Javascript frameworks like jQuery, Dojo, ExtJS, etc. or Flex. Wicket is a Web 1.0 architecture with AJAX tacked on (I was once a heavy Wicket user). It relies on significant amounts of server processing, server state, and network traffic to get its job done.
Today’s RIA web application architectures treat browsers and Javascript as a first class programming platform, not a dumb terminal hooked to a super smart server. Almost all of the view logic can be written directly in Javascript or GWT, with only REST calls required to pull down data and control logic (not shoving UI information over the pipe)
I can deliver a significant amount of functionality in a 46kb Javascript download, that is only loaded once, cached forever, and makes only a few small JSON calls to do its work. The responsiveness is far superior to frameworks which rely on running all of the view/controller logic on the server.
@Ray
You start off as if the post is all about widgets (not true) and hence I have a misconception :) Actually we completely agree on a couple of points:
a) GWT makes sense if you don’t have to go to the server all the time. Especially for the kind of work you appear to do which is rendering graphics in the browser.
b) GWT is not a full blown MVC library. I think Ryan at comment #18 does a great job explaining this.
That said, the example here is simply about dynamically updating an HTML table in the browser so I don’t think that comparing GWT and Wicket code for this is “wrong headed” like you say. And no GWT widgets have been used either.
Coming to your points:
I’m sure it is possible if you try hard enough but the example here proves a case where it is not – unless you get into the DOM or something like that. BTW which UI Template language are you referring to? The one I could find was in the incubator.
I think for real-life applications you would. Would you recommend otherwise?
Really? Then why are these GWT issues still open?
I completely disagree. Even when AJAX is involved, in Firefox, I can select a section on the page, right click and “View Selection Source” or even use the DOM inspector. And there is a big difference between debugging JavaScript (which could also be obfuscated) and looking at the rendered HTML.
One of the points of this blog post is that when you actually need something from the server (JSON, REST, RPC, etc.), it is not as simple in GWT as you make it sound, especially if you want to use Hibernate. As I said, I hope to have another blog post to examine this in detail.
b)/#18 While somewhat valid, the comment about reflection on the client side is based on a misconception of the underlying reason why you don’t want this. See my session on Deferred Binding: http://www.youtube.com/watch?v=uX1Nhr75zDI
There are GWT libraries that provide dynamic introspection on the client, but they run the risk of massively bloating the code base. The GWT compiler aggressively prunes unused code and obfuscates identifiers. Dynamic introspection would block the compiler from doing this because you’d never know whether or not the server might send an object to bind to a method/field at runtime, and you’d have to keep the original unobfuscated names of everything around, thus massively bloating the code.
5) Yes, I would recommend it, I use this approach myself. The RootPanel.get(id) method isn’t there by accident.
6) If you’re on the Mac, you can right click and bring up the DOM inspector. If you’re on another platform, you can either use Firebug Lite, or you can check out the Out Of Process Hosted Mode version of GWT. Or, you can go to Web mode from Hosted Mode.
Moreover, you misinterpreted what I said. The View Source I was talking about was the browser’s (not Firebug) View Source of the static loaded content. This is a frequently used myth about GWT that the host HTML is nothing more than an empty BODY tag. View Selection Source is built by introspecting the DOM, and covered by my comment on AJAX. That is, when doing AJAX programming, dynamic inspection is far more important than static inspection.
As for getting data from the server, it’s pretty simple if you start out without a legacy architecture. It is a mistake to want to ship arbitrary object graphs between client and server, and I’m not a total fan of RPC approaches because they hide the underlying costs.
I prefer JSON/REST approaches because a) they work with multiple languages (neutral payload format) b) efficient evaluation in Javascript and c) they force you to think about what you’re sending over the wire. d) they mesh well with the Web’s existing cache/proxy semantics.
While I’d acknowledge that simply querying a POJO collection from JPA/Hibernate and sending it via RPC might be a simpler and easier to understand client-server pathway, it’s also one that could lead to pathologically bad behavior, and, it tends to be unfriendly to Python/Ruby/etc programmers.
Comparing this with Wicket is an apples-to-oranges situation because Wicket does everything on the server. You don’t generally pull POJOs from Hib in widget, and send them to the client for logic to be executed on them.
This is completely 180 degrees with the Web 2.0/Mashup style architecture where people pull data-only via JSON/REST and do all the calculations on the server.
GWT is a work in progress. The foundation is the compiler and hosted mode, that’s where most of the work goes. The various libraries being built on top of this solid foundational architecture are slowly maturing (earlier versions of Wicket weren’t exactly a joy to use either) Out of Process Hosted Mode is coming, a super-efficient compile-time templating system is coming, new methods for integrating with the server are evolving.
So yes, some of the criticisms are valid, but the foundation is sound. Wicket to some extend is grounded in a completely separate architecture, one more closely aligned with the Web 1.0/J2EE world, one that demands alot from the server.
Thus, I think the comparison is apples-to-oranges and there is really no reason why Wicket and GWT couldn’t be used together really.
Wicket should be comparing themselves to ZK, RIFE, Echo, Tapestry, JSF, et al.
“You don’t generally pull POJOs from Hib in widget”… s/widget/Wicket/
“where people pull data-only via JSON/REST and do all the calculations on the server.” … s/server/client/
Come on. I don’t use a Mac and OOPHM isn’t even available yet. I actually linked to the open issues on the GWT tracker in my previous comment.
The point is whether you can do inspection of the *dynamic* HTML (which in a GWT app will be 80 – 100% of the page) in hosted mode and I think the answer is no.
You can invoke all the Web2.0 buzzwords you want but you still haven’t convinced me that this is an apples to oranges comparison. And I initially thought that Wicket and GWT could be used together but the experiences of people on the Wicket mailing list have not been positive. Here is a quote from the wiki as of today:
If you don’t have a Mac, and don’t want to use a non-stable OOPHM build, then use Firebug-lite. I think you’re making a mountain out of a mole hilll. I’ve written significant amounts of code in both GWT and Wicket, and I can debug just fine.
“The point is whether you can do inspection of the *dynamic* HTML (which in a GWT app will be 80 – 100% of the page) in hosted mode and I think the answer is no.” The answer is yes on OSX, currently no on Linux without Firebug-lite which you seem to want to ignore.
The reason why it’s Apples-to-Oranges is that GWT never billed itself as a full stack MVC framework. Go read the first paragraph of the GWT homepage. It was meant as an RIA/AJAX framework for doing frontends, replacing the need to write large front end applications in Javascript.
GWT is meant to be a foundation, lean and mean, on top of which, beefier frameworks are built, and there are no shortage of people doing their own MVC stuff on top of GWT.
It’s like comparing GCC and STDC library to Swing.
As for integration, without knowing more, this may as much be a problem with Wicket as it is with GWT. Back when I was using Wicket (2 years ago), it had trouble integrating with dependency injection frameworks, so I’m not surprised.
Here’s the simple point of the matter. I write applications more like Gmail, Docs, etc, full fledged Javascript applications. They operate both online and disconnected offline. They run inside third party social network containers easily. They run inside mobile phones. The same code with few changes runs in a servlet, offline as Javascript, or compiled as a mobile Java app.
This is simply not something Wicket is up to. It’s great for doing intranet apps, and compared to Tapestry, JSF, and the other server-centric frameworks, it’s the best. But it simply not a replacement for what GWT does.
And that’s why its an Apples-to-oranges comparison.
Good. So we have cut through all the spin and down to Firebug Lite as the only possible option in hosted mode. I just tried Firebug Lite in hosted mode and it does not work. Here’s the screenshot. I even tried the “inspect” button but the rendered HTML is not detected by Firebug Lite at all.
Gosh, you can have the last word on the “apples to oranges” allegation. But let me say this then. The example here proves that even when it just comes to manipulating a plain old HTML table, Wicket does the job far more elegantly than GWT. Go figure.
Well, it does appear to work in OSX. I’m not sure what more you want to hear. The GWT guys are aware of the issue, they’ve re-architected hosted mode as a client/server instead of using SWT embedded browsers and the next release will include the ability of hosted mode to attach to any existing browser.
You can always hit the “compile” button which is what I do when I need to debug in other browser engines.
I’ve been doing GWT development for almost 2 years now and none of this has been a hindrance to my development, in fact, I’d say my productivity increased with GWT (coming from Wicket)
I think Wicket is a great framework for doing traditional web apps, especially intranet apps. It does not replace what you would do with Flex, GWT, or jQuery/Prototype/Mootools/Capuccino/Dojo/etc. GWT is not a universal hammer for every app, and neither is Wicket, and I’d certainly admit that there are types of apps for which wicket is well suited, and that GWT needs improvement.
However, I think this comparison, like the ZK one, is somewhat flawed. 2 years ago, when I was using Wicket, there were similar comparisons, and the answer was always “wait till the next Wicket version. Wicket 2.0 is going to have this and that…” Did that stop early adopters from using it? No. It’s an open source project, just like GWT, and people contributed to it to fix some of the deficiencies.
I don’t think any hardcore GWT developer is going to be swayed by these observations, because they’re already aware of them, and can see the awesome stuff in the pipeline that is coming real soon now. For an outsider of the community, its not so obvious.
Compilation can take a long time. See point #10 in the main blog post.
It can and the example code here proves it. If you read the blog post it mentions that this example cannot even be done in Flex.
*can* take a long time, not will. If you know you are going to be using Firefox, you can tell the compiler to only compile 1 permutation.
As for replacing the RIA client side, your example doesn’t prove it. What it proves is that Flex doesn’t have an HTML table layout built in. On the other hand, it would be very hard to produce something as interactive like 280Slides, Zoho, Google Docs, GMail, etc using Wicket, nor can you produce completely offline applications. If you cherry pick your requirements, you can come to any conclusion.
Thomas, great post!
Ray, please stop your GWT rant. You made your point in your first post. Now go back to working on your GWT compiler while the rest of us build real UI’s.
@Brent, I’d hardly call providing corrections and workarounds a “rant”, but “real UIs” certainly is a snide ungentlemanly remark, and not useful to the discussion.
This is very interesting discussion. In my opinion, it is more useful to compare GWT with Java WebStart than with Wicket (apples vs apples). When you talk about RPCs, threads, etc., you have crossed a line – you have started to make an application program. In that case, what I really want is to be able to take advantage of the full power of the JVM (database,security, threads, etc.) and all those great tools – why settle for less (see my Blog for more)?
On the other hand, if I am writing a WebApp (i.e not a web-hosted desktop app) then I might consider using Wicket. In the meanwhile we are using Seam (have been using this for a while now), but evaluating Wicket. Nice thing about Seam is that when used with EJB3 you get a complete application development platform. But I like wicket, just bought the ‘Action’ book and waiting for Amazon to deliver it.
Maybe we should define some new terms: WebApp = traditional server driven web application (hotel reservations, etc). Web Desktop App = More of an application that happens to use services of a Web Server (Google docs, etc.)
WebApp => Wicket or Seam
WebDesktopApp => GWT or WebStart
I’m not about to say anything groundbreaking but it might be a useful comment for some people:
Bear in mind, whatever tool you use, we are trying to make web browsers do some pretty crazy things. The essence of the web page, static or dynamic that you’re looking at is actually the DOM, not the HTML. The DOM is the thing that makes the things we see. HTML is just a markup language that allows us to tell the DOM what to do, equally javascript is another way to tell the DOM what to do. Some could argue that programming for the DOM is more direct than feeding it markup, but then again scripting implementations differ slightly from browser to browser. But the fact that you can’t click View Source when debugging a rich client application (like a GWT one) isn’t really a good enough reason to bag it, although for people who really a lot on this technique, well fair enough.
I suppose thing like Wicket would seem to have an advantage on this point simply because most of the work happens on the server, whereas with GWT probably all of the UI happens on the client. Not invalid, just new and different.
I’m a big GWT user and have programmed many successful application which are both client intensive and do a lot of grunt work on the server, and they work well and my clients are very happy… so I’m not sure why Brent needs to make comments like “Now go back to working on your GWT compiler while the rest of us build real UI’s”. I’m not sure what a “real UI” looks like if it’s so different to some of the incredible work that’s out there using GWT.
I hope you can tell I’m not the ranty type and certainly don’t mean to annoy people in forums, but @Thomas, interestingly I have been working on a hotel reservations system and demonstrated two prototypes, a server heavy version and a client heavy version and the GWT one was far more intuitive to use, so your definitions:
WebApp = traditional server driven web application (hotel reservations, etc).
are a little blurry too.
Anyway, I appreciate the discussion. Cheers
Would it be cheeky of me to suggest that for this particular example, it would just be easier to go ahead and write it in JavaScript, leaving the door open to plug data into it in a manner independent of whatever you’re running on the server side?
http://www.jonathanbuchanan.plus.com/space.html
@Jonathan
Pretty neat! I think it is a great reference for those interested in how you can do this using hand-cranked JavaScript and without getting into Java at all. Had not heard of DomBuilder before. Thanks!
Pingback: IT pro life
Based on what I’ve read, I think this would work in Flex using the advanced data grid. You would also use a standard mx:List component and just customize the way the data is rendered.
What is the status of JForum? The source repo doesn’t seem to be accessible. Would you consider converting JForum to a Flex front-end? Send me an email!
I have a good case study of GWT v/s Wicket performance over slow networks. The project I am working on uses both technologies, and I have to say that I love both. I do however find that for me the task at hand determines which to use.
Parts of our project are used locally for system admin. (Maintenance of static data etc.) These were done in wicket, which worked brilliantly for the job.
However, another part of the system had the following constraints:
* Batch capturing of consighnment data is done by large teams of workders at a time.
* Due to the large amount data to be captured, and the small timeframe, we could not afford to let them wait for anything if not absolutely nessisary. In other words, quick response times were vital.
* These capturers normally work in remote locations with verry severe bandwith restrictions. To give you an idea, it takes about 5 minutes for a full HTML page with a couple of small images to load.
These batch capturing (and editing) functions were done in GWT, which allowed us to accomplish the following:
* Most static data is loaded once at startup and then cached on the client. In other words, they never get loaded again. Static data which would quite possibly not be used is loaded later in the application, but once again this happens at one specific point in the application and gets cached once downloaded.
* While this static data is being downloaded, the user is presented with a clear, interactive display indicating the progress of the download. Despite the slow network connection, the download of all required static data takes about 20 seconds. (GWT by default uses a much more compressed format to send data over rpc than standard XML/JSON.)
In one screen weve got a page/page list of consignments with some advanced search functionality (10 entries are shown at a time in the results). Over the slow network mentioned above, it takes less than 10 seconds to download & render the next set of results.
* It takes less than 5 seconds to open the details of a consignment (About 50 fields)
* The validations that need to be applied to a consignment are quite complex, among other things only allowing certain combinations of entries in the consignment. All validations are done in realtime on the client side as the user enters data without a single call to the server.
* When the user submits a new consignment, the data is placed in a queue on the client and sent asynchronously to the server. The user is immediately presented with the clear consignment form, ready to capture the next one. On the bottom of the screen, the user is presented with the details of how many consignments are still queued for update, as well as the option to navigate to consignments updates which were incorrect (The one validation that could not be done without communicating to the server is the checking for uniqueness. This was therefore left for after the consignment was submitted.) Al this meant that, even if the network totally failed, or the server got restarted, the users could keep on capturing uninterrupted. There updates would simply be queued on the client until the connection to the server was restored and then sent.
In short, my thingking on the matter is: Use the right tool for the right job. If you do not have serious network/resource restrictions, and do not already have an application framework in place, Wicket is definitely the simplest way to go. On the other hand, if you do have serious network restrictions, or need to perform complex operations on the client (like the real world example above), the right tool for the job in comparing these two frameworks would in my experience definitely be GWT.
Why on earth did you write HTML elements for collapsed mode then replace them for expanded mode?
That’s such a waste of time and just shows your ignorance of HTML, the DOM, Styles, and Javascript.
It’s dead easy to hide rows in tables, by using Javascript to find the element by id, then tweak it’s style. I’ve done exactly this kind of element wrangling for work. I found this even tweaking easier with the “Prototype” Javascript library!
@Infernoz: Your comment shows *your* ignorance because you haven’t bothered to read or understand the post or the comments.
This post is about GWT and Wicket – and using Java – not JavaScript or Prototype. Also have a look at Jonathan’s comment at #53 and my reply.
I like this example and try to use extjs-gwt in eclipse project. This is my first article about extjs-gwt:gxt
http://extjs-gwt.blogspot.com
See more about Extjs-gwt on eclipse.
I think this extjs-gwt article can help beginner to learn.
Pingback: Wicket im Vergleich « just IN time
Good comparison…
—
I wrote some articles/outlines regarding the issues with GWT as well as comparing several RIA frameworks here:
sonymathew.blogspot.com
—
I want to add a few things here:
Yes, the FlexTable component is clunky – but I don’t see you leveraging much of Java’s OO capacity in GWT – for e.g. I don’t see a SpacePanel, SpaceRow etc. that could encapsulate some of the nasties like row/column mappings etc. Additionally with Java you can potentially create components that have a more fluent API to layout than HTML e.g. AxisPanel (another article I wrote – Fluent DSL for Rich UI – same spot as others).
—
GWT can also support what you are doing in Wicket i.e. segment components using HTML templates. GWT has an HTMLPanel component which allows you to inline HTML code as is and then replace div#id with any Widget or rewrite a#href etc. In fact I created an equivalent HTMLIncludePanel that allows me to include any HTML chunk located at any URL and rewrite/replace specific elements/attributes as I see fit – this is mostly desigend for dynamically composing a web-page from semi-static content managed externally from the app (e.g. header/footer/borders etc.)
@Sony – thanks, also appreciate the RIA comparison on your site.
True, the best I could do was use two inner classes “ExpandClickListener” and “CollapseClickListener”. I did mention in point #7 that with a little more thought I could have abstracted things better.
But my point is that this needs more effort and upfront design compared to Wicket (perhaps because of the clunky-ness you mentioned) – and it would likely increase the number of lines of code.
A fluent DSL is indeed nice to use but the counter argument is that you need specialists to create and maintain the framework code for this. And of course the mixing of CSS, layout etc. in Java code which is evident from the example in your article.
P.S. Hey I thought you were a Tapestry fan, what happened ;)
Tapestry was great and served its purpose well – no regrets – it was the best framework for that generation – but it can’t provide the desktop like RIA levels I was looking for moving forward.
Update: some good discussion on the Wicket mailing list on Wicket vs GWT:
http://www.nabble.com/GWT-vs.-Wicket–td22950178.html
Hi there Peter,
Not related to your last post, but I just wanted to pass on how much I love jtrac! It’s allowed me to roll out an issues register for the IT staff at a Public Library that I work in, without needing a server or client software.
From testing to roll out has taken me half a day. Awesome job!
Cheers,
Tom
Thanks to Peter for that VERY helpful post as I am now
in the situation of having to develop a web application
and I am thinking of doing it in GWT or Wicket or something
else.
Also I would like to thank all the commenters!
The controversial discussion about particular
elements and arguments are contributing very much
to clear the situation and to get the meaning right
– so thank you very much!!!
And so here are my considerations also:
Eelco Hillenius wrote:
> Btw, personally I believe Wicket is as much of a hack as GWT is
For me, Wicket seems much more transparent than GWT does – but
this may also be due to the fact that I know more HTML and Java
than Javascript.
Jonathan Locke wrote:
> When you get down to it, HTML, HTTP and JS are ugly hacks
> that were not designed for building applications.
> I will accept that it’s not perfect, but within such a hacky
> deployment environment,
> I think Wicket actually does a lot to make things LESS hacky.
Indeed – although many seem to overlook (or trying to repress) it,
the technologies that web servers and browsers are using have not
been intended to be used to develop complete client-server applications
– their main purpose is to serve content. The dynamic generation of that
content and AJAX technologies have been packed onto those in a more or
less efficient way. And HTTP + port 80 is used in many cases just to
make sure the traffic is not blocked by the firewall (thinking also
about the increasing number of content walls) even if a completely
different protocol would have been much more adequate.
From all the frameworks I have seen so far, Wicket seems the less
hacky one and I find it very good accepting HTML and CSS as the
most adequate technologies for web servers and browsers. My
experience as user of web applications the web-apps making heavy
use of Javascript for example do not behave so well regarding
caching and so on. Further I often had discussions about the
design and this can be done in the stylesheet by the customer
so I don’t have to bother with it.
Me, myself and I wrote:
> So it’s really two different worlds,
> in terms of requirements from a framework.
> I think Wicket is better than GWT for intranet
> business apps, and GWT is better for typical web apps.
I tend to agree – the only thing is that I am not sure that a
“typical web application” is necessarily fitting into the picture
that you have drawn.
Flemming wrote:
> In the end I believe the there is more memory in 10 client machine
> that 1 server, so why not use the client machine memory to
> “keep/execute” the application?
What I see from other web applications making intensive use of
Javascript (if it is now GWT, ExtJS or whatever), that clients are
basically downloading the complete application each time they access it,
even if they finally just use a small portion of it. I do still find
it useful to split a web application to several different pages that either
can be opened into different tabs in the browser without tweaks
(GMail behavior is annoying regarding that for instance).
Flemming wrote:
> Everybody can do swing, AWT or SWT.
> So getting people started in GWT is very easy.
> You dont know you are doing a application executed in a browser
> or a thick client.
I agree in that – I tried getting started with GWT and Wicket and with
GWT I was a little faster – although – I think it is because of the
better documentation available for GWT (at least from what I found
with first searches).
But knowing HTML (and CSS sufficiently) I find it more adequate
eating that frog as HTML and CSS is the strength of the browser.
Overloading the browser by shipping “just” a bunch of Javascript
code seems a little weird and in fact I find it very annoying if
a web app then somehow hangs up and causes my complete browser to
crash. This is worse than a single app crashing because one app
then crashes all other open websites/webapps.
Flemming wrote:
> Our application is more a “desktop application” than
> a “normal” webapp. Therefor GWT do present a nice development
> environment.
In that case maybe the application should have become better
a “normal” application than a web application (thanks to
Java web start it should not make that big difference in
getting it to the client). ;-)
Ryan wrote:
> No, the problem with GWT is that that is _all_ it provides
> the answer for. It does not attempt to address any of the
> _hard_ problems of modeling web applications, which come down
> to the issues of binding data to presentation and vice versa,
> validating user input, and transitioning users around the
> application.
I only just had a brief look at both frameworks but this is
equal to my first impression when I imagine using each framework
for a more complex application. GWT – even more together
with SmartGWT produces cool impressions for the user just looking
at it and clicking around a little. But when it really comes to
productivity the first euphoria is damped a little – at least for
me in many cases.
I see the Google applications like GMail, Google Calendar and
so on as the best examples for rich internet applications out
there but one have to take into consideration that those are
all quite small and focused on a particular service.
Thinking of a complete web based CRM or ERP system things are
a little different IMHO.
Ashley wrote:
> GWT’s primary purpose is for client-side RIAs which use RPC
> to talk to the server.
> Wicket’s primary is for server-side Web applications
> (which, of course, may include AJAX components).
From my experience in software development in general I
cannot share such a clear separation of intentions.
Most applications have more or less fixed GUI and rely
on data pushed and polled from the server. GWT is trying
to avoid server processing time as much as possible while
Wicket is trying that less.
Anyway the “whow”-effect onto my boss (and customers)
probably will be less cool if I use Wicket over GWT so
I am still a little undecided…
Peter Thomas wrote:
> But I know many
> people considering GWT for front-ending server-side logic,
> so I’m sure that this post will be helpful.
Indeed, you say it, exactly – therefore it is very useful to me!
Stuart Evine wrote:
> In general I quite like wicket too, however I just hate
> writing HTML + having to modify more than one file to make
> a change… hence my preference is GWT.
This for me is also an argument pro GWT – as I am the
developer and the GUI designer as well. But who knows,
that might change…
Pipe wrote:
> GWT was made for a specific purpouse: to be able to make
> RIA by java developers easily using ajax feature. Thats
> why u put the client code on the clients pc (to use it,
> and to not overload the server)
As I guess that Google web-apps are one of the most and heavily
used in the world it is clear that they want to shift most of the
work to the client otherwise they would not be able to catch up
with adding more servers. I can’t avoid thinking of old times when
people implemented parts of code in assembler to gain maximum
performance. ;-) – Jokes apart, you point out that what others
mentioned also: It really depends on the application needs and
focus.
Pipe wrote:
> Every time u ask for a change on the client side, there’s a
> call (ajax call) to the server to refresh some portion of the
> client ui.
This indeed can make the end user suffering during application
usage when the server or internet connection is slower/under heavy
load. GWT maybe takes more time to initially load but then is
maybe more responsive.
Pipe wrote:
> Finaly, I have to repeat myself, GWT is not for a web team to
> make web applications, it is a toolkit to let java developers
> make RIA applications easily, so please dont compare both as
> different ways to do the same by the same people.
In my case it is the same people (me) and I do not see sooo
much difference in a web app and a RIA – both makes use of the
browser and some server side stuff/data. So for me it makes
sense comparing both variants. Sure, the focus is a bit different.
Thanks Martin for the feedback and thoughtful comments.
Update: I just found a couple of very good discussions at StackOverflow.com on the pros and cons of GWT:
http://stackoverflow.com/questions/99866/biggest-gwt-pitfalls
http://stackoverflow.com/questions/523728/why-isnt-google-web-toolkit-more-popular
Thank you for the links, it was interesting reading through them.
I do consider using GWT for applications that have a well defined smaller context.
For applications that might become big projects I think Wicket is more adequate – this is just my impression so far.
BTW: In the links I did not find anybody mentioning SmartGWT and experiences with that. Wonder why this is “nobody” using…
I´ve never used Wicket but am now very willing to learn it, what would be a good resource for it?
Also, I wanted to add some quick comments:
* In GWT there’s an HTML object that allows you to add complex HTML structures to your page. I´ve used it and it works, but is too much of a hack.
* It *is* really frustrating to create layouts in GWT and trying to follow an HTML mockup, which is what your designer will give you.
* OTOH, in GWT you can create quick disconnected interfaces that exhibit complex behavior or do fancy calculations.
* Also, you can build a GWT interface and do the server side on PHP or Rails. This is amazing, BTW.
* I´ve found that GWT is a beauty when it comes to moving visual blocks around your app. This makes the typical client´s request “ohh, I wanted this down here and the menu vertical” less of a headache.
* Actually, messing with HTML files with scattered “business rules” is something I´d really like to never do again.
* I think that using Java everywhere is a very desirable thing. Having used many other frameworks, this is a big win over breaking your head trying to find which variable name is wrong in your HTML file or config file.
* Since GWT is a presentation toolkit, you still need to use a framework for the controller and the model. May I suggest you read http://blog.hivedevelopment.co.uk/2009/08/google-web-toolkit-gwt-mvp-example.html where current best practices are explained in detail.
Martin, I´ve used SmartGWT and although it has wonderful widgets and the binding capabilities are great, its size (2M!) has turned it into a pain since even with compression it takes around 40 secs to load. The documentation is also not very good and you almost always need to resort to SmartClient, the underlying library.
And of course, I agree with the notion that every tool should be used where it fits best. My guess is there are some amazing Wicket apps out there that would have been idiotic if built in GWT, and the opposite is true. This quick example of yours is useful but of course Jonathan Buchanan showed us that for this particular case the right tool was JavaScript…
@Dario
I strongly recommend the Manning book Wicket in Action.
Couple of comments:
> moving visual blocks around your app
This is indeed debatable but IMO this is easier to do in HTML / CSS than mess around with layout managers.
> messing with HTML files with scattered “business rules” is something I’d really like to never do again
Ah, then you will really like Wicket because the creators took a conscious decision to not allow *any* logic in the HTML templates, all of it is in Java. Have a look and see for yourself.
Given than the evaluation was done a year ago, but there are still recent comments, it’s be interesting to redo the comparison in the latest versions (hint).
Pingback: Atanas Roussev – J2EE, Java Developer, UI Engineer, Resume – Vancouver » Blog Archive » Java web frameworks – GWT and Wicket
i dont know either framework right now
and reading wicket code looks better from maintainability point of view
I would hate to use an api where you have to pass 0,1,2 as arguments
dont we have enough bad experience with java Dates and Calendars?
Just for the record – this is easily done in Adobe Flex, and you avoid the pains of GWT. You know which pains I mean – there are still significant difference between how GWT applications work in different browsers. Particularly once you add pop-up windows etc (you can click components behind a modal window in some browsers, and not in others, events are fired on the background in some browsers and not in others – the differences are significant and problematic).
The easiest way to do this in Flex (or Silverlight for that matter) would be to use a list with custom components. Remember. That stuff you can not really do in most framework.
Flex and Silverlight are application development tools. You develop applications the same way you used to do for desktop apps. You don’t muck about with html tables and divs.
For LOB (in-house stuff, where the vast majority of SW development happens) creating major apps in GWT, Wicket, JSF is absurd compared to using Flex or Silverlight.
If it really is so easy as you say, please implement the example and let us all know. Until then, just for the record – I don’t believe you at all.
Peter – it makes me sad that your religion is so strong that you have to assume that all people you disagree with are liars.
The easiest way to write this would be to implement a listbox with an item renderer. The itemrenderer is a panel with two states, open and closed. In a closed state it would show only the sum, in the open state it would have the datagrid with the numbers and the sum. Again – this is not hard to do in Flex, it is trivial.
Which part do you think would be impossible? Creating the renderer in a list? Having a datagrid on a Panel? Please elaborate. In the mean time, to remove some of your stubborn ignorance, read some of the links below.
If you still want to call me a liar I will prove that you are an idiot by writing it for you this weekend when I have time. I haven’t done Flex in about two years, so it might take a couple of hours (including installing Flex builder).
http://livedocs.adobe.com/flex/3/html/help.html?content=advdatagrid_10.html
Again, this is not hard in neither Flex nor Silverlight, it is trivial.
Tsk Tsk. I didn’t call you a liar, just said that I don’t believe that it is possible until I see proof. But yeah, go ahead, label me as religious, stubborn, ignorant and an idiot. Oh my.
Really? And “I don’t believe you” is, in some weird way, not calling someone a liar? Do you understand the difference between saying “I don’t think that is possible” and “I don’t believe you”? Not only do you need to do “Computers 101” over, but it seems you really need to work on “English for dummies” too.
Oh, and my annoyance comes from that one sentence.
Found some time today to download Flex Builder 3 and put this one together: http://www.bivrost.com/tryit/index.html
It’s quick and dirty, and it was trivial. Anything you feel isn’t right? Please take into consideration I haven’t done Flex in a couple of years.
This is not developed the way I would recommend developing a LOB application of any size, I did, for example, not use Cairngorm or any similar MVC/MVP framework.
@T A – yeah, just what I deserved. A lecture on English 101. Based on one line I typed in a hurry :)
Anyway, truce. Really appreciate the time you took for this. Sorry I upset you. But since this ended up goading you into creating the Flex version I personally think it was all worth it :) Keep in mind that this blog post got a decent amount of traffic and for almost 2 years no-one had come forward with a Flex version. I had asked a few Flex experts I knew personally at the time (maybe they weren’t expert enough?) and they were not able to create a Flex example that came close.
Personally, I am in to comparing various web-app frameworks as you can see from my other blog posts. Can you please share the code behind your sample? I would really like to discuss more and compare.
A few things that I feel aren’t quite right:
But otherwise, not too bad :) Looking forward to seeing the code behind this.
Hi, Peter,
Do you know about the many upgrades in GWT last versions (like UiBinder) and how they might change your comparison conclusions?
Regards,
Gabriel
This is rather outdated. It was probably a nice comparison back in 2008. But people are still using the arguments exposed here to choose one or another framework, and that’s wrong.
Both frameworks have evolved, but GWT is now much different than it was back in 2008. First of all, it has much more support behind, better documentation and a bigger community. This is always important. GWT learning curve is lower than Wickets.
Most of this articles tries to make the user notice that Wicket separates code from markup, and since GWT has now UIbinder, all that is all of the sudden not relevant anymore.
And, although Wicket is better for your average blog app, I want to see how you achieve features as MVP (easy unit testing) where you really program a very elegant web application able to interact with all components you have in screen without round trips to the server. Considering that HTML5 is around the corner and GWT is starting to support it (I wish I could say the same about Wicket), one could create a completely stand alone application that runs on the browser and access the user’s computer resources without any need to go back to the server.
Wicket AJAX support is most a gimmick than something else and it really feels like a hack.
And you should’ve mention how wicket store all your history in your session object and how it can grow and destroy your scalability.
@ulon
I’ve had a look at UIBinder, but I’m not convinced if it makes the example here significantly better. For the benefit of readers, here is the link to UIBinder documentation:
http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html
Take a look at the first “Hello World” example. It looks like a lot of work to just replace the contents of a simple <span> element. Right now I don’t have the time or interest to learn all that. But yes, those reading the blog post now (2010+) should take a look at UIBinder and see if it makes things any easier. Better still – if you or anyone else can provide the code, I’ll be happy to update the example and do another blog post if required.
Since you asked, Wicket has excellent support for unit-testing. There is no need for specialized support of HTML5 as you are in complete control of the markup.
If you feel that Wicket AJAX support is a “gimmick” and a “hack”, that’s too bad. All the best with GWT.
Those worried about whether Wicket can “destroy your scalability” can take a look at this blog post:
Pingback: Confluence: EFETnet
Pingback: Confluence: EFETnet Hub
Hi ,interesting discussion.
if your web application is destined for millions of concurrent users,use “GWT” and push the data and process to client machine .
If your web application is for 100’s and 1000’s and needs to be secure and will be in intra-net or vpn then use “Wicket”, “ItsNat”. —
ItsNat is an ultimate server-side technology managing a dom for each client and replicating it on the client browser by JavaScript tailored to the specific client browser. user events fire event handlers in java which in turn modify server side dom which again is replicated to client browser automaticaly.
So you have to choose the path based on your need.
One has to give this to GWT – “millions of concurrent users” becomes an easy possibility as there is no serverside state required.
Wicket – however nice and well engineered, can serve limited clients as there is serverside state being maintained.
Please correct me if I am wrong in this regard about Wicket.
Thanks.
It would be great if you could post the source code. I am trying to learn wicket. Thanks
Isn’t it from the security point of view better to keep a server-side state?
I am trying to understand if it is possible to have GWT code merged with a standalone app code ( such as Swing ) and tell to the gwt compiler to not pay attention on Swing stuff but only generate JavaScript from GWT part of the program.
Pingback: Confluence: External Projects
Ok – Its 2013. Can I request a favor to do a similar comparison now with GWT and Wicket? Gurus on both sides can provide their input. We are planning on a new web2.0 project but with a mix of RIA and some heavy server-side calculations. I am still at crossroads because I see pros/cons for both wicket and gwt.
Thanks,
Mike
Pingback: Confluence: Product Info