This post originated from an RSS feed registered with Java Buzz
by Warner Onstine.
Original Post: Why hasn't Tapestry been more widely adopted?
Feed Title: Tapestry Live
Feed URL: http://www.jroller.com/WarnerOnstine/feed/entries/rss
Feed Description: Home of the Tapestry Live book by Warner Onstine.
First let me preface this post by saying that I still think that Tapestry is one of the best platforms to be developing your Web application on. Having said that I think that there are some issues that need to be addressed to help improve Tapestry‘s adoption into the Java community (and Web development community as a whole).
Without further ado what are some of the issues that I see with why Tapestry hasn‘t been more widely adopted as the preferred Web platform (at least amongst Java developers).
JSF - the big gorilla in the room
Rails – the wakeup call for the Java Web community
Grails – shows us that we can have rapid development and still have Java
Tools – should we need them? Rails doesn‘t seem to care one way or the other
Shifting sand – constantly changing the entire framework without time for the existing release to gain a strong following
That‘s a lot of points and I want to cover each of these in as much detail as I can, starting with JSF.
JSF (or JavaServer Faces) is Sun‘s answer to .NET and it has some really good features, 99% of which Tapestry does too (and better IMO). It has bindings straight through to the model (which Tapestry does), it has a component-driven architecture (which Tapestry does), and it has component lifecycle (which Tapestry does too). Where it has the advantage is simply in the fact that Sun supports it, it‘s a Sun spec that most companies are going to look at and use in their cost-benefit analysis. Sun created this spec with the idea that they would have tool vendors create the tools around it that would make it easy to write a JSF application. I think that this is flawed, much in the way that the idea of the JavaBeans spec was flawed (same technique, but very few tool vendors ever took advantage of it). That isn‘t to say that what came out of JavaBeans hasn‘t been immense (can anyone say Reflection API?), but I never saw large palettes of components that you could just configure and drop in your Swing app fly off of the shelves (at least not the way that VB components do). That is why I think that this line of thinking is inherently flawed, Sun isn‘t going to magically create a market where none existed before, especially for Web components. I think what Sun forgets time and time again is that the Java space is not the same as the .NET or VB space. Isn‘t it time that we leave the Microsoft architectures behind and sow our own seeds? But the simple fact that JSF exists has definitely put a crimp in Tapestry‘s market-share so to speak.
Alright, enough of JSF, what about Rails? How has that affected the adoption of Tapestry? I know several developers who were using Tapestry in their day-to-day jobs and found Rails and fell in love, leaving 90% of the Java community behind (sans some helpful tools that just don‘t exist in the Ruby/Rails world like Lucene or some continuous integration stuff). Rails showed these developers how fun writing a Web app used to be and they embraced it, warts and all (and yes there are warts ;-). Losing these bright developers is like a sign of things to come, they are bright and follow the trends before they really are trends. Granted Tapestry 5 is learning from Rails and adopting a lot of the convention over configuration and is heading in mostly the right direction with things, but that doesn‘t change the fact that the Java community is losing the very people who would use Tapestry in the first place.
Now Grails picks up from there, what do you do if you like Rails but still want to do Java, you do Grails, and it is picking up steam. It still has a way to go, but 1.0 is on the horizon and I have a feeling it‘s going to make a big splash in the Java world. From all accounts the Groovy and Grails books at JavaOne were literally flying off of the shelves, they ran out several times (I personally have been waiting for Groovy In Action since I first heard about it). Groovy is a great, dynamic language (I‘ve got several posts on BlackBox if you care to read about my experiences with it) and I think that some kind of marriage between it and Tapestry would make a great taste (hey you got my peanut butter in my chocolate! no, you got chocolate…never mind). So, we have yet another brain drain of sorts, but this time from new developers who will never hear about Tapestry and latch onto Grails because of its similarity to Rails (vague, but the concepts are the same) and the fact that it is very Java-like. Again, Tapestry loses (well, so do other frameworks but I‘m focusing on Tapestry here).
What about Tools? With most of the OSS projects I‘ve been involved with this seems to be the number one concern, “Is there a plugin for Eclipse, IDEA, [your favorite IDE here]? When will it be available, because I can‘t be serious about it until there is such a tool.” To a certain degree I agree with this assessment, but only to a degree. Rails doesn‘t have that many tools out there, and quite honestly it got really popular well before any serious tools were developed for it. All of the Rails webcasts used a popular editor (TextMate – it really does rock, I love it!) for developing the application, an editor, not an IDE (yes of course there‘s no compilation for Ruby, but you can always use Maven/Ant to do that step for you). Tapestry used to have a really good toolset for it called Spindle, which unfortunately isn‘t even available for Tapestry 4 or the upcoming 5. I can‘t speak about the other plugins because I haven‘t used them but they are out there. So, the tools question I‘m going to leave on the table for discussion is this. For a project (in the Java world) to be successful does it need a toolset behind it?
This next issue is the Big Kahuna for me and one that I‘ve been thinking about for a loooong time, one that I find personally frustrating and as an author really irritating. One of the biggest issues that I see with Tapestry‘s adoption rate is the very simple fact that shortly after a final version of Tapestry is released, Howard has already announced that the next version is already under development, and by the way it‘s going to blow the doors off of this version. Now, I don‘t want people reading this the wrong way because I like Howard, but this is a huge issue IMO. I can understand wanting to showcase some of the cool directions that you want to take a framework but what ends up happening is that it erodes confidence in the current release and causes confusion amongst developers. This happened with the release of Tapestry 3 and is happening right now with Tapestry 4. I can‘t say how many times I‘ve seen the question on the listserv “Should I wait for Tapestry 5 (or 4 in the earlier case), or should I start developing with the current version?” This question arises because of the major changes to the way applications are built between each major release and no clear upgrade path between the two versions, it is always left as an afterthought which never occurs. The worst part about all of this is that I‘m not alone, there are others that feel the same way and have either stopped supporting the community they were instrumental in building or decided to keep their applications in the previous version because of the difficulties in upgrading their codebase.
How can we address these issues and truly make Tapestry the number 2 or number 3 framework that it should be (but unfortunately isn‘t right now – and no I don‘t have any hard numbers to back this up it is just a gut feeling). As it stands right now I think that Struts is still number 1 (due to shear momentum), JSF number 2, and the number 3 slot is an open market (Struts 2, Spring MVC, and I think Grails are all top contenders for this spot).
Here are things that I see that could help improve the adoption rate:
When Tapestry 5 is released make this the new base, don‘t even think about Tapestry 6, just look at how to incrementally improve 5
Provide a clear path for migration from 4 to 5, see Rails migrations for a great starting point on this
Encourage new developers to use 4 with the understanding that there is a clear upgrade path and it won‘t all be in their hands
Tools consolidation – this appears to be happening, but I‘m not sure
The bottom line is that I think Tapestry 5 addresses a number of the previous issues with respect to adoption, but it isn‘t out yet, so you have to let developers get started now without fear of having to do it all over again (and I heard some of these same complaints when 3 was out and 4 was announced with major changes). People shouldn‘t be afraid to use a framework just because a new version is coming out. Ok, I‘m going to step off of the podium now and leave the floor to the rest of you. I hope that this will get the community talking and we can come up with some solutions to these problems. Or, if you don‘t think they are a problem, tell me why you might convince me.
Previous Topic
