Web Frameworks: How is Play different from Spring MVC? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

The Play Framework offers the following quick overview, but with the exception of the Groovy template engine (which you can get in Spring MVC i开发者_Go百科f you want), Spring seems to offer all the same features and more...

• Fix the bug and hit reload! Edit your Java files, save, refresh your browser and see the results immediately! No need to compile, deploy or restart the server. Spring does this, which can get annoying.

• Stateless model Play is a real "Share nothing" system. Ready for REST, it is easily scaled by running multiple instances of the same application on several servers. Typical Spring applications have a stateless application tier; it's not purely RESTful unless you want to be, but Spring is "ready for REST".

• Efficient template system A clean template system based on Groovy as an expression language. It provides template inheritence, includes and tags. Spring uses Java, but Groovy is an option too.

• Resolve errors quickly When an error occurs, play shows you the source code and the exact line containing the problem. Even in templates. Spring does this as well.

• All you need to create a cool web application Provides integration with Hibernate, OpenID, Memcached... And a plugin system. Spring integrates with everything and more.

• Pure Java Code with Java, use any Java library and develop with your preferred IDE. Integrates nicely with eclipse or netbeans. Spring is pure Java as well.

• Really fast Starts fast and runs fast! Subjective, but Spring is pretty quick.

So what does the Play Framework actually do differently than Spring MVC?

In a nutshell what can Spring do that Play framework cannot (and vice-versa)?

---

I find the "pure Java" claim on either side very funny.

Of course, it's unrealistic for a project to use absolutely nothing but java. Still, a "pure Java" label should have some standards, I don't think either framework qualifies.

Play actually modifies the semantics of Java language. That is all right as long as it's clearly specified. If you do some byte code manipulation, just be honest about it. Usually it's done by AOP-ish trick, instance methods are decorated with additional behaviors, their manifest behaviors - these written in the code, are usually preserved. This is not too hard to accept, we can pretend our code are subclassed by the framework and our methods are overridden with additional behavior.

In Play, one static method calling another static method in the same class can have magical effects, and the behavior is nothing like a method call. That is a huge problem, if a Java programmer can no longer be certain what a static method call is.

Spring - well, their Java part is still pure Java all right. But it's so magical(from java's POV), and depends so heavily on a heavy framework, calling Spring "pure Java", is like calling a burger "pure vege" if we overlook the meat. The meat is the best part!