Tapestry5 vs Play framework

Question

I know there are many questions here comparing one framework with another. I feel i have to add one more.

What is the advantage of play framework over Tapestry5 framework? Which one would you recommend and why?

Here are the similarities that i have found.

1. Both are stateless frameworks (i know play is more stateless)
2. Both really boost developer productivity with live class reloading

Why would one choose one over the other. I have used both to do a 'glorified hello world' type of applications and i feel like both are very similar.

Canopy

Answer 1

I have no direct experience with Tapestry. But a colleague in a project where we use Play has worked with it, and he was really fed up with it. He had many complains, but you can find most of them listed here*.

Personally, I think the main comparison points between Play and other frameworks are:

• Quick turnaround (edit-build-deploy cycle disappears)
• Quick development/prototyping
• Support of Scala (natively)
• User happiness using the framework/community (if users complain about the framework/community, that means something)

If your framework supports all this as well as Play, then you can go deeper into details, like if it's a stateless/stateful framework, etc.

*Wayback machine version because the post has been deleted from stack overflow.

Leilani

I wonder why I get a negative vote 3 months later... Tapestry fans? :P – Leilani

From the links you pointed out : reason 1 : Because Howard Lewis Ship is a liar -> means that "major revision requires you to completely rewrite your application". Indeed ... like Play :D. Seriously though, the backward compatibilty was quite increased since v5.0, and error reporting is, in my mind, quite good. The only fact I would really agree is learning curve. It's a bit like Maven you know, there is A way to do it well, but it's not always clear. And yes, I'm a Tapestry fan, but you answer really deserve a +1. – Isidore

Answer 2

Also note that Play does not appear to be (directly?) compatible with standard application servers; it doesn't use the Servlet API, but it's own definitions of Request and Reponse.

It's rather draconian as well, recompiling/reloading Java classes on each request (sorry if this is FUD, it's what I remember from the JavaOne talk).

It is not component based, it's an action based framework, like Struts or SpringMVC; it uses templates that are an improvement on JSPs but lacks Tapestry more full-cycle approach. Much of the power of Tapestry comes from building complex functionality from simple elements.

Tapestry includes very sophisticated technology for dealing with assets (images, stylesheets, JavaScript libraries) that are packaged inside JARs. It's all transparent to the user and to the developer, just drop the JARs on the classpath and they automatically load and configure.

I think Play! has some good ideas, and a very good name, but its playing in a different league than Tapestry. It's rather draconian in avoiding any server-side state ... by contrast, Tapestry uses limited amounts of server-side state and manages that state carefully, and does so largely to embrace redirect-after-post semantics.

There's only so far you can go in an action oriented framework when you have the same behaviors spanning many different pages. Although I, personally, would use Tapestry even on a single-page application, it's true that Tapestry really shines when developing larger-scale apps with larger teams.

Gadgeteer

Thank HMLS. Am still waiting for the Tapestry5 in action Book. Hope it will be out soon. – Canopy

Play can be deployed into Servlet servers as a .war, but it's not the recommended way. I don't miss the servlet API at all. – Gannon

"recompiling/reloading Java classes on each request" - only if they've changed, and only if it's running in development mode. Production mode is precompiled. – Gannon

I apologize for any FUD. I was working from what I remembered at your JavaOne talk ... kind of wish you had swung by mine! – Gadgeteer

I crossed out that FUD from your answer, hope you don't mind. – Kasher

Answer 3

The Play framework is not component based. There is not a Java class backing every page. Instead, it follows a strict MVC separation, where the meat of the application must reside squarely in the model.

Play is meant to be very similar to Ruby on Rails or Grails, but in Java. Also, it is possible to deploy a Play application on its own built-in server (based on JBoss Netty).

Which one you choose mainly depends on how you approach the view layer. If you prefer plain HTML, CSS and JavaScript, go with Play!. If you prefer Java components, go with Tapestry.

Riley

Answer 4

I don't know play at all, I have seen only some 5 min introductions, but didn't like it, but I have some experience with Tapestry 5. What are advantages:

• Tapestry is component based and that would be first and most important advantage. Components are just something you can't work without (if you will like them of course ;))
• It is very modular, in meaning it is easy to combine couple of independent projects. T5 is build around great IoC container (which should be promoted more by T5 team) and thanks to that it is easy to reconfigure default behavior of service classes (logic layer)
• you build on top of html like templates (how much tapestry tags are put into view depends just on your coding style)
• It is easy to persist state on server side when needed, however, by default it is just like you mentioned.

BTW tapestry 5 in action book just became available on MEAP

Once again, please note that I have no idea about play and was only trying to address points you mentioned. If you want more advantages of Tapestry (not over play, but overall strong sides of framework, please message me. I'll be happy to write more (especially as I'm in process of convincing client to switch from Spring to T5, and any practice before that talk is welcome ;) )

Regards Michał

Isabellisabella

This Michal for your response. I am very much interested in tapestry. When it comes to component frameworks, i have been using wicket and guice ioc. Once in a while i peep into tapestry. The only issue is docs. Am poor in reading wiki type docs. I like to get the big picture first then use the wiki/howTos to solve specific problems. Wicket on the other hand is too much work (maintaining 2 sets of files with nearly the same information). So am still looking for a silver bullet. May be T5 is the one. – Canopy

I was searching for my silver bullet when T5 was still in beta. I evaluated back then couple of frameworks and even thought I had raw start with it, now I can't imagine how people may live with spring. (edit -so don't accept enters ;)). Right now i'm working for a client in spring, and it is just painful to see all that components that will never be created. Also uglines of jsp makes me wanna puke. Last, but not least, I miss integration between controller and page template. It just doesn't make sens that you need to do awkward stuff like packaging data into model class to send it to view – Isabellisabella

Answer 5

The benefits of the Play! framework vs. Tapestry5 are:

• speed (a lot faster)
• existing code/modules you can use and save time

There are also 3rd party modules for Tapestry5 - but they will not save you time, they will consume time. Most of them are not maintained and you always need to fork, understand and modify all 3rd party code so it will work with the latest Tapestry versions. In the end, it is easier to write everything yourself. In general Tapestry5 is more expensive as you need to calculate code maintenance. On every Tapestry upgrade, you need to change your code as methods are deprecated - not only in your own code but all other modules from 3rd parties you have integrated. This is a big time killer and costs a lot of money.

Compared to Play! where you can just grab something like Facebook/oAuth authentication and it just works - also in the next updates of the framework, this is a huge cost benefit.

In general I always though Java webapps are most expensive to develop, maintain and host. However with Play!, the calculation is getting better - although the approach is sometimes less "intelligent". But if time-to-market and development costs count go for Play! or some other technology such as RubyonRails or PHP. However RubyonRails developers are as expensive as Java folks.

Girl

Play! framework upgrades are not exactly painless either (e.g. 1.0 vs 1.2), so I would not call them "it just works - also in the next updates". For more details zeroturnaround.com/blog/… – Dott

I'd object to the premise; Tapestry had such issues five or six years ago. With the move to the new code base, upgrades have been minimally painful, and growing easier with each release. – Gadgeteer

The only head to head I've seen performance wise gave play a small advantage against Tapestry 5.2. 5.3 is quite a bit faster, especially under heavy load. – Gadgeteer

There is also good and helpfull modules on Tapestry. Take a look on Tapestry's site : tapestry.apache.org/community.html#Community-Modules – Isidore

Answer 6

I would also say, even it's obvious for both Play and Tapestry users, that Tapestry is more conventional than Play, and meet more easily standards. I would not argue that's a good or a bad thing.Once again, it's not often a bad things to go somewhere off the beaten track. Play have a really good built-in home made stuff. So you don't need so much extra modules or plug Play to other librairies.

Both have great built-in features : live class reloading that is clearly incredible, injection, ... Sometimes one have better support than the other (REST for Play, for instance). They both really improve productivity. But Tapestry is quite more closer from standard than Play.

You don't need to include REST support in Play, neither to use a Servlet engine or plug any build system. It's an ALL-INCLUSIVE offer :). But when you need to meet standards criterias in a professional context, it's quite more difficult.

I recently had to make the choice, two times.

• Once whe decided to choose Play (greenfield developement for a new customer) and more experienced free developers (yes it matter ;))
• the other Tapestry because we REALLY needed to conform to our customer standard (and for good reason in my mind) : Maven, J2E server + JMX, use of enterprise libs based on ServletFilters we didn't want to develop again...

So, this is, from my point of view one of the main differences between those two incredibles frameworks.

Matt Raible (even if controversed ;)) said you should not choose framework from what the can do, but regarding on what they can't ! Its clearly the main debate here ! The can both do great works, but in two slightly different ways :)

Mckenney