Imagem de Rayday333

Lendo os tweets das pessoas que sigo acabei neste post do Dr. Nic: “Being reminded of the pains working with a sinatra app, without the toolchain that rails offers, in #rdrc2 tutorial.”

Coincidentemente hoje também estava preparando o material de introdução ao Desenvolvimento WEB da Pós-Graduação da UNA. No material estou usando Sinatra para explicar a geração de conteúdo dinâmico, verbos, cabeçalhos e outras aspectos do protocolo HTTP.

O resultado dos exemplos é que com quase nada de código vai ser possível explicar esses conceitos de uma forma pura. Mas ao ler o tweet do Dr. Nic me fez lembrar como eu não gosto de usar Sinatra em meus projetos reais.

Na verdade a tecnologia é muito funcional e extremamente simples mas hoje eu considero o uso da ferramenta apenas em situações muito específicas.

Tanto o site quanto o blog da Objetiva são feitos em Ruby sobre o Rack. As páginas do site são feitas com Sinatra e para o blog nós usamos o Toto.

Ambas as tecnologias são bem legais e funcionam muito bem, mas em retrospectiva, eu não teria feito a mesma escolha hoje. Eu também não sei se usaria Sinatra em nenhuma das situações que usei no passado.

O problema

Na verdade, desenvolvimento web é uma coisa muito chata. Para desenolver um site você precisa saber no mínimo 4 tecnologias (HTML, CSS, JS, Ruby ou outra linguagem). HTML por si só já é uma linguagem chata, verbosa e repetitiva. Por exemplo, se você quer montar um grid com 50 projetos vai ter que repetir alguma coisa assim umas 50 vezes:

<div class='project'>
   <a class='lightbox thumb' href='/images/projects/01.jpg'>
     <img src='images/projects/siteface-thumb.jpg' />
   </a>
   <span class='title'>Siteface CMS</span>
 </div>

Para colocar um simples css na sua página você precisa escrever isso tudo:

<link href='/stylesheets/main.css' media='screen' rel='stylesheet' type='text/css' />

Para resolver toda essa chateação temos linguagens de programação para nos ajudar, mas ainda precisamos criar classes, métodos e objetos para gerenciar coisas como redirecionamentos, mensagens de sucesso ao enviar formulários, modos de desenvolvimento e produção, internacionalização, validações de campos, gerenciamento de recursos estáticos e muito mais.

A verdade que hoje em dia eu estou tão mal acostumado com as facilidades do Rails que mal consigo escrever HTML puro. Ferramentas foram feitas para nos deixar mais produtivos e devemos nos orgulhar disso.

Com tudo isso em mente, toda vez que opto por usar Sinatra ou qualquer outra coisa minimalista eu fico muito próximo de todos esses problemas de novo e me vejo escrevendo classes, métodos, helper, rotas e etc. Nessas situações, sentir falta de algo mais “highlevel” é certo.

Outro problema é que nem sempre algo que é simples vai permanecer simples para sempre. Dependendo do que for o projeto mais cedo ou mais tarde novas necessidades vão aparecer e eu não vou querer ficar codificando tudo manualmente ou fazer uma re-escrita.

Durante o desenvolvimento do nosso site eu senti isso dezenas de vezes e gostaria muito de ter feito tudo em Rails desde o inicio.

HEY, Rails é overkill !!!

Ao pensar em usar Rails para um site praticamente estático você vai pensar: “Você não pode usar Rails, é ferramenta de mais para pouca coisa!” ou então “Rails é uma solução overkill para isso”.

Eu considero algo “overkill” quando o excesso de ferramentas atrapalha. Por exemplo, até pouco tempo atrás, se você fosse desenvolver um site em Rails e não precisasse de Banco de Dados você ainda precisaria instalar o ActiveRecord, carregar a gem e ainda ter um arquivo database.yml (mesmo que nunca viesse a usar). Isso é overkill, ou seja, ganho dependências de mais para uma coisa simples e vou ter que lidar com isso ao longo de todo o projeto.

Outra situação que me preocupo muito com dependências é ao acrescentar Gems a um projeto comercial. Neste caso você sabe que aquela dependência é sua responsabilidade, principalmente se os mantenedores da Gem descontinuarem o projeto. O problema intensifica se você não tiver conhecimento ou verba para manter o código fonte da Gem abandonada.

O fato acima não é o caso do Rails. Ninguém vai descontinuar o framework e é muito improvável que você tenha que fazer algum patch para um projeto simples, ou seja, você não tem custo para manter nada além do seu próprio código.

Nós últimos anos, Rails se tornou um framework modular e se eu vou construir um sistema complexo posso usar todas as ferramentas mas se vou construir um site semi-estático eu posso usar só os helpers e rotas que gosto tanto. A medida que novas necessidades forem surgindo eu ainda posso ir “plugando” as partes que eu tinha tirado.

Desta forma, eu não acho mais o Rails uma grande dependência. Se como um todo o framework é enorme o seus módulos separadamente não são e você possui todos os benefícios e produtividade para aquela camada que você precisa.

Se você gosta de programar por programar eu não vejo nada de errado em usar Ruby puro sobre o Rack para escrever aplicativos web. No entanto, o que eu gosto mais do que programar é ver o projeto funcionando, se usar Rails encurta este prazo e sem perder qualidade então eu vou usar.

Prova de fogo

Colocando em prática a modularidade e minimalismo que falei acima, nós poderíamos ter um projeto Rails com apenas um único arquivo. Veja abaixo o exemplo que peguei de Brian Lopez (@brianmario):

# minimal rails3 app

require 'action_controller'

Router = ActionDispatch::Routing::RouteSet.new
Router.draw do
  root :to => 'site#index'
end

class SiteController < ActionController::Metal
  def index
    self.response_body = "waddup son"
  end
end

run Router

Seria apenas colocar esse código dentro de um config.ru e apontar para algo como Passenger e seu site minimalista vai estar pronto. A medida que as necessidades forem surgindo basta incluir as outras partes ou adaptar sua estrutura de pastas.

Conclusão

Se você gosta de Sinatra ou já tem as ferramentas que tornam mais produtivo o uso de tecnologias mais “low-level” eu acho que você deve usar isso com orgulho.

Não existe nada de errado com Sinatra, mas do meu ponto de vista, as coisas mudaram bastante ultimamente e agora Rails se encaixa muito bem onde eu usava Sinatra anteriormente.

Eu tento sempre pensar que programar por programar é muito bacana, mas apenas em Dojos e problemas acadêmicos. Em projetos que custam dinheiro eu acredito que é melhor economizar suas horas e reduzir o custo inicial e também de manutenção.