Hi, On Fri, Jan 3, 2014 at 6:12 PM, Richard W. Adams <rwada...@up.com> wrote:
> I don't have first hand knowledge of the decision making process, but I > understand there were two main factors: > > 1. Difficulty in changing/maintaining the intermediate corporate > libraries, especially when considering whether to make the leap from > Wicket 1.4.17 to 6.x. > How was it difficult? > > 2. A perception of excessive cost in training new developers to use > Wicket. I myself am fairly comfortable with Wicket now (after 2 years > experience), but have to admit the leaning curve was pretty steep. > IMHO this is not going to improve with Angular.SJ+ Spring MVC: its is going to be worse. 1-With wicket you might hire a very good wicket developer that creates the components / widgets you need and the rest of the team just use those components and be "shielded" form JavaScript and mostly just do "server side". With Angular you will need more developers covering the whole stack (sever side and client side). 2-You can also reuse code at a maximum and if you have a lot of applications/similar screen you can roll out "meta components" covering those use cases... Not sure you will be able to achieve the same so easily with Angular.JS + Spring MVC. As I mentioned before I was working last three weeks with an application built with Backbone.JS (similar to Angular but less high level) + Spring MVC. All the "complexities" of this application would be mostly trivial using wicket. One thing that stoke me the most if the non DRYNESS of development: you change one thing at a place and you have to manually hunt down in all layers how this trivial change will impact application.
