>>>>> "Nelson" == Nelson Ferraz <nfer...@gmail.com> writes:
Nelson> Eu tenho usado o Mojolicious em aplicacoes web, mas nada de muito
Nelson> sofisticado ate' agora.
A pergunta é: se sua aplicação não é sofisticada, porque não usar um CMS?
Nelson> Ate' agora nao tenho nada a reclamar -- ele simplesmente funciona.
:)
Bom, na minha experiência, todas as apps que eu escrevi nele precisaram
ser re-escritas pra acompanhar os caprichos do sri. Sério, se nenhuma
das suas apps quebraram com os trocentos rewrites e quebras de
retrocompatibilidade ao longo da história do projeto mojo, você
provavelmente deveria estar usando um CMS.
Nelson> (E e' por isso que muita gente usa PHP. Se o projeto der certo -- e
Nelson> essa e' uma questao de mercado, nao de tecnologia -- o codigo pode
ser
Nelson> reescrito mais tarde.)
Engano seu. Sistemas raramente são re-escritos na prática porque é
difícil justificar o custo do re-trabalho pro departamento financeiro,
principalmente quando o "departamento financeiro" é a poupança de uma
empresa pequena e iniciante. Talvez no seu universo seja fácil
justificar isso ou os recursos sejam abundantes aí, ou sei lá. No meu
não é. E mais especificamente, quando se trata de um sistema escrito em
perl, boa parte das considerações de re-escrita geralmente envolvem
re-escrever em outra linguagem "mais simples".
Nelson> Se eu fosse desenvolver um ERP, consideraria o Catalyst -- por causa
Nelson> da maneira como ele estimula a separacao em varias camadas.
Isso é um engano *tremendo* da sua parte, ele não estimula nada,
inclusive, não tem nada pré-implementado nele que faça ou estimule esse
tipo de separação no código do end-user e a doc é bem clara quanto a
isso:
https://metacpan.org/module/Catalyst::Manual::Tutorial::02_CatalystBasics#The-Simplest-Way
O Dancer e o Mojolicious é que já vem com camadas pré-implementadas de
funcionalidades semi-prontas, como renderização de templates, cookies,
etc. que ele acha que você vai precisar.
Nelson> O que me faz pensar que talvez possamos separar os casos de uso da
Nelson> seguinte forma:
Nelson> 1) Uso corporativo -> enfase no planejamento, na construcao de bases
Nelson> solidas -> Catalyst, Java
Não, não precisa planejar nada porque 90% da sua app vai estar
pré-implementada através dos componentes disponíveis. Inclusive, existem
já trocentas apps cujo desenvolvimento envolve a mera instalação de
alguns componentes, com *zero* de código. É igual instalar word, excel,
outlook, open office, etc. Exceto que você tem os fontes se precisar
customizar depois.
Nelson> 2) Startups, hobbies -> enfase na experimentacao, nas possibilidades
-> Mojolicious, Dancer, PHP
Talvez hobbies sim, mas no caso de startups o que eu vejo é exatamente o
contrário, ninguém quer "explorar possibilidades", todo mundo quer
solução pronta, zero de desenvolvimento e 100% de foco no negócio. Não
considero que o PHP entre nessa categoria, no mundo do PHP quase ninguém
monta um sistema do zero usando só usando frameworks, geralmente é um
CMS abarrotado de plugins e customizações, e não é isso que o mojo e o
dancer oferecem, e eu sei porque eu os uso.
Nelson> Esta divisao nao e' rigida, mas talvez explique porque os usuarios
de
Nelson> (2) reclamam da "complexidade" de (1).
O que não entra na minha cabeça de jeito nenhum é porque existem pessoas
no mundo que consideram que instalar e configurar alguns componentes
usando *zero* de código é algo "complexo" e "corporativo".
Nelson> Obviamente os usuarios de (1) nao vem complexidade nenhuma, pois
estao
Nelson> habituados com a linguagem/framework.
Você está enganado, e essa afirmação ressalta o fato de que você não
conhece nem o framework nem o eco-sistema.
--
Eden Cardim
+55 11 9644 8225
=begin disclaimer
Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer
