Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Tuesday, June 16, 2009

Why choose Tapestry?

I recently had an e-mail exchange with a Tapestry user; after congratulating me on creating Tapestry, he went on with the following observation on his organization:

The company I work at unfortunately chose JSF for their big app. The reason was that Tapestry was "brittle" in the sense that, if one developer breaks something, on a page or a service, very often the whole site won't come up because the initial registry startup will fail. Or for example, if page A has a pagelink to page B, and page B is broken, then page A won't render. While I agree that we shouldn't ship unless the whole app is working, this is a thousands of pages big app with hundreds of mediocre (as in likely to break things) developers. They'd rather have 80% of the thing working than nothing at all. I never thought of this for my own projects, and haven't had the time to examine the truth of their claims. What's your take?

I provided the following response:

Early failures are absolutely, 100%, the only path towards code quality. You may have heard the phrase "no broken windows" (see "The Tipping Point" by Malcom Gladwell for more details) but the short form is that when errors go uncorrected (whether they are broken windows in an abandoned building, or broken code in an application) they tend to multiply quite rapidly.

The things that will "break" a link from page A to page B are substantial problems such as invalid templates, references to unknown properties or components, or compile errors in the page B class ... things that no other developer should ever see when page B's developer is working and checking in code. That is, problems that should never be checked into trunk, but instead kept in a local workspace or a private branch.

An organization that thinks that fail early is a problem is an organization that isn't prepared to develop a large application in any technology. The image I'm getting is one where there is no build server, no continuous integration, at best CVS for source code management (or possibly one of those "shared directory" monstrosities) .... i.e., a chaotic environment where errors are allowed to be checked in to the trunk and can go unnoticed for some time.

The solution to coding errors in pages or components is not to wait until your testers (or end users) find the bugs, but to identify and fix the bugs early. That's called "engineering discipline" and the reality is that even self-professed "mediocre" developers can do it. Tapestry helps because it fails early and has great exception reporting to guide you right the problem so that you can fix it.

Another factor here is enforced helplessness. If only Fred understands page B and he's out when it's broken, then all development stops waiting for Fred to get back. I hit this problem myself, years ago working on a large Struts application (those words give me the heebie jeebies now!). We had lots of code, a fragile and slow build process, and many little code "fiefdoms". I spent too much wasted time twiddling my thumbs.

Nobody should "own the code"; if page B is is broken, Julie (who normally develops page A) should be free to fix it. Julie will need to understand the page B code well enough to fix it, but also you need an overall environment with shared source, no repository locks (that is, nothing that says "Only Fred can change this file"), and no management PHB's getting in the way. Pair programming is the best way for Fred and Julie to share knowledge so that they can understand each other's code. Even if pairing occurs only part time, it's very effective at knowledge transfer as well as ordinary coding.

The idea that "mediocre" developers should use JSF as it is more tolerant of errors is absurd! Tapestry 5 is designed to improve productivity for all developers, by streamlining, simplifying, being smart and being concise ... not to mention live class reloading and best-of-breed exception reporting, which makes it fast to identify and fix those errors.

If your doctor tells you to eat less red meat, that doesn't mean you should switch to a diet of fried chicken three meals a day! Likewise, if you have concerns with code quality from your developers, you should not switch to a less agile, more code-intensive, less supportive development model and hope to catch all the bugs in QA. Sweeping problems under the rug is never a winning strategy.

Coming down off my soap box, I should also add that Tapestry 5.1 works a little bit differently than 5.0 in this respect, so it does (in fact) defer more of the page loading and validation until a link is actually clicked. This is more for performance reasons than to shield developers from application problems. Even in 5.0, the loading and validation was the "reach" from page A to pages explicitly referenced (usually via PageLink during the rendering of page A), so it's a highly unlikely case that a single error in a 1000 page application will keep the application from starting up, unless the start page of the application links to all 999 other pages.

Re-reading the above post I can't emphasize enough: you can't ignore quality problems. Quality problems lead to development failures, schedule slips, missing functionality, low morale and high turnover. Saying "we don't have time to fix the quality problem first" is to ignore the second law of Thermodynamics. You are expecting a miracle, literally writing it into your project plan.

Formos addresses this issue two ways: First, we use Scrum and deliver on (typically) 4 week cycles. Thus we set real deadlines and have a constant check on quality (we're providing working code constantly). We don't even try to predict what we'll be doing six months or two years from now, we just deliver a steady, manageable stream of software.

Secondly, Formos uses Tapestry precisely for all the reasons that the anonymous developer's organization rejected it, and for many, many more reasons besides.

16 comments:

Unknown said...

hi howard, nice post. but from my experience this is not the problem of Tapestry 5 or Tapestry IOC adoption. most customers and stakeholders i present T5 and T5 IOC (btw i love working with T5 IOC) will counter that Tapestry has a bad reputation because of the loss of backwards compatibility. they all agree that T5 is a great and productive framework but they are convinced that using a framework with no record of successful backward compatibility is not a good choice for a production environment. especially considering the amount of money that will be invested in this new products. I'd wish i could present some facts and evidence that T5 is different and that backwards compatibility wont be a problem any more (at least not that much:)). maybe a compatibility layer for T4 would be a good starter (we also have T4 applications running). that said i'm still a tireless proponent of T5. and we are currently working on a project with 15+ developers using T5/IOC. And we are going to double them in one year (timeline is still vagueai just wanted to report the reactions i get when talking to a group of potential customers.

g,
kris

Unknown said...

Backwards compatibility was the reason I pushed to get 5.1 out early. It was not a total success (perhaps it was too late to pull out PrimaryKeyEncoder) but otherwise upgrade from 5.0 varies from 0 work to a small effort (typically, areas that were undefined in 5.0 but considered errors in 5.1). Anyway good news about your app ... be in touch if you need some help!

Ron Piterman said...

While I find working with tapestry is very productive, developer throughput is only one of the aspects that should be considered when deciding for a web framework.

Tapestry has many drawbacks, in how I see it, it does not only sum in backword compatibility but the fact that howard is a solo devloper on this project.

He does great work, but he does what he likes and how he likes it, and does not really care - which is a great thing for some things, but there is no control-team to balance different interests. So its how Howard Lewis Ship sees it at the moment of decision.

(Apropos: why do spring beans do not inject anymore to tapestry IoC services but vice versa ? Do you really think that Tapestry IoC, the web layer, should be the Main Layer of the/any application ? really ? )

Every Corporate has a Board which balance each other; at some stage SUN enbraced this and grounded the JCA.

Now you can say there is community involvement in tapestry, but the truth is, it is a one man show and, just like in business, this is not a solid ground for any framework.

Ofcouse you will mention tapestry 4.1 : what happened there is howard made 4.0 and let a bunch of community members do 4.1 - and probably did not write one code-line for this version. It was not team work, it was just a community branch.

The lack of a team is also visible in the unprofessional documentation.

Just something I read today in a component docu:

"The trick is to also bypass server-side"

"Trick?" really ? where do you read about tricks in, for example, the spring documentation ?

We do software development and not magic - like and dislike are not valid arguments and tricks are not tools we use.

Best regards, Ron

sicklittlemonkey said...

"The trick is to also bypass server-side form processing ..."

Ron, your point here is very weak criticism, and simply suggests you are a fluent but not native speaker of English. This idiomatic usage is common and natural and has nothing to do with magic.

I wouldn't bother commenting on this, except that your tone is so scathing. Comparing Tapestry's documentation to that of a well funded multi-national company like SpringSource is a bit strange.

Cheers,
Nick.

Ceki said...

It's actually a very good thing if there is a person who feels responsible for the project. There are many software projects out there with no clear leadership. They usually drift aimlessly in purgatory awaiting one decision or another.

Ron, instead of leaning on Howard, you should be thankful for this hard work and leadership.

Ron Piterman said...

I Agree with you both: the comment about the documentation was out of place; my main argument was: tapestry is and always was a one man initiative. As such, balanced decisions as to the perspective of the project are missing very often.

I have build once a very large project based on tapestry for a startup. As a result of that work I will never ever recommend tapestry to a client. For tiny projects it may be fun, but for a big project you just need someone serious standing behind a framework and not just an Howard...

I am not saying here that Howard is not serious. He is. But its he is just a single Person, and make decisions from his own perspective. How I see it, this is not enough.

Unknown said...

Ron, I'm sorry you feel that way. I like to think that the majority of my decisions are good ones (at least in terms of coding decisions). To be honest, most of the feedback I get tends to be favorable in terms of my ability to predict potential problems or issues and to address them in advance. I too would like to see more involvement by the other committers but, with the exception of Kent Tong, I don't know of any committers with whom there have been any real clashes or strong disagreements. Kent and I disagreed not on any specific concerns but on a much, much larger concept of what Tapestry itself should be as a framework and an API. In any case, what you see on the mailing lists is the full discourse, I'd say 0.01% of my interaction with the other committers has happened off the mailing lists.

Unknown said...

One thing that really needs T5 is more defualt GUI components as Tabs or rich text area or others.

Yes it is easy to create new components with T5 but it still takes time to build my self that. I would like to have default components and focus on the application in mind and not in build frameworks over T5.

JSF with Richfaces got lots of components, GWT lots of components, Click framework have many default components but Tapestry only have the html ones.

There is a project with some T5 components I think is chilkak but is a mess to build that and have lots of dependecies in other frameworks that we dont need for web apps.

Anyway Howard IMHO T5 needs:

1.Keep backwards compatibility always from now on.

2.A new T5 book with examples and explain more in detial the inside of T5 and better online docs/wiki

3.More default components, you could also wrap jquery UI and we can also have kick ass ajax components for just use right away and we web application developers does not need to think to build frameworks just apps.

2c.

sicklittlemonkey said...

@Muchacho

1 - This is a stated goal of T5

2 - Is Howard's current priority

3 - Have you seen ChenilleKit?
http://www.chenillekit.org/demo/tapcomp

I'm not using T5, unfortunately, but it's easy to see there is plenty of work being done to make it a best-of-breed framework.

Cheers,
Nick.

Adedayo Ominiyi said...

This may be coming late but I just had to put in my two cents. Its unfortunate to see that some people instead of contributing positively to the world of software development spend their time criticizing those who have helped and are helping change things. I am a developer (SCJP, SCJD, SCWCD) and I used T5 (precisely, 5.0.14) in a project along with a team last year and it was great. We loved the IOC among other things and We found lots of free components when we needed them. I believe that Howard has the right ideas. If you have a problem with how he does things take the source code and do something about it. T5 was a radically change from T4 and definitely, definitely better than T4 (cant remember which version I used right now). The hardest thing is change and I think keeping T4 at that level is okay. If he and his team decides they want to do something radically different from T5 as it is now. I am all for him spinning a T6 and breaking backward compatibility with T5. Once again if you have a problem with good change take the code and do something about. Thank you Howard for adding value to our lives.

Unknown said...

Adedayo,

Thanks for the support and I'm glad you are happy with Tapestry. I just felt the need to reiterate that I don't see there ever being a T6; I see a stream of backwards compatible updates to Tapestry 5.1. In fact, I think the 5.0 -> 5.1 transition was a little rougher than I'd like for future releases.

The overall approach in T5 was to eliminate the root issues that caused the backwards compatibility problems in earlier Tapestries. I'd say we've been reasonably successful in achieving this goal.

Luke said...

Hello Howard

What is your take on the Freemarker templating engine? It seems like a nice way to do the presentation. Would it make sense to use it together with Tapestry? Is it possible?

Unknown said...

Luke,

The power and simplicity that Tapestry brings comes from the tight integration between the template and the page (or component) class; both are incomplete without the other. Although it is possible to render portions of a page using an external engine, it's problematic on many levels and can never be a simple replacement.

Unknown said...

I think that the Layout component is too weak because its only possible to insert page specific content in 1 place (At the t:body)... I am missing the support for includes, because with includes, you can insert content in different places on the layout.

Unknown said...

Mario ... you do not yet Grok the Block!

Pawan Kumar said...

Hi Howard, first of all I would like to thank you for developing such a nice framework. I have create a small application with integration with chanellkit components. What is the best way to put the source code on any of tapestry site so that others can get started quickly with T5?. Documentation is still very little on tapestry on the web.