On Fri, May 1, 2009 at 8:01 AM, Tony Giaccone <tgiacc...@gmail.com> wrote: > 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.
I hope you get a chance to use T5 soon; it's the same "flavor" as T4, but a whole new recipe ... the differences are more than the sum of the deltas. > > 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. I'll accept the shifting sands from Tx upto T4. One of the reasons I'm very interested in getting T5.1 out the door is to demonstrate my contention that T5's new architecture supports adding significant new features (i.e., performance boosts, better templates, gzip compression, javascript aggregation) without breaking backwards compatibility. > > 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. I think the new IoC container is much easier to understand, and there's no XML. People still stumble over the concept of service configurations. However, there's a lot more examples now, in the cookbooks and elsewhere. > > 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. Are you willing to fund this kind of effort? Didn't think so. Documentation is *hard*. I think Tapestry should get some kudos that the documentation is at least accurate. There's a wealth of very rich JavaDoc, the component reference, and lots of hand-tooled reference documentation. Nobody likes to do documentation. That's a problem in a volunteer effort. If Tapestry's committers reported to me, I'd be parceling out the kind of documentation you're talking about. That's not how it works. In a separate thread, I'm promoting the use of a wiki as the basis of future documentation. I think opening up documentation to the community is the only way of bridging the gap ... but that brings in its own problems w.r.t. oversight and accuracy (not to mention readability and consistency). > > 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. Now you are citing yourself as a newbie. Anyone who's followed this mailing list has seen Tapestry 6 come up and everyone, including myself, strike it down. Sure, there's a couple of things that I'd do differently now, but not enough to address the kind of effort involved in yet another rewrite. Again, 5.1 is a demonstration of the future path, where new features can be added non-disruptively. > > 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". > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
