Bruno Borges @brunoborges made a Twitter poll by the end of October. The question was If you're a server-side #Java developer building web apps, please respond: have you ever tried/used Apache #Wicket?
The final results are (from 1,128 votes) : 13% Yes, and I like it ! 9% Yes, but just tried 12% Yes, and didn't like 66% No. What is Wicket ? To all Apache Wicket Users, your contributions to the analysis of these results are very important. Remember any thoughts, any contribution are very welcome ! François > Le 1 nov. 2016 à 18:11, Mihir Chhaya <mihir.chh...@gmail.com> a écrit : > > I would like to share my personal experience from developer's perspective. > First and foremost, I personally love Apache Wicket more than any MVC > framework I have worked with so far (Struts/JSF). This is just me. > > The place I am currently working adopted Wicket 1.4 around 2012. That time, > the management in general was relying on individual developer's technical > skills and abilities. Everybody was recommended to use Wicket 1.4. I > personally evaluated couple of different options and then picked up Wicket > 1.4. > > That time, Apache Wicket in general was lacking good documentation, good > third party libraries and community awareness. Not any more. > > My other colleagues and developers eventually started working with Wicket. > Many applications got developed using Wicket. Most of the time the code was > 'copy and paste' from components point of view. We had working components > developed in-house; but no solid third party components except in-method > grid (which was great, but with some of the issues of it's own). > > Developers got used to writing Wicket based application. > > Now, agency became more serious on adopting technologies which had sound > community and commercial technical support, and which could be considered > as 'standard'. Also, came the need of responsive design and web > applications for smaller devices. > > More than 75% of the colleagues I was working with were not interested in > writing their Junit test cases, nor writing their own css/javascript and > other UI related stuff - I could not find anybody other than 2-3 guys > interested in developing rich, responsive in-house components. They were > looking more for ready-to-use components. > > So, the agency started evaluation (close to two years ago) and other > developers were assigned to find and evaluate different options. > > We had group of developers who had past experience of Richfaces/Icefaces > etc. > > So, the evaluation started keeping following points in mind: > > 1. Solid technical and commercial support. Larger community support with > detail documentation. > 2. Following standards (Java/JEE etc). So if standards changes in future > then it would be minimal impact. > 3. Standards supported Out-Of-Box by application servers. > 4. Responsive design. > 5. Less of presentation layer coding. > 6. For CDI/Injections, rely on Java instead of Spring. > 7. Finding developers with prior experience in specific technology. (This > is case-by-case and by location. Not necessarily a must - but nice to have > kind of point to consider in evaluation.) > > And at the end, agency decided to move forward with using JSF (as it is > 'standard'), EJBs and Java EE based technologies for CDI/Injection. > Choosing JSF brought Prime-faces and it's theme to develop responsive > applications for any devices. > > Considering the progress Apache Wicket has made in last couple of years, I > do believe Apache Wicket can do all of above and much more then any other > framework. Believe me, I still love Apache Wicket over any other framework. > It just puts so much of control in my hand instead of relying on some > bloated versions of html files. Additionally, I am also able to unit test > and presentation layer - improving my confidence. > > But most of the developers I am working don't care to read and understand > framework architecture in detail, nor they care exploring the power of such > frameworks which allows them to build their components the way they want. > They were primarily looking for something which is ready-to-use (which you > can get with Apache Wicket + Kendo UI/ BootStrap or any other JS > framework). > > We do have projects in Wicket (latest one I migrated from 1.4 to Wicket > 7.1), but all new development is now in JSF. > > Apache Wicket team and the whole community has done exceptionally fantastic > job in all aspects to improve the framework and making the project more > appealing. > > Additionally, what can be done to (which Francois has already suggested in > his post): > 1. Maximize developers' interest in exploring and looking into the > components. > 2. How to show case /sample Wicket based web application developed for > smaller devices? How to make developers look at Wicket show cases? > 3. Commercial support and marketing it aggressively. > > By no mean I am trying to show/share that we have migrated to other > framework. Above is just my sharing, by all mean to help such strong > framework whichever way I can. > > Thanks, > -Mihir. > > On Tue, Nov 1, 2016 at 11:49 AM, Tobias Soloschenko < > tobiassolosche...@googlemail.com> wrote: > >> I think it is also good to tell that there are a lot of new features like >> http/2 support to show that Wicket is not a framework at which developers >> stopped working on new features several years ago. >> >> I wrote an article about that on a blog of Jörn Zaefferer who is >> responsible for jQuery UI Dev Lead | QUnit | Globalize | Infrastructure. >> >> Maybe the page about models can be integrated into the user guide to >> improve it. >> >> kind regards >> >> Tobias >> >>> Am 01.11.2016 um 16:31 schrieb Andrea Del Bene <an.delb...@gmail.com>: >>> >>> Hi Francois, >>> >>> I'm glad to read such a clear and smart analysis. I agree with you at >> 100%. Buzz is something we definitely lack of. We should improve our >> examples and write more articles on Wicket. I've also noted that Vaadin >> people have increased the amount of the "buzz" lately. For Vaadin it's >> easier since they have a commercial company behind it, and it seems to m >> they have joined the forces with other commercial entities (like JRebel and >> people behind jOOQ), but this is just my impression. After the ApacheCon I >> hope to find the time to write more on DZone about Wicket. >>> >>> I also think that it's important to work against some misconceptions >> that Wicket might have in dev community (for example, the idea that it is a >> stateful-only framework). At least this is what i will try to do at >> ApacheCon. >>> >>> Andrea. >>> >>> >>> >>>> On 01/11/2016 11:44, Francois Meillet wrote: >>>> Hi, >>>> >>>> Following Tobias Soloschenko thread about the Twitter poll result >>>> >>>> I think we should focus on who who don't know Wicket. >>>> People who don't like Wicket, the unhappy users, will not come back. >>>> >>>> Only 34% of the respondents know what is Apache Wicket. >>>> Put another way 66% don't ever know what is Wicket. >>>> >>>> >>>> A) Apache Wicket's Adoption >>>> —————————————— >>>> Adoption (software or any good) has 2 channels : buzz and word of mouth. >>>> For many authors word of mouth (WOM) influence 50% of the acquisition >> decision. >>>> >>>> So to increase Wicket Adoption we have 2 choices : >>>> >>>> 1) Wicket buzz) >>>> The buzz channel is done via articles, conferences (ApacheCon), meetup, >> social network (twitter). >>>> The superbe Wicket's website welcome everyone who wants to adopt Wicket. >>>> >>>> How the 50% of the 66% who don't know Wicket could be targeted ? >>>> >>>> By increasing the buzz. >>>> We can increase the buzz by more articles in which we could give >> specific examples where Wicket has strong value, >>>> write beautiful small examples to demonstrate the beauty of our beloved >> framework (this is what Vaadin has been doing since few months ), >>>> nice conference's coverage (ApacheCon video on youtube) .... >>>> >>>> By improving its impact using redundancy. >>>> Mentioning Wicket'skills on dev's social network profile (linkedin) ! >> (very few do it) is one example. >>>> By retweeting, by mentioning Wicket more often, .... >>>> >>>> >>>> 2) Word of Mouth) (WOM) >>>> Word of Mouth is the passing of information from person to person by >> oral communication (Wikipedia) >>>> WOM is the second channel, with an equal importance for Wicket Adoption. >>>> >>>> Word of Mouth is made of by the developers and project managers >> feedbacks. >>>> A lot has been done, through a nice and complete user guide to make the >> learning curve easier. >>>> >>>> if I think we should focus on who who don't know Wicket, I think we >> must hava a clear understanding why developers don't like Wicket. >>>> Understanding the difficulties and dislikes is very important. And >> should be done without affect. >>>> >>>> >>>> >>>> B) Difficulties and dislikes: >>>> —————————————— >>>> In many projects, developers start writing few pages, using the >> examples. >>>> Most of the time developers have difficulties understanding models, and >> while trying to implement the functionalities that have to be done for >> yesterday, >>>> they still do not masterise theirs models, and do not pay attention to >> their codes. >>>> They just do not have time for these 2 tasks. They have to deliver. >> Bugs will be fixed after..... >>>> >>>> They do copy and paste to implement first functionalities, and after >> few weeks, the code is so messy that you start thinking at the servlet / >> jsp … ! >>>> The style of coding we can find in the Wicket Examples is used to write >> ugly classes. >>>> In many places I have seen pages with more than few thousand lines. >>>> >>>> No one wants to read it before lunch time or a friday afternoon ! >>>> And as in any corporation, developers attempt to name a culprit. From >> outside the developer's corporation. >>>> Guess what ? >>>> This is the time Wicket starts to receive a bad reputation. >>>> And this is where this bad reputation stops the natural spreading >> Wicket’ usage between developers, between teams in a company, between >> companies. >>>> Word of mouth adoption channel is closed here. >>>> >>>> And needless to say, when new developers arrive on this kind of >> existing project, they are not in a "wicket's loving mood". >>>> Difficult to understand, difficult to maintain. >>>> And you know, the first meeting is important ! >>>> >>>> We can improve a lot Wicket Examples's value by having more comments or >> a better pedagogical naming convention. >>>> A "test yourself" page where developers can test their Wicket’s skills, >> with the correct answer and with the minimum level score to start using >> Wicket with ease, could be interresting. >>>> But it's not good enough. >>>> >>>> The difficulties I have found in many places are : Model, Page, >> Granularity >>>> Model, Page, Granularity : from my clients, these 3 points are the >> "dislike's culprit" : >>>> >>>> Models seem to be difficult to masterise, but it’s a core concept. >> Getting Models proficiency is the key. >>>> Writing page (java code) that are well structured, have nice code, are >> easy to read should be highlighted (even if it’s more a Java skill than a >> Wicket’s one) >>>> How granular should components be organized is a not an "exact science" >> and some best practices, examples could help a lot. >>>> >>>> >>>> François >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
