A fan of web2py started a discussion wondering why web2py is not more popular.
I’m sure everyone has their reasons, I will enumerate mine.
The DAL Layer is sweet
web2py seemed to have a better database layer than Django and I like the flat object space over what I do with SQLalchemy. But user base, community support are strong factors that often lead one to choose a more popular project over a better project.
Magic imports
One of the striking differences between Django (which I also hate) and web2py (which i’m impressed with to some extent) is that in django code you have a large number of explicit imports.
web2py does away with that but you are often left writing code that is will not run standalone and that you are not sure is properly imported.
As this user said:
Just to add my own perspective on the web3py play Massimo outlined: in my experience, the main weaknesses in web2py are the “magicness” of the import/namespace model, and the lack of comprehensive client/server communication tools. By the first I mean many of the things I’ve asked about (and been graciously helped with) over the past several months. The way that web2py manipulates import paths, executes code per request, and populates namespaces automatically (e.g., making names defined in model code available in controllers) makes many things convenient. However, the magic underlying this is not fully exposed, meaning that code reuse can become difficult if you stray outside the predefined magic boundaries. It’s difficult, for instance, to create modules that factor out db-centric code, because the db object (typically defined in a model file) won’t be available; this forces you to reimplement the wheel to some extent by taking the db-creation code out of a plain model file and put it in a function — which then breaks things like the db-admin tool. Obviously these are complex issues, but in the end I think it would be ideal to find a way that makes simple things smooth without making more complex code interdependencies quite so painful. (Importing rather than executing code may help in this regard.)
The second weakness is client/server communication. The web2py view template model is great, so telling the client what you want to serve is easy. The problem comes when you want more or less continuous back-and-forth communication between client and server. Most of web2py’s client/server communication model is based on forms, which require the entire page to be reloaded. While I’m not super gung-ho for “single-page apps”, I do think that it’s essential to facilitate “incremental” or “modular” communication between individual page elements and the server. A clear example is validation. Web2py has an elaborate validation mechanism which is quite powerful, but the need to submit an actual form makes it rather ponderous for situations where you want a “form” as just part of a page. For instance, if you have a login form as a small box in the corner of a content page, you really want stuff like email validation to happen without a page reload. It still needs to talk to the server, but it should be doing it with per-item AJAX. I do think, though, that this is something that could be added to the existing web2py without requiring a wholesale rewrite; it basically amounts to adding more full-featured client-side tools, with linkups to the server, so that instead of using SQLFORM or whatever you can just have a series of <INPUT> elements in a view along with a {{=submitAjax}} or something that causes them to do their thing independent of the rest of the page. The “components” model seems to be something along these lines but from what I see it is still a good deal less comprehensive than the whole form/validator mechanism available to “real” forms.
https://groups.google.com/g/web2py/c/89a846kPeGA/m/I4YcpPZYBAAJ
Pull-style templating
Terence Parr codified the term ‘push-style templating’ to raise the bar above what should be allowed in server-side web application development… once he did so, I had ZERO interest in pull-style systems like genshi, jinja, mako, django-built-in templates and also web2py templates.
I wont go into the whys and wherefores of push-style over pull-style, but would you invite to read his article to see the difference.
Database driven but not semantic driven
It is very impressive how little code you have to write in web2py to build a model which then creates the skeleton of a website. That being said, I prefer to semantic-OO approach of CubicWeb over the web2py approach.
Cubic Web is based on a widely used and well-documented standard for system modelling called the semantic web. web2py has support for reusability as well. So you are encouraged to reach your own conclusions about what works for you.
Small Community for Support
The web2py book is well-written, in fact PC Magazine ranked web2py over Django by a hair long ago because of superior documentation. But the turnaround on questions was too long for me. And why did I have questions? Mainly when I wanted to do things but wasnt sure how to do it in web2py. With web2py you are buying into an opinionated and magical framework. And if you take the time to learn it, that can benefit you. But it also may show why Flask and Django are more popular: as long as you know Python, you can write what you want and then replace it with something better later.
Confusion over evolution
I recall Massimo acknowledging that javascript and interactivity becoming more and more prevalent. He began to experiment with web3py but now has py4web.
for a product to have a small user base and the leader of the ship creating 2 additional products puts question marks on what you will have support for.
not evolved enough
This, for me, is the nail in the coffin about web2py as well as web3py and py4web. It also is why I focus on data engineering as a job and stay the freak away from any job requiring web application development.
Django, Flask and products based on them like superset have a tremendous issue going on: the frameworks are server-side yet single-page client-side apps are the rage.
A large amount of business and rendering logic in Django/Flask apps is not in Python: it is in react or jquery or typescript creating a data and language impedance mismatch: you are forced to come up with business entities in 2 languages communicating via REST.
Py4web appears to be an evolved web2py. But it does not appear to address the growing requirements for desktop-like functionality for the web. It has the same server-side limitations as Django or Flask and in addition has a small userbase and support community.
The way to evolve Django, Flask or web2py, in my opinion, exists in only in products that allow one to to web development entirely in Python and offer transpilation to web-assembly or javascript. There are many such world-class products in Python and they are solving the problems of the modern reactive web in ways that Django, Flask and web2py/web3py/py4web are not.