Why rewrite Tapestry between versions?

[David O'Meara]

I understand that none of Tapestry versions 3, 4 or 5 are compatible, meaning existing apps need to be written to make use of each new version.

Why has this been the case, and is it a practice that is likely to continue?

Also, could this have impacted the uptake of Tapestry so far?

[Alexander Kolesnikov]

Rewriting Tapestry from scratch, as it happened with version 5, gave its creators an opportunity to implement the best and latest ideas, to make exactly the framework they've envisaged. Even huge companies do steps like this when they look into the future: look at Microsoft and what happened with its COM technology when .NET was introduced. The company's language of choice is now C#, not C++. I am sure that many people are unhappy of such a drastic change, but that's life.

It is exactly because Tapestry is able to make those major changes, it stays at the bleeding edge of Java web development. When you opt for compatibility, you inevitably go for compromises and you can't get to the edge.

Having said that, Tapestry 5 was specifically designed in such a way that its future versions were compatible.

Of course the lack of compatibility between versions is a negative factor in the adoption of Tapestry, but, and especially when it comes to version 5, it should not be the most important factor. Tapestry has huge benefits, and if you can develop a Tapestry project in a fraction of time required for a similar Struts project, isn't this more important than the arguable issue of future compatibility of versions?

By the way, Struts is not compatible with JSF, but does this mean that Java web development should stay forever in the world of actions?

[Brent Sterling]

I dropped in with similar concerns to those of David. From an outside with limited knowledge of Tapestry, it sure seems like the Tapestry team is shooting itself in the foot with each major release. Just as the product gets a little momentum and books and documentation pop up the project reinvents itself. I gave a brown bag overview of Tapestry a year or two ago...I guess it was for version 4. At the time I said that you had to pretty much ignore any books or articles written for a previous version. It sounds like this is even truer with Tapestry 5.

- Brent

[Gregg Bolinger]

Forces everyone to *buy* new books, doesn't it?

[Anselm Paulinus]

Well its not all bad with rewriting frameworks between versions. One advantage of rewriting Tapestry between versions is that it keep us employed. Was part of a team that migrated a project from Tapestry 3 to Tapestry 4. Who knows how many projects that would need to be migrated to Tapestry 5. so guys cheer up rewriting is sometimes good for our profession.

[Alexander Kolesnikov]

How do you think, Anselm, would it be easier to rewrite similar projects from Struts to, say, JSF? Would you ever dare to do this? Companies are upgrading Tapestry 3 projects to Tapestry 4 because that is quite possible and brings them some benefits.

[Gregg Bolinger]

Originally posted by Anselm Paulinus:
Well its not all bad with rewriting frameworks between versions. One advantage of rewriting Tapestry between versions is that it keep us employed. Was part of a team that migrated a project from Tapestry 3 to Tapestry 4. Who knows how many projects that would need to be migrated to Tapestry 5. so guys cheer up rewriting is sometimes good for our profession.

Are you kidding? Most companies would cringe at the cost of re-writing an entire application just because the key framework's latest version *might* be better than the one you are using and it isn't backwards compatible, AT ALL.

[Anand Hariharan]

Originally posted by Gregg Bolinger:


Are you kidding? Most companies would cringe at the cost of re-writing an entire application just because the key framework's latest version *might* be better than the one you are using and it isn't backwards compatible, AT ALL.

In fact, even if there is no *cost* involved in upgrading a third party software that a particular software shop depends upon, unless there is a real tangible *benefit* to upgrading it, there is going to be a lot of inertia to upgrade it.

[Charles McGuire]

I've heard good things about Tapestry, but the one big problem that keeps coming up was the fact the Tapestry re-write broke backward compatibility. To be honest, it kept us from picking it up and trying it out. I directed our limited resources to another framework instead.

Refactoring is good but breaking code is bad. I wonder if Tapestry will overcome that big skid mark on it's history? Managers think that it happened before, it will happen again.
[ March 05, 2008: Message edited by: Charles McGuire ]

[Alexander Kolesnikov]

Well, Charles, obviously I cannot guarantee that Howard's ideas will not jump ahead for another decade. And definitely, if compatibility of versions is very important for your company, Tapestry is not for you.

Personally, I cannot understand, why this compatibility is so crucial, but maybe I just don't know something. Say, we have created two huge applications with Tapestry 4.1. Now, Tapestry 5 appeared at the scene. If everything goes well, I will try T5 for a small project and see how it works. I will have to support two 4.1 apps, but why should I rewrite them if they work well? They say in Russian, "the better is the enemy of the good".

Why can't I consider T4.1 as a different framework? It continues to evolve, led by Jesse Kuhnert. The good thing is that it is conceptually close to T5 and there should be no problem for me - and for everyone in the team - to support both versions. It will be probably much easier than supporting two totally different frameworks.

I just can't understand how limited compatibility of versions can overshadow the benefits of Tapestry...