Simon's article is entertaining but of low quality. It contains a few errors.
Wicket received negative points certainly for the wrong reasons. I don't know what Simon tries to address with his criticism of Wicket's inheritance. Designing a web site based on markup inheritance could be considered difficult to grasp. But that is optional and I don't think he even tried to get there. He does not comment on whether other frameworks even provide this. Unfortunately he used this in multiple rating criteria. But he did not mention markup composition and dynamic component replacement which in Wicket is very easy. Components have to extend Wicket's basic components like Panel. This is easy. Not understanding this concept easily would be a concern. His comments on scalability are not convincing. He does not distinguish between performance and scalability. Wicket has a slight scalability disadvantage because of its reliance on session affinity which he did not mention. Wicket generates content on the server like Grails, Struts, Spring MVC, Play and JSF. GWT and Vaadin are more client centric. So he would have to group client side and server side frameworks to clarify. "Wicket works well for scalability if that is your goal when developing the foundation; otherwise, youre better off using another framework that doesnt have such a huge server resource consumption problem." This sentence is nonsense, semantically and technically. It disqualifies the whole article. He would need to clarify what his "foundation" is and provide a scenario to back up his claim of "huge server resource consumption problem". I think it is quite difficult to rate Web frameworks, especially when they are based on different architectures, and have different purposes. Bernard On Wed, 31 Jul 2013 13:56:09 +0200, you wrote: >I don't agree with everything in it, but it's a good article anyway :) ... > >http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/ > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
