Some interesting points here. 2009/4/30 kranga <kra...@k2d2.org>
> 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. Yes. That is the main time-eater. Finding out how non-trivial things are supposed to work. But that is a "feature" of most OS project's documentation: a) hello world b) some simplistic blog/calendar/whatever without any relevance to real world projects c) bits and pieces all over the net. And this is already good documentation as far as OS goes... The main problem here is that non comitters probably cannot help in writing the docs, since they just don't know enough. The result would not be better as what is there. One example of an excellent documentation in OS projects was Stripes Framework original docs by Tim Fennel. Since I didn't check the project for a long time I don't know about its current state. 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). There is no debate. One just has to look at the sources of well known and big scripted projects and the difficulties they have to maintain them. In the end there is no difference between the ugly php hacks and the more recent varieties of languages. If it is easy to program bad, then it will be done. Especially under time pressure. Statically typed languages make a lot of the more annoying mistakes hard to do, like typos which are only caught at runtime or wrong assignments like assigning a char sequence to a variable which is meant to be int and calculated upon. again only caught at runtime. Not having to implement an interface makes it easier for tapestry to change implicit contracts. That is a totally different beast when talking about interfaces with methods. But if it would be only marker interfaces there is anyways no difference between a certain package requirement or implementing an interface, so no reason to change anything. 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. True. But since components are easy to make in Tapestry the market would probably be very limited anyways. All the important building parts are already there and for 95% of cases you get along with not more code than it would need to adapt to a premade component. JSF components are shiny and all, but they all require you to adapt to their needs while in Tapestry you can tailor components for your specific needs with relatively low effort. That said, some more premades would be nice :) > 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. > Yes, JSF gets all the hype because it is a standard. But reading in Java magazines makes it clear very fast, that even simple problems have quite complicated solutions. It is an endless well of articles for the mags and so the visibility even rises _because_ it is terribly designed. And a standard. And because it has shiny components with slick buttons.
