As to "How was it difficult?" Don't know. Nothing official came out. I'm so low on the food chain I don't have many details. All I know is what leaks out through the grapevine.
In any case, whether the new frameworks will be better worse. I have no influence over what course the corporation takes. The high level architects & budgeteers have already decided our course, apparently. From: Ernesto Reinaldo Barreiro <reier...@gmail.com> To: users@wicket.apache.org Date: 01/03/2014 12:59 PM Subject: Re: Rationale for Converting to AngularJS/Spring MVC 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. ** This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies. **
