I'll give my opinion on this, and I think I can speak with some authority as I used to work in WebObjects which at the time was by far head and shoulders above the rest of the pack of web development frameworks. In fact I would say that WebObject still in many ways leads the pack of Frameworks and it's pretty much been stagnant for the last 5 years. In addition while I've not worked with T5 yet, I have done work in both T3 and T4.
1) Tapestry has a deserved reputation for being a framework who's foundation is on shifting sands. The changes from T3 to T4, and then from T4 to T5 have been enormous. In the enterprise world, that's a major disadvantage. That the code is not backwards compliant, means that for an enterprise to stick with T5 it has to either continue on a framework that's become stagnant, or worse dead. Or invest a large amount of money re-writing an app to support a new architecture. 2) Hivemind - Learning Tapestry for many developers was an uphill battle. Understanding Hivemind and how to make use of it, was more like Mt Everest. Documentation was miserable, examples sparse. I was able to get the Hivemind to spin up services and work with Spring but boy it wasn't easy. Hivemind is gone in T5? The IOC container has to be well understood, well described, and documented with examples at the same level as Tapestry rendering frameworks. 3) Documentation - Good solid reference examples of how to do do simple apps, explained in detail. Most developers want a framework to be like lego building blocks. I do A, B, C and D and I get E. I assemble a dozen different pieces and I have my app. Really how complicated are most web apps? They are forms and workflow and validation. To get developers to use your framework you need good examples of how to do each, laid out and described in simple guaranteed to work steps. There need to be examples of these in both Netbeans and Eclipse; preferably several examples of each. 4) Stability - you need to lay down a road map that shows management and developers that they can count on a stable environment for the foreseeable future. Howard, T6 can't be so different from T5 that you have to rewrite apps. Tapestry has a bad reputation and if you want general adoption, you personally have to assure everyone that the days of major changes in the framework have ended. My personal opinion is that those four things are the starting point. They may not be enough, but if you can't get them done, you won't get anywhere in terms of major commercial adoption. WebObjects had most of those advantages and a few others ( an integrated object relational management system that blows away Hibernate for example), but it got killed because it wasn't "Standards compliant". However, the truth is no one was willing to trust Apple, to provide them with a web development framework. They used the "Standards compliant" argument to discard what they really didn't want in the first place. If they hadn't had that argument, they would have found another. Tapestry has similar problems. The standard arguments I've heard against using Tapestry are: 1) The framework changes too much from release to release. 2) The team of developers who commit to the code base is too small. 3) It's hard to learn. 4) It's not standards compliant. 5) We can't find developers to hire who are trained in the use of the framework. Perception is probably more important than reality when it comes to what frameworks are in vogue. Mindshare is key. Now on the other hand, WebObjects was often viewed as a competitive advantage by our customers. We had a lot of clients who wouldn't let us write up success stories because they didn't want their competitors to learn what framework they were using. Tapestry has a lot going for it, so it's nice to use a framework that is, "stealth". Tony Giaccone On Fri, May 1, 2009 at 3:07 AM, Inge Solvoll <inge.tapes...@gmail.com>wrote: > To possibly bring the discussion to a higher level: > > Why is T5 so far from being the DE FACTO STANDARD web framework? > > Is getting web developers to use T5 comparable to encouraging 80-year-olds > to throw away their radio and use MP3 instead? > > The two actually seem related: > - There's a learning curve (probably more intimidating seen from a > distance) > - There exists a strong standard that feels comfortable, familiar and > somewhat sufficient > - The supporters of the alternative are not your age, not your kind of > people, and they don't hang where you hang. > > So who are we? Are we the new cool teenagers drawing the shape of the > future, or are we the crazy religious people committing suicide together to > try to get to the sacred planet? > > Inge > > On Fri, May 1, 2009 at 8:16 AM, Otho <taa...@googlemail.com> wrote: > > > alex, > > sorry you are right. I was blown away on points 2 & 4. > > > > > > 2009/5/1 kranga <kra...@k2d2.org> > > > > > For Tap 3, we had a very elaborate form with loop implementation and we > > > added Ajax-validation such that you only write validation code once in > > Java > > > and for javascript validation, an ajax call is made to run the same > > > validation code and bring back the results. The error handling could > > > correctly handle n-input fields in a form all generated via a loop. > > Needless > > > to say the code was quite complex and horrendously convoluted and now > is > > > outdated :( haha > > > > > > -------------------------------------------------- > > > From: "Inge Solvoll" <inge.tapes...@gmail.com> > > > Sent: Thursday, April 30, 2009 6:09 PM > > > > > > To: "Tapestry users" <users@tapestry.apache.org> > > > Subject: Re: T5: What is NOT beautiful about Tapestry? > > > > > > Agree with Alex on the last comment about proving that issues don't > > exist! > > >> > > >> I have one example of a trivial thing that I have found difficult to > > >> implement in all Tapestry versions I have used(3, 4, 5): > > >> > > >> - A form with a loop in it. > > >> > > >> This is extremely common in the pages I make, and my mind always > > struggles > > >> when trying to find how this is done in the new Tapestry version. I > > never > > >> figured out a way to do it in 3 and 4 that made sense to me and looked > > >> correct. > > >> > > >> It also happened in T5. Maybe I'm stupid, but I really had to struggle > > >> hard > > >> to track down the details needed to implement this correctly, using > > >> encoders, initializing my form objects in the correct method in the > > >> correct > > >> way, and so on. I didn't find an example in the docs showing me the > best > > >> practice for this (for me) very trivial and very common pattern. > > >> > > >> > > >> On Thu, Apr 30, 2009 at 11:17 PM, Alex Kotchnev <akoch...@gmail.com> > > >> wrote: > > >> > > >> I will echo Kranga's #1 and #2 and add a couple. I'm all for > > >>> convention over configuration, but when you have to dig out the > > >>> convention out of source code, mailing list, or somewhere else, I'd > > >>> wish I had a well defined interface that I could just implement. The > > >>> not-so-pojo aspect becomes too apparent when you have to write some > > >>> test cases against the said components and you start scratching you > > >>> head about "now, how do I make all of those magical annotations work > > >>> if I don't do the whole IoC bit where it will inject everything". > > >>> > > >>> One additional difficulty is that T5's model is so different in > > >>> respect to AJAX that it takes a while to wrap (or warp) your head > > >>> around what you need to do in order to do something seemingly simple > > >>> w/ a known Javascript framework (e.g. think Dojo, Prototype, jQuery). > > >>> There are a plethora of people out there that know how to make up a > > >>> snazzy ajaxy interface; however, when it comes down to T5 you have to > > >>> jump through a couple of hoops just to get the URL to which the Ajax > > >>> code will hook into (e.g. the componentResources.createPageLink , > > >>> createEventLink, etc). Componetization support and all within T5 is > > >>> nice, but when you have to climb a big hill of learning a lot of T5 > > >>> before you can do a silly autocompletion example for Dojo or jQuery, > > >>> it just makes it harder than necessary. Certainly not a boon. > > >>> > > >>> Finally, it's great that T5 is so well decomposed into small > > >>> interfaces , so that you can override anything you want. However, too > > >>> many small classes/interfaces + a bunch of dependencies on each other > > >>> (which are really easy to do when IoC can magically inject > > >>> dependencies for you) starts being a drag when you want to > > >>> implement/override one, and then you realize that in order to do one, > > >>> you need to figure out a bunch more things that need to be injected > > >>> (or something like that). It's really easy to get into a rabbit hole > > >>> of "oh, I wanted to implement this one thing, now I have to > understand > > >>> these other three before I can implement the first one" > > >>> > > >>> Otho, > > >>> I don't think the point of this thread is for us to prove that the > > >>> issues that are brought up are not actually issues. The fact that > > >>> people bring them up, means that those issues still exist. I doubt > > >>> that someone will go through the trouble of typing up a big email > > >>> regarding his troubles w/ T5 if these were not issues that he/she has > > >>> dealt with. > > >>> > > >>> > > >>> Cheers, > > >>> > > >>> Alex K > > >>> On Thu, Apr 30, 2009 at 9:28 AM, kranga <kra...@k2d2.org> wrote: > > >>> > 1) Documentation: It is one thing to remove dependencies on > framework > > >>> > interfaces but quite another to leave the developer hanging with no > > >>> > documentation. Programming by convention is programming in the dark > > if > > >>> the > > >>> > convention is not known. > > >>> > 2) Although Tapestry claims to be POJO, you still have to have a > > > >>> contract > > >>> > (whether it is methods by convention or annotated methods). In the > > long > > >>> run > > >>> > whether this is really better than interface implementation is not > > > > >>> fully > > >>> > proven (much like the current debate of whether dynamically typed > > >>> languages > > >>> > will prove more difficult to maintain in the long run). > > >>> > 3) Lack of a component marketplace: Wow, 4 years on and this is > still > > > > > >>> on > > >>> my > > >>> > list. We wrote a gigantic application in Tapestry 3 which is still > in > > >>> > production. But we've decided to write all new apps in JSF with the > > aim > > >>> of > > >>> > quickly adopting 2.0 when the spec is released. The main reason - a > > >>> plethora > > >>> > of components to choose from. > > >>> > 4) Developer mindshare: Our analysis with Tapestry 3 shows that for > > > > >>> every > > >>> > developer we hire, we have to write off 2-4 weeks until they become > > > > >>> well > > >>> > versed in Tapestry. I don't believe T5 will be any different. You > > > >>> cannot > > >>> > argue against a standard like JSF that is supported by vendors. The > > > > >>> lack > > >>> of > > >>> > penetration of JSF speaks to its terrible initial design which > > > >>> hopefully > > >>> > will be rectified in 2.0 > > >>> > > > >>> > I don't believe Tapestry will dwindle and die but I don't see it > > > >>> becoming > > >>> > the defacto standard ala Struts in the early 2000s. > > >>> > > > >>> > -------------------------------------------------- > > >>> > From: "Pedro Januário" <prnjanua...@gmail.com> > > >>> > Sent: Thursday, April 30, 2009 5:43 AM > > >>> > To: "Tapestry users" <users@tapestry.apache.org> > > >>> > Subject: Re: T5: What is NOT beautiful about Tapestry? > > >>> > > > >>> >> I totally agree with Hugo's ideia. > > >>> >> The wiki sounds good and should be a easy to make documentation > > about > > >>> >> common > > >>> >> problems. > > >>> >> > > >>> >> 2009/4/30 Hugo Palma <hugo.m.pa...@gmail.com> > > >>> >> > > >>> >>> I agree a book would be great, what happened to the > tapestry5-book > > >>> >>> project http://code.google.com/p/tapestry5-book/ ? > > >>> >>> > > >>> >>> Still, i think a lot better could be done with the online > > >>> documentation. > > >>> >>> I believe the structure of the online documentation should be > very > > >>> >>> similar to a book, it should start with the basics and evolve to > > more > > >>> >>> "hardcore" stuff from there. Just the fact that the current > > >>> >>> documentation is structured with only one level of depth and the > > list > > >>> >>> of item is ordered alphabetically makes the task of finding some > > >>> >>> information much more difficult. > > >>> >>> > > >>> >>> I for example really like how the hibernate documentation is > > >>> >>> structure, i usually have to problem finding what i'm looking for > > >>> >>> there. > > >>> >>> So, maybe the wiki could be a starting place for the birth of a > > >>> >>> documentation with such a structure. > > >>> >>> > > >>> >>> On Thu, Apr 30, 2009 at 10:06 AM, Blower, Andy > > >>> >>> <andy.blo...@proquest.co.uk> wrote: > > >>> >>> > I think you hit the nail on the head Carl. The documentation is > > >>> > > >>> > okay > > >>> >>> generally (some bits poor, some very good) but there is not > enough > > to > > >>> tie > > >>> >>> it > > >>> >>> all together and guide new developers so they know what they can > do > > >>> with > > >>> >>> T5. > > >>> >>> I'm not convinced that the main documentation should attempt this > > on > > >>> its > > >>> >>> own, or whether it should strive to be a great reference with > some > > >>> >>> more > > >>> >>> higher level introductory/discovery bits along with a good > > published > > >>> book > > >>> >>> to > > >>> >>> handle introducing everything and tying it together. Having the > > only > > >>> >>> published book for T5 being so out of date is a huge problem for > > the > > >>> >>> framework in my opinion. > > >>> >>> > > > >>> >>> > I don't think a wiki is the answer to this, I really like > knowing > > >>> that > > >>> >>> the documentation that I'm looking at is for a specific version > of > > >>> >>> Tapestry > > >>> >>> and is updated when the code is - I would not want to lose that. > > >>> >>> > > > >>> >>> > Andy. > > >>> >>> > > > >>> >>> >> -----Original Message----- > > >>> >>> >> From: Carl Crowder [mailto:carl.crow...@taptu.com] > > >>> >>> >> Sent: 29 April 2009 22:04 > > >>> >>> >> To: Tapestry users > > >>> >>> >> Subject: Re: T5: What is NOT beautiful about Tapestry? > > >>> >>> >> > > >>> >>> >> Discovery of it's parts. Franky the documentation is lacking > and > > >>> even > > >>> >>> >> with reading the mailing list, reading the howtos wiki, buying > > the > > >>> >>> >> Tapestry 5 book and working with it for over a year I still > come > > >>> >>> >> >> > > >>> >>> >> across > > >>> >>> >> things I never knew existed that would have solved a problem > > I've > > >>> had. > > >>> >>> >> I > > >>> >>> >> often spend ages writing something myself after searching for > a > > >>> >>> >> solution. > > >>> >>> >> > > >>> >>> >> What's beautiful about Tapestry? That almost every problem has > a > > >>> >>> >> >> > > >>> >>> >> simple > > >>> >>> >> solution built in. What's not beautiful about Tapestry? That I > > >>> >>> >> generally > > >>> >>> >> find these solutions by accident, and way after I've written > my > > >>> >>> >> own! > > >>> >>> >> > > >>> >>> >> Lots of things are obvious and easy to understand once you > know > > >>> >>> >> what > > >>> >>> >> they are but it's learning what they are that is the problem. > > I've > > >>> >> > > >>> >>> >> been > > >>> >>> >> waxing lyrical about Tapestry where I work and while the >>> > >> > > >>> developers > > >>> >> > > >>> >>> >> who > > >>> >>> >> tried it love it, their main gripe is always that it's > difficult > > >>> >>> >> to > > >>> >>> >> understand what it can do. > > >>> >>> >> > > >>> >>> >> The cookbook is the right idea but it's only got 5 entries > right > > >>> now. > > >>> >>> >> It > > >>> >>> >> needs to be way more comprehensive > > >>> >>> >> > > >>> >>> >> Inge Solvoll wrote: > > >>> >>> >> > Hi! > > >>> >>> >> > > > >>> >>> >> > I have been reading the "beautiful" thread and added my > > opinion > > >>> >>> >> > >> > > >>> > > > >>> >>> >> > about > > >>> >>> >> what's > > >>> >>> >> > great about Tapestry. It's nice to sum up why we all are so > > >>> excited > > >>> >>> >> about > > >>> >>> >> > this, it obviously makes both us and the creator(s) feel > good > > >>> about > > >>> >>> >> > ourselves. But for a little while, I challenge us all to > stop > > >> > > >>> >>> >> > > > > >>> >>> >> > tapping > > >>> >>> >> each > > >>> >>> >> > others' backs and go into depth about what's not to like > about > > >>> >>> >> > our > > >>> >>> >> beloved > > >>> >>> >> > framework. > > >>> >>> >> > > > >>> >>> >> > The most obvious questions that could be asked probably have > > >>> > > >>> >> > some > > >>> >>> >> very > > >>> >>> >> > obvious answers. But T5, as I see it, is all about > addressing > > >>> stuff > > >>> >>> >> that > > >>> >>> >> > other frameworks have given up on and create excellent > > >>> >>> >> implementations > > >>> >>> >> > rather than just looking the other way. Difficult and > > >>> uncomfortable > > >>> >>> >> > questions should be addressed the same way. > > >>> >>> >> > > > >>> >>> >> > So: > > >>> >>> >> > > > >>> >>> >> > What are the main reasons that T5 isn't one of the "big > ones", > > >>> when > > >>> >>> >> we all > > >>> >>> >> > seem to agree that it is so much better than most other >>> > >> > > > > > >>> frameworks > > >>> >>> >> out > > >>> >>> >> > there? Why is T5 NOT beautiful? > > >>> >>> >> > > > >>> >>> >> > Hope I'm not insulting anyone, I'm a big fan too, I just > think > > >>> this > > >>> >>> >> actually > > >>> >>> >> > could lead to significant insight :) > > >>> >>> >> > > > >>> >>> >> > Regards > > >>> >>> >> > > > >>> >>> >> > Inge > > >>> >>> >> > > > >>> >>> >> > > >>> >>> >> > > >>> --------------------------------------------------------------------- > > >>> >>> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > >>> >>> >> For additional commands, e-mail: > users-h...@tapestry.apache.org > > >>> >>> >> > > >>> >>> > > > >>> >>> > > > >>> >>> > > > >>> >>> > > > >>> --------------------------------------------------------------------- > > >>> >>> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > >>> >>> > For additional commands, e-mail: > users-h...@tapestry.apache.org > > >>> >>> > > > >>> >>> > > > >>> >>> > > >>> >>> > > --------------------------------------------------------------------- > > >>> >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > >>> >>> For additional commands, e-mail: users-h...@tapestry.apache.org > > >>> >>> > > >>> >>> > > >>> >> > > >>> >> > > >>> >> -- > > >>> >> Cumprimentos... > > >>> >> Pedro Januário > > >>> >> > > >>> > > > >>> > > --------------------------------------------------------------------- > > >>> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > >>> > For additional commands, e-mail: users-h...@tapestry.apache.org > > >>> > > > >>> > > > >>> > > >>> --------------------------------------------------------------------- > > >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > >>> For additional commands, e-mail: users-h...@tapestry.apache.org > > >>> > > >>> > > >>> > > >> > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > > > > >
