Por que, um framework – que aparentemente faz não mais do que os outros – está fazendo tanto barulho?
Qual a diferença entre Rails, Spring, Symphony, ASP.NET, Seaside?
Todos são “Web Frameworks”, todos se baseiam em princípios básicos do tão falado e tão pouco entendido M.V.C., todos possuem camadas de abstração de persistência e todos – sem exceção – foram feitos para cuspir HTML aos browsers.
Então, porque Rails, um dos últimos concorrentes a chegar – muitos dos outros foram concebidos no século passado! ou próximo disso – um dos mais simples, rodando sobre uma linguagem até então virtualmente desconhecida, está fazendo tanto barulho, causando tanta discussão?
Tenho certeza que a principal razão é sua característica de ser um “Opinionated Software”. A visão de David Heinemeir Hansson (DHH) não é muito diferente da visão de um Steve Jobs.
Mp3 Players existem há anos, de vários tamanhos, de várias cores. Creative, Sony, Chineses™. Porém, foi necessário Steve chegar com uma caixa branca chamada “iPod” para a indústria realmente começar a girar em torno do multi-milionário mundo do conteúdo digital. A Apple foi capaz de criar um produto que não tinha metade dos botões da maioria dos outros players e se especializou em fazer o necessário: tocar música. Graças uma visão maior de ecossistema, o iTunes Music Store e as centenas de acessórios “made for iPod”, o mundo de tocadores de música mudou.
O maior pecado de todo framework é querer ser tudo para todo mundo. Você não pode. O resultado é que se acaba não sendo muita coisa para quase ninguém.
Veja o JSF: podemos conectar diversos toolkits nele. Veja o Spring, apesar de Hibernate ser o “líder” de mercado, podemos configurar quem quisermos nele. Veja Struts, podemos usar Action Forms ou Dynamic Action Forms. Podemos usar Spring com Struts ou com JSF. E agora o próprio Struts se subdividiu: Action 1, Action 2, Shale.
Claro, óbvio, mais do evidente: “precisamos” ter a “possibilidade” de ir por outros caminhos “se quisermos”. “E se amanhã eu quiser usar iBatis no lugar do Hibernate?”. “E se amanhã eu precisar de um toolkit com mais opções?”. “E se amanhã eu quiser implementar forms mais complexos?”. “E se eu quiser mudar de Oracle para Informix?”. “E se ...”, “E se ...”.
No meio de tanta conjectura paranóica, acabamos nos conformando com opções demais, complicadas demais, desperdício demais configurando sempre a mesma coisa! Precisamos de muitos botões no mesmo mp3 player. E se quisermos tocar a música de trás para frente? Dificilmente iremos querer fazer isso, mas queremos essa opção. Nunca ficaremos satisfeitos ou seguros se não tivermos opções inúteis.
Parem, respirem fundo e pensem: quantas vezes começamos diferentes projetos sempre, sempre, do mesmo jeito! Configurando tudo igual. E quantas vezes realmente realizamos essas mudanças “e se …”? Quantas vezes desconectamos um Hibernate e substituímos por um iBatis? Quantas vezes trocamos os toolkits? A resposta é óbvia: nunca.
“Não é verdade! Eu já tive que fazer isso mais de uma vez!”. Ok, vamos contar 1 contra mil. Sempre existem exceções. Como disse antes: nunca poderemos ser tudo para todos. E justamente por querer considerar as minorias, a maioria é obrigada a se consolar com trabalho extra. Pois bem, adivinhem só: e se parássemos de olhar para as minorias?
David resolveu que Rails seria o framework que concentraria apenas, e tão somente, as práticas que ele usa no dia a dia, e nada mais. Rails foi concebido para concentrar todas as Opiniões de David a respeito de como uma boa aplicação web deve ser feito. Outras pessoas podem pensar diferente, e David não está preocupado em satisfazê-las. É o sentido de um “Opinionated Software”, um software de opiniões. São exatamente as pessoas que tendem a chamar David de arrogante e passar a criticá-lo.
O raciocínio é simples: se precisamos de algo muito diferente de Rails, então não precisamos de Rails. Precisamos de Spring. Precisamos de ASP.NET. Porém, se pararmos por um instante e observarmos Rails pelo que ele é, de repente uma nova porta se abre. O grande volume de restrições sobre o Rails é o que chamamos de “Convention over Configuration”. Ou seja, se seguirmos as convenções, os padrões e as opiniões de Rails, estaremos trocando dezenas de horas de configuração, debug, testes, corno-job por algo extremamente simples e óbvio: toda aplicação web é concebida igual.
Mas dessa forma Rails nunca será útil ao mundo Enterprise!. Ok, pode ser que não. Mas não foi para isso que Rails foi concebido, e David deixou claro que não vai deixar suas opiniões de lado apenas para satisfazer uma minoria que quer usar Rails ao lado de Cobol. Alguém muito esperto pode conseguir fazer isso, através de plugins ou outros hacks, mas não será David e nunca será parte do pacote oficial de Rails.
Para aqueles que querem ultrapassar as restrições do Rails, ele cita o que chama de syntatic vinager ou “sintaxe avinagrado”, para lhe dar um gosto azedo. Por exemplo, uma tabela no banco de dados deve ter seu nome sempre no plural e a classe sempre no singular. A chave primária sempre será surrogada e sempre se chamará “id”. Podemos fazer outra “configuração”, mas aí a classe começará a ficar “poluída”, “feia”. Segundo a visão do David, se quiser fazer algo fora da Convenção, pode fazer, mas terá que ser “punido” por tentar.
Não é difícil entender porque David faz isso. Como ele diz: Constraints are Liberating (“restrições são liberadoras”). Não precisamos mais ficar escolhendo: quais partes eu quero grudar agora para montar o framework para meu novo projeto? Já está tudo pronto. Não precisamos mais tomar essas decisões: elas foram tomadas para nós. Vamos logo para o próximo passo e nos preocupar com o que realmente interessa: o que meu aplicativo precisa para ficar pronto, dado que a infraestrutura está pronta e decidida.
Esse é o segredo do sucesso de Rails: liberar os desenvolvedores das tarefas mundanas e deixá-los criar Basecamps, Odeos, 43things, UnSpurs, etc. Nunca fomos enganados, sabíamos desde o começo que essa seria uma faca de dois gumes: o mesmo fator que trouxe o grande sucesso de Rails também trouxe a maior parte das críticas. Metade vibra pelas convenções e a outra metade odeias essas mesmas restrições.
É como Kathy Sierra disse : precisamos despertar as Paixões nas pessoas para fazer sucesso. Se o produto se coloca numa faixa onde tenta se proteger das críticas, será apenas medíocre. Um produto de sucesso desperta paixões. Ninguém apenas “gosta” dele, as pessoas “amam” ele! Porém, essa é uma via de mão dupla. Paixão significa que outras pessoas se apaixonarão em odiá-lo! E é esse conflito que gira a máquina que, em última instância, faz Rails crescer. Exatamente como a Apple sempre fez: despertou a paixão nas pessoas, tanto no bom sentido quanto no mal sentido. Em vez de ser apenas mais um produto, se tornou um estilo de vida.
Finalmente, o recado é simples: não tentem nadar contra a maré do Rails. Se quiser realmente tirar tudo que ele tem a oferecer, jogue fora seus paradigmas antigos e aceite a forma como Rails decidiu que deve ser. É nesse momento que vamos obter todos os benefícios. Se seu ambiente não permite isso, infelizmente Rails não poderá ajudá-lo. Rails NÃO é “apenas mais um framework web”. Ele não foi feito para todos. Por isso mesmo compará-lo com outros frameworks não faz sentido, pelo simples fato que a “concepção”, o conceito, é outro. Sempre será como comparar maçãs e abacaxis.
Só porque Rails é open source não significa que seus desenvolvedores são obrigados a atender tudo que todos pedem. O fato de ser open source apenas dá a David uma proteção ainda mais forte contra isso. Ele não vai prostituir o Rails apenas porque uma IBM pediu. E muito menos porque você pediu. É por isso que o suporte de um Action Web Services, por exemplo, é comparativamente aquém de um Apache Axis. E vai continuar assim, pois a opinião de David é que tudo seja REST e não mais um WS-Deathstar.
Ser arrogante não é ruim se vier junto de uma atitude para defender essa posição. Ser falso e enganar a si próprio tentando agradar todos e não conseguir é muito pior. E essa é a razão de Rails ser o que é hoje: Não é apenas mais um punhado de bits, ele é um Ideal, quer alguns gostem e outros não.
Todos os diretos reservados a RubyOnBr. Copyright RubyOnBr .
This site is powered by Radiant CMS.