On Sat, Nov 19, 2011 at 9:31 PM, sthomps <stho...@gmail.com> wrote:
> 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.

* the email was written as a statement, not a question.
* it had a derogatory and arrogant tone
* it did not directly ask for feedback
* most of these questions have been asked before and answers are
available in the mail archives


> Frameworks in the ui space are numerous and all serve a different need or 
> perspective.
> 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]"<ml-node+s1842946n408747...@n4.nabble.com> 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: 
>> > http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4080411.html
>> > Sent from the Users forum mailing list archive at Nabble.com.
>> >
>> > ---------------------------------------------------------------------
>> > 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:
>> http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4087474.html
>> To unsubscribe from Apache Wicket is a Flawed Framework, click here.
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4088008.html
> 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

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

Reply via email to