Update README.pt-br.md

@@ -476,22 +476,14 @@ GetMaterialApp(
 )
 )
 ```
 ```
 
 
-# Porque eu fiz esse package
+# Por que GetX?
 
 
-O problema que esse package tenta resolver é possuir a maioria das funções que preciso num package só.
+1- Muitas vezes após uma atualização do Flutter, muitos dos seus packages irão quebrar. As vezes acontecem erros de compilação, muitas vezes aparecem erros que ainda não existem respostas sobre, e o desenvolvedor necessita saber de onde o erro veio, rastrear o erro, para só então tentar abrir uma issue no repositório correspondente, e ver seu problema resolvido. Get centraliza os principais recursos para o desenvolvimento (Gerencia de estado, de dependencias e de rotas), permitindo você adicionar um único package em seu pubspec, e começar a trabalhar. Após uma atualização do Flutter, a única coisa que você precisa fazer é atualizar a dependencia do Get, e começar a trabalhar. Get também resolve problemas de compatibilidade. Quantas vezes uma versão de um package não é compatível com a versão de outro, porque um utiliza uma dependencia em uma versão, e o outro em outra versão? Essa também não é uma preocupação usando Get, já que tudo está no mesmo package e é totalmente compatível. 
 
 
-Um dia, quando eu atualizei um dos meus apps no trabalho para o Flutter 1.9, algo ruim aconteceu: Tudo quebrou.
+2- Flutter é fácil, Flutter é incrível, mas Flutter ainda tem algum boilerplate que pode ser indesejado para maioria dos desenvolvedores, como o Navigator.of(context).push(context, builder[...]. Get simplifica o desenvolvimento. Em vez de escrever 8 linhas de código para apenas chamar uma rota, você pode simplesmente fazer: Get.to(Home()) e pronto, você irá para a próxima página. Urls dinamicas da web é algo realmente doloroso de fazer com o Flutter atualmente, e isso com o GetX é estupidamente simples. Gerenciar estados no Flutter, e gerenciar dependencias também é algo que gera muita discussão, por haver centenas de padrões na pub. Mas não há nada que seja tão fácil quanto adicionar um ".obs" no final de sua variável, e colocar o seu widget dentro de um Obx, e pronto, todas atualizações daquela variável será automaticamente atualizado na tela. 
 
 
-Todas as bibliotecas pararam de funcionar, na atualização foi bloqueado o uso do hifen "-". Alguns atualizaram seus packages, outros não. Outros eu tive que olhar o porque do projeto não compilar. Outros simplesmente se tornaram incompatíveis com a versão atual, como o `image_extended` que eu até ofereci um PR lá pra conseguir corrigir, e tudo isso por causa de um simples update.
+3- Facilidade sem se preocupar com desempenho. O desempenho do Flutter já é incrível, mas imagine que você use um gerenciador de estados, e um locator para distribuir suas classes blocs/stores/controllers/ etc. Você deverá chamar manualmente a exclusão daquela dependencia quando não precisar dela. Mas já pensou em simplesmente usar seu controlador, e quando ele não tivesse mais sendo usado por ninguém, ele simplesmente fosse excluído da memória? É isso que GetX faz. Com o SmartManagement, tudo que não está sendo usado é excluído da memória, e você não deve se preocupar em nada além de programar. Você terá garantia que está consumindo o mínimo de recursos necessários, sem ao menos ter criado uma lógica para isso. 
 
 
-Eu perdi 2 dias de trabalho só procurando por erros pra saber de onde eles vieram.
+4- Desacoplamento real. Você já deve ter ouvido o conceito "separar a view da lógica de negócios". Isso não é uma peculiaridade do BLoC, MVC, MVVM, e qualquer outro padrão existente no mercado tem esse conceito. No entanto, muitas vezes esse conceito pode ser mitigado no Flutter por conta do uso do context. 
+Se você precisa de context para localizar um InheritedWidget, você precisa disso na view, ou passar o context por parametro. Eu particularmente acho essa solução muito feia, e para trabalhar em equipes teremos sempre uma dependencia da lógica de negócios da View. Getx é pouco ortodoxo com a abordagem padrão, e apesar de não proibir totalmente o uso de StatefulWidgets, InitState, e etc, ele tem sempre uma abordagem similar que pode ser mais limpa. Os controllers tem ciclos de vida, e quando você precisa fazer uma solicitação APIREST por exemplo, você não depende de nada da view. Você pode usar onInit para iniciar a chamada http, e quando os dados chegarem, as variáveis serão preenchidas. Como GetX é totalmente reativo (de verdade, e trabalha sob streams), assim que os itens forem preenchidos, automaticamente será atualizado na view todos os widgets que usam aquela variável. Isso permite que as pessoas especialistas em UI trabalhem apenas com widgets, e não precisem enviar nada para a lógica de negócio além de eventos do usuário (como clicar em um botão), enquanto as pessoas que trabalham com a lógica de negócios ficarão livres para criar e testar a lógica de negócios separadamente.  
 
 
-Eu confesso que foi uma das situações mais estressantes que eu já passei na vida. Foi exatamente nesse dia que eu decidi colocar tudo num package.
-
-Eu sei que parece que esse package é feito só pra sanar minha experiência pessoal, mas eu sou um programador, e eu tento resolver problemas sempre da perspectiva do programador. Eu não me importo em nada mais que fazer a minha vida e de outros programadores mais fácil com esse package.
-
-Sempre que eu passo por uma experiência frustrante, eu escrevo no meu caleundário, e tento resolver depois de completar o projeto.
-
-E então eu decidi fazer um package que tenha três coisas que eu sempre uso: Gerenciamento de Estado, de rotas e de dependências. Depois eu fiz também internacionalização, e persistênsia de dados (estilo Hive)
-
-Essa biblioteca sempre será atualizada e terá sempre nova features sendo implementadas. Sinta-se livre para oferecer PRs e contribuir com o package.