web2py was very much inspired by Django and if you know one it is easy to learn the other. We added some features we did not find in Django, including: database migrations (alter tables automatically), tickets on errors, a web based IDE, a database abstraction layer that works on Google App Engine, a role based access control mechanism with pluggable login modules.
One of the fundamental design differences is that in Django apps are implemented as modules and therefore you need to restart the server when you edit them. In web2py instead Models/Views/Controllers are not modules, they are executed (not imported) by the frameworks and therefore you do not need to restart the server when they change.
Another difference is that Django uses an ORM, web2py uses a DAL. The DAL is slightly lower level than the Django ORM and this makes it closer to the SQL syntax (for example is allows left joins, arbitrary aggregates, nested selects and combinations thereof) while remaining portable (we support 10 different databases). The DAL also make it easy to do dynamic meta-programming of models (such as create models at runtime based on specs stored in file such as an XML or CSV file).
Django has been around longer so you find more people skilled with it and more applications deployed.
Django = old
Web2py = new
Anything Django does, web2py does better. This is because web2py was made long after django and has learned from Django’s mistakes, though it makes all new mistakes 😉
Main difference, and what is keeping me in web2py:
Django has incredible documentation…web2py is so intuitive that it doesn’t need as much…HOWEVER! I have found that the Django documentation is applicable to web2py, for the most part. If you spend a day and read the django book (Ch 1-7), you will get the idea about how that is true. So in a way, saying Django is better documented is asinine. Also, note that any framework that goes around talking about the volumes of documentation for it as a good thing…be concerned… documentation is good, not needing any to begin with = better. Web2py’s existing documentation more than meets the needs of 90% of the users. The remaining 10% have to go take a look at the framework library code (not as much of it as Django, and not as scary). Also, if you get to the point where you are spending more than 30% of your time going through library code, it is time to move away from frameworks and move towards collections of libraries (such as pylons). At that point it means you are not doing anything that web frameworks were designed to handle…
SQLForm in Django is TextModel. Once you create a form using TextModel (=SQLForm). Good luck trying to change the CSS of a single input field! In web2py you just do form.element(), no such thing in Django. You have to go through “widget()”, but to get to widget, you have to first go through the input field type, etc…
Also, manual DB migration…change schema? Sorry…have to either download and install a separate migration app (South), or have to do it manually in your DB console.
Lastly, no out of the box support for multiple DBs… think hoops…
In other words… with Django… hope you like jumping and hoops.
If you want to really take a jump forward from web2py, try Pylons…seriously…
Biggest drawback of web2py is its age and smaller code base…this is not unreasonable though, considering Django is like the first python web framework to implement RAILS style RAD ideas and is like twice the age of web2py. Web2py is still in its early adopter portion of its life…Django is in the beyond critical mass part coming up to decline… web2py should reach critical mass any day now in the next 2 years, I predict.
Spend a day, read the django book (ch 1-7), and read the Pylons book (Part 1), and then think about why you are using a framework to begin with. For me it was to get as much done as quickly as possible, and without looking up documentation 30% the time.
Web2py meets the above needs for me.
- Mix View and ViewSet in a browsable api_root
- Django redirect() with anchor (#) parameters
- Django NameError: name 'views' is not defined
- How should I be implementing user SSO with AAD in a Django application (using the Django Microsoft Authentication Backend module)?
- How to Model a Foreign Key in a Reusable Django App?
I made a small in-house web app completely in Django, and then afterwards completely in web2py. It’s the only way to really understand the differences and their impact upon the developer experience.
I prefer web2py because there are more conveniences built into the environment than offered by Django, but web2py is much newer than Django, and hindsight always makes it easier make new implementations better. Since web2py has guaranteed backward compatibility, it is entirely plausible that some new tool makes web2py outdated in a few years from now. That is the normal way of things.
Anyhow, they are very close to each other, far more so than any other web framework compared to either of the two. From the point-of-view of a Java-based web framework for instance, they might seem almost identical to each other.
- Django reset auto-increment pk/id field for production
- Django: default language i18n
- Configuring django settings to work with 1.4.1. Loading template error
- Acessing POST field data without a form (REST api) using Django
- Django 1.9 JSONField order_by
It definitely helps to have knowledge of some python framework.
Most effective way to get started would be, to compare the different sectors of the two, i.e. Model, View, Controller, Url Dispatching, Templates, Forms, etc.
Here is one great comparison of few frameworks. Am sure it’ll help.
- Instead of Primary Key Send Different Field in Django REST Framework
- How to print pretty JSON on a html page from a django template?
I was a Django programmer before settling on web2py. I found myself more efficient with web2py, possibly because of the sensible defaults (implicit imports, default views, etc) and the great support at the forum.
- What is the best IDE setup for web development?
- Python + Django on Android
- Redirect after login simply appends LOGIN_REDIRECT_URL