If you’ve read my previous posts, you’ll know that I’m on an unending quest for the right Java web framework. While Faces shows some promise, I’ve got this conviction that the future of the web-layer isn’t going to come from Sun. Call me pessimistic, I don’t care, i’m just not excited by the technology. …..so I thought I start another food fight by communicating some positive and negative first impressions about another Java framework - Wicket. Read more…
To Tapestry lovers, before you decide to write a rant about how Tapestry is the one true way, please understand that I already know that. I chose to evaluate Wicket because I don’t know Wicket, please calm down a little bit about Tapestry and read a bit about Wicket, maybe there’s something to learn, maybe not. Thanks.
Wicket First Impressions: A Summary
It’s different, in some ways refreshing, but like all web frameworks, it comes with a special set of problems. It’s a little code heavy to be considered cool by the Web 2.0 crowd. But, at the risk of sounding like a Java developer, there’s nothing wrong with writing compiled code now and then, and Wicket seems to make it easy to approach web application design from an OO “mindset”. In terms of web development, Wicket avoids the Markup <-> Code impedance mismatch by making a clear choice to favor Java over markup. You won’t be writing JSP code, you won’t be fumbling around with some tag library and then figuring out how to convert a set of form fields to an object. Instead, you’ll be writing Java code (with a fair number of inner classes and anonymous types). It is certainly a different approach than most J2EE developers are used to, and if you are new to Java, it’s entirely different from the (A|J)SP approach.
Another Framework? do we need another Framework?
Like many Java programmers out there: I’m am of two minds. On one hand, I’m doing some pretty intense “enterprise” development in Java using JMS, clustered JNDI, writing lots of multi-leveled applications with some pretty complex logic. On the other hand, there’s this constant pressure to simplify (especially at the web layer). So while the Java programmer in me really appreciates Wicket as an elegant OO approach to web development, the Rubyist in me is horrified. This is an internal conflict at least a few of us are experiencing: when it comes to Wicket, here are my two opinions, the bad one first, because it was my intiial reaction:
The Bad: Wicket == More Code, More Tedium, Too “Frameworky”
WTF? Wait a minute, so we go from something like Ruby on Rails where I’m templating in Ruby and can do anything in the world, straight to having a Java class for every page and having to have HTML files sit next to my Java classes. Are you insane? Please help me out here, just creating a link between two pages requires:
- The Creation of an Anonymous-type in a Page class: add( new Link(”viewLink”, new ViewProductPage(this, product.getId() ))
- Referencing of this link with some wicket:id: <a href=”#” wicket:id=”viewLink”>view</a>
Wicket is an awful code explosion, written by Java-intoxicated programmers. If you are looking for lightweight, nimble framework, a framework that could conceivably be used by semi-programmers or the usual half-wits who occupy your average corporate IT stable, this is not the framework for you. In fact, compared to something like Ruby on Rails, this framework has a steep and somewhat endless learning curve that can be summed up by the phrase: “just copy the example code, and customize it”. But, if you’ve tried doing anything even remotely involved, you’ll no doubt run into increasingly cryptic error messages like “_
” component not found, for which there is no good answer on google or nabble because CONGRATULATIONS! you are one of the first dim wits to start using this framework. Good job early adopter, on a river with no oars.In this age of lightness, Wicket is a heavy hammer. If you are looking for Hello World in 1 minute, run toward something else as quickly as you can.
The Good: Why Wicket is Great Framework
Code heavy? That’s a valid criticism, but I’d rather have code heavy for some problems than be stuck messing with markup all the time. Listen, I want a collapsible AJAX tree, and I don’t want to A.) Write any Javascript, B.) Have to deal with figuring out how to install some tree component (from some project like Dojo), and I certainly don’t want to have to spend multiple hours debugging some cross browser nonsense with how IE and Firefox respond differently to body onLoad events. Call me a contrarian, but I’ve got a lot of money and time invested in my code, and I just don’t care to rewrite everything in Ruby on Rails just because it happens to be the latest fad. I’ve got an object model, I’ve got a persistence library thanks to hibernate, and I’ve got good separation with the Spring Framework, now my boss wants me to make some fancy-nancy AJAX-enabled web site, and I don’t want to juggle the Rhino book and the Ajaxian website. AJAX is great, but it’s also something of a tar pit if you don’t do it right.
See here’s the problem, AJAX development with something like RJS and Rails only scales so far, once you start getting into the business of creating extremely granular AJAX interactions which change multiple DIVs you’ll find that you’ll be managing IDs of practically everything on your page. You’ll end up having to code some fairly ridiculous complexity into your code just to manage the coordinate system of your HTML document. Check out this TreeTable example. Doing this in Rails and RJS or Struts and DWR or any other framework (except maybe Faces and Tapestry) would take a great deal of complexity. Wicket creates that table in no time at all.
Sure the learning curve is a little steep, but once you catch on, it makes perfect sense, and contrary to my negative opinion, the fact that there is a rich set of examples makes it easy to figure out how to: implement AJAX trees and tables, data grids, without spending days and days reading umpteen blogs and “participating” in hostile, low-traffic development mailing lists. You might have some trouble getting the Spring integration to work properly, but if you’ve alredy got a bunch of DAOs in Spring, hooking them up to your Wicket models, applications, and pages is as simple as putting some annotations on your Page’s member variables.
if you are looking for the Hello World in One Minute framework, there’s a good chance that you are not developing a real application. Wicket brings complexity in the form of a rich component framework, but this complexity brings with it the ability to code a web site without having to code yet another table, or yet another paging mechanism. Believe it or not, the code you end up creating with Wicket is clean, and from what I’ve seen you don’t end up making any compromises wrt to separation of presentation and logic.
What the hell is a ‘wicket’ anyway?
The definition of a Wicket will make absolutely no sense to you. Here’s the first definition: “Either of the two sets of three stumps, topped by bails, that forms the target of the bowler and is defended by the batsman.” then there is the second definition, “A batsman’s innings, which may be terminated by the ball knocking the bails off the stumps.”
So wait, what? I don’t know, cricket is a mystery to me.
Wicket Extensions, Wicket Stuff (Spring, Groovy integration)
Depite all my complaining about Groovy not being a real language (compared to Ruby), it is a refreshing break from the verbosity of Java. Wicket provides interoperability with Groovy in the form of a seperate integration project. Wicket 2.0 (which you’ll have to build from Subversion) has some good contrib add-ons for scriptaculous, prototype, Dojo, hibernate, Spring, all the usual suspects. I just wrote an extension library for Wicket myself for a Flash video player and it was a pretty straightforward task once I copied an existing widget.
Conclusions
If you are looking for something lightweight that will take a few minutes to learn, Wicket is not for you. If you are looking for a component-oriented approach, Wicket is a contender. It requires some up front investment of time, and the documentation isn’t 100%, but the applications I wrote in Wicket are cleanly designed and easy to modify. It is a refreshing change of pace for anyone grown accustomed to the disaster that is Struts 1.x, and along with Tapestry it is one of the logical choices if you are looking for a component-oriented alternative to Java Server Faces. But, be aware that Wicket isn’t any sort of Rapid Application Development tool, and it doesn’t aim to be one. I use Wicket when I need to create an extremely AJAXified interface, something much more than simple DIV replacement.
The only solid conclusion I can come to about web frameworks after the endless years of searching is that there is no holy grail (despite what people are going to write on the comment thread ;-) ). There is only, “the right tool for the right job”. Me? I like Wicket for some projects, for others I wouldn’t use a component-oriented approach. You?……form your own opinion, but, do me a favor, give it more than a cursory glance before you tear it to shreds, the internet is full of enough hot air.
Hi,
You should look at the Click framework, http://click.sourceforge.net
It is like Wicket, but much more simple ... enjoy!
I've been using Wicket for about a month on a new project, and while it did require a significant up-front investment of time to get my head around some of the concepts, it is more than worth it in the end. It may not be a "Hello World in 20 seconds" type of framework like Rails, but it is powerful, efficient, and scalable (my experience of Rails is that its nice for the developer, but a nightmare for the sysadmin).
Additionally, the ##wicket support channel on irc.freenode.net is filled with some of the most helpful developers I've experience in any free software project (although Rails also has a pretty good support community).
Nice piece, thanks for writing it.
I agree that Wicket is no golden hammer, and probably isn't the best choice for all applications. I got involved in Wicket because I was looking for a framework that would help me deal with building complex applications (complex desktop-like UI, big domain model, many developers) in a sustainable fashion. It is great when you have half of the UI done in two weeks by dragging and dropping and hacking bits together, but not so great if you're banging your head against the wall two months later when the first big refactorings need to be done, new people get on the job and the project starts drowning in complexity. Object Orientation is a good way to manage complex projects, and this is exactly what Wicket tries to achieve: give developers a real OO programming model (most JEE frameworks, with the most notable exceptions imo being Echo and GWT, basically provide a procedural model, whether they are called action based, flow based or whatever). OO isn't the best solution for everything (sometimes a bunch of scripts work better), and neither is Wicket. But we certainly hope to provide a good alternative.
Oh, just one remark about the mailing lists and 'newness' of the framework. If you look at http://www.nabble.com/Java-f787.html, http://www.nabble.com/Web-Development-Framework-f16257.html or http://www.nabble.com/Apache-Incubator-f355.html you can see the mailing lists are actually one of the most active around (the dev list is at Apache now, but the user list has 23245 messages encounting... there *must* be something to find there!). And number of sourceforge downloads just passed 100,000 and the maven hit on ibiblio are about the same. Furthermore, there is a book on Wicket: http://www.apress.com/book/bookDisplay.html?bID=10189 and a second one nearing completion (Wicket In Action).
My point is that Wicket isn't as obscure as it may sound :)
Yeah, that's about right and I agree with Eelco's comments as well. However the case about code explosion is a little overstated. We have an auto-linking feature that eliminates the drudgework of creating link objects everywhere. But more importantly, since Wicket is a fully OO framework, you can use design patterns and leverage reusability to achieve code compression you cannot achieve in other frameworks. For example, one could create a RAD component for doing bean editing. We were talking about calling that kind of CRUD support "Wicket on Wings" (WOW) at one point. Once this reusable object has been designed, it achieves a very high level of code compression by making object editing forms as simple as constructing an editor object.
Overall, a very well written article. Just one comment, although docs are important, I can't overemphasize how useful the wicket community has been at answering all of my questions. I usually get an answer faster than I could googling through docs.
In regards to docs, Pro Wicket book published in Oct last year...
http://apress.com/book/bookDisplay.html?bID=10189
Wicket isn't as obscure as it may sound though. If you look at Nabble, the mailing lists are ranked amongst the most active and the user list has 23,000+ messages (and the develop list probably half of that). There must be something people can find in the archives :) Furthermore, with over 100,000 downloads and about that number of maven hits on ibiblio, I think we can say there is at least some interest. And then there's Pro Wicket from Apress (in stores now), and Wicket In Action from Manning, which will be in stores in a few months.
Another rant to Java to glorify Rails Buzz and Hype. Last time I checked the best next thing it was Python with Zope and now is Ruby and Rails. I dont see where we going with this shaky scripting languages. If you are tired of writing code quit programming career that simple. Programing is to write code and enjoy it, Im still enjoy writing assembly language.
@alpha3000...dude, sorry I mentioned Rails, seems like a really touchy topic for you. Maybe you had a bad experience with rails? Maybe you were replaced by someone who kept on talking about Rails? Anyway, sorry to offend. And, if you like Zope, that's great, more power to you, hey, if it makes you feel better, go back and read the article and substitute Zope for every time I mmentioned Rails. Again, I'm totally sorry for offending you, and thanks for taking the time to leave the comment.
@{wicket people}, you guys respond fast. The bad reaction is exagerrated (admittedly). One thing I'm certain of is that Wicket is a great solution once you get a hang of it, but it is also looks to be a dangerous tool in the wrong hands. I really like Wicket, but I'm certain that people should be required to take a test before being allowed to deploy a Wicket application professionally (half joking)
I was trying to scare people away :-)
Ugh. Sorry about the double comment. I thought it didn't came through :/
I like your standpoint. Sometimes you use this, sometimes you use that.
More Wicket articles here: http://cwiki.apache.org/WICKET/articles-about-wicket.html
To go off-topic a bit (I won't take it personal if this comment vanishes), I first heard of a wicket in croquet, and I don't know cricket either. Was using Wicket a sticky wicket to learn?
"an unending quest for the right Java web framework" - I was on that same quest until I found wicket. Now as for me and my house, that quest is over at least for a light-while. happy searching to those still on their quests :)
Tim,
I've said the same thing about people taking a competency test before building a production app with Wicket, particularly around Wicket's models. There are training courses offered for Wicket for teams that want to jump in with both feet.
Oh yeah, I forgot to plug that :) For support, there is www.wicket-support.com and skillsmatter.com/wicket-training-course
Have you looked at the click framework yet?
@arturo, Ricardo,
Haven't look at Click yet, but I will, and after a few months I'll let you know how it went.
And Wicket has moved over to the Apache Incubator. I wonder how Apache Wicket will differ from Plain Old Wicket? Maybe moving to Apache will afford the opportunity to get rid of the Hungarian "I" prefix from the Wicket interfaces. ;)
@C Gardner,
Seems like these days Apache doesn't have the transformative effect (for better or for worse) that it used to have on projects like Wicket. In the past, moving to the ASF meant attracting the attention of a large group of developers (both good and bad), these days it seems like communities that move through the ASF incubation process retain more identity than they did in the past. This has a lot to do with the decision to break up Jakarta made by people long ago.
Changing IModel->Model and Model->BasicModel or SimpleModel or something is probably not feasible at this point. i don't like the idea of changing this now any more than i did the last time we discussed this for weeks because:
- the change would cause confusion and code breakage for no important reason
- the I prefix prevents name collisions between interfaces and classes of the same fundamental name. you can rename IModel->Model and Model->ModelImpl or ObjectModel or SimpleModel or whatever, but that extra piece of the name is just as arbitrary and meaningless and distracting as the 'I' prefix.
and btw, although it's a prefix, it's not really hungarian. hungarian notation was used in C to deal with typing problems that can't exist in java. the purpose of the I prefix is not hungarian at all, but rather to increase transparency of names when reading code. if your interface is named Model instead of IModel, your code is less transparent because you MUST go read that class definition to even know that it is an interface. if the interface is named IModel, you know the very first time you see it and without looking at the .java file that it's an interface. while it seems like clutter at first, it does actually increase the readability of source code, particularly if you're in a hurry and don't know the entire system.
anyway, that's my two cents. i don't care to argue this point since it's a religious issue and i'd prefer not to change it, but it's up to the community.
I love Wicket but agree that it might be dangerous in the wrong hands. With large development teams most code eventually ends up in the wrong hands.
If you understand the power of OO and know how to apply patterns to reduce complexity you can do great things with Wicket. If your developers don't understand these concepts you will probably end up with 3000 line java classes being used to implement complex web pages.
I would also like to see a comparison between Wicket and Click by someone who has used both.
I don't agree with the learning curve argument. I learnt Wicket basic principles in 1 day, and i'm far from being a genius ! The thing is that if you know Java, you know Wicket. In response to Paul Lee, i think that java developpers who don't understand OO programming will produce dumb code, whatever good is the framework you give them, and they'd better try PHP ;-)
@Landry Soules,
Learning basic priniciples isn't the tough part. I can teach you all the basic principles of Java in about a semester. You can faithfully record them in notebook, and you can even pass tests with trick question. Taking that knowledge, internalizing it, and then being able to use it to create something novel is usually a much longer problems.
Let's take the infamous "Learn Java in 21 days" book. You can read learn Java in 21 days, you can think that you've really understood Java, but it'll take you a few more years to get to the point where someone will feel comfortable asking you to use Java in a professional setting.
That's what I'm saying about Wicket. Sure, basic principles in a day, no sweat. But, try going out and coding a very complex Wicket site after a single day, and I promise you'll get a lot wrong. Wicket, like just about any other technology, is all about trial and error, and like other similar technologies (GWT or Struts 2), no matter how quickly you read the material, it if difficult to rush the process of understanding.
And, that's the difference. Sure, you can "learn" Wicket in a day, but it's going to take longer to really understand Wicket. And, by understanding, I mean not just how to do it, but why to do it, and when to not do it.
@Tim: Sure, you can "learn" Wicket in a day, but it's going to take longer to really understand Wicket.
s/Wicket/[Struts|JSP|WebWork|Tapestry|JSF|Driving a car|Having sex]/g
There is no silver bullet. Wicket works for X, Y works for Z.
Imo rather than depending on reviews from other people - however interesting it is read such opinions - everyone should really spend a few hours with every alternative they are evaluating. It's good for your skills and as an added bonus, you'll actually have something of a based opinion rather than an idea what others think.
So Click... yeah, everyone reading this, just give it a try. I did that roughly a year ago, and decided Wicket addresses my needs better as it supports an arbitrary hierarchy, whereas Click is basically page based (like Tapestry is). But don't listen to me... just download it and play with it a bit and see what suits you best! :)
Wicket is probably "harder" then most frameworks out there: not because it requires the developer to write more code, but because it requires the developer to have a more complete understanding of Java and OO principals. Wicket was designed from start to be an OO framework. We can discuss various advantages and disadvantages of OO until we all get blue in the face, but I think what we can all agree on are a couple of simple facts:
a) OO skills are valuable and having them will make you a better developer - especially when working with an OO oriented language like Java.
b) By learning and using Wicket you will actually learn a lot about OO and become a better developer :) You can read all the pattern books in the world, but until you start applying those patterns in real world situations you are not going to learn anything.
c) Wicket projects offer a great learning playground for newbie developers. Because wicket is so code-centric it allows the developer to use the full suite of refactoring tools that come with IDEs, so you can easily change your code and see the pros and cons of those changes.
The Click framework says it doesn't use JSP, but uses Velocity templates instead. It is still a mix of HTML and non-HTML code in one place and can be as bad.
@Tim O' Brien
Sorry to have been misunderstood : i didn't want to pretend i learnt Wicket in one day. Of course it will take you much more time before you can say you're a Wicket expert. What i meant is that after having tried various frameworks, Wicket was the easier for me to understand, probably because i already had a not too bad OO background. In comparison, after 2 years of Struts everyday programming, i still don't understand some of its basic principles !
Paul Lee wrote: "If you understand the power of OO and know how to apply patterns to reduce complexity you can do great things with Wicket. If your developers don't understand these concepts you will probably end up with 3000 line java classes being used to implement complex web pages."
On the contrary ... if you understand OOP then you probably also know how to implement that 3000 line WebPage subclass into 5 smaller and reusable objects. This is what I have seen many times during my Wicket projects. Many times you start by implementing something ad hoc, just following the page design or spec. And you end up refactoring components from the page into things that are generic enough to put in a seperate project so that you can reuse them for your next project.
This is the real power of Wicket. Instead of hacking together low level throwaway code in 'classic' MVC frameworks you design components that you can reuse many times.
Wicket + Maven has been a nice combi for me. I ended up with many small projects containing reusable components with associated markup and resources that are basicaly plug and play.
Keep that in mind and after a few months of Wicket coding you have a magic toolbox and you will do your next web project in a 10th of the time. While still building more components for the one after that. Whoohoo.
S.
Sorry Paul .. I misread that paragraph. You are probably saying the same thing :-)
S.
Thanks for this post Tim. After your "evaluation" of Click I would appreciate if you let us know your impressions about Stripes.
http://stripes.mc4j.org/confluence/display/stripes
@Landry, no my apologies, I frequently come off as a pontificating jerk ( :-) ). I'm not saying it is impossible to "get" Wicket in a day, and I don't want to assume that you couldn't. I'm just a bit less confident in my own "Time to Grok" (TtG) any specific framework.
@handerson, sure I'll take a look at Click and Stripes, but don't take my opinion over others. I can only tell you my opinion for my context (projects and clients that I work on). I think everyone should get in the business of reporting on experience with software (especially open sources), and unlike the oddball filth we get from Hani, we should be getting more mixed reviews and less marketblogging.
Hey Tim, hope you read this, another web framework? there are a lot of Frameworks around, component frameworks too, Tapestry, JSF, Wicket, GWT, Rife, well a lot of them, and yeah I do believe that you need the right tool for the right job, but for me it seems like we have too many frameworks to choose from.
I think that freedom to choose is ok, and it should happen, but sometime is too overwhelming and especially for begginers, myself, I started working with Struts since 2003, and even though it was not the best, it did help me, especially three years ago. But now, well you need a better framework.
Tapestry is my choice for now, I have been working with it and it's just a relief from all the messy code and messy html that I had to write with Struts (perhaps I did not use it well, whatever) but the community is not as strong as Struts community was (or is), There are some Tapestry books yeah of course, 4 or 5, not comparable with JSF books there should be a lot more.
My point is, how can we give birth to another framework as important as Struts was? in my company .NET is pushing so hard because within the only choice is ASP.NET, and inexperienced developers feel relief, 1 IDE for everything, they are not looking for ASP.NET frameworks, they have that and nothing better awaits or is being developed.
Wicket, Rife, JSF or Tapestry or the thousands of frameworks around (never heard about click before) are nice frameworks, but I do believe we need a big community, a real big community, nice documentation and specially, sweet IDE Plugins, it is dumb to develop new frameworks every day instead of getting a framework to mature.
How can I help ? how can we help ?
Any thoughts on TIBCO GI? I think they recently went OpenSource.
@Luis,
I understand the sentiment, I used to think the same way, but I think differently. Java's strength really is the amount of choice. It might be confusing to some managers and some businesses, but in the past few years Java has seen an explosion of options.
And, we're not just talking about web frameworks, there are a thousand ways to [parse xml|read data from an RDBM|expose a SOAP service]. Many decry this as a negative for the platform - "why can't we just standardize on one?" Standardizing on "one way to make a website", might be good for Sun or for Big Business, but it is bad for innovation and competition.
Anyway, I'm not writing this as a "No, your wrong" response. i'm just trying to communicate that I think the confusing number of options is going to eventually be judged as empirical proof that Java had already won the battle.
Java has so many options because it's the most widely used platform, Java has so many options because it's the common technical language.
Apple might be reaping the benefits of a standard, highly aggregated approach, but I believe that when you focus on the Long Now, they will be forced to open up the platform to innovation and competition.
Microsoft might be reaping short-term benefits by providing single, simple answers for questions like "How do I write a web site in .NET?" But, eventually this monolithic approach is going to be blindsides by the Darwinian approach being taken by Java (i.e. the current rapid species bloom being experienced by Java web frameworks)
I don't wish another Struts, maybe I hope that eventually the meritocracy that is "The Market" identifies a handful of people to pay attention to, but I always want to know that there is a team of people out there with a good idea for a web framework.
IMO, Struts' monopoly on web frameworks wasn't a good thing. Just like Jakarta as a monolithic star-stage didn't make any sense.
i like disaggregation
"I do believe we need a big community, a real big community, nice documentation and specially, sweet IDE Plugins, it is dumb to develop new frameworks every day instead of getting a framework to mature."
I'm good with this approach, so long as it's Wicket we pick. ;-)
I can understand the feeling. However, one of the big, lasting problems with the Java/OS approach to a problem like web frameworks is that the industry is happy to take from an OS project like Wicket, but unwilling to give anything significant back. One of the reasons that .NET ASP is dominant is that it's integrated with Microsoft's strategy and Microsoft is paying scores of people very big salaries to work on it. There's a whole team in some building over there just working on user education and documentation. The same is true of JSF. If Java is going to have a dominant web framework, we need something better than JSF (if JSF was that great, frankly I never would have invested such a huge amount of time in Wicket) and we also need people with well-paid permanent jobs to continue working on that framework as a real product. This simply does not exist because the industry does not have enough vision or organization or quality-focus to do anything about it. The bottom line is: you can't get something for free. OS software like Wicket is great stuff and it will continue to get better and grow, but it simply can't become a product on par with JSF in terms of market dominance without real financial support. The same is true of all these other OS frameworks. They are all the passionate after-hours side-projects of people who are tired of the status quo for one reason or another. If the industry wants a dominant OS framework, it should take a long look in the mirror and then put its money where its mouth is. If the Java community wanted Wicket to be something much more than a side project, it could find a way to get together and actually HIRE the dozen core developers working on this for industry rate salaries. The result would not bankrupt the top 100 companies that use Java web frameworks and it WOULD provide a product on par with JSF or ASP.NET in the end. It's just a matter of resources and long-term thinking. In the end, the software industry is like most big business entities in that is utterly incapable of intelligent long-term thinking. If you stop and think about what would be possible with collective action here (and for pennies relative to what these monster companies make), it's NOT selecting and sponsoring OS projects that ought to be real OS PRODUCTS that is going to cost big business in the end. You have already pointed out some of these costs.
With big community support, Wicket could well become JSF3?
Tim, it is me again, I understand that diversity is a well desiered status, but what I am concerned about is that from my perspective we have not seen something really outstanding in web development, no offense for Jonathan Locke or Howard Lewis Ship, your products are ok, I checked Wicket and looks really nice, but trying to make a point:
for example I would mention some outstanding frameworks or tools
Eclipse, "the IDE", yeah I suppose that a lot of you have been using Netbeans or IntelliJ even the infamous JDeveloper, but I think that eclipse has (or had) a good momentum, and a lot of the other tools have copied features from it, or even have it embedded in the IDE's or at least we know that Eclipse is one IDE that rocks!
Hibernate, it really outstands for persistance, Gavin King was spec leader for EJB 3 (so far I know, might be wrong) and even though some of you might have worked, JDO, iBatis, EJB 2, hibernate really outstands
Spring, it is really ubiquotus, outstanding, the nicer IoC lightweigh container, you might have worked with Pico Container, even Hivemind, but Spring is "the Framework".
But can we say that of any framework that it is out there? JSF? with that tool IDE dependency? is that Wicket or Tapestry? to tell you the truth I doubt that, perhaps the market is too big, and millions of people work with tapestry, wicket, rife, why not?
hibernate, spring and eclipse have nice documentation, nice community and are great great products, do we have the same in web development? yes we do, but can it be that marketing has been troublesome? or really is just a problem for me??? at least in my country is not just me, I can tell you that, diversity sometime is overwhelming and some how or another we need to experience the raise of "the web development framework"
Cheers
Struts is still more ubiquotus than Spring (yes, I mean Spring proper, not Spring MVC). There is no Java Web framework to replace Struts, yet. Of course, in terms of market.
I mean, in terms of market dominance.
I finally found a guru in u man! You are right that theres a right tool for the right job. I guess here ends my quest fro the holy grail and start digging docs.
More power to yah!
It's easy Luis, there are way more variations possible with web frameworks than with ORM and object factory frameworks. There are a couple of frameworks that just copy each other, but most of them serve their own niche, with their own happy following. I think that is a good thing, as if you are informed enough, and know well what you're looking for, chances are you'll find the framework that is just right for you. And sometimes even seemingly tiny difference can result in significantly different results when it comes to productivity, maintainability, etc.
The only problem with too much choice is that it doesn't make people happier; instead they feel they can't make the best choice as whatever they choose, they will miss out on some of the strong features of competing frameworks. And they feel overwhelmed by the number of choices and feel 'the market' lacks transparency because they can't evaluate them all :)
"Wicket" is also the name of the little Ewok who befriended Princess Leia in "Star Wars: Return of The Jedi."
Never trust cute little furry animals with girls!
We've been using Wicket since 1.3 here at Mu - it definitely gets the job done. I have nothing but praises to sing about how it fit in with our Eclipse based appliance platform and the speed and quality it provided for our front end development.
The only problem I have is finding good Wicket developers. So if you want to help me out and live in or want to move to the SF Bay Area, send me an email (jschmidt at musecurity dot com).
Thanks!
PS. Big thanks to Jonathan / Ryan / Eelco / Martijn and the rest of the Wicket gang for their good work!
PPS. Anyone working on a Wicket (Flash) Charting Component?
If you want to do charting in Wicket, just use JFreeChart to draw on a dynamic image (see image examples).
"Click framework says it doesn't use JSP, but uses Velocity templates instead."
Click uses Velociy by default and it is possible to use it with JSP as well.
The Apache Velocity is now a top-level project of the Apache Software Foundation.