I really enjoyed the first interview I did some time ago with Robert Elves, from Mylyn. I find very nice to gather some opinions and thoughts from relevant people in our field, and specially people involved with Open Source Software.
This time I was lucky enough to make an interview with Eelco Hillenious and Martijn Dashorst, from Apache Wicket. I’m pretty happy with the results, and I hope you guys enjoy it too. On to the interview!
Bruno Pereira: How did you first get involved with Wicket?
Eelco Hillenious: At Topicus where I worked a few years ago, we had been looking for good web framework for a while to help us address the issues we had with scaling our developing effort. We were doing a couple of reasonably large projects using web MVC frameworks Struts and Maverick. The user interfaces were quite complex at times - they had things like nested tabs, wizards and paginated lists - and we had a hard time implementing them with those frameworks in a maintainable fashion. Also, we were bummed by the fact that we couldn’t reuse parts of what we did elsewhere in a project - search/ result panels for instance - and that we ended up with so much copy paste code and ad-hoc session usage. And for one of the projects, we were developing customer-specific variants. Again, we ran into the problem that it wasn’t easy to reuse elements of the user interface that we had developed elsewhere.
Another reason we were looking for alternatives for web development with Java is that we saw that colleagues who were using ASP.NET were faster and produced better maintainable code than we were with Java. They even had more fun doing it; pretty much everyone on the Java team hated to do the web work.
I started out evaluating JSF, which was by then nearing completion. In my experience however, one of the major problems with the way we were developing web applications was the fact that so much logic was put in templates. Not only does that make refactoring harder, it also means that you get thrown back to a procedural programming model where you can’t reap the benefits like static typing and encapsulation, etc. So I wasn’t to crazy about the role JSPs play(ed) in JSF. I did give JSF a serious look though. I read a book on it, walked through the source code and created a simple proof of concept. But the further I got with it, the more I hated it, up to the point that I simply didn’t want to put any of my spare time with it. I just didn’t like much of the architecture, and man, creating custom JSF components was even more work than creating custom JSP tags (which isn’t exactly the most elegant thing to code either).
After that I looked at Echo. I liked Echo. I still do in fact, even though I never actually worked with it. However, I didn’t think it would be a good choice for what we were doing, because it works with layout managers. As much as I like Swing coding, I actually prefer working with HTML/ CSS to Swing’s layout managers. Furthermore, I had this hope that one day we wouldn’t be translating Photoshop designs into screens ourselves, but rather have a designer creating mockups for us that we could use with minimal adjustments.
I also gave Tapestry (3) a serious look. I started reading Tapestry In Action, looked at the source code (which imho looked a lot better than JSF’s), and started experimenting. Halfway through the book, I had a big stack of ‘why?!’s. I could agree with the thoughts behind the concepts, but I didn’t agree with some of the solutions. Abstract classes, rewinding; it just had this stench of premature optimization to me. Still, I was ready to introduce Tapestry at Topicus, as I thought that it at least looked like an improvement for us. When I started talking to colleagues about this however, it turned out that some people had actually used it before and were quite unhappy with it. I would clearly make a couple of people unhappy by going through with it, so I didn’t.
A couple of months later - I kind of had given up for the moment - colleague Johan stormed into the office saying he found the framework we’ve been looking for: “Wicket”. It was (and is) centered around ‘Just Java’ programming, with clean templates and reusable components. I remember we checked it out, had a simple example running in under an hour and were pretty much sold to the framework that same afternoon. Wicket was very rough, incomplete even, back then, but it had the core ideas right. It was still alpha code, but the code base looked very well engineered, and Wicket already worked well for the things we tested.
So we started building a prototype with Wicket. We had a fun few weeks, and we already agreed that this should be the framework that would give Topicus their competitive edge in the near future. We also felt we weren’t ready to be transformed to be ASP.NET coders just yet. But then Jonathan Locke - the inventor of Wicket - sent a message to the list that he was about to shut down the project because he accepted a job at Microsoft and it would be a conflict of interest for him to keep working on Wicket. That would have such a waste to let that happen! So I got Johan and Martijn in a room, and asked them if they wanted to help out and take Wicket over. We agreed to commit to at least a year of whatever it would take of our spare time to turn
Wicket into a mature project suitable for Topicus, and hopefully with a viable community around it as well. We also invited Juergen and Chris to join us. They were already active on the list and had sent in a few good patches. The cooperation turned out great, and when Jonathan left Microsoft again a few months later (for unrelated reasons), we welcomed him back into a Wicket that was quickly approaching a 1.0 release and had a good core of early adopters.
Martijn Dashorst: Mostly like Eelco’s answer, but from a different perspective: I was a Windows client developer used to build GUI’s with Borland’s VCL. Then I had to build web apps using Maverick and Velocity. I hated that experience and constantly asked myself: WHY is this so hard and so much work. Wicket salvaged me from this negative experience: it felt like returning to VCL programming and for the first time I enjoyed
building web apps.
BP: We have perhaps a hundred Java web frameworks, and Wicket was not among the first of them. However, I like to put Wicket in a separate class from the others, as it offers a new paradigm of web application development. How would you say Wicket fits in this field and what does it bring to Java web developers?
EH: Many of these alternatives are really flavors of the same model 2 ideas. In my opinion, there are basically these frameworks - Struts, WebWork, SpringMVC, whatever-the-flavor-of-the-day - and frameworks like Wicket but also GWT, Echo and Tapestry that really provide a different alternative.
Most web frameworks go through great lengths trying keep their users far away from regular Java programming. Wicket provides a programming model that stays as close to Java as it can, with all the advantages of static typing, encapsulation, etc.
BP: JSF is perhaps Wicket’s strongest competitor (if there is such a thing), and it benefits from Sun’s support, good development tools and a huge set of avaiable components. How is Wicket evolving in terms of tooling support and avaiable components?
EH: Frankly, I think JSF isn’t doing so great when it comes to the availability of components. Much like the component market for ASP.NET, there is a lot of promise but not much delivery if you ask me. Yes, there are a bunch of component libraries out there, but they are often incompatible and are often quite monolithic. The latter is JSF’s fault really.
The fact that Wicket tries to make creating custom components as easy as possible (ideally, as easy as extending a class and maybe providing some markup that goes with it), makes that it is less relevant what
components are out there. You want to have a good base set of components that are easy to extend and/ or customize, and hopefully people will create their own library of components that suit their particular needs.
That said, Wicket actually has an impressive range of custom components. Besides the decent number of components that are available as part of the core Wicket projects, there are a ton of projects in wicket-stuff (of varying quality, but there are a few real gems in there), and there are initiatives like DataBinder and InMethod that provide custom components.
But really the best way to go with Wicket in my opinion is to create a layer of base components for your project that look and behave exactly what you need. A little bit of work upfront, but it can save you a lot of work and maybe even code duplication later on.
FWIW, I don’t view JSF as our largest competitor in Java land; I would think that is GWT. There’s pros and cons to both GWT and Wicket, and I certainly think Wicket has an edge in some areas, but GWT is very cool conceptually, and from what I’ve seen it is very nicely done and even has tooling support that actually works.
BP: We have seen many Ruby on Rails zealots claiming Java’s dead and that RoR is the next big thing. I’d like to know your thoughts on that. Can we consider ourselves Java’s orphans? 
EH: Nah. The hype is already sinking in, and you read more about infighting dramas than success stories nowadays. I’ve also heard several stories from developers who actually did do one or two serious RoR projects, and as much as they liked having quick results the first few weeks, they got into a mess later on. Basically, their code base grew, they got more people on the project, all with their own ideas of neat DSL-like constructs and gung-ho LOC saving tricks, and pretty soon no-one understood much of what was going in that code on any more. And some of those people actually did have real scaling problems.
Much of the critique on Java from the RoR camp (and others) was quite justified however, and I think J(2)EE can take much of the blame for that. You can develop quite ‘light’ and practical with Java if you just ignore most of the heavy sounding advice you see on ‘enterprise development’ and use your own brain instead. Unfortunately, the idea that the next step in productivity is dumbing down development by providing more wizards, drag and drop tools and servers that clean your house and do your shopping on the side is wide spread. To me, the most exiting thing about the whole RoR uproar was that it brought back the spot light on coding instead of big fancy tooling and servers.
BP: I know several Wicket developers like Scala, which seems to be a very promising new language. Do you think it will become mainstream in a near future? Will Wicket have something done in Scala?
EH: That’s hard to say. I like some of the ideas of Scala. It really looks like an incredible piece of work, and there are plenty of things in Scala that I’d love to work with today. It would make working with Wicket a lot more elegant, and it definitively would make my own code a lot nicer.
However. What almost everybody I spoken to about Scala says, is that Scala provides too much freedom, too many ways to achieve the same thing. They may be right. Part of me says, well, it would be great to have a language just for the experienced people who hopefully know how to use constructs with taste. But then again, I haven’t seen much actual Scala code or discussions on the Scala list that give me that warm fuzzy feeling. In fact, when I lurked on their list a while back, quite a number of the discussion were about how to make notations even shorter (and consequently less readable). Research says that the bulk of the cost of producing software comes ‘after version 1.0′, and that’s my own experience as well. Maintainable, understandable and predictable software is what we need, even if it means that you need to write out a few more lines. Less code is great for maintainability, but it needs to be readable at the very least.
Also, I firmly believe Scala needs a *very* good IDE to succeed. I’m a fan of good IDEs. I like the time they save me when looking at new code (code navigation, javadoc hoovers, code generation and completion). Without good IDE support for Scala, I’m simply more productive with Java, even though it means that I have to implement ugly workarounds for things that would have been easy and elegant with Scala. There are some initiatives for IDE support but I think that to get something really good, there has to be industry support. Maybe one of these days a vendor realizes how much of their effort they are wasting on JSF and see the potential in Scala.
Another thing Scala badly needs is a bunch of people who can sell it. The fact that RoR looked sexy from the start might have been quite an important factor in their success, and Scala currently is probably the un-sexiest looking framework on the planet. And that’s ‘just’ a matter of community building really. I’m sure if people are interested in making Scala a success, they can find people to work on their image and get the name out there.
Anyway, we’ll see. I hope Scala can be a good counter to .NET on the long term; it could be the Java variant of F#, and maybe we’ll get our own taste of LINQ with it.
BP: Wicket started as a project on Sourceforge, then it was incubated in Apache Software Foundation, and finally became an Apache top level project. I’d like you to comment on this process of joining the most respected open source foundation. How was this experience?
EH: It actually started as a project on codehaus. Unfortunately, we had problems getting commit rights after we wanted to take over from Jonathan, and after waiting for a few weeks, we decided to move the project to Sourceforge.
The experience was good. We had a couple of mentors who were great in guiding us through and backing us up with discussions.
What we got from moving to Apache is - amongst other things like image and stuff - that we are even more conscious about our community. I think we always had the proper open source attitude, which means so
much that you try to get people to participate, take them seriously in discussions, and understand that it comes with a responsibility, but now we don’t have just our name to keep high, but also Apache’s name.
Oh, and it was very nice to attend conferences and put some faces on the names of the people who have been slaving on their own cool projects.
MD: Joining took longer than we expected, but Apache folks constantly remind me that Wicket was actually one of the fastest projects to go through the incubator. The slowness was really our own fault: we didn’t concentrate on getting out but were too caught up in maintaining three branches. When we axed one main development branch we were able to get out of the incubator in a couple of weeks.
Apache brings us a solid legal foundation to our code. Although this adds more ceremony to releasing and accepting new code made by third parties. I think it is worth the extra effort to have a solid legal foundation at the base of our code.
Another thing that Apache brings and one probably can only understand by experiencing it first hand is that Apache is a Community of projects - not a couple of projects sharing a server. There is a large difference between Apache and sourceforge, googlecode, java.net. The latter three are just servers with a lot of projects on them.
BP: Wicket has a distributed development team, much like most open source projects. I’d like you to describe your development process, and how do you manage the community contributions.
EH: You can find all that on the Apache site! I would say every thing goes very bottom up. Everyone feels responsible to take up things, and activity of most people fluctuates. We have a large, very active community and there is lots of discussion, bug reports and patch submissions (though we can never have enough of those!) happening. We all have our own areas of the code base we like to work on, but in principal, anyone can work on anything. We don’t always do a lot of upfront discussing regarding fixes etc (unless of course, something isn’t clear to start with), but we all keep an eye on the commit logs, and you can regularly see a discussion start about a commit, sometimes resulting in rolling back or further tweaking the code. We’ve worked like that from the start, and I still think it works great.
BP: You guys are finishing the writing of Wicket in Action, the second book on Wicket. I read the first seven chapters, and the book helped me a lot understanding some aspects of the framework. I’d like you to talk about the book experience, and how do you expect it to help Wicket’s adoption.
EH: The third book by now even! Kent Tong also wrote a book on Wicket.
I hope the publisher isn’t reading this, but I hate(d) writing the book. Martijn and I did it primarily for Wicket and it’s community, so that people would have some more ammo convincing their managers to adopt Wicket, and to give Wicket’s users a better understanding of how Wicket can be used successfully. Neither of us wrote a book before, and we figured, oh what the heck, it’s something to brag about in front of the grand kids when we’re 70. Well, we certainly hope the bragging will be good, and many people will benefit from reading it, because it was a lousy experience for us. It brought me back to high school, when I pretty much never did any of my home work (in fact, I would often skip school to work on my C64 programs), but still had enough of a conscience to feel guilty about it. Writing Wicket In Action was like that. I would put things off - hiking, making music, checking out bands - because I felt I had to reserve my evenings and weekends for writing. And often, in the end, I didn’t even get to do much because I was uninspired, or a friend showed up, or we had to do shopping or cleaning the house. And then I’d feel guilty again!
I would sum it up by saying that for me it felt like work, whereas coding on Wicket in my spare time felt like a hobby. If I would do it all over again, I would take a few months off and write during the days. That would probably make the whole thing acceptable (though coding is still much more fun).
MD: One remark: don’t write a book in your spare time. Eelco and I have been writing this book for over 2 years now. This means: no hobbies for 2 years. Bringing laptops with you on vacations to write. Staying
up until 2am writing and getting up at 7am because the day job also needs your attention. And all this for more than 2 years.
If I would have to do it again (which I doubt, my wife would kill me), I would do it full time instead of in the little hours after work.
The book itself is coming together quite nice. We have quite a lot of folks that help us with the book: our early access readers (THANK YOU!) and we have an excellent editorial team. Since Wicket has such a large surface area, I even use the book to learn more or look up things. So you can say it caters to both beginners and more experienced Wicket users.
BP: Wicket recently released the 1.3 version, the first after becoming an Apache project. Could you provide us a vision of the current state and the future of the project?
EH: We are regularly discussing this on the list, and we’re currently working on Wicket 1.4.
1.3 is a solid release. 1.2 can be used in production environments just fine, but 1.3 is optimized in many ways, and we got most of our API streamlined in a fashion that should last for a few years now.
1.4 has a limited scope in that it only introduces generics and Wicket with a couple of other Java 5 features people have been wanting for a long time. 1.4 should be backwards compatible. You’ll just see plenty of warnings when you don’t use generics. So Wicket In Action should be good for 1.4 without adoption.
What we’ll do after that is open to debate. We definitively got the message from all the ex-Tapestry users that we should not go overboard with API changes between releases, so we’ll do our best to keep providing smooth upgrade paths between releases.
One thing we’ll probably look at is how to make controlling what URLs are generated even better. This is very flexible already, but a bit clunky at times.
Closures could make Wicket a lot nicer to work with as well. Though, considering that we just now switched to Java 5, that might take a while to get into the framework.
And who knows… if Scala gets good IDE support and a good sized following, I think it would be exiting to see what we could do with it in for Wicket. I think we could build on top of the Java version, and provide a thin framework that makes working with Wicket in Scala smooth.
MD: The future will bring beautiful things. I expect us to work on better integration with JavaScript libraries and trying to implement the Yahoo rules for performance (merging javascript files into one to limit the number of http requests, etc). Versioning of JavaScript libraries is also something I like to see solved in the future. We are also going to take a good look at our unit testing framework: it is pretty solid but the API doesn’t feel Wicket like. I’d also like to integrate an animation framework into our Ajax implementation to
enable effects when updating pages. I think that it currently is harder to do than strictly necessary.
BP: Closing thoughts…
EH: Thanks for the interview! And download the first chapter of Wicket In Action for free at: http://www.manning.com/dashorst/; even if Wicket isn’t your thing, I hope it gives readers some background in the problems it tries to solve.
MD: I know that a couple of Brazilian companies have adopted Wicket for their main development. I’d like to see a Brazilian community evolve and generate such events as we have in Europe (Amsterdam, London, Copenhagen) because I’d love to visit your country again :-). If you are not a Wicket user, then check out our examples: http://wicketstuff.org/wicket13 or http://wicketstuff.org/wicket14 (may not be available now, but will in the future). Our community is very welcoming and active: join our user list to ask questions and
help out. Join the dev list to help us make a framework you want to use. And if you don’t fancy email, you can join our irc channel that is always available: ##wicket at irc.freenode.net. Obrigado!
Well, if you read til this point, I hope you’ve enjoyed! Please leave your comments if you wish.
5 Comments | 
design, posts em português | 
Permalink
Posted by blpsilva