Well, I had to use Google Translate, so not sure I got everything, but here are a few thoughts:
- Sounds like he used web2py quite a long time ago, before the DAL was re-written, and before countless other improvements, so this is not really a criticism of the current web2py. - web2py does not have an ORM, it has a DAL. He seems to be thinking the DAL was intended to be an ORM and somehow failed, hence his disappointment. It's true that the DAL is closer to SQL, but it is not "SQL in disguise" (you don't have to know any SQL), and in particular, it uses a single universal syntax/API across all supported backends (just like an ORM). This design actually makes the DAL more flexible than an ORM in terms of what it can model. The DAL also tends to be faster than ORMs. It would be interesting to ask what he thinks he can do with the Django ORM that could not easily be done with the DAL. Anyway, this is somewhat a matter of preference, though many web2py users consider the DAL to be one of web2py's great strengths. - I don't understand what he's saying about objects returned by the DAL (perhaps a translation issue). I'm not sure what mapping he thinks needs to be done by hand. - The complaint about views being difficult to maintain because they include Python + HTML + Javascript doesn't make any sense -- that's exactly what Django does as well (though Django uses a specialized template language rather than straight Python, but effectively no different in terms of inter-mixing of code and ease of maintenance). Perhaps he simply saw some bad examples. - Regarding "magic" and the existence of a few global API objects, such as "request", so what? He seems to prefer the Django method of importing and instantiating everything but doesn't explain the benefit of that. Why does he like repeating the same boilerplate code everywhere for objects as common as "request" and "response"? I refer him to the following quotes from Zed Shaw: https://twitter.com/#!/zedshaw/status/80415443558477825, https://twitter.com/#!/zedshaw/status/80418794526351360. - Regarding executing models, I'm not sure exactly what he means about overhead, but we now have conditional models, and you can always import your models from modules, just like in Django. - Regarding the admin editor, it is not intended to replace Vim, Emacs, etc. It is just a convenience for minor editing and to help beginners get started. Using it is completely optional, so it's an odd reason to give for leaving web2py -- just don't use it. Also, it's a third-party editor that was simply plugged in, so including it did not take away precious development time from the framework as he suggests (the current web2py also has a much better editor than the one he would have been using back then). Some further reading: http://www.quora.com/What-are-the-advantages-of-web2py-over-Django Anthony On Thursday, May 3, 2012 7:40:45 AM UTC-4, Ramos wrote: > > a person just wrote this about web2py in a portuguese forum > Anyone care to coment? > > > Viva, > > Eu conheci primeiro o web2py e só uns meses depois o Django. > Ao início achei bastante interessante (a ferramenta de admin, tutorial > fácil de seguir, etc.). O que me fez saltar do web2py para o django e nunca > voltar para trás foi, entre outros, o seguinte: > > - web2py não tem um ORM, tem uma api OO mas que segue o mesmo paradigma de > SQL, No fundo, ao fazer .select() / .union() estamos a escrever SQL > disfarçado. Um bom ORM permite não ter de escrever SQL em 90% dos casos, > poupando trabalho. > > - Os objectos retornados pela camada de persistência do web2py não têm > classes que façam sentido no domínio (Books, Persons, whatever seja o > domínio), aquilo retorna umas instâncias de Record (ou lá o que é) que não > são mais do que dicts. O mapeamento disso para instâncias de classes do > domínio tem de ser feito à mão. > > - A ideia de poder meter python arbitrário no template parece gira mas > facilmente descamba para ficheiros com python+html+javascript tudo > entrelaçado e impossível de manter. > > - A magia da framework. Se bem me lembro os dados do request actual são > postos em variáveis globais sem qualquer necessidade (podiam ser passados > para a view, como no django). > > - Os models são executados ( exec() ) a cada pedido. Não há necessidade > para este overhead. > > - Com tantos editores excelentes (emacs,vim,eclipse,vstudio,..),porquê > usar um editor inferior no browser? Se gastarem tempo a trazer esse editor > ao nível dos outros, perderam tempo que podia ter sido usado para melhorar > outras partes da framework. > > - A qualidade do código é incomparável. Pequeno exemplo: Lembro-me que o > núcleo da persistência do web2py na altura era um sql.py com algumas 3000 > linhas, todo martelado com ifs para emitir SQL cozido ou assado consoante a > BD e, de ver o Massimo* argumentar na mailing list que não era crítico > melhorar aquela parte. > > Para mim, o web2py é bom como uma ferramenta de aprendizagem, nada mais. > > Cumprimentos. >
