Web development frameworks – part 1: Options and criteria
Since our last evaluation we have been using Java application servers powered by Struts 2 as MVC, Tiles as templating engine, jQuery for Javascript awesomennes, DWR for AJAX calls and MyBatis as ORM.
But we think it’s time to re-evaluate and move on to a newer/better/friendlier framework.
In this post I’ll present you with our candidates and the criteria we are evaluating each framework with. Over the next weeks I’ll post the actual evaluation of each framework and finally what our choice is and why.
Before listing the candidates I should point out some of the assumptions and restrictions we made in order to shorten the list:
- We will evaluate only frameworks based on Ruby, Python and Java. There is nothing wrong with .Net or PHP or other technologies, but we cannot cover them all and this three are our prime candidates anyway.
- The company has a lot of experience and accumulated knowledge on the Java platform, so you will see more Java based frameworks. Though hopefully no bias towards them.
- All frameworks must be free to use and preferrably open source. Additionally there has to be no need to use a proprietary IDE, application server or database to develop with them and/or use them in a production environment.
The candidates
The frameworks we chose to evaluate are:
- Play Framework 2.0
- Ruby on Rails
- Django
- Google Web Toolkit
- Spring Roo
- Spring Framework
- Struts 2
- JBoss Seam
Criteria
And the criteria we will use will be composed of the following items:
- Learning curve
- Development performance for simple tasks
- Development performance for complex/singular tasks
- Dependency management
- Code performance/security tunning capabilities
- Platform escalation/redundancy capabilities
- Acceptance in corporate markets
- Complexity of developing and consuming SOAP and REST services
A score scale of bad, medium and good will be assigned to each framework in each criteria item. To asses them we will perform the following tasks using each contender:
- Install the framework in a development workstation
- Setup a development environment using a free IDE, application server and database
- Develop the “Hello world” or similar sample outlined by the frameworks tutorial
- Modify the sample app to perform a specific database query over a custom structure and display the results
- Add a dependency to a third party library and perform a computation using it in our app
- Develop a “Hello world” REST service
- Consume our own service from our app
We are starting with the Play Framework 2.0, I’ll post the results as I have them.
Reference: Choosing a web development framework – part 1: options and criteria from our JCG partner Ricardo Zuasti at the Ricardo Zuasti’s blog blog.
Hello. Like your set of rules. We did had some discussion and published some of our finding on this (http://blog.8thcolor.com/2011/07/rails-django-the-showdown/). Hope it can be useful. I’m quite curious to see your results, especially as you are evaluating non java frameworks as a java shop (and this means switching from language, framework, but also platform and ecosystem – it is not just picking a language : http://blog.8thcolor.com/2012/07/you-are-not-just-picking-a-language-follow-up-on-from-java-to-ruby-post/). Martin
only one standard – JSF2
JSF is awful
JSF is the best and java web standard, people who complain from JSF does not understand his goal and life , you can find what another frameworks try to copy JSF core. Try JSF2 with primefaces, I success done about 40 JSF projects. If you start with php, jsp or another, during development you will try construct JSF schema:))
JSF2 cover all others
You’re missing Apache Sling. Here’s why, given your criteria: > Learning curve Very shallow, even if the documentation could be improved > Development performance for simple tasks Very good > Development performance for complex/singular tasks Very good > Dependency management Completely based on Maven / OSGi > Code performance/security tunning capabilities Very good > Platform escalation/redundancy capabilities Not sure what this means > Acceptance in corporate markets Sling is maintained by Adobe Systems and used in many internal and external Adobe products, mainly in CQ5 / AEM > Complexity of developing and consuming SOAP and REST services Sling is a… Read more »
Hmm… you’re evaluating Spring Roo, while ignoring Spring Boot? It seems like this should be the other way around.
Roo is all but deprecated at this point… an experiment several years back that failed to gain traction, and whose lessons learned resulted in Spring Boot later. Today, Boot is basically being pushed by the Spring guys as the preferred way to start every project.
Interesting. You include Ruby on Rails and Spring Roo, but not Grails. Grails is used much more than Roo.