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.


On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki <> 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:
> For additional commands, e-mail:

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

Reply via email to