Diferenças entre Django e Web2py

Publicado em 2012-12-21 por Vinicius Assef

(Atualizado em abril/2018). Dois frameworks web poderosos. Ambos pretendem te ajudar a desenvolver um aplicativo web, mas cada um ao seu jeito. Quais as diferenças entre eles?

Uma pergunta recorrente vinda de iniciantes em Python é: "qual é o melhor framework web para Python?"

Existe quase que um consenso a respeito da qualidade dos frameworks web em Python: qualquer um que você escolher, vai resolver o seu problema. Cada um temm seu estilo próprio, mas você não vai ficar na mão. Eles estão sendo atualizados e suas comunidades são bem ativas.

Mas o que seria uma boa notícia, traz um inconveniente: se todos são bons, qual escolher?

Segue abaixo uma lista não exaustiva, escrita com minhas opiniões a respeito das diferenças entre Web2py e Django.

Nota: se você tem dúvidas sobre o que é um framework fullstack, leia Qual a diferença entre framework fullstack e microframework?. Adicionalmente, o artigo Uma visão sobre frameworks fullstack aborda algumas vantagens e desvantagens dos frameworks fullstack.

Mercado de trabalho

Django tem muito mais mercado de trabalho. Se você ler uma oferta de vaga para Python na web, é quase certo que constará Django nela. Se o seu interesse é trabalhar com Python na web, pode parar de ler esse artigo e ir estudar Django.

Por outro lado, se você quiser conhecer um pouco mais sobre abordagens diferentes, vamos continuar.

Nomenclatura

A primeira diferença é de nomenclatura.

O Web2py usa o conceito MVC (Model-View-Controller) comum, amplamente conhecido. O Django usa o MVT (Model-View-Template). Ou seja, o que todos chamam de View, o Django chama de Template. O que todos chamam de Controller, o Django chama de View.

Linha de comando

O Django tem uma abordagem bem linha de comando. Você usa a linha de comando para iniciar um novo projeto, para criar novas aplicações dentro do projeto, para criar e executar migrations, etc.

O Web2py deixa você fazer algumas coisas por uma interface web. Querendo, é possível editar todos os fontes do projeto pela web, no servidor local de testes. Você não é obrigado a fazer assim, mas pode. Na verdade, ninguém que eu conheço faz isso.

Convention over configuration

Seguindo a tendência da maioria dos frameworks modernos, ambos trabalham com convention over configuration. Como sabemos, essa abordagem acelera o desenvolvimento e deixa a estrutura da aplicação mais clara.

Explícito ou pragmático?

O Django adere ao conceito explicit is better than implicit para as partes dele que você vai usar. Isso quer dizer que em toda view (o que o Web2py e o resto do mundo chamam de controller) você terá que escrever os imports necessários para os módulos do Django. Nenhuma novidade aqui. Python funciona assim mesmo.

O Web2py optou pelo practicality beats purity e te deixa usar a infra-estrutura dele sem precisar dos imports. Ele já carrega tudo no ambiente global. Por exemplo, basta usar request, response e session sem nenhum import. Eles já ficam disponíveis para toda a aplicação. Isso inclui os helpers da view (o que o Django chama de template) e infra-estrutura de internacionalização (muito simples, por sinal).

Acesso a dados

Tanto Django quanto Web2py têm uma forma de acessar seus dados sem escrever SQL.

O Django usa um ORM (Object-relational Mapping) e o Web2py usa a PyDAL (Data Abstraction Layer).

Objetivamente, a DAL te permite escrever comandos de uma forma mais clara, para o meu gosto pessoal. A abordagem do Django é mais OO, porque para escrever um Model, você precisa definir uma classe. No Web2py você define sua tabela chamando uma function.

Mágicas

O Web2py já traz algumas coisas prontas que facilitam sua vida, como o grid, que é um componente que te permite escrever um CRUD completo com 1 linha de código e te dá pesquisa de brinde! E integra-se ao seu sistema completamente. Ele também traz um componente de wiki embutido bastante prático.

O Django, por sua vez, tem o admin. O admin do Web2py, apesar de ter o mesmo nome, propõe algo diferente, o que frustra alguns iniciantes que não estão atentos à nomenclatura. Ele se destina a adminstrar sua aplicação, ao invés de servir de plataforma para administrar eficientemente os dados sobre os quais ela atua, apesar de fazer isso de forma básica.

Rotas

O Django exige que você escreva um mapeamento de URLs para cada URL do seu aplicativo, o que é bem útil em casos de sistemas grandes. Novamente, explicit is better than implicit.

O Web2py também suporta essa forma de trabalhar, mas, por padrão, ele infere qual controller/function é associado à URL requisitada, evitando que você escreva o mapeamento de URLs logo cedo. Isso ajuda a diminuir o tempo de entrega, adiando decisões que podem não ser importantes no início.

Migrations

O Web2py traz migrations transparentes e automáticas. Elas são bem práticas, deixando que você pratique baby steps em seu esquema de banco de dados de forma natural, sem recorrer a plugins ou comandos adicionais. Se você mudar um model e executar a aplicação, o Web2py roda a migration automaticamente. Claro que esse comportamento pode ser desativado, mas é o padrão.

O Django também tem migrations, mas você precisa invocá-las manualmente. Em contrapartida, você consegue escrever scripts completos para serem executados quando uma migration for acionada. Isso te dá o poder de tratar e/ou converter os dados em tempo de migration, o que é muito bom. O Django também permite fazer rollback de migration. Resumindo, as migrations do Django são muito poderosas.

Templates

Nos templates do Django (que são as views para o resto do mundo) você não escreve código Python. Ele trabalha com uma linguagem de templates que tende a restringir o que é possível fazer neles.

O Web2py deixa você usar código Python nas views.

Ambas abordagens têm seus pontos fortes e fracos. É bom ter o poder para usar quando for conveniente. Por outro lado, a linguagem de templates do Django tem filtros bastante úteis, coisa que você não vai ter no Web2py.

Além da linguagem própria de templates, o Django também suporta Jinja2, que é também muito bom.

Python 2 ou 3?

A partir da versão 2.0, o Django não suporta mais Python 2.

O Web2py, por outro lado, ainda não suporta Python 3 oficialmente, apesar de vários testes indicarem que ele funciona com Python 3.

Considerações gerais

Muita gente recrimina o Web2py porque ele faz "mágicas" para simplificar sua vida (o lance dos imports que citei antes) e usa exec e eval para rodar seu código. No entanto, para o perfil comum de aplicativos que fazemos na web, não vejo problema real com isso.

Com o Django você vai ter o benefício de encontrar praticamente de tudo já desenvolvido pela comunidade. E sem dúvida, a comunidade Django é muito maior do que a de qualquer outro framework. Só não me arrisco a compará-la com a comunidade Plone, por causa da idade dele.

Estou aqui pontuando alguns itens de uma forma não apaixonada para te mostrar que, no final das contas, o que vai contar mesmo é o seu estilo pessoal, quando você puder optar por qual framework usar. Em várias situações você vai ter que usar o que sua empresa determina mesmo.

Pessoalmente, gosto da abordagem mais pragmática do Web2py, mas é importante levar em consideração o perfil dos projetos e de seus objetivos pessoais. Para sistemas maiores, a aparente burocracia do Django organiza as coisas muito bem.

Sobre a longevidade do projeto, se você está escrevendo alguma coisa para durar muito tempo, alguns colegas defendem o uso do Pyramid, um framework que propõe não te incomodar muito com mudanças desnecessárias.

Alguns acham o Flask uma boa alternativa para projetos que precisam escalar rapidamente.

No mais, apesar de essa sugestão ser frustrante, minha sugestão é você pegar um tutorial de cada um framework e fazer seus testes. Entre na lista de cada um deles e acompanhe as mensagens por uns dias e veja o que você consegue tirar de conclusão.

O importante, para mim, é você sentir-se bem atendido, mas sabendo que não existe uma alternativa perfeita para todos os casos. Não compartilho do pensamento one size fits all.

Qualquer um desses frameworks que você escolher terá uma comunidade pronta para te ajudar, como acontece no mundo Python. Mas sempre vale a dica de ler a documentação antes e também pesquisar o histórico de perguntas das respectivas listas.

Vinicius Assef

Eu sou apaixonado por Python e shell script.

Aprenda com seus erros e dê nome certo às coisas.