If you come here and try to start a flame about how bad Wicket is while you 
obviously have no clue how it works then atleast have the decency to write a 
propert post instead of a lame list of cons (and no pros) and a oneliner saying 
Spring MVC is the only other option...


-----Original Message-----
From: Eric Kizaki [mailto:erickiz...@gmail.com] 
Sent: donderdag 17 november 2011 16:45
To: users@wicket.apache.org
Subject: Apache Wicket is a Flawed Framework

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 Nabble.com.

To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to