[SP-pm] Teen sells Perl cloud startup to ActiveState

Thiago Rondon thiago at aware.com.br
Tue Jun 14 10:28:21 PDT 2011


On Tue, Jun 14, 2011 at 12:35:21PM -0300, Eden Cardim wrote:
> >>>>> "Nelson" == Nelson Ferraz <nferraz em gmail.com> writes:
>     Nelson> Catalyst, he said, wasn't good for moving apps from build to
>     Nelson> testing and deployment.
> 
> Bulshit
> 

Esta discussão pode ser saúdavel, mas há uma grande trade-off aí. O
Mojolicious tem como proposta oferecer um ambiente mais simples (e para alguns
até mais confuso) de construir um aplicativo, porém pode tornar ele um produto
mais simples de ser vendido. É como comparar Nova Schin com La trappe.

Eu tive uma experiência com o mojolicious com o ReRe que estou trabalhando
agora nos últimos dias, fiquei muito contente com a documentação inicial do
site, com a disposição das soluções e saí para o código. Porém chegou em um
determinao momento, verifiquei que o ecosistema ainda do framework é novo, e
ainda falta um pouco mais de tempo para que ele se torne um framework usavel
em produção na minha opinião.

Até por que usavel implifica em manutenção, não há ainda pela falta de
amadurecimento do framework uma cultura de retrocompatibilidade, então além de
construir o teu aplicativo, você provavelmente vai ter que ficar "mantendo"
ele com as mudanças que o framework irá sofrer.

Não colocaria o Mojolicious em nenhuma aplicação para cliente, ou mais
"séria", pois acredito que eles estão amadurecendo o framework e isto esta
gerando alguns problemas simples como falta de encapsulamento entre seus
componentes para que eles consigam evoluir de forma "orgânica".

Alias, se o cliente quiser usar tudo bem, mas provavelmente isto vai gerar
mais tempo de uso de mão de obra.

Um dos exemplos que tive, logo de inicio foi o suporte a autenticação básica
do http, que o plugin estava desatualizado com a versão corrente do próprio
mojolicious, isto me fez analisar um pouco melhor a escolha do framework.

A desatualização era por conta de mudanças no core do Mojolicious, que não tem
ainda componetização e gera como consequencia que qualquer um faça as coisas
do seu jeito.

Por outro lado, o Catalyst já é bem grandinho, tem uma arquitetura de
componente muito boa, e até díficil você conseguir fazer uma cagada nele, e o
ponto negativo como produto do Catalyst na minha humilde opinião é que ele
requer uma curva de aprendizado maior, e isto torna o uso do Catalyst mais
restrito por consequencia.

O Mojolicious tem soluções "simples" até de mais (vide o ::Lite ou o
one-liner) para montar uma pequena situação de comunicação via http, ou se
você quiser montar um pequeno mock para alguma coisa.... com uma curva de
aprendizado muito menor.

Resumo da opera, na minha opinião o Mojolicious tem futuro e esta evoluindo
rápido, porém precisa de um ecosistema de componetização maior e uma cultura
de retrocompatibilidade boa.

O Catalyst esta maduro, muito estável e com uma comunidade de recursos humanos
e técnicos excelente ao redor, mas talvez possa conseguir mais desenvolvedores 
trabalhando nele se oferecer soluções simples que os usuários iniciais do 
framework precisem na maioria dos casos para entender melhor onde estão pisando. 
Mas, não sei se esta é a proposta na realidade do catalyst.

Bom, eu estou tirando o Mojolicious do ReRe, e estou trabalhando com ele como
componente agora, e espero que ele seja uma extensão para qualquer framework
ou servidor web que suporte PSGI.

Ps.: Sei que há na lista desenvolvedores de ambos os frameworks, mas esta é
uma opinião de um usuário destes frameworks. ;-)

Meus centavos,
-Thiago Rondon



More information about the SaoPaulo-pm mailing list