Speaking of which... The technology radar disapproves of JSF and similar frameworks (i.e. server side component oriented frameworks):
> We continue to see teams run into trouble using JSF -- JavaServer Faces > -- and are recommending you avoid this technology. Teams seem to choose > JSF because it is a J2EE standard without really evaluating whether the > programming model suits them. We think JSF is flawed because it tries > to abstract away HTML, CSS and HTTP, exactly the reverse of what modern > web frameworks do. JSF, like ASP.NET webforms, attempts to create > statefulness on top of the stateless protocol HTTP and ends up causing > a whole host of problems involving shared server-side state. We are > aware of the improvements in JSF 2.0, but think the model is > fundamentally broken. We recommend teams use simple frameworks and > embrace and understand web technologies including HTTP, HTML and CSS. While they open with a clear message: don't use JSF, it is actually a jab at Wicket, Tapestry, et al. I don't agree with them (other than that Wicket/JSF/Tapestry are no golden hammer): I still think the model is valid for many use cases. Especially large and complex applications is where Wicket really shines: reuse, proper abstractions, state management, back button support to name a few which are hard to achieve with "simple frameworks": we did that in 2004, did not like it, still have state management issues haunting us today. Martijn On Thu, Jan 30, 2014 at 12:15 PM, Martin Grigorov <[email protected]>wrote: > Hi, > > At > > http://wicketinaction.com/2014/01/capture-javascript-errors-and-log-them-at-the-server/I > posted a short article about something recommended by ThoughtWorks' > radar <http://www.thoughtworks.com/radar/#/techniques> > > > Martin Grigorov > Wicket Training and Consulting > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
