Why it is better then JSF?

[Vladimir Shcherbina]

Hi All,

Is it easier to learn ? In any case JSF is a standard...
Vladimir

[Marco Ehrentreich]

Hi Vladimir,

as I understood Wicket allows to easily incorporate many other technologies so from this point of view you can at least integrate official standard technologies. I'm not sure if it's a real hindrance that Wicket itself is not a standard technology. I think there are both - standard and not standard technologies - which are good and others which are not so good, too.

Marco

[Martijn Dashorst]

Originally posted by Vladimir Shcherbina:
Hi All,

Is it easier to learn ? In any case JSF is a standard...
Vladimir

I think the Sun motto is: Innovation happens elsewhere. JSF may have a benefit of being a standard, but it is also its achilles heel. Improvements in the platform arrive at glacial speed because they have to be approved by the committee.

IMO Wicket's biggest advantage over JSF is the ability to really easily create custom reusable components. If you know the extends Java language keyword, you are all set to create your own custom Wicket component.

New comers to the framework are very pleased with the total lack of XML configuration, and the strict separation between the markup and the Java code.

One of the other benefits I think is that you don't need to stack additional frameworks to make working with Wicket a pleasant experience. When you have to build JSF applications, I hear a lot of additional frameworks that are necessary to make it workable: seam and facelets come to mind. This in addition to hibernate and spring. If you are already diverging from the standard by using e.g. facelets, then why not use a framework that was set up to provide this experience from the beginning?

[Jonathan Locke]

I actually think it's quite a lot worse than that. In some sense many of these standards based frameworks are more or less designed by committee, which is a bit like having several authors write a book. Wicket has something like 20 developers now and has branched out to do a lot of things I never envisioned, but I think this has been relatively painless simply because it started with a single coherent vision.

Originally posted by Martijn Dashorst:


I think the Sun motto is: Innovation happens elsewhere. JSF may have a benefit of being a standard, but it is also its achilles heel. Improvements in the platform arrive at glacial speed because they have to be approved by the committee.

[Frederic Daoud]

JSF has many drawbacks. It's not practical. That bloody faces-config.xml file. Templates are a mess. Custom components are way too much work to implement. It sometimes gets in your way for very simple things. Select boxes need a JSF-specific SelectItem class (why??). I could go on. JSF wasn't designed by people who write web apps in the real world and it shows.

Wicket suffers from none of these drawbacks.

JSF has funding behind it - Wicket does not.

Shame on you JSF.

[Peter Thomas]

I made a presentation recently that contains comparison points for Wicket vs JSF, you can find it here:

http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/

[Hussein Baghdadi]

Originally posted by Freddy Daoud:
JSF has many drawbacks. It's not practical. That bloody faces-config.xml file. Templates are a mess. Custom components are way too much work to implement. It sometimes gets in your way for very simple things. Select boxes need a JSF-specific SelectItem class (why??). I could go on. JSF wasn't designed by people who write web apps in the real world and it shows.

Wicket suffers from none of these drawbacks.

JSF has funding behind it - Wicket does not.

Shame on you JSF.

And those are kids??!
http://www.jcp.org/en/jsr/detail?id=127

[Frederic Daoud]

Originally posted by John Todd:

And those are kids??!
http://www.jcp.org/en/jsr/detail?id=127

To be clear, I have no doubt that these people are skilled, experienced, and talented. In fact, that is exactly why I deplore the poor result. Issues with JSF 1.x are even documented on the Seam site: http://seamframework.org/Documentation/JSF2

JSF 2.x might be better, but only time will tell.

[Frank Silbermann]

Originally posted by John Todd:

And those are kids??!
http://www.jcp.org/en/jsr/detail?id=127

I guess comparing Wicket to JSF is like comparing Hibernate to EJB 1 Entity Beans.

In a past life I taught a course on programming languages. A theme that seemed to motivate the progression of languages was the desire for better mechanisms for abstracting common aspects of applications so that code could be re-used. From machine language to assembly language we developed the macro. From assemply language to 3rd generation languages we obtained the subroutine (functions and procedures). Functional programming we obtained higher-order code that could receive operations as input parameters and return operations as results. Object oriented languages could also do this because objects embedded operations, and operations could receive and return objects. In addition, object oriented languages such as Java added inheritance and polymorphism. In Wicket you can use all of those techniques (via Java) to parameterize and re-use your views, and any pieces thereof.

Using JSP, incontrast, is like going all the way to reliance on assembly-language style macros for re-using pieces of your view. I don't think JSF makes re-use any easier -- it mainly gives you more powerful components as initial building blocks and the opportunity for tools to help you assemble them.

The people who created J2EE web technology are not stupid, but I think they were trying to imitate Microsoft technology rather than working from first principles. JSP technology was so that Java programmers could embed Java into HTML files much as Microsoft's ASP let users embed Visual Basic code into HTML. (Then we got a whole lot of frameworks to deal with the fact that embedding programming language statements into HTML was really not a very good idea -- though it was an approach that high school students found easy to comprehend.)

JSF imitated ASP.NET -- which in turn imitated client-server rapid-application-develelopment tools, which were intended to let users design with a WYSIWYG tool and program by entering code and data by clicking property editors. That makes it easier to do the common tasks, at the expense of making it harder to do the less typical tasks. For example, if you want to abstract and generalize some of your view functionality and make it available for re-use, you're expected to build a GUI program (a set of design-side component classes) for developers to execute inside the IDE to enable him to insert your component into programs.

With JSF it will be too much effort to re-use much code. The only advantage is that if you do go through all the trouble of preparing a design-side interface, the your component's users won't have to read the JavaDoc to learn its API.

I think it all comes down to the question as to whether you want a tool that makes it easier for a bad programmer to write bad code, or a tool that makes it easier for a good programmer to write good code.
[ September 26, 2008: Message edited by: Frank Silbermann ]

[Pat Dezenzio]

I might be late on this topic but where I work we have an issue - JSF or Wicket. Our application is 1.5 million lines of code and is loosely based on Struts and EJB 2.0 on top of OC4J 10. Last year we were asked to prototype on eof our common pages in both frameworks and give a summary of what we liked, disliked, and preferred. The architects like Wicket and the developers like JSF. I prefer JSF. I used JSF at another company using RichFaces and it blew Struts out of the water. Yes, the faces-config can get cumbersome, but we also have complex navigation that Struts couldn't handle unless you rewrote the handler.

With this new application, Wicket had its good points - easy to configure and 100% pure Java. The problem is you better be a pretty good web page designer. If you have those skills then Wicket might be your best bet. Most Java developers are not. We are application developers and we leave the page layout and markup to the web designers. The other issue is converting existing web pages. Since you can't have components in one without the other, I found I had to start from scratch and add component by component. I left off all of the complex Javascript since it is very tricky in Wicket. I also did away with CSS for now. What I was left with is an HTML table within table, within table, etc. Since the original screen had tables with pagination, I was able to use Wicket's components. The issue again is the beautification is up to the developer. By the time I was able to convert just the meat of the screen, it took over a week. I also ended up with 16 new Java classes. In my opinion, there is tight coupling in Wicket and I estimate 3,400 new Java classes to replace all of our jsp pages. That's with re-use too.

Then I prototyped with JSF using IceFaces. I chose IceFaces because it seemed IceFaces was a bit more friendlier to configure and it felt more active than RichFaces. Remember, I said I did this last Spring. Being familiar with JSF and Facelets, I had an unfair advantage. It took me less than 2 days to have the page written using JSF and Facelets. That included all validation and formatting. Unfortunately, I was not able to configure OC4J to use Facelets. Here's where things get interesting. OC4J is done by Oracle. Oracle bought up Sun, who made Java and JSF. Oracle says use Web Logic. Fun. Really, by the time we get around converting over to Web Logic, JSF 2.0 will be mature. It does have a tempting feature set and IceFaces and RichFaces are proceeding ahead with JSF 2.0 codebases by the summer.

In short, Wicket is 100% Java and is easier to configure. JSF is more fun and seems easier to learn if you have Struts/JSP background. JSF also has a ton of components that pretty much handle 90% of any task you need to do and you don't have to be a web designer to get a nice site up and running. I also found Wicket can get very bloated - the sample web page took over 3,000 lines of Java code. Told you this application is huge, it's not a login page with 2 or 3 fields on it. Think full-fledged banking application - anything and everything a bank does is in this application. Maybe if this a tiny application I might choose Wicket, but it's been 10 years since I've seen a small app.

[Tommy Delson]

@Pat Dezenzio

I see why you're experienced so many problems and issues by converting to
Wicket simply at the first place you or the team probably didn't have a
clear vision and direction before converting the app to Wicket.

First of all, you and your team probably didn't start the architecture of the application
from scratch in converting to Wicket to determine best approaches, desisgns,
and good pratices on the new framework. If you do I think you and your team might
not experience many problems.

For instance, not everything you have on the existing application or architecture able to
convert nicely to the new framework in this case Wicket. Therefore, one must
be do an extensive research and architecture before decided to prototype or do a converting.

In your situation I'd stick and go with the technology that best fit for the application
and it architecture. Don't try to jump on something that you wouldn't know for sure whether
it works best for your application or not.

Talking about HTML, let the designer or who's good as design do the job so, you or your team
can focus on the coding and the logic. Separating of tasks to each developer and designer
is the best pactices not only for the team itself, but for the application as well.

If you're not good as web design then let or ask someone else do the job. Why taking on
something that you're not good and interest at?

I'd utilize or try Wicket or other framework on the new application rather than converting to
existing one. This could avoid a lot of issues, problems, and headache down the road. And
that's what exactly what I am doing.


In summary I've done quite extensive research about Wicket, so far it's really convincing. It has
all the feature and does all the job in one framework, rather than JSF+Facelets+JSTL+JSP+RichFaces,
Ice Face etc., not counting all the wiring, flow, and configuration of pages yet.This mean you
adding codes on top of other and later your codes look like a spaghati codes.

More importantly, efficient, code reuse, event handling, OO, maintain state session
transparently, desktop like application etc.

Wicket Highlights
*Web application framework
*Component based & Object Oriented
*Just Java & HTML
*Clean separation of Code and Markup
*Easy to create and re-u


Another good referece from other developers' view:
http://ptrthomas.wordpress.com/2007/03/02/wicket-impressions-moving-from-spring-mvc-webflow/


I'd use Spring + Wicket together rather than just Wicket or Spring alone...