web2py vs Django, PHP, Pylons, Turbogears, j2ee, cakephp
[edit]web2py is better because it is faster, it is easier to use, and is more stable than other frameworks. It is also always backward compatible.
You should read the detailed comparison of features here:
http://mdp.cti.depaul.edu/examples/static/web2py_vs_others.pdf (if you find something is incorrect let us know and we will fix it)
or the wikipedia comparison (less detailed)
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
Finally you may want to read benchmark results for the web2p ORM vs other ORMs popular with other frameworks
http://mdp.cti.depaul.edu/AlterEgo/default/show/76
If you feel the need to say something negative about this framework without having tried web2py and without going to substantiate it with hard facts, please take your rant somewhere else. web2py respects other frameworks and other developers. We have learned a lot from Django, PHP, Pylons, Turbogears, web.py, Rails, etc and we do acknowledge that. So, please, respect us.
more explicit but incomplete comparisons:
If you know Django you may want to read this
If you know TurboGears you may want to read this
If you know Rails you may want to read this
If you know PHP you may want to read this
This is the web2py FAQ, not a blog.
Comments
The inability to use legacy databases WITHOUT ALTERING THE DATABASE to conform to web2py is a serious drawback that will keep it from being used to provide web access to legacy databases. In 15 years of business programming, I have never encountered a company that will allow such a thing. Data is the life of a company (from an IT standpoint) and there is no compelling reason to go with a product that requires you to change the schema of every database file that you want to access for the web (an auto-increment key). To recommend that a user try to alter a companies' database shows little real world experience in this design aspect.
When you alter this part of web2py, it will be worthy of trying, until then, it should only be limited to web development of new databases.
The designers of Grails understand this, it's too bad that the designers of web2py do not. [inappropriate?]
web2py can import tables saved in csv format therefore it can access legacy data.
web2py can also access existing databases directly (MySQL, PostgreSQL, SQLite and Oracle) if each table has an auto increment field called "id" and if this is the field used for referencing. Most legacy databases can be converted into the above format by using ALTER TABLE.
If the legacy database cannot be converted into such format, it has serious design issues and should be reworked anyway. web2py tries to enforce good software engineering practice. [inappropriate?]
Imorting via csv format is NOT interacting with legacy data in a dynamic manner - this is a kludge.
There is NO NEED for an auto increment field and there is no compelling reason to add one to a database that already has a unique key or a unique compound key.
MANY legacy databases cannot be converted becasue they are not designed around web2py, but around business needs and support many legacy applications which do not use just SQL, but use record level access.
The addition of an autoincrement key in many instances would be unneeded and is not a good software engineering practice. Altering a database to fit the requirements of a web application framework instead of business needs is foolish. A properly designed tool will take into account REAL WORLD needs.
The response of mdpierro leads me to believe that he/she may have very little or no experience in a business environment, but has spent most of the time ensconced in academia. [inappropriate?]
Just to avoid confusion, mdipierro is a "he". My full name address and phone number are on the main web page.
It is "good practice" for all records unique auto-increment id. web2py assumes that, Rails Active records assumes that, Django assumes that. You can always use ALTER TABLE to fix the problem. [inappropriate?]