Again address the content and not the speaker.  I prompted him to post this to 
get some good feedback on why Wicket is a better alternative than the UI 
frameworks than we have come across.

Frameworks in the ui space are numerous and all serve a different need or 

If all you have to say is essentially you suck, you haven't done anything to 
promote the virtues of wicket and it's ideals.

I like wicket and I've seen
It put to good use  based on the ideals it try's to follow by.

If all you have to say is you suck you're stupid etc don't fucking post.

He's obviously done some research and has as an informed opinion - give him the 
respect by offering a intelligent counter argument to his points or dont post 
at all. 

You really just come off as a  jerkoff zealot.
Sent from my iPhone

On Nov 19, 2011, at 5:29 PM, "Eelco Hillenius [via Apache 
Wicket]"<> wrote:

> Really, is this what you do, go around posting to user lists of 
> frameworks you don't like? I imagine one can have a full time job 
> doing that. 
> Eelco 
> On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki <[hidden email]> wrote:
> > Violates Dry:  You must repeat the component hierarchy of your widgets that 
> > are in HTML in Java Code for no good reason.  If you move your widget 
> > around 
> > in the html it will break the Java and you get a stack trace if you change 
> > the nesting.  You have to keep these two files synched.  A JSP file is more 
> > maintainable.  At least the view code is in one place. 
> > 
> > Not previewable:  One of the supposed benefits of Wicket is a clean 
> > template 
> > that could make pages previewable for designers.  First, we don't have 
> > seperate designers at my company.  Second, it is better if the samer person 
> > does development and design.  Third, if you use extends your page will not 
> > be priviewable outside an application server running Wicket.  This supposed 
> > benefit does not exist. 
> > 
> > Violates MVC:  It smashes view and controller code into the same Java file. 
> > You have code that regulates page flow and code that changes css attributes 
> > in the same file.  Even Spring MVC had better separation of concerns. 
> > JSP/Servlets with Spring MVC is better. 
> > 
> > Excessively verbose and complicated:  What is a LoadableDetachableModel? 
> > The learning curve for Wicket is immense. 
> > 
> > Breaks POJOS:  A real POJO does not need to implement an interface or 
> > extend 
> > a class.  Wicket forces your beans to be Serializable.  This is like using 
> > EJBs in how it forced you to implement interfaces. 
> > 
> > Terrible AJAX:  Compared to a few lines of jQuery AJAX is excessively 
> > complicated and verbose in Wicket.  A lot of things like “AJAX” links 
> > should 
> > not be done via “AJAX” at all.  Hiding a div on the client would simply be 
> > done with JavaScript on the client.  Wicket better not require a server 
> > request for that.  You also have no JSON support and good luck debugging 
> > any 
> > JavaScript or AJAX in Firefox.  Instead you have to use the subpar Wicket 
> > debugging. 
> > 
> > HTML5:  No support for HTML 5 form elements unless you upgrade to Wicket 
> > 1.5.  You will get a stack trace.  The upgrade to Wicket 1.5 is painful and 
> > will break your code.  Good luck getting this to work with jQuery mobile. 
> > 
> > Bad Defaults:  Most pages are stateless.  The default for Wicket is 
> > stateful.  So if I want a decent URL and a bookmarkable page I have to 
> > mount 
> > the page and use a bookmarkable page link with page parameters.  Using page 
> > parameters is worse than how Spring MVC does binding.  I have to keep doing 
> > this over and over for each page.  There is too much work involved to get a 
> > decent stateless page with a nice URL. This should be the default. 
> > 
> > Interferes with other libraries:  It screws up your jQuery code.  It forces 
> > you into a restrictive way of doing web-development:  the Wicket Way. 
> > 
> > Causes a redeploy whenever you add anything:  Maybe Java developers are 
> > used 
> > to this, but in any other web development environment I do not need to 
> > redeploy after adding a text box to the page.  It is completely absurd. 
> > Only with JRebel is this alleviated.  No, embedded Jetty in debug mode 
> > still 
> > slow.  Even a simple JSP file has hot reloading on Tomcat and if I make a 
> > change to my view code the changes are immediately viewable in the browser 
> > when I refresh.  This is WITHOUT JRebel. 
> > 
> > HTTPSession Objects are not hard:  Most pages do not need state.  If you do 
> > use HTTPSession it is simple.  Can you use a map?  Then you can use 
> > HTTPSession.  This is less comlicated than most Wicket code. 
> > 
> > Stateful Component based framework are a terrible idea:  Even at the 
> > theoretical level this is a bad idea. It is a leaky abstraction over a 
> > simple request/response cycle.  It made something simple and made it overly 
> > complicated.  This remind me of Hibernate and ORMS.  I disagree that we 
> > should abstract things to this level and do everything in verbose Java. 
> > People are dropping Hibernate and going back to native SQL and Spring JDBC 
> > template.  SQL and the relational model are easy.  Working with HTTP 
> > requests is easy too.  What was wrong with JSPs/Servlets?  Keep it simple 
> > stupid.  We know JSF was too complicated and it was terrible.  Spring MVC 
> > is 
> > better and has rest support.  It just works with Spring and has great 
> > support for the JSON Jackson mapper. 
> > 
> > -- 
> > View this message in context: 
> >
> > Sent from the Users forum mailing list archive at 
> > 
> > --------------------------------------------------------------------- 
> > To unsubscribe, e-mail: [hidden email] 
> > For additional commands, e-mail: [hidden email] 
> > 
> >
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: [hidden email] 
> For additional commands, e-mail: [hidden email] 
> If you reply to this email, your message will be added to the discussion 
> below:
> To unsubscribe from Apache Wicket is a Flawed Framework, click here.

View this message in context:
Sent from the Users forum mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to