Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/17/d418276000/htdocs/websitesframeworks/blog/wp-content/themes/rtpanel/lib/rtp-init.php on line 242

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/17/d418276000/htdocs/websitesframeworks/blog/wp-content/themes/rtpanel/lib/rtp-init.php on line 242

Warning: Cannot modify header information - headers already sent by (output started at /homepages/17/d418276000/htdocs/websitesframeworks/blog/wp-content/themes/rtpanel/lib/rtp-init.php:242) in /homepages/17/d418276000/htdocs/websitesframeworks/blog/wp-includes/feed-rss2.php on line 8
Blog Websites Frameworks http://blog.websitesframeworks.com An agile web framework comparison Fri, 06 Jun 2014 09:05:42 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.10 A Practical Comparison of Agile Web Frameworks: Presentation in video http://blog.websitesframeworks.com/2014/04/practical-comparison-agile-web-frameworks-presentation-video-541/ http://blog.websitesframeworks.com/2014/04/practical-comparison-agile-web-frameworks-presentation-video-541/#respond Sat, 05 Apr 2014 12:23:36 +0000 http://blog.websitesframeworks.com/?p=541 Hello, This is the presentation in my university of this project: A practical comparison of agile web frameworks: Rails, Grails, Django and CodeIgniter under a test. In this presentation I show: – Previous comparisons of web frameworks – The objetives of the project – The methodology that I followed to compare the web frameworks: Basically, […]

The post A Practical Comparison of Agile Web Frameworks: Presentation in video appeared first on Blog Websites Frameworks.

]]>
Hello,

This is the presentation in my university of this project: A practical comparison of agile web frameworks: Rails, Grails, Django and CodeIgniter under a test.

In this presentation I show:

– Previous comparisons of web frameworks
– The objetives of the project
– The methodology that I followed to compare the web frameworks: Basically, I develop a simple web application with each of them in fixed time: 125 hours for reading programming language documentation, making exercsies, reading web framework documentation, develop the small web application.
– A comparison of the different web frameworks based on this experience.
– Conclusions and future works.

Hope you like it.

The post A Practical Comparison of Agile Web Frameworks: Presentation in video appeared first on Blog Websites Frameworks.

]]>
http://blog.websitesframeworks.com/2014/04/practical-comparison-agile-web-frameworks-presentation-video-541/feed/ 0
Comparison of the ease of learning of Web Frameworks: Rails, Grails, Django and CodeIgniter http://blog.websitesframeworks.com/2013/12/comparison-ease-learning-web-frameworks-rails-grails-django-codeigniter-471/ http://blog.websitesframeworks.com/2013/12/comparison-ease-learning-web-frameworks-rails-grails-django-codeigniter-471/#comments Wed, 11 Dec 2013 10:10:03 +0000 http://blog.websitesframeworks.com/?p=471 This article compares the ease of learning of web frameworks: Rails, Grails, Django and CodeIgniter based on the experience of learning how to use the framework and developing a toy application, MyBlog, in fixed time. More details about this test can be found here. Points of comparison will be timing, documentation, community support, steps to execute common functions, some features, lines of code and readability of solutions.[[...]]

The post Comparison of the ease of learning of Web Frameworks: Rails, Grails, Django and CodeIgniter appeared first on Blog Websites Frameworks.

]]>
This article compares the ease of learning of web frameworks: Rails, Grails, Django and CodeIgniter based on the experience of learning how to use the framework and developing a toy application, MyBlog, in fixed time. More details about this test can be found here. Points of comparison will be timing, documentation, community support, steps to execute common functions, some features, lines of code and readability of solutions.

Complete source code of the implementations in each framework can be found here.

We can divide the development of the toy application into the following modules:

  1. User + Authentication system: A user is able to register, login, logout, etc.
  2. Blog: A user is able to create a blog.
  3. Post: A user is able to publish posts for his/her blog. These posts are listed in the front page and in each blog page.
  4. Comment: Users and guests can post comments.

If you would like to read a more extensive explanation, you can refer to this link.

It is important to keep in mind that this development process occurred between March and the end of July 2013, therefore notes and opinions are based on their state in those dates. The frameworks could have evolved since then.

In table 1, it is shown a comparison of developing time for each step with each framework. The same data is presented in a graph manner in figure 1. The order of columns represents the order in development. Developing with CodeIgniter required the least amount of time compared with other frameworks, 17 hours less to finish the exercise compared with Rails. Myblog application was finished with every framework in fixed time excluding Grails, which was almost finished with some errors. Developing with Django required less time than with Grails and Rails: 7 hours less.

Table 1: Developing times with Rails, Grails, Django and CodeIgniter
Step Rails Grails Django Codeigniter
Documentation 30 22 30 23,5
User + Authentication 13,5 31,5 20 15
Blog 8 9 6 5,5
Post 8 3,75 7 8
Comment 8 6,5 4,5 6,5
Friendly urls 6 1,5 0 0
Views as described in design 2 3 0 0
Pagination 2 0,25 1 2
Refactoring 0 0 2 0
Total 77,5 77,5 70,5 60,5
developing times in a web framework comparison for Rails, Grails, Django and CodeIgniter
Figure 1. Developing times in a web framework comparison for Rails, Grails, Django and CodeIgniter

Before comparing different steps, it will be exposed the commonalities between these frameworks.

  • All of them are MVC frameworks.
  • All of them have a route file to map the urls to the controller.

In the next sections, a comparison of different steps throughout development will be exposed.

Documentation

Rails had an excellent documentation. It had several examples which facilitated to understand the framework, it also had a getting started guide which gave an overview of the framework and had a division between beginner and advanced topics. Furthermore, it presented the highest popularity in StackOverFlow, most questions were already asked and solved.

Grails required less than 30 hours to read documentation. Documentation was difficult to understand and there was not a general division for beginners and advanced readers. It was considered, probably a wrong consideration, that it had been read enough documentation to start implementation and it would be well understood throughout development. Therefore, Grails required more time than others in the second step, when development began, because documentation was not clear. Other sources of documentation were used to understand it and people were complaining about lacking of documentation in blogs and forums. Main problems were Shiro and Hibernate.

Django had an excellent documentation, it was easy to follow, understand and it had several examples. Most questions were solved in StackOverFlow clearly too, but it presented a bit less popularity than Rails.

CodeIgniter presented a concise and short documentation. It lacked examples but it could be completely read and understood in 23.5 hour.

Implementing authentication

In Rails, implementing the User module and authentication required the least amount of time. Probably due to the fact that it was implemented following the Ruby on Rails Tutorial. Only with this framework, an own authentication system was built. The reason was that plugins(gems in Rails vocabulary), which offered this functionality, advised to build an own authentication system if the programmer had never done that.

In Grails, implementing authentication was the most difficult task. It was not known if it should be used Shiro or Spring Security plugin. At the beginning, it was tried with Shiro, but the official documentation was complex to be understood. This was the reason why it was tried to build an own authentication system as in Rails. All over this process, some better documentation for Shiro was found and finally, Shiro authentication library was used.

Django came with a bundled authentication system which was well documented, it simply had to be understood and adapted.

CodeIgniter had a Tank Auth library which was well accepted. This library was copied into the application. The source code was easy to understand and it was modified according to requirements.

Implementing Blog, Post and Comment

The modules Blog, Post and Comment are really similar: CRUD (Create, Read, Update and Delete) operations on database tables which are related between them. Therefore, it has be chosen a small example to compare them. This example implements the following use cases and features:

  • A user can create a post.
  • A user can read a post, the comments associated to this post and he/she has the possibility to publish a new comment.
  • The url to show a post must be friendly.
  • The owner of a blog is allowed to delete comments of his/her blog.

In table 2, the steps that were followed to implement this example in each framework are shown. This allows us to compare the different methodologies used to develop with each framework. From a wide perspective, code generators were used with Rails and Grails, while class-based views were used with Django and most of the code had to be written with CodeIgniter.

Table 2: Comparing steps in development
Rails

  • In console, use scaffold generator to create Post and Comment CRUD operations: it would generate basic views, controllers and models. Migrations to create database tables are created too. They simply have to be run. It is necessary to understand scaffold and the generated code.
  • Edit Models: Write validations and relations between models. Modify the method to_params to use the title as the param to pass in parameters. In the post model: Create a filter to autogenerate the permalink based on the title. It is necessary to understand Rails validations, relations and the to_param method.
  • Edit Post Controller: modify create method to create the post and link it to the user and show method to receive the permalink.
  • Edit routes file: adapt it to use the permalink of the post. It is necessary to understand routing.
  • Edit Comment controller: allow only create and delete. Adapt create comment to relate the comment to a user if he/she is signed in. Adapt delete method to control if the user is the owner of the post.
  • Write template for showing a post.
Grails

  • Create the domains Post and Comment, write validations, relations and  create a filter to auto generate the permalink based on the title in post domain. It is necessary to understand Grails domains.
  • Scaffold Post and Comment based on the domains defined. Similar to Rails but there are no migrations.
  • Edit Post Controller: Adapt save method to create the post and link it to the user. Adapt show method to find the post using the permalink.
  • Edit UrlMappings file. Adapt it to receive the permalink of the posts to look for it. It is necessary to understand routing.
  • Edit Comment controller: Only allow to create and delete methods. Adapt create comment to relate the comment to a user if he/she is signed in. Adapt delete method to allow execution only if the user is the owner of the post.
  • Write templates for showing a post.
Django

  • Define new models for Post and Comment in models file: Their fields, relations and methods for setting friendly urls. It is necessary to understand well Django models and their methods.
  • In console use syncdb to make Django create the database tables.
  • Create the views inheriting from the Class Based Views and adapt them to satisfy the requirements. It is necessary to understand the class-based views well: their workflow and their methods to know which ones are necessary to be modified.
  • Configure routes to map the urls to the methods.
  • Write templates for showing a post.
CodeIgniter

  • Create the databases you need with SQL statements or any database management software.
  • Create the models: Implement the method to publish a post. Implement the method to read a post. Implement the method to read a comment and to delete a comment. Implement the method for retrieving all the comments from a post.
  • Create the controllers: Implement the create method for creating a post. Implement the show method for showing a post. Implement the methods for creating and deleting a comment. Load classes needed, retrieve data to pass it to the view, test if input data is valid.
  • Create the views

Rails and Grails steps are really similar. It may be used code generators and adapt them. These generators implement the CRUD operations in a resource with basic views. You can see code generated and adapted for the post controller, the post model and the post show view in Grails and Rails. These generators can be used to agile development and make the required changes to the code.

Django offers a different approach with the class-based views, although it is possible to write similar code in Django than the one generated by Grails or Rails. It would be more time consuming than using class-based views. The Django approach requires the programmer to understand well the class-based views, their workflow and methods. This approach follows more strictly the DRY principle than Rails and Grails. In this link, views, models and a template are listed for the post module. Complete source code can be found in the source code of the full implementation. The action of creating a post is implemented by defining a class PostCreate, which is a subclass of CreateView, to create a record based on a model. The model to be used is defined and two methods are overwritten: the dispatch method and the form_valid. The first one is modified to require a user to be signed in, while the last one is modified to connect the post to a blog, afterwards it is called the super method in both cases.

CodeIgniter does not have generators neither class-based views. It requires the programmer to write most of the methods needed. It has libraries to help in the task but the active record implementation does not offer a complete set of functions to treat database records as objects. The source code for the model, controller and view is listed here. It can be seen that several methods used in the rest of the web frameworks in this comparison had to be implemented, for example: create, get_post, update, among others.

Code generated by Grails vs Rails

Rails and Grails code generated and adapted for the post controller, model and show post are listed in this link. As it can be seen, Grails did not generate a model. First, the model had to be written and afterwards the code could be generated. Code generated by Grails was larger than code generated by Rails. But Grails offered more features with the code generated: it was already prepared for internationalization and, when updating a resource, it controlled if the resource had been updated since it was retrieved. On the other hand, Rails was prepared to render JSON with the code generated. Views generated by Rails were cleaner and more concise than those generated by Grails.

Comparing general features

Some features which have been discovered throughout development are compared here: database tools, active record implementation, Javascript support, support for forms not binded to models, support of  DRY principle and convention over configuration.

  • Database tools: Tools for creating databases, tables, fields, get back to previous state or move forward.
    • Rails had a complete functionality for managing databases. It could be created databases, tables, updated fields, among other features. Furthermore, it supported migrations: any change made to the database was stored in a file called migration which could be set up or down, to commit the changes described in the file or recover to previous state.
    • In Grails, it was defined the model in a file and the database was created in HSQLDB. It is not known how difficult is to migrate from this DB to MYSQL, SQLite or others.
    • Django supported creating database, although it did not have migrations. Therefore, updates in table structure had to be made with other software.
    • CodeIgniter did not offer tools for creating the database.
  • Active Record Implementation, searching in models and pagination: Tools for operating with records in database in an object-oriented manner. For example, to get a post is possible with the statement post = Post.find(id); to access its fields: post.title; or its relations: post.blog.
    • Rails had a full active record implementation. It did not support search queries in database, while Grails and Django did.
    • Grails had a full active record implementation. It supported searches and pagination. It can be seen an example of use in Myblog in this link.
    • Django had a full active record implementation. It supported searches and pagination. It can be seen an example of use in Myblog in this link.
    • CodeIgniter active record implementation lacked several features. There were no standard methods to retrieve an object from a database, or to find a record by an attribute, among others.
  • Javascript feature: send a dialog to confirm to delete a resource. This project built the application with different frameworks not taking care about the front end. Therefore, it was not necessary to use Javascript. There was only one case where it was useful: to open a dialog requesting if a resource should be deleted or not. Based on this problem:
    • Rails: it was really easy to implement and was full supported.
    • Grails: Similar to Rails.
    • Django: It was not supported.
    • CodeIgniter: It was not supported.
  • Follows the DRY Principle:
    • Rails: Its structure followed greatly the DRY principle but the code generated was repeated in several controllers.
    • Grails: Same as Rails.
    • Django: It was the best framework in the comparison following this principle due to the fact that it used class-based views.
    • CodeIgniter: It did not follow the principle as strongly as other web frameworks did. Most of the methods had to be written and they were usually very similar.
  • Forms not binded to models: There are special cases where a form is presented in a website but it is not binded to a model. A contact form is an example. What is the approach of each framework to this problem?
    • Rails used virtual attributes to define models which were not connected to a model. It was not well understood after development. It did not seem as clear as other solutions.
    • Grails had a class that was called command objects and they served for this purpose.
    • Django had a class called forms.
    • CodeIgniter had a form library to help in this task.
  • Convention over configuration
    • Rails followed strictly the convention over configuration principle. It was positive to obtain a more concise code, as most of its part was assumed by the convention. But, if it was necessary to implement something different from the convention, for example not using REST convention, it increased complexity by implementing it.
    • Grails followed less strictly convention, more configuration had to be done but it also helped when defining the personalized behaviour.
    • Django followed this principle less strictly than Grails.
    • CodeIgniter lacked following a convention, for example, there was no standard to call the models. It was decided to use the letter m in front of the name of the resource for naming it.

Comparing lines of code

Table 3: Comparison of the total amount of lines of code of the different implementations with Rails, Grails, Django and CodeIgniter
  Rails Grails Django CodeIgniter
Views 375 777 314 507
Models 59 76 56 429
Controllers 271 436 296 516
Routing files 20 44 26 18
Total 725 1333 692 1470

Table 3 shows the total lines of source code for every implementation with each web framework. Grails called the models domains and Django, the controller views, but here it will be used the words model, controllers and views following the names used in the MVC pattern. It has been divided into four groups: views(it includes small functions to help called helpers and layouts), models, controllers(forms included) and routing files.

According to the results, Django presented the least amount of lines of code, followed by Rails and Grails and CodeIgniter. Django used the class-based views which implied less repetition and shorter code. Rails used code generation, but it generated a really short code which was possibly due to all the conventions assumed. Grails made generation, but it added more functionality in the code and was more verbose. Furthermore, it did not follow so many conventions as Rails. In CodeIgniter, it was necessary to write most of the functions, therefore, it had the biggest amount of lines of code.

Conclusions

Concerning the documentation,

Rails is a really well documented framework and has the greatest support from the community but learning how to use it requires a huge amount of time. Documentation could not be finished and many features could not be discovered throughout this implementation.

Grails documentation is not well organized, it is difficult to understand, it lacks examples and it has a poor support from the community. It seems to point to developers coming from Java frameworks, like Spring or others. Nevertheless, when it is understood, developing begins to be fast, as it has been proved in the developing times after the first module was implemented: second, third, and fourth module presented a similar implementation time in every web framework. It has more features than those which were discovered in this implementation.

Django documentation is as good as Rails, at least, and it has great support from the community. It has more features than those which were discovered in this implementation too.

CodeIgniter documentation could be completely read in less than the fixed time. Documentation was clear and concise. It was not necessary to look for questions because most of the times it was already known how to solve the problems. Mainly, because it was the programmer who had to create the methods.

Conerning the authentication system,

Rails was the framework which required the least amount of hours to implement this requirement despite the fact that the authentication system was built, it was not used any plugin(gem). It shows that, for an inexperienced programmer, it was faster having a tutorial than learning how to use the plugins in the other different frameworks. Being built by the programmer has the cons of being probably more insecure.

In Grails and Django the authentication systems had to be adapted, but the code was not easy to understand, neither how to customize it, it required more time. It is important to keep in mind that probably Grails and Django approaches are more secure as they underlie in the plugin implementation.

On the other hand, CodeIgniter offered a library whose code was copied into the application and adapted to it. It was easier to customize because it could be read the whole code, remove unnecessary parts and adapt others. Nevertheless, as it was copied into the project and fully adapted, it could have security problems as in Rails.

Concerning the developing common operations, CRUD,

Rails and Grails generated code are good approaches. Specially for an inexperienced programmer. It is more common that they will not know how to approach these problems, scaffold give a fast solution and it can be worked from there. Nevertheless, code is repeated several times in different controllers, it does not follow so strongly the DRY principle. As it was commented previously, Rails generated code was clearer than Grails, although Grails offered internationalization and version control.

Django approach with the class based views can be a bit harder to understand, but it is the best approach to follow the DRY principle and it gives the most concise code.

CodeIgniter does not offer generators,class-based views and even it does not have a complete ActiveRecord implementation, a library for accessing database records in an object oriented way. The framework helps with libraries and facilitates to follow the MVC pattern, but it has to be written several methods which were already supported in other frameworks. Due to this fact, it weakly follows the DRY principle and the Convention over Configuration.

Concerning the developing times,

Rails was the first framework to develop with. There were a lot to learn about the problem and web development in general, for example, differences between POST and GET verbs. Furthermore, when it was tried to modify the conventions, it increased complexity solving the problems. In Rails, in general, everything is going to be implemented, there will be a Rails manner to implement it and it requires the programmer to learn it.

Grails is the only framework whose implementation was not possible to be finished. It was almost finished but there were some functionalities left and some errors. The main problem with Grails was the documentation, the IDE, Groovy and Grails ToolSuite based on Eclipse, and the fact that the JVM had to be loaded for developing slowed down development speed.

Django was the first framework which presented less time to implement the full application. Reasons may be: experience from previous implementations, readable and understandable documentation and class-based views.

CodeIgniter is the only framework which required less time than fixed to read documentation and to implement the application. Nevertheless, it is the framework which less adequately follows the DRY and the Convention over Configuration principles. CodeIgniter does not have as many features as other frameworks in this comparison, therefore, it was not necessary to read the documentation all the time. Throughout the development, most of the times, it was not necessary to read how to use libraries and how they connect to each other, it simply could be programmed as it was needed. Therefore, it required the least amount of time, compared to others in this comparison.

In my opinion and summarize conclusion,

If a newbie programmer just wants a small web application get started fast, CodeIgniter is a good choice.

Rails, Django and Grails are frameworks which require a great effort to learn how to use them. Nevertheless, they are better prepared to support bigger applications, using them will result in a clearer, better organized, less repeated, easier to support code and to follow better a convention. Learning those frameworks is a time investment to obtain benefits in several months.

It is more common that bigger corporations will use Java, therefore Grails, based on Groovy, which is compiled into JVM, is more probable useful to find a job. Nevertheless, as it has been said, it is more difficult to learn it than others in this comparison.

Rails and Django are easier to learn, better documented and has strong support from the community. If you already know where you want to work or you want to become a web developer to implement your own projects, consider making the investment of time to learn to use any of those frameworks. I would choose between these two, mainly because of the support from the community.

My professional life now,

Since two month ago, I began to develop a web project with Rails.  Why did I choose Rails?

  • Ruby.
  • Support from the community.
  • Migrations.
  • Apparently it has better support for Javascript.
  • I know some people who began to work with Django and migrated to Rails.

And what really bothers me about Rails is that:

  • It does not have bundle authentication system.
  • It does not have class-based views or some way to avoid repetition in controllers. I specially miss this feature.

Are other frameworks I tested bad? No, it is not the case. Well, I think CodeIgniter is the worst option if you want to become a web/web-service developer in the long term. But other frameworks in this comparison are great, despite the fact that Grails has an awful documentation. In case you are interested in JVM framework, perhaps it would be better to take a look at Play!, it seems to be well supported. It is written in Scala, based on JVM.

What to say about this project?,

I have invested 800 hours in this project. That’s nearly 6 months of full-time job. It has been almost a year. Despite of that, I have a really low knowledge of each framework. Having a good level of knowledge about each framework would require more time. I have been able to make a comparison of ease of learning in any case.

So, a final question and the most important one:

Is it clearer now which web framework to choose?

Thanks for reading. Comments, criticism and sharing will be appreciated.

The post Comparison of the ease of learning of Web Frameworks: Rails, Grails, Django and CodeIgniter appeared first on Blog Websites Frameworks.

]]>
http://blog.websitesframeworks.com/2013/12/comparison-ease-learning-web-frameworks-rails-grails-django-codeigniter-471/feed/ 5
Comparison of programming languages: Ruby, Groovy, Python and PHP http://blog.websitesframeworks.com/2013/11/comparison-of-programming-languages-ruby-groovy-python-and-php-353/ http://blog.websitesframeworks.com/2013/11/comparison-of-programming-languages-ruby-groovy-python-and-php-353/#comments Fri, 08 Nov 2013 12:36:15 +0000 http://blog.websitesframeworks.com/?p=353 This article is part of a comparison of web frameworks which tries to measure the ease of learning and development for several web frameworks(Rails, Grails, Django and CodeIgniter) with a practical test. In order to learn Ruby, Groovy, Python and PHP, 8 hours were invested in reading documentation and a set of exercises were implemented. […]

The post Comparison of programming languages: Ruby, Groovy, Python and PHP appeared first on Blog Websites Frameworks.

]]>
This article is part of a comparison of web frameworks which tries to measure the ease of learning and development for several web frameworks(Rails, Grails, Django and CodeIgniter) with a practical test. In order to learn Ruby, Groovy, Python and PHP, 8 hours were invested in reading documentation and a set of exercises were implemented. Source code of the implementation of the exercises can be seen here. In this article, a comparison based on this learning process and experience is made.

This article has the following structure:

  1. Comparison of time developing each exercise
  2. Comparison of readability of the languages
  3. Comparison of results in benchmarks and lines of code. From the project Computer Language Benchmarks Game
  4. Conclusions

It is important to notice that the first section can be difficult to understand without knowing about the implemented exercises. Therefore, in case you do not know about them I recommend you to skim it or jump directly to section 2.

Comparison of developing time

Table 1: Hours required to develop programming exercises with programming languages
Exercise Ruby Groovy Python PHP
Strings, files and regular expressions 4,5 3 2 2
Numbers set 4 2,5 1 2
Composite Pattern 1,5 1 1 0,5
TOTAL 10 6,5 4 4,5

Table 1 shows a comparison of timings used to implement each exercise with each technology. According to the results, Python is the programming language which required less hours to finish the exercises and Ruby was the one which needed the most. It is important to remember that the order of columns is the order in development. The first programming languages used required more time than the last ones. Python and PHP were the exception.

In the first exercise, Ruby was the first language used to implement. Therefore, at the beginning, it had to be understood the regular expressions and how to use them. For example, Ruby solution to the first exercise uses a regular expression which does not satisfy all the cases, therefore, an exception code had to be written. Nevertheless, in Groovy, the regular expression which satisfies all the cases was used. Python already had a method to separate between words and another method for removing punctuation, which increased the speed in resolving it. PHP solution is close to Python solution.

In the second exercise, in the case of Ruby it was necessary to understand the code blocks well. For the Groovy case it was easier, since Groovy block codes are similar to Ruby. For the Python case it was even easier, since Python has a number set class. When using PHP it had to be programmed in a manner closer to C++.

In the third exercise, Ruby and Python did not support control type argument, hence exceptions had to be written to control type arguments. On the other hand, Groovy and PHP allowed to control type argument. Furthermore, PHP supported abstract classes, therefore the Component class could be implemented as abstract.

Table 2: Source code lines in programming exercises
Exercise Ruby Groovy Python PHP
Strings, files and regular expressions 30 27 28 35
Numbers set 56 51 28 56
Composite Pattern 50 48 38 50
TOTAL 136 126 94 141

In table 2, the number of source code lines for each exercise was counted. Python presented the shortest code. The reasons are: Python does not need end statements in block of code, neither it uses curly braces syntax. Furthermore, in the Number Set exercise, it already had a library for implementing it, which resulted in a shorter code. Rest of programming languages are close to each other. PHP presents the longest code. It uses curly braces and does not have any special method for iteration, it uses the for structure which results in more lines. Besides, Ruby and Groovy are really close, but Groovy has control type argument for example, which allows to write less lines in the third exercise.

Based on this analysis and experience, Python presented the best productivity with the least amount of lines of code. Mainly due to the following facts: it provides a complete set of libraries which allowed to solve each exercise quickly and it has a mandatory indentation syntax. Difference in time between Groovy, Ruby and PHP can be a bit tricky, because how to solve the exercises was learnt using Ruby. Furthermore, the programmer had knowledge about how to use PHP because the manner to solve the problems is really similar to C++. Nevertheless, according to the facts PHP presented a high productivity, close to Python.

Readability

In this section, an analysis of readability of each programming language will be made. A comparison between programming languages and the natural languages will be carried out.

In natural language, a predicate is the completest part of a sentence. The subject names the “do-er” or “be-er” of the sentence; the predicate does the rest of the work. There are several types of predicate but it is always composed by a verb which may connect the subject with other modifiers or information. Object-oriented syntax is close to natural language. In the common form object.method(arguments) the object is the subject, the method is the verb and the arguments are the modifiers.

In table 3, different orders are expressed in natural language and their implementations in the different programming languages are shown. Examples have been extracted from the exercise whenever it has been possible.

In the first example, it is shown that Ruby allows to use a structure closer to a subject, the number set; the action, the method; and the question symbol which shows it expects a boolean. Groovy is similar, but it does not allow the ? symbol. In Python and PHP implementation the verb, the method, acts over the subject, in a less object-oriented manner.

In the second example, a structure for collecting inside a list of elements is shown. In this case, Groovy and Ruby are really similar, they both use the iterators and blocks of code, providing a solution really close to natural language. Groovy presents a shorter solution using the it keyword. Python and PHP present a closer syntax to C++. PHP uses the dot to sum strings, which is not as intuitive as the plus.

The third example is similar to the first one. Ruby uses the ! symbol to make reference to a method which will change the state of the object. Groovy uses an object-oriented manner and closer to natural language but does not use the exclamation symbol. In this case, Python is closer to natural language than before. PHP still uses the verb, function over the object.

Finally, the fourth example shows the ability of Ruby to use the unless statement.

Table 3: Comparing readability of programming languages
Natural Language Code Examples
Is the list of numbers empty? Ruby
@theNumberSet.empty?
Python
len(self.the_set)
Groovy
numbersMap.size() == 0
PHP
count($this->arrayset);
Collect names of each element and write them in a paper called result. Ruby
@composite.each{ |item|
result+=item.toString
}
Python
for element in   self.listComponents:
string += element.toString()
Groovy
components.each{
string += it
}
PHP
foreach ($this->list as       $element){
$string .=   $element->__toString();
}
Remove white spaces from the line Ruby
line.chomp!
Python
line = line.rstrip()
Groovy
Line.trim()
PHP
$word = trim($word);
If variable is not a component type, throw an exception. Ruby
raise ‘No component type’ unless component.kind_of?(Component)
Python
if not isinstance(component,Component):
raise NameError(“No component type”)

In table 3 a list of capabilities which make a language readable are shown. They are extracted from the experience developing these exercises and the website. Python is supposed to be highly object oriented, but it has been seen some examples where Ruby and Groovy are more object-oriented than Python. Furthermore, Python is the only programming language which considers indentation mandatory, which is a good feature for improving readability. The fifth feature shows languages which support keyword arguments. This feature was added to Ruby in version 2.0. It increases readability since it is not necessary to remember the order of the arguments for a method, instead it can be used named arguments.

Table 4: Comparing features for readability in programming-languages
Feature Example Ruby Groovy Python PHP
Highly object oriented 3.times{ puts ’hello’ } yes yes almost no
It allows to use ? And ! in methods line.chomp! yes no no no
Unless and until statements println ’hello’ unless dont
knowhim
yes no no no
It uses block codes and iterators listnumbers.each{|number|
print number
}
yes yes no no
Indentation is mandatory and is
used to delimit blocks of code
no no yes no
Keyword arguments. Arguments for a method can be passed by a name travel(from=’pointa’, to=’pointb’) yes no yes no

Based on these examples and the experience developing, Ruby is considered to be the closest to the natural language because it has special syntax features. Groovy will be the second, Python the third, and PHP the last one.

Performance

In this subsection a brief analyses of performance for each programming language will be made. Results in figure 1, shows that Ruby, PHP and Python are similar in performance. Groovy is not shown. But Groovy is considered to be 8 times slower than Java. Hence, it would be around 10 20 times slower than C.

Performance comparison of programming languages.
Figure 1: Performance comparison of programming languages. Source CLBG

Figure 2 shows difference in execution time, memory and lines of code of Python over Ruby for 10 tiny examples. It is important to notice that Ruby and Python are similar in lines of code in these examples. In some examples Python is shorter and in others larger.

Python vs Ruby in peformance
Figure 2: Python vs Ruby in peformance. Source CLBG

Conclusions

Doing these exercises allows to have some level of experience with the different programming languages. It is difficult to measure productivity, due to the fact that the first implementation is when the first solution for the problem is described, hence it requires more time. Nevertheless, the next conclusions are extracted:

  • Python was the most productive language. Mainly due to the existence of libraries. It was the most concise too. It is important to remember that in The Computer Language Benchmark Game: Ruby and Python were similar in lines of code.
  • Ruby is the most readable language. Groovy is really similar to Ruby. Python presents new syntax features which are not common in C++, while PHP is really close to C++, hence less readable.
  • Groovy presents the best performance. PHP, Python and Ruby have a similar performance.

Those are the conclusions from this experience.

In my opinion:

  • Ruby is the most readable language, I really like it, I think its semantics and syntax is the way to go. I just miss the mandatory indentation from Python.
  • Python has libraries for almost everything. It is not only something  I have observed from this set of exercises. I have talked with colleagues about this topic and they agree Python has loads of libraries, specially about scientific computing. Furthermore, it is said it is well prepared to call C or C++ functions within Python. This feature allows you not to care about performance while developing and, if it is necessary, to make profiling at the end and to translate the parts of code which require more time to be executed. Nevertheless, it is not as readable as Ruby neither as object oriented and it does not have the same performance as Groovy.
  • Groovy is really similar to Ruby but it is not the same. Nevertheless, it has a better performance. Furthermore, you can develop in Groovy and call functions in Java. This allows to have the same methodology than with Python and C/C++.
  • PHP was designed for web development. Its syntax is really close to C++ but it is easier. It is fine for web development in case you do not want to use a web framework. Furthermore, WordPress, Joomla, Drupal, Moodle among others are build with this language. Hence, if you are planning to make a web project which adapts to those CMS, you will need to learn PHP to modify its behavior.

What do you think about this comparison? Which language do you think is more productive? and readable? What about the performance? Do you agree with my opinion?

Thanks for reading. Comments, criticism and sharing will be appreciated.

The post Comparison of programming languages: Ruby, Groovy, Python and PHP appeared first on Blog Websites Frameworks.

]]>
http://blog.websitesframeworks.com/2013/11/comparison-of-programming-languages-ruby-groovy-python-and-php-353/feed/ 18
A website for web framework comparison http://blog.websitesframeworks.com/2013/05/web-framework-comparison-a-website-267/ http://blog.websitesframeworks.com/2013/05/web-framework-comparison-a-website-267/#comments Wed, 01 May 2013 20:52:28 +0000 http://blog.websitesframeworks.com/?p=267 In this article, it is defined the website to be developed in order to test each framework. Due to the limits of the project time, a deep research has not been able to be carried out in this section. Therefore, the expert, Carlos Hernández, founder of Endeve and expertise in agile development, has helped in the website definition. A multiblog-only-one-author application has been decided. It requests the developer to know implementing CRUD operations with related data, validations, user session management and searching in a database. Next [[...]]

The post A website for web framework comparison appeared first on Blog Websites Frameworks.

]]>
This article is part of a comparison of web frameworks which tries to measure the ease of learning and development for several web frameworks with a practical test. In this article, it is defined the website to be developed in order to test each framework.

Due to the limits of the project time, a deep research has not been able to be carried out in this section. Therefore, the expert, Carlos Hernández, founder of Endeve and expertise in agile development, has helped in the website definition.

A multiblog-only-one-author application has been decided. It requests the developer to know implementing CRUD operations with related data, validations, user session management and searching in a database.

Next, a small index of the article:

  1. Website requisites
  2. Actors in the website
  3. Use cases
  4. Data model
  5. Visual design
  6. Steps in development

Requisites

  • A visitor can read blog posts
  • A visitor can read comments in blogs
  • A visitor can search for posts
  • A visitor can comment posts
  • A visitor can register
  • A user can login
  • A user must have a blog and no more blogs
  • A user can create posts in his/her blog
  • A user can comment in his/her posts and other posts
  • A user can search for posts
  • A user can read blog posts and comments

Actors

There are two actors in the website. Visitor and registered user.

  • Visitor: It is a person who has not registered yet or has not logged in.
  • User: It is a registered person, a user. He/she has a blog.

Use cases

Next the use cases:

Use cases of a website to develop for a web framework comparison
Use cases of the user
Use cases of a website to develop for a web framework comparison
Use cases of the Visitor

Data Model

Data stored for each entity:

The class model of a website to develop for a web framework comparison
The class model of a website for a web framework comparison

Visual design

Aesthetic and complex interaction using AJAX are not considered in this comparison. The views will be just HTML divs with titles to show interaction and options.

Next, there is a mockup of the front page for a signed user. In case you would like to see all the mockups, you can download them by clicking here .

User front page for a signed user. A website to develop in order to compare web frameworks.
User front page for a signed user of a website for a web framework comparison.

Steps in development

These are the tasks in the order in which they will be carried out in the development process:

  1. User authentication system
    • Create a user
    • Show a user
    • Update a user
    • Delete a user
    • Secure authentication: Login, logout, remember session. Allow to update a user only to signed users and to their accounts.
    • Image attached to the user: Add the image for the users. Upload system and display the image in the profile.
    • Change password
  2. Blog system
    • Create a blog
    • Show a blog
    • Update a blog
    • Delete a blog
    • Update delete user: Remove blog if user is removed
    • Authentication functionalities: Only a signed user can create a blog. Only the owner of a blog can update it and delete it.
  3. Post system
    • Create a post
    • Show a post
    • Update a post
    • Delete a post
    • Show the list of posts in the blog view
    • Update delete user: Remove posts if user is removed.
    • Authentication functionalities: Only allow owner of the blog to create, update and delete posts
    • Search posts with any words in the title or in the body
  4. Comment system
    • Create a comment
    • Show a comment
    • Delete a comment
    • Authentication functionalities: Only allow owner of the post to delete comments
    • Update delete user: Leave comments if the user is removed with its last data.
  5. Fixing everything together
    • Friendly urls: myblog.com/timy must show Timy’s blog and the url of the posts must be friendly too.
    • View as described in design: The interactive design must be as described. For example, the front page must be an index of all the posts ordered by date.
    • Page counter: When there are too many posts to be listed in a page, it must be divided by pages with links to choose between them.

It is an easy website to be developed but it could not be too complex due to the 45 hours limit to do the task. Would you change anything in the design? Would you proposed a different one?

Thanks for reading. Comments, criticism and sharing will be appreciated.

The post A website for web framework comparison appeared first on Blog Websites Frameworks.

]]>
http://blog.websitesframeworks.com/2013/05/web-framework-comparison-a-website-267/feed/ 6
Programming exercises for language knowledge testing in a comparison of web frameworks http://blog.websitesframeworks.com/2013/04/programming-exercises-language-knowledge-testing-comparison-web-frameworks-254/ http://blog.websitesframeworks.com/2013/04/programming-exercises-language-knowledge-testing-comparison-web-frameworks-254/#comments Wed, 17 Apr 2013 12:59:27 +0000 http://blog.websitesframeworks.com/?p=254 This article is part of a comparison of web frameworks which tries to measure the ease of learning and development for several web frameworks with a practical test. In this article, a set of programming exercises which tries to test language knowledge is defined. Due to the limits of the project time, a deep research […]

The post Programming exercises for language knowledge testing in a comparison of web frameworks appeared first on Blog Websites Frameworks.

]]>
This article is part of a comparison of web frameworks which tries to measure the ease of learning and development for several web frameworks with a practical test. In this article, a set of programming exercises which tries to test language knowledge is defined.

Due to the limits of the project time, a deep research has not been able to be carried out. Therefore, the expert, Juan Carlos Rodríguez del Pino, a language programming professor at the ULPGC and the author of Virtual Programming Lab, has helped in the language programming exercises definition.

Exercises

A subset of the exercises used at the Computer Science School in ULPGC has been chosen. Figure 1 shows which features of the programming language the subject has to practice in each exercise.

The first exercise demonstrates knowledge of files operations, strings and regular expressions. The second exercise demonstrates basic knowledge about classes, types and structures in the language. The third exercise is the composite pattern, it demonstrates inheritance and polymorphism knowledge. The third and last exercise is the composite pattern because, despite being important in programming language knowledge, it is not considered to be important for developing the website.

Basic components such as variables, constants, data types, control structures, data structure and functions are the most used because they seem to be more important for programming with a web framework.

Language exercises learning table
Figure 1. Language exercises learning table

The Strings, Files and Regular Expressions exercise

Given a text in a file and a dictionary in another file, the output has to be a file with every word included in the text that is not inside the dictionary surrounded by square brackets and emails have to be surrounded by braces. Words which are parts of emails are not tested if they are in the dictionary.

Example:

  • Text:
Welcome to a great comparison framework. Contact me on contact@websitesframeworks.com
  • Dictionary:
to
a
great
comparison
  • Output:
[Welcome] to a great comparison [framework]. Contact me on {contact@websitesframeworks.com}

The Numbers Set exercise

A class NumbersSet which contains a set of numbers and has the following operations:

  • Empty constructor: A default constructor which creates empty sets.
  • Vector constructor: An optional constructor which allows to initialize the set with numbers without repeating them through a vector. If repeated, it throws an exception.
  • size: Number of numbers in the set
  • isEmpty: It gives an answer if the set is empty or has at least one number
  • add: It adds a number if it does not exist, if it exists, it throws an exception.
  • belong: It tests if a number is inside the set
  • equal: Given a set, it tests if it is equal. Two sets are equal if they have the same numbers.
  • subset: Given a set, it test if the set is a subset of the instance.
  • vector: Given a vector, it returns all the elements of the set in the vector.
  • union: Given a set, it creates the union between the set and the instance.

Example of use:

array v1={1,3,4,7,-10};
array v2={3,5,-2,1,4,8};
array v3;
NumbersSet A(v1);
NumbersSet B(v2);
NumbersSet D;
D=A+B;
D.elements(v3);
for(i=0; i<;D.size();i++){
   print v3[i];
   print " ";
}
print "\n";

The Composite Pattern exercise

Some documents have to be represented. A document is made up by components. A component can be some text, a number, a date or a composite component. A composite component is a collection of one or more components. Every component offers the operation:

  • toString: String representing it

The composite component has the following operations too:

  • add: It adds a component to the collection
  • size: It returns the numbers of elements in the collection
  • modify: Given a component and an index, it substitutes the element indicated by the index for the component in the input.

Define the classes Component, TextComponent,  NumberComponent, DateComponent and CompositeComponent.

Example of use:

p= new CompositeComponent;
p.add(TextComponent("String. Number"));
p.add(NumberComponent(1));
p.add(TextComponent("\n"));
p.add(TextComponent("Date: "));
p.add(DateComponent(today));
p.add(TextComponent("\n"));
p.add(TextComponent("Yesterday:"));
p.add(DateComponent(yesterday));
d= new CompositeComponent;
d.add(TextComponent("Testing composite"));
d.add(TextComponent("\n"));
d.add(p);
delete p;
d.add(TextComponent("End testing composite"));
print d.toString();
print "\n";
d.modify(0,TextComponent("Beginning modified"));
print d.toString();
print "\n";

I think these exercises are adequate for testing programming language knowledge in order to get ready for the web framework learning process. Is there anything else you miss?? Would you propose a different design? Which one?

Thanks for reading. Comments, criticism and sharing will be appreciated.

The post Programming exercises for language knowledge testing in a comparison of web frameworks appeared first on Blog Websites Frameworks.

]]>
http://blog.websitesframeworks.com/2013/04/programming-exercises-language-knowledge-testing-comparison-web-frameworks-254/feed/ 4
The practical test for web framework comparison: learning and development steps http://blog.websitesframeworks.com/2013/03/practical-test-web-framework-comparison-244/ http://blog.websitesframeworks.com/2013/03/practical-test-web-framework-comparison-244/#comments Wed, 27 Mar 2013 18:48:13 +0000 http://blog.websitesframeworks.com/?p=244 In this article, the subject background, the chronological development of all the tests, the test steps to do with each web framework, their times and the documentation that will be used along the process, are described. [[...]]

The post The practical test for web framework comparison: learning and development steps appeared first on Blog Websites Frameworks.

]]>
This article is part of a web framework comparison which tries to measure the ease of learning and development for several web frameworks with a practical test. In this article, the subject background, the chronological development of all the tests, the test steps to do with each web framework, their times and the documentation that will be used along the process, are described.

Due to the time limitations of the project, a deep research could not have been done in this section. Therefore, the experts, Juan Carlos Rodríguez del Pino, a language programming professor of ULPGC, the author of Virtual Programming Lab, and Carlos Hernández, founder of Endeve, expertise in agile development, have supervised the language programming exercises definition and the website definition.

Subject background

The subject will be the student, in this case it is me. My relevant background to this project is:

  • A five year degree in computer science.
  • Several courses on C and C++.
  • I programmed in Java for some subjects but I did not receive any Java programming course.
  • I programmed a course exercise in PHP.
  • I read Yii documentation for several hours.
  • I used Django for several hours in a Startup Weekend.

Chronological development

The chronological development of the frameworks will be:

  1. Ruby on Rails
  2. Grails
  3. Django
  4. CodeIgniter

It is a hypothesis that it will be more difficult to develop with the first frameworks, whatever they are. Therefore, those which are supposed to be the easiest ones to develop with are the first ones. This allows that, in case Ruby on Rails is the first I finish developing with, it cannot be said it is because it is the last one.

Steps of the web framework comparison practical test

These are the six practical test steps which will be accomplished with each web framework:

  • Reading the programming language documentation(8 hours): The subject can read the official documentation of the programming language, use search engines for answering questions and do tutorials, but he is not allowed to do the programming exercises.
  • Making the exercises to demonstrate language knowledge(12 hours): The subject has to focus on solving the exercises with the language. He can read the documentation and search in Google, but the priority is solving the exercises. The exercises will be described in a few days.
  • Reporting the language features and development experience(5 hours): A report has to be done along this project. In this step, the subject can write part of the report. Furthermore, the report improves his learning.
  • Reading the web framework documentation(25 30 hours): It is close to the Reading the Programming Language Documentation step. The subject has to focus on reading the documentation, he cannot program any of the website.
  • Developing the website(50 45 hours): The subject has to focus on developing the website. He can read documentation and search in Google to help him in his tasks but the main priority is developing the website.
  • Reporting the web framework features and development experience(25 hours): In this task, notes about web framework functionality and problem solution are written in the report.

Timing steps

In this section, the fixed times for each step are defined. Each time multiple of five. If the subject makes five hours per working day, each task is separated for at least one day from the previous one. Furthermore, main tasks are separated by weeks. Language related tasks are done in one week. Learning web framework documentation is done in another week. Developing the website is done in two weeks and notes are written in one last week. It means five weeks for each framework test with five hours per working day.

Next, tasks divided by hours:

  • Reading the programming language documentation: 8 hours
  • Making the exercises to demonstrate language knowledge: 12 hours
  • Reporting the language features and development experience: 5 hours
  • Reading the web framework documentation: 25 30 hours
  • Developing the website: 50 45 hours
  • Reporting the web framework features and development experience: 25 hours

Reading language documentation is so short due to the fact that the subject already knows how to program and just simply has to learn the new syntax and structures of the language. The main learning is done through the exercises.

Documentation

The official documentation of the web frameworks and the languages will be used along the process. In the development steps, Google can be used to solve problems.

What is your opinion about this practical test design? What do you think about the times and steps? I included Google in the documentation for the development process because I think it is closer to a real situation. Do you think that my background will favour any web framework?

Thanks for reading. Comments, criticism and sharing will be appreciated.

EDITED: Finally, 25 hours for learning the web framework have been considered insufficient. Therefore, it they have been increased to 30 hours and website development has been decreased to 45 hours.

The post The practical test for web framework comparison: learning and development steps appeared first on Blog Websites Frameworks.

]]>
http://blog.websitesframeworks.com/2013/03/practical-test-web-framework-comparison-244/feed/ 2
Web frameworks selected to be compared http://blog.websitesframeworks.com/2013/03/web-frameworks-selected-to-be-compared-236/ http://blog.websitesframeworks.com/2013/03/web-frameworks-selected-to-be-compared-236/#comments Mon, 18 Mar 2013 17:19:24 +0000 http://blog.websitesframeworks.com/?p=236 This article is part of a project which tries to measure the ease of learning and development for several frameworks with a practical experiment. In this article, the selected web frameworks and the reasons for their selection will be presented. First, web frameworks chosen. Second, the reasons to choose them. I want to say I […]

The post Web frameworks selected to be compared appeared first on Blog Websites Frameworks.

]]>
This article is part of a project which tries to measure the ease of learning and development for several frameworks with a practical experiment. In this article, the selected web frameworks and the reasons for their selection will be presented.

I want to say I would like to have enough time to review more frameworks. Specially, all those component-based frameworks such as GWT or Tapestry, which have a great usage and are growing nowadays. Unfortunately, there is no enough time to compare every framework.

Selected web frameworks

In case you do not want to read the whole article: Web frameworks which have been chosen are:

  1. Ruby on Rails
  2. Grails
  3. Django
  4. Code Igniter

Reasons why they have been selected

Figure 1 shows the most popular frameworks, those which have better characteristics of usage and ease of development. Perl language has been excluded because, despite being a highly used technology, its frameworks are not considered in comparisons. Python has been included although without being named in comparison because it presents a significant use in high traffic sites and Django usage is increasing.

Although there are more frameworks to choose in Ruby and Python frameworks universe, Ruby on Rails and Django are the most widely used. Community focus on one framework is said to be a good characteristic. On the other hand, there are plenty of Java and PHP based frameworks.

Web frameworks map
Figure 1. Web frameworks map

Component-based frameworks are an approach to desktop application development. Their http request abstraction is not accurate for CRUD and classical websites development. A request-based approach is closer to web development and this project will focus on developing a CRUD website. Therefore, component-based frameworks are excluded from the group of web frameworks to choose from.

Request-based web frameworks table
Figure 2. Table of request-based web frameworks

Figure 2 lists request-based frameworks and compares their features. All of them support every feature in some way. The objective of this project is evaluating the ease of development in different frameworks with different based technologies. Therefore, a cross-language set is chosen, one framework of each programming language.

In a previous article, Raible’s matrix was used to modify weights according to priorities in this project. Results showed that Grails and Rails were the request-based framework winners.

Consequently,

  • Ruby on Rails and Django have been chosen due to being the only famous frameworks in these technologies.
  • In PHP, CodeIgniter presents the best performance and it is said to be easier than Symfony, CakePHP and Zend. Yii could be an alternative but, due to its less adoption, CodeIgniter seems the best option.
  • There are so many JVM frameworks that more than one should be in the comparison. Nevertheless, because of time limitation, only one can be chosen. According to the old Villamor article, agile Java web frameworks are Roma, Grails and Trails. Roma was also compared in Wähner article but it is not very popular. On the other hand, Grails is in the second position in the adapted Raible’s matrix and Villamor considered it an agile web framework. Therefore, Grails has been chosen.

The post Web frameworks selected to be compared appeared first on Blog Websites Frameworks.

]]>
http://blog.websitesframeworks.com/2013/03/web-frameworks-selected-to-be-compared-236/feed/ 8
Web frameworks benchmarks http://blog.websitesframeworks.com/2013/03/web-frameworks-benchmarks-192/ http://blog.websitesframeworks.com/2013/03/web-frameworks-benchmarks-192/#comments Fri, 15 Mar 2013 15:41:14 +0000 http://blog.websitesframeworks.com/?p=192 In this article, an overview of the main web frameworks benchmarks is presented. To begin, it is analysed a presentation by Van den Enden, Ward Vijfeijken and Guy Veraghtert which is probably the best web framework benchmark done. Only Java-based frameworks are compared but  the methodology and results are still valuable. Next, there is a […]

The post Web frameworks benchmarks appeared first on Blog Websites Frameworks.

]]>
In this article, an overview of the main web frameworks benchmarks is presented. To begin, it is analysed a presentation by Van den Enden, Ward Vijfeijken and Guy Veraghtert which is probably the best web framework benchmark done. Only Java-based frameworks are compared but  the methodology and results are still valuable. Next, there is a set of small web frameworks benchmarks posted on blogs, despite the fact that they could be more precise, the presence of close results in them leads to conclusions which could help in taking decisions on which framework to choose.

World Wide Wait

Stijn Van den Enden, Ward Vijfeijken and Guy Veraghtert made a presentation at Devoxx 2011 where they compared different Java frameworks.  They measured for every framework the requests per second that it was able to accept, the load in different CPUs, the mean page load time, the cost of scale and other features.

Compared web frameworks were:

  • GWT
  • Spring
  • JSF
  • Wicket

The study is scientific and precise. A web application based on common patterns was built and a set of tests were sent to the application. It consists of more than 700 hours of test run and more than 16 GB analysed. The results were validated. The database was simulated to avoid bottlenecks, it had a 40 milliseconds response time.

Web frameworks benchmark. GWT, JSF , Spring and Wicket.
Figure 1. Java web frameworks benchmark. GWT, JSF , Spring and Wicket.

In figure 1, it is shown the mean page load time versus concurrent users, ThreadCount. In the case of GWT, DOM updates executed after onLoad event are not counted. Therefore, it should be a little higher.

Web frameworks benchmark. Cost of scale. GWT, Spring, Wicket and JSF.
Figure 2. Java web frameworks cost of scale.

Figure 2 is a brief diagram which shows framework cost of scale for 10000 users and a limit of 5 seconds to answer. GWT is the cheapest to scale despite being the second faster in average mean page load time due to the fact that GWT sends JSON to the client and it renders it. Because of this, server has a lower load and it is cheaper to scale, while the client has a higher load because of the rendering. Furthermore, research authors said that GWT was the most difficult to develop with.

In conclusion, Spring is the fastest framework but it costs around 50% more to scale with it than with GWT. GWT is the cheapest framework to scale but it gives a slower response time. Wicket and JSF are slow and expensive.

The Great Web Framework Shootout

Seth Davis made a more imprecise benchmark. According to his words “it would be foolish to consider these results as scientific in any way”. He tried to test frameworks performance just out-of-box. Data collected are not as precise as World Wide Wait data are but he compares different web frameworks based on PHP, Python and Ruby. The frameworks which have been compared are:

  • Bottle
  • Flask
  • Sinatra
  • Web.go
  • Pyramid
  • Django
  • Rails
  • Kohana
  • TG
  • Yii
  • CakePHP
  • Symfony

In case you are interested, the methodology and setup are well defined in his blog. Furthermore, there are more graphics than the one shown here.

Web frameworks benchmark.
Figure 3. Web frameworks benchmark

Figure 3 shows requests per second for a template with a DB query. Bottle, Flash, Sinatra and Web.go are microframeworks which do not have so many capabilities as full stack frameworks have. The full stack frameworks which have higher requests per second are Pyramid, CodeIgniter, Django and Rails.

Benchmarking Web Applications and Frameworks

Paul M. Jones made a benchmark for PHP frameworks. The PHP frameworks which have been compared are:

  • Aura
  • CakePHP
  • CodeIgniter
  • Lithium
  • Solar
  • Symfony
  • Zend

First, he tested the maximum responsiveness of the benchmark environment without any framework. The tests were a base line HTML page with “hello world” and a PHP page with “Echo hello world”. Afterwards, he tested each framework rendering the HTML page. Results in figure 4 show the requests per second in relative percentage to the PHP page rendering time.

PHP web frameworks benchmark. Code Igniter, Aura, CakePHP, Lithium, Solar, Symfony and Zend.
Figure 4. PHP web frameworks benchmark

 CodeIgniter presents the best performance.

Rails, Wicket, Grails, Play, Tapestry, Lift, JSP, Context

JT Dev published a benchmark for Java web frameworks and Ruby on Rails. The frameworks which have been compared are:

  • Grails
  • JRails
  • JSP
  • Lift
  • Play
  • Rails
  • Wicket
  • Context
  • Tapestry

The test is a single html page where a list of products objects with associated category are rendered. All data is in memory to avoid the use of a database.

web faremworks benchmark

Figure 5 shows response time versus number of users. The best performance is presented by Play rendering with Japid and Netty, followed by Play with Japid, Play with Scala and Netty, Tapestry, JSP, Grails and more. Rails has a poor performance compare to rest. JRails presents the worst performance.

Conclusions

It is important to notice that each benchmark measures different features. In the first one, it has been measured mean page load time. In the second and the third one, request per second. While, in the last one response time.

The best benchmark approach is the World Wide Wait. It shows that Spring is the fastest framework but it costs a 50% more to scale with it than with GWT. GWT is the cheapest framework to scale but it gives a slower response time. Wicket and JSF are slower and more expensive.

The second and the third benchmarks show CodeIgniter as the leader in PHP. Pyramid and Rails are the leaders in Python and Ruby languages. Django is following Pyramid in Python language and close to Ruby on Rails.

Wicket is presented in the first benchmark and the last one. It could be inferred that all the frameworks which last longer than Wicket on response time in the last benchmark have worse performance than Spring or GWT.

The post Web frameworks benchmarks appeared first on Blog Websites Frameworks.

]]>
http://blog.websitesframeworks.com/2013/03/web-frameworks-benchmarks-192/feed/ 8
Wähner categorization and comparison of web frameworks http://blog.websitesframeworks.com/2013/03/wahner-categorization-and-comparison-of-web-frameworks-229/ http://blog.websitesframeworks.com/2013/03/wahner-categorization-and-comparison-of-web-frameworks-229/#comments Wed, 13 Mar 2013 13:56:51 +0000 http://blog.websitesframeworks.com/?p=229 Wähner published a more neutral web framework comparison through defining types of web applications and assigning a web framework to them. The web frameworks in the comparison are: Grails Lift Struts Spring JSF Tapestry Wicket Roma ZK Vaadin GWT JavaFX Flex In figure 1, types of applications are exposed. CRUD client makes reference to a […]

The post Wähner categorization and comparison of web frameworks appeared first on Blog Websites Frameworks.

]]>
Wähner published a more neutral web framework comparison through defining types of web applications and assigning a web framework to them.

The web frameworks in the comparison are:

  • Grails
  • Lift
  • Struts
  • Spring
  • JSF
  • Tapestry
  • Wicket
  • Roma
  • ZK
  • Vaadin
  • GWT
  • JavaFX
  • Flex

In figure 1, types of applications are exposed.

Web application types
Figure 1. Web application types

CRUD client makes reference to a simple classical web application where the main actions are Create, Read, Update and Delete(CRUD). A portal makes reference to websites which contain more than one web application. RIA(Rich Internet Applications) refers to applications which need a plugin to satisfy their requirements, for example Adobe Flash. A Rich Client tries to create a better experience using HTML with AJAX.

Wähner web framework comparison
Figure 2. Wähner web framework comparison

Taking into account this typology, frameworks can be distributed according to figure 2 where complexity means difficulty to learn the framework for a Java developer.

It is important to notice that Grails learning is considered complex for a Java developer because he has to learn Groovy first, explains Wähner. Nevertheless, according to Villamor and Matt Raible, Grails is an agile framework which can be compared to Ruby on Rails.

On the other hand, Roma was in Villamor’s comparison too and it was the winner.

Thanks for reading. Comments, criticism and sharing will be appreciated.

The post Wähner categorization and comparison of web frameworks appeared first on Blog Websites Frameworks.

]]>
http://blog.websitesframeworks.com/2013/03/wahner-categorization-and-comparison-of-web-frameworks-229/feed/ 2
Web frameworks statistics http://blog.websitesframeworks.com/2013/03/web-frameworks-statistics-174/ http://blog.websitesframeworks.com/2013/03/web-frameworks-statistics-174/#comments Sun, 10 Mar 2013 16:00:08 +0000 http://blog.websitesframeworks.com/?p=174 In this article web frameworks statistics will be analysed. First, it will be analysed web frameworks usage in websites and in the top 10.000. Second, it will be analysed web frameworks usage growth. Third, conclusions. Web frameworks usage statistics BuiltWith provides web frameworks usage statistics. Its data does not seem totally accurate because several libraries […]

The post Web frameworks statistics appeared first on Blog Websites Frameworks.

]]>
In this article web frameworks statistics will be analysed. First, it will be analysed web frameworks usage in websites and in the top 10.000. Second, it will be analysed web frameworks usage growth. Third, conclusions.

Web frameworks usage statistics

BuiltWith provides web frameworks usage statistics. Its data does not seem totally accurate because several libraries appear as frameworks. For example, Telerik Controls. However, it is the only source of web frameworks statistics usage. Therefore, it will be analysed.

In figure 1, the websites column shows websites using this technology and the last column shows usage percentage in the top 10.000 sites. Web frameworks which are not full stack have been removed from the table, because it is not interesting for this article. According to BuiltWith, they use two detection techniques to recognize Ruby on Rails use: Ruby on Rails and Ruby on Rails Token. To avoid confusion in this table, results from both techniques have been added.

Web frameworks usage statistics based on BuiltWith
Figure 1: Web frameworks usage statistics based on BuiltWith

ASP.NET is the most used web framework with a great advantage, followed by Ruby on Rails. Private web frameworks are ASP.NET, Silverlight and Adobe ColdFusion. Open source web frameworks are Ruby on Rails, Code Igniter, CakePHP, Django and GWT. Silverlight, Code Igniter, Cake PHP, Django and GWT present a usage percentage less than 0.5% in the top 10.000.

Web frameworks usage statistics growth

BultWith offered a five days trial to access web frameworks usage growth. In figure 2, it is shown the growth since 12, 6, 3 and 1 months ago and in the top 10.000, 100.000 and 1 million sites.

Web frameworks usage growth
Web frameworks usage growth based on BuiltWith

Best growth in 12 months is presented by GWT in all the tops. Spring presents the second best growth in the top million and in the top 100.000 sites but it shows a really low growth in the top 10.000, only 1%. Django, Tapestry and Code Igniter are the only ones which show better growth in the top 10.000 than in other tops. Silverlight and Adobe Coldfusion are decreasing.

Conclusions

  • ASP.NET is leader in web frameworks usage with a great advantage.
  • GWT has the greatest growth.
  • Every technology which is highly used is growing, excluding Silverlight and Adobe ColdFusion which are decreasing.
  • Spring, Ruby on Rails, Django, ASP.NET and Tapestry usage is growing.

Thanks for reading. Comments, criticism and sharing will be appreciated.

The post Web frameworks statistics appeared first on Blog Websites Frameworks.

]]>
http://blog.websitesframeworks.com/2013/03/web-frameworks-statistics-174/feed/ 14