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 -igor > > 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. >> NAML > > > -- > 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
