Apache Wicket – three years of lessons learned | Hacker News Reader

Apache Wicket – three years of lessons learned

blog.bosch-si.com

6 pointsrohshall6 comments

Wicket is a single design flaw:

-no clean dependency injection possible due to the "page" life cycle

-inheritence hell out of the box with coder kiddies thinking adding even more subclasses would be "clean" and maintainable

- excessive round-trips required in the build and test cycle

- breaking Maven conventions w.r.t to resources and Java classes which f###'s up Eclipse workspaces

Compare this against Bootstrap and a lightweight server-side implementation which can be learned in a fraction of time compared to Wicket's "different" approach.

great "design"

Which light-weight server-side frameworks you would recommend then? apache click? I could not find any which is popular.

Rails/Grails/Node ... I'm still using Spring MVC a lot for implementing REST-like APIs (annotated controllers are all I need). These APIs are the foundation for client-side templates (currently I prefer Handlebars) then.

Granted... Spring MVC requires a round-trip for API changes as well compared to more dynamic languages but it's quite short due to the compact and focused backend-code base.

BTW: one more thing which I initially did not mention is that Wicket generates a hell lot of client-side code with loads of nested DIVs (per component probably), weird and long wicket IDs which tell you nothing (they are automatically created). Pretty tough to get used to - especially for someone trying to understand what happens "under the hood".

Thank you. I was under the impression that Spring MVC (actually Spring, in general) requires a lot of XML configuration. But, maybe it's the best bet now. I checked out Play 2.0. It's a nice framework, but documentation is sparse, which is a show-stopper for a newbie like me.

Server died. Here's the Google cache version: http://webcache.googleusercontent.com/search?q=cache:-UXdDxO...

Reply on news.ycombinator.com