Tapestry5 vs Play framework

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 recommen开发者_StackOverflow中文版d 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.

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.

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.

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.

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ł

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.

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 :)