Published on

Como Ruby on Rails redefiniu o desenvolvimento web entre 2004 e 2011

Authors
como-ruby-on-rails-redefiniu-o-desenvolvimento-web-entre-2004-e-2011

Fabio Akita apresenta Ruby on Rails como um caso raro de tecnologia que mudou o fluxo de trabalho do desenvolvimento web, não apenas como framework. Ele contrapõe o ambiente de 2019 — GitHub ou GitLab, pull requests, testes automatizados, CI, staging no Heroku, monitoramento e análise de código — ao cenário de 2004, dominado por Java corporativo, SAP, UML, servidores pesados, Subversion difícil de operar, ClearCase e uma divisão rígida entre programadores, DBAs e infraestrutura. A tese é que boa parte desse padrão atual foi consolidada pela comunidade Rails.

O episódio explica por que Rails funcionou naquele momento. A escolha de Ruby, então uma linguagem quase inexistente fora do Japão, permitiu criar uma cultura nova sem carregar práticas antigas. DHH extraiu o framework do Basecamp, produto real da 37signals, e impôs uma visão forte: convention over configuration, DRY, estrutura previsível, pouco boilerplate, segurança ligada por padrão e testes presentes desde a criação do projeto. Akita ressalta que essa postura opinionated era controversa, mas produziu integridade conceitual e reduziu a fragmentação que ele via em Java, PHP e depois JavaScript.

A narrativa avança por uma cronologia de 2004 a 2011, conectando Rails à Web 2.0, Ajax, Git, GitHub, Heroku, AWS, jQuery, RSpec, Capistrano, Sinatra, Travis-CI e CodeClimate. O argumento não é que tudo nasceu em Rails, mas que a comunidade reuniu práticas ágeis, produto, open source, testes, deployment e serviços em um ecossistema coerente. Akita também revisita tensões internas: a acusação de que Rails não escalava no caso Twitter, que ele atribui mais à arquitetura de broadcast do que à linguagem, e o conflito com Merb, resolvido por pressão política e técnica no Rails 3.

A dimensão brasileira aparece como parte da história: mailing lists, blogs, livros, tutoriais, empresas, eventos e a Rubyconf Brasil ajudaram a criar um mercado local quando quase ninguém prestava atenção em Rails. Akita reconhece que Rails já não é obrigatório em 2019 e que problemas posteriores, como mensageria massiva, mobile moderno, Docker, Kubernetes e DevOps, abriram espaço para Elixir, Go, Swift, Kotlin e outras ferramentas. A pergunta prática que fica é quando vale escolher o pacote coerente e maduro de Rails e quando um componente especializado justifica sair desse caminho.

Assistir ao episódio original

Referências encontradas

Livros

Este post contém links de afiliado. Se você comprar por eles, eu posso receber uma pequena comissão sem custo adicional para você.