bostacapa

Minhas leituras ruins de 2016 – como avalio livros técnicos

Todo final de ano publico algo neste blog sobre minhas boas leituras do período (farei isto agora em dezembro). Este foi um ano de muitas leituras e, infelizmente, boa parte delas considerei puro desperdício do meu tempo. Vou falar aqui de livros técnicos:  poderia listar uma longa lista de títulos, mas creio que é mais produtivo, ao invés, expor como avalio um livro técnico.

Não será uma avaliação geral sobre livros técnicos, mas sim sobre aqueles que me interessam, isto é, livros de programação. Talvez este post soe agressivo: é por que  é. Livro é algo que levo muito a sério. Literalmente minha vida se funda neles.

Entenda, minha crítica não é a blogs ou tutoriais. É a livros, vendidos como livros, pelos quais você paga ou com seu tempo ou com seu dinheiro ou com ambos.

O tutorial disfarçado de livro

O que busco ao comprar um livro técnico: um conhecimento aprofundado a respeito do assunto que estou estudando. A leitura vai além do simples “aprender como se faz”, vai além de um mero “passo a passo”.

Não quero aprender como persistir dados usando um banco de dados NoSQL, por exemplo. Quero saber como eles são persistidos, por que são persistidos como tal, o quê motivou a tecnologia a ser daquela maneira, os limites da tecnologia. Quero que minha experiência de leitura me leve a um nível superior de conhecimento. Estas perguntas foram respondidas? Meus livros favoritos responderam a estas perguntas ou ao menos tentaram e, ao tentar, me criaram questionamentos que me motivaram a pesquisar mais a respeito.

Entre gastar meu dinheiro lendo um mero “passo a passo” a ler a documentação oficial, prefiro a segunda opção. É de graça, é fonte primária, foi escrito por quem criou a tecnologia ou tem um contato mais íntimo com esta.

Mais do que isto: um bom livro vai além. O autor irá tratar dos conceitos que envolvem aquela tecnologia, se termino a leitura aprendendo e entendendo novos termos, tive uma boa leitura, terá valido à pena.

(Wittgenstein dizia que nosso mundo é nossa linguagem. Se você aprende novos termos, seu mundo cresce. E eu não creio nisto, eu tenho certeza.)

Nada impede um livro de ter lá seus tutoriais embutidos (tem de ter mesmo!), mas estes obrigatoriamente devem ser precedidos de uma boa abordagem conceitual ou estarem mergulhados nela.

Livro é pra aprofundar, tutorial é pra quebrar seu galho. Não seja tonto, economize seu tempo!

(agora, se o livro se vende como tutorial, é válido!)

O conhecimento que surge do autor, e apenas do autor – por que a bibliografia importa (e muito)

O livro tem bibliografia? Não? Tutorial disfarçado de livro detectado.

O autor foi o criador da tecnologia? Se sim, esta tecnologia foi criada a partir do nada? Se não, aonde o autor aprendeu sobre ela? Autor que não cita fontes caracterizo em uma das opções abaixo:

  • Desonesto intelectual.
  • Alguém que não tem o preparo mínimo necessário para publicar seu trabalho.

A bibliografia, que muita gente ignora, é vital. Ela nos possibilita:

  • Ter acesso às fontes primárias que possibilitaram a escrita do livro.
  • Nos aprofundar no conteúdo do livro através da leitura do material auxiliar.
  • Validar o que está escrito. Mostra que o autor não está expondo sua mera opinião.
  • Mostra a fonte que o autor estudou para compor seu trabalho. Isto é fundamental para entender de onde vêm as opiniões do autor. Mais do que isto, mostra que o autor estudou!

(livro técnico fundado em opiniões é livro furado)

Recentemente comprei um livro sobre um dos meus frameworks favoritos e fiquei chocado com o fato do autor decorrer o texto inteiro sem fazer uma citação sequer e, claro, sem bibliografia e, claro, era um reles “passo a passo”. Se este livro fosse físico, talvez eu o usasse para limpar cocô dos meus cachorros.

Resumindo: livro não tem bibliografia? Desconfie. Sempre olhe o índice. No exemplo acima cometi este pequeno deslize e mais uma vez perdi meu tempo.

(e olha: tem autor famoso (muito) por aí que além de não citar fontes, muda o nome de conceitos conhecidos há décadas para você achar que são criação sua. Fique esperto, nem o nada surge do nada)

Autor despreparado

Aqui entra um ponto que considero ser fundamental: a responsabilidade do autor. Quando você compra um livro, o faz esperando que o autor seja alguém que tenha vivência técnica com aquela tecnologia, certo? E quando não tem? Indo além, como detectar isto?

Fácil: primeiro que hoje temos ferramentas como LinkedIn, Facebook e blogs, que nos permitem, pelo menos checar o currículo do autor. Sabe aquela orelha na qual fala um pouquinho sobre o autor? Leia aquilo! Vai te poupar muito tempo. Não tem texto falando sobre o autor ou o texto é exageradamente curto? Desconfie.

E no livro, é possível detectar a experiência do autor? Yeap, mas é algo um pouco mais sutil. Normalmente autores que não tem uma vasta experiência com a tecnologia só falam bem dela. Não expõem dificuldades inerentes ou suas limitações (e todas elas são limitadas em algum aspecto, não se esqueça).

E aí entra outra pergunta: um autor com pouca experiência no assunto está proibido de escrever livros? Respondo: pode  se for intelectualmente honesto. O que quero dizer com isto? Simples: é 1000 vezes mais válido se apresentar como alguém que está iniciando-se na tecnologia que como um expert.

Aliás, ler as dificuldades de quem está começando em algo sempre é uma leitura extremamente enriquecedora dado que o leitor normalmente também está começando e portanto se identifica com o autor e suas dificuldades. Agora, já o expert com seis meses de experiência… desculpe, é picareta.

Título enganador (ódio!)

Alguns meses atrás na itexto quis comprar para um estagiário material sobre REST. Queria que ele entendesse bem os conceitos fundamentais e também algumas técnicas essenciais.

Foi quando cometi o erro de comprar um livro sobre o assunto escrito por um autor que muito considero só pela capa: qual não foi minha surpresa ao descobrir que mais da metade do livro era sobre Java, e não REST? Por que a merda do livro não colocou no título isto, ou mesmo no subtítulo? O que eu queria? Conceitual sobre REST. O que ganhei? Java EE!  AHHH!!!!! Pior. Eu nem li o livro e já passei pra ele! Até hoje peço desculpas!

Sabe o subtítulo? Ele tem uma boa razão para existir: sua função é enriquecer o título mostrando um detalhamento melhor sobre o que aquele livro trata. Assim idiotas como eu, que compram na correria não compram errado (e não, piadinha no subtítulo de livro técnico é muito sem graça, vai por mim).

Pior: muitas vezes você deixa de ler algo excelente por causa do título enganador. O melhor livro que já li sobre uma certa linguagem de programação, por exemplo, tem um título mais ou menos assim: “Linguagem X com Framework Y”.

O livro quase não fala de Y, e o que fala sobre X é brilhante e profundo. Muita gente não o compra achando que é sobre Y. Ao questionar o autor, sabe o que ele me respondeu? “A editora me disse que venderia mais se eu também falasse sobre Y”. Resultado: cagaram no livro (e num puta livro!).

Destraduções

Existe tradução e destradução no vocabulário Kiconiano. O ato de se traduzir um livro é de uma responsabilidade monstruosa. O tradutor, além de cumprir o seu papel literário, está também cumprindo um papel social. Está tornando acessível a uma camada enorme da população que não domina o idioma original da obra acesso a esta.

Aí você, que não sabe nada de inglês lê em seu livro “tipos de costume”. Pensa se tratar de uma abordagem social ligada à computação, certo? Errado, são tipos customizados. Agora dou nome a alguns bois como exemplo. Tenho uma cópia em português do “Arte do Desenvolvimento Ágil” e outra do “Hibernate em Ação” que se eu jogar na parede grudam de tão nojentas. Recentemente tive uma experiência péssima de leitura com o “Clean Code” para português também.

Mas aqui preciso ser justo: as traduções tem melhorado muito de uns anos pra cá. Ainda há problemas? Há, mas estão reduzindo e não posso tirar daqui esta minha crítica a livros que são bons no original e um cocô na tradução.

Ausência de índice remissivo

Sabe o índice remissivo? Aquele outro índice, normalmente presente no final do livro que é usado para que a gente saiba aonde um termo aparece no texto? Parece inútil né? Né não!!!

Dado que livro é material de referência, se ele for físico não ter esta informação toma muito meu tempo quando quero me lembrar aonde um conceito foi tratado. Sabe… não tem Ctrl+F em lívro físico. E por falar em livro físico…

O aspecto do livro físico

Parece futilidade, mas não é. Ainda sou uma pessoa que compra livros físicos e considero um tapa na minha cara, enquanto consumidor, quando vejo em minha prateleira um livro que comprei há seis meses simplesmente se desfazendo em minhas mãos.

Entendam algo editoras (nacionais e estrangeiras): se alguém compra um livro físico, tem dentre os interesses a durabilidade do que está comprando. Eu, por exemplo, gosto de livros físicos como material de consulta, no meu caso são inclusive ferramenta de trabalho.

Engana-se quem acredita que livros de informática têm curta durabilidade: no meu trabalho com pesquisa de legados, por exemplo, uso material que foi impresso duas, às vezes três décadas atrás (acredite se quiser).

Livro não é como periódico que tem curta duração. Já notou que as pessoas deixam os livros expostos em estantes por anos? É coisa feita pra durar, não pra se desintegrar com o tempo!

Claro, há livros e livros. Se o valor for muito baixo e o material for vagabundo, é até válido. Já se for caro, é inaceitável. Exemplo: minha edição do Introduction do Algorithms (paguei quase R$ 400,00 na época!) do Cormen: conteúdo lindo, fisicamente um LIXO.

Concluindo

Bom, estas foram minhas leituras ruins deste ano e do passado. Talvez como autor eu tenha cometido alguns destes erros (torço para que não). Achei que seria interessante compartilhar aqui o que mais tem me incomodado.

Claro que há exceções, sempre há. Sim, há um ou outro tutorial disfarçado de livro que é livro mesmo, mas são muito raros, extremamente raros. E naturalmente, esta é apenas a minha avaliação literária de livros técnicos então, se te ofendi… problema seu.

Daqui a pouco escrevo sobre as minhas excelentes leituras que fiz em 2016. Muito livro bom!

PS: este foi um post desabafo.

kico_devcamp2016

Minha apresentação “Enriquecendo seu ‘legado'” na DevCamp 2016 acaba de ser publicada!

Olha que legal: o InfoQ acabou de publicar o vídeo da minha apresentação “Enriquecendo seu legado” que foi realizada na DevCamp 2016.

Nela falo basicamente como vejo código pré-existente (vulgo legados), mas assistindo de novo, é essencialmente uma apresentação sobre aquilo que mais gosto: código e as pessoas que geram este negócio.

Espero que gostem! Segue o link: https://www.infoq.com/br/presentations/enriquecendo-o-legado

Eu e o empreendedorismo do palco

Em janeiro de 2015 Nanna e eu oficializamos a itexto: foi um dos momentos mais legais da minha vida pois um sonho (O sonho) muito antigo finalmente estava se concretizando. Setembro de 2016 está chegando e de lá pra cá já atendemos quase 30 clientes, formamos uma quantidade enorme de pessoas nas tecnologias que dominamos e as coisas caminham bem.

Caminham bem agora, após 16 anos de incontáveis tentativas, a esmagadora maioria fracassada devido à minha arrogância e ignorância. No meio do caminho decidi reduzir minha ignorância partindo para o mercado e buscando trabalhar com aqueles que fossem mais experientes que eu. Venci a arrogância ao reconhecer que pra comandar meu destino primeiro tenho de ter sido comandado.

Este investimento se pagou: observando os erros alheios (sempre os mesmos) pude chegar a algumas teorias que, finalmente, ao colocar em prática se confirmaram e o negócio começou a caminhar, o que se confirma no crescimento (muito) controlado da empresa em um período de crise econômica profunda do país.

E aí você achou que este seria mais um texto motivacional daqueles que geram uma vergonha alheia profunda né?

Esta “vibe empreendedora” me incomoda

(odeio a palavra “vibe”, mas foi a melhor que encontrei no momento, desculpe)

Vejo muito papo furado em apresentações sobre empreendedorismo, startups e cia. Como alguém que tem uma empresa de verdade, pagando salários e impostos reais, resolvi listar aqui parte das lorotas que dizem.

A ausência de uma palavrinha chave que começa com “R”

simpsons-radioactive

Sabe: quando assisto a algum picareta no palco falando sobre sua “trajetória de sucesso” ou mesmo aqueles caras que claramente nunca abriram seu próprio negócio te dizendo como proceder raramente vejo uma palavra ser dita: responsabilidade.

Ok, você quer abrir seu negócio. Você sonha se tornar alguém que criou algo importante, mas já parou pra pensar na imensa responsabilidade que é ter seu próprio negócio?

Já parou pra pensar na honra que é alguém querer trabalhar contigo? Honra esta que não pode se tornar uma decepção. No compromisso que é mensalmente pagar todos os impostos envolvidos no pagamento de salário desta(s) pessoa(s)? Já se atinou pro fato que você pode fuder a vida de quem trabalha com você?

Se só tem sócios na sua empresa, será que sua empresa terá estrutura para ter pessoas recebendo no regime legal, que é o CLT?  Desculpe: você só sabe o que é ter uma empresa quando assinar a primeira carteira de trabalho de alguém.

E a responsabilidade que é alguém te escolher como fornecedor? Te escolheram, confiaram em ti e no seu serviço/produto: agora vai ter de corresponder.

Agora vamos para um nível acima: já parou pra pensar que ao abrir uma empresa você está influenciando a sua economia local? Que se seu negócio for pura lorota, você pode desacreditar todo um ramo?

Quase sempre a mesma historinha!

conto_de_fadas

Releia os três primeiros parágrafos deste post. É inacreditável como sempre escuto nas apresentações a mesma história composta por três atos.

  1. O empreendedor tem uma ideia que considera genial, mas ele é arrogante devido à sua própria ignorância. Ele segue em frente.
  2. Aparece um obstáculo e nosso herói sofre um forte baque. É o momento em que sua ideia é posta em cheque. Será que ele consegue vencer o obstáculo?
  3. Ele aprendeu com os erros, adaptou-se, adquiriu humildade: agora está mais sábio e tudo deu certo.

Há uma outra variação cruel desta mesma história. Segue abaixo:

  1. O empreendedor tem uma ideia que todos consideram idiota, mas ele tem e segue em frente.
  2. Ninguém acredita em nosso herói, mas ele continua. É o período tenso, no qual sua fé é testada.
  3. De repente sua ideia começa a funcionar! Todos percebem que estavam errados e não o herói, mas o mundo percebe que era arrogante e se redime.

Percebeu que há uma forma compartilhada?

  1. Nascimento da ideia – herói empolgado
  2. Momento da dificuldade – herói se questiona
  3. Dificuldade superada, sucesso atingido – herói confirma sua ideia (mesmo que a adapte)

Você realmente acredita que o mundo é tão simples assim??? Não são expostos muitos detalhes a respeito dos passos reais envolvidos no problema. É como Vitor Hugo, que dizia ter escrito Les Miserables de uma única vez. Anos após sua morte encontraram um baú com inúmeros manuscritos.

Resumindo: sempre o mesmo conto de fadas, a realidade é mais interessante (e árdua) que isto.

(aliás, este é o arquétipo mais básico do herói presente na literatura ocidental)

A ideia de que basta ter uma ideia e um… app

Claro, sou um desenvolvedor, quero trabalhar e tal, então não deveria dizer isto, mas é tanta gente iludida com a ideia de que para ser um empreendedor de sucesso você só precisa de um aplicativo e uma ideia…

E os caras falam isto no palco!!!

“Kico, se tivermos um app como o Krankster ficaremos ricos!” – Yeah! Nem precisamos pensar nas pessoas que cuidarão dos fornecedores, contato com clientes, manutenção, suporte, o computador resolve tudo pra nós!!! O Processo é o sistema!

“Nada pode dar errado!” (copyright)

A venda de uma vida sem sentido

O indivíduo é seduzido pela ideia de ter um negócio próprio, investe horrores na construção da infraestrutura necessária e começa a ver a coisa tomando forma.

Então chega uma pessoa e lhe pergunta: uma vez aberta sua empresa, como será seu dia a dia?

 

 

 

 

Um silêncio profundo dominará a conversa.

 

 

 

cricricri

Sério, já parou pra pensar nisto? Uma das razões pelas quais oficializamos a itexto foi nosso desejo de desempenhar um conjunto de atividades diárias no trabalho. Se você não sabe como será o seu operacional básico, pra quê abrir uma empresa?

Já parou pra pensar que uma vez aberto o negócio, você passará um bom tempo nele fazendo alguma coisa? Será que descobrir o que é esta “alguma coisa” depois é uma atitude inteligente?

A venda de uma realidade gringa

Arde: te mostram um modelo de negócio maravilhoso, aquela estratégia genial que funciona extremamente bem… na Europa e Estados Unidos.

São casos envolvendo ideias pouco convencionais no primeiro momento como Twitter (quem poderia imaginar: 144 caracteres!), Facebook, Apple (quem imaginaria um computador em casa?), Microsoft (os caras largaram a faculdade!) e por aí vai.

Mas não mencionam que lá existe uma cultura empreendedora centenária, uma economia brutalmente competente, um governo que não te sufoca com impostos, etc. Não mencionam que é um ambiente no qual você tem fôlego para falhar.

Sério: criar rede social no Brasil? Nossos problemas  são outros! Cansei de ver consultores ou investidores apresentando modelos gringos aqui.

E sinceramente, desconfio que o modelo de startup no Brasil é fadado ao fracasso por ser vendido, em sua maioria, baseado em ideias estrangeiras muito mal adaptadas à nossa realidade (basta pensar um pouquinho no próprio termo “startup”).

Gente que te ensina a abrir uma empresa e cuja própria empresa é… ensinar pessoas a abrir a própria empresa.

Meus comentários são desnecessários aqui.

(aliás, já escrevi a respeito)

As fórmulas prontas

“X passos para o sucesso”, “N oportunidades para ficar milionário em 2017”, “as Z coisas que pessoas de sucesso fazem todo dia”

Sério que as pessoas acreditam que a realidade é tão simples assim?

Levando em consideração a quantidade de leitores destes livros de “auto-ajuda para empreendedores”, era para estar pipocando milionários. Cadê eles?

Uma infantilização extrema

Por favor, faça o seguinte exercício: acesse o YouTube e busque por vídeos apresentando startups. É grande a possibilidade de você ver o seguinte:

  • Uma animação cartunesca
  • No fundo musical vai ter um banjo (99,99% de chance! Se não tiver banjo, tem pandeiro!)
  • Todas as pessoas sorriem por que todo mundo é divertido e o mundo colorido!

Talvez soe ranzinza mas… quem quer investir em uma empresa dirigida por pessoas assim? Oh: desculpe, talvez eu esteja com inveja por não fazer parte do grupo das pessoas legais… (percebo que não faço, sinto alívio!)

Esta infantilização se manifesta de forma clara quando observamos o uso repetido ao extremo da imagem do jovem prodígio.

Na realidade a infantilização nada mais é que a exploração da carência presente em cada um de nós (e sobre isto ainda escrevo um texto).

Então empreender é ruim?

Claro que não: o que quero mostrar neste texto é que abrir uma empresa não é algo simples ou fácil como este povinho picareta diz nos palcos. Empreender é algo sério e deveria ser um ato virtuoso, mas infelizmente aos poucos estão criando uma aura negativa em torno do verbo.

Quer abrir uma empresa, vai fundo, mas saiba aonde está entrando e nas consequências dos seus atos. Quer ver palestra de gente que diz te ensinar como agir? Vai lá e assista, mas pelo menos questione! Saiba assistir a uma apresentação.

Desculpem a franqueza, mas quem tem uma empresa real, como eu, ao assistir este conteúdo furado tem seu estômago revirado. Alguém tem de falar, tá chato ver a quantidade de pessoas afundando por que se iludem com estas lorotas.

formacao_itexto

Formação itexto de volta – Groovy, Grails, Spring e mais!

Desde o ano passado ministro esporadicamente treinamentos online e ao vivo pela itexto através do nosso projeto Formação. E este momento está se aproximando novamente: desenvolvemos uma nova plataforma de ensino e estamos planejando novos treinamentos de Groovy, Grails, Spring e outras tecnologias com as quais trabalhamos e que sabemos gerar valor real para nossos clientes.

Os treinamentos sempre são ao vivo, pois acreditamos que nada substituí a presença do instrutor e seu contato direto com os alunos (as aulas ficam muito mais ricas).

Nosso primeiro treinamento será o “Grails Essencial”  e já estamos preparando novos relacionados ao ecossistema Groovy e Grails (muitas ideias!).

Se estiver interessado(a), basta preencher nossos formulários de interesse, presentes tanto na página inicial do Formação quanto em todos os treinamentos que irão aparecer no site.

Assim que as turmas forem lançadas, aqueles que manifestarem seu interesse pelo cadastro serão chamados, lembrando que as turmas sempre são reduzidas (8 alunos no máximo) e costumam lotar bem rápido!

Há também um formulário de contato no qual vocês podem nos enviar suas dúvidas e sugestões.

Aguardo vocês!

Link para a Formação itexto: http://formacao.itexto.com.br

grails_vuejs

Grails + Vue.js – A série

Resolvi iniciar uma nova série de vídeos chamada “Grails + Vue.js”. Ainda não sei quatos vídeos serão publicados: o objetivo é apresentar rapidamente e de forma bem leve o Vue.js para desenvolvedores Grails, além de também mostrar como é o desenvolvimento de SPAs usando estas duas ferramentas e mais algumas (como o Zurb Foundation).

Já publiquei o primeiro vídeo, e você pode acompanhar a play list do YouTube neste link, espero que gostem!

O código fonte pode ser obtido no GitHub neste link.

vuejs

Exprimentando Vue.js – aplicando no /dev/All

Recentemente comecei a buscar frameworks JavaScript para serem aplicados em nossos projetos na itexto. Publiquei algum tempo atrás minha experiência de aprendizado envolvendo o Angular.js: chegou a hora de falar sobre o Vue.js.

Como fui parar no Angular.js

 

angular-js_600x400

Aprender Angular foi uma experiência muito enriquecedora para mim pois me pos em contato mais profundo com diversas ferramentas usadas no ambiente JavaScript, tais como o Gulp e o NPM.

O que mais gosto no Angular é a ideia de templates renderizados do lado cliente. Apesar de na esmagadora maioria dos nossos projetos boa parte da renderização ser realizada do lado servidor (diversas razões para isto, o que, por si só, já daria um post), em alguns casos a renderização do lado cliente nos parece a solução ideal.

Um dos nossos projetos em que os templates do Angular cairam como uma luva foi o /dev/All que, até a versão 1.8 usava este framework do lado cliente.  Não conhece o site? Abaixo você pode ver um print do mesmo:

devall_vue

Com o passar do tempo a arquitetura do /dev/All foi sofrendo algumas modificações, dentre elas a criação de uma API na qual estamos trabalhando aos poucos. Entre as chamadas desta API está a nossa busca, que é usada atualmente na interface do site com o usuário final.

A primeira versão do /dev/All era 100% renderizada do lado servidor. Com isto, sempre que o usuário paginava os posts ou realizava uma busca, todo o conteúdo da página era carregado novamente (ignorando os cacheamentos de JavaScript e CSS).

Este problema foi a razão pela qual na versão 1.8 do /dev/All passamos a usar o Angular na confecção da nossa interface gráfica. O resultado foi muito bom: os usuários agora baixavam uma única vez o código da página e em todas as chamadas subsequentes o Angular fazia o trabalho de atualização da interface.

Como encontrei o Vue.js

vuejs

Tivemos esta experiência bem sucedida com o Angular mas fiquei com a impressão de que ele era uma solução muito complicada para as nossas necessidades. A curva de aprendizado do Angular é muito íngreme: são muitos conceitos para que você comece a se tornar produtivo: controladores, módulos, injeção de dependências, inversão de controle, diretrizes. Minha única preocupação era a view: eu só queria um template que fosse renderizado do lado cliente e que tirasse proveito da nossa API.

Eu também queria algo com o qual pudesse reaproveitar conhecimentos que já dominava, como o jQuery: misturar Angular e jQuery é complicado para dizer o mínimo (sei que é possível, mas mesmo assim é mais complexo que o necessário).

Nisto passei por algumas soluções interessantes: Mustache, Rivets, Tangular (apenas 2Kb!) e mais algumas alternativas, dentre as quais estava o Vue.js, cujo primeiro contato foi feito totalmente por acaso através de um vídeo do Vedovelli.

Resolvi experimentar o Vue.js: o primeiro passo foi ler o seu guia para desenvolvedoresA leitura do guia me fez esquecer o Angular. Achei a documentação do Vue.js uma das melhores que já li: rápida, direta e curta. Terminada sua leitura você já consegue criar coisas interessantes com o framework.

(o guia do Vue.js devia ser usado como exemplo de documentação bem feita: virei fã)

A impressão que tive do Vue.js foi a de se tratar de um “Angular” fácil de aprender. Em aproximadamente três horas de estudo você já consegue criar aplicações com o Vue.js: no caso do Angular levou pelo menos uma semana para começar.  Vi esta experiência de aprendizado se repetir com Lucas, nosso estagiário na itexto.

A versão 1.9 do /dev/All, publicada no dia 19/6/2016 substituiu o Angular pelo Vue.js (usamos a versão 1.0). Quantas linhas de código JavaScript precisamos escrever para criar toda a interface do site? 30 (!), incluindo o boiler plate padrão do jQuery ($(document).ready).

O jQuery faz as chamadas ao servidor e o Vue.js renderiza o resultado para nós. É simples assim. :)

Outras coisas que gostei no Vue.js

Além da excelente documentação e facilidade de ser usado com outras bibliotecas (jQuery), houve outras razões pelas quais este framework me ganhou.

API fácil

A API do Vue.js é muito simples: essencialmente você só precisa conhecer o construtor Vue. E não só o guia é fácil de ler: a documentação da API também é excelente!

Levou um tempo até que eu me habituasse com o modo como a injeção de dependências é realizada no Angular (especialmente os problemas que podem surgir durante a minificação e “uglyficação” do código). No caso do Vue, como é focado apenas na view e não há controladores, tudo fica muito mais fácil.

Tem o que gostei no Angular

A sintaxe dos templates do Vue é muito parecida com a do Angular. Tanto é que não precisei reescrevê-los ao migrar para o Vue.js: a grosso modo bastou trocar as diretrizes “ng-*” por “v-*”.  A mesma sintaxe “mustache” se mantém.

Também há diretrizes, como o Angular, assim como filtros. A diferença está na facilidade de aprendizado.

Outra similaridade importante: também implementa o data binding bidirecional. Este recurso é muito interessante, especialmente quando se quer construir interfaces de cadastro mais complexas como, por exemplo, formulários do tipo mestre-detalhe ou mesmo simulação de planilhas (para estes dois casos já estamos projetando soluções baseadas no Vue.js na itexto).

Por falar em data binding, o modo como lida com formulários é também essencialmente o mesmo que temos no Angular.

Criação fácil de componentes

Assim como o Angular, o Vue.js também te permite criar componentes. No caso, o Vue é muito inspirado na spec Web Components do W3C. Note que é inspirado e não uma implementação desta spec.

A vantagem é que você pode escrever sua biblioteca de componentes reaproveitáveis com o Vue e, caso deseje abandoná-lo no futuro, o trabalho de reescrita (em teoria) deve ser bem menor.

Concluindo

Para situações nas quais só me interessa a renderização do lado cliente e a aplicação não é muito complexa (como o /dev/All), creio que Vue.js seja uma solução mais interessante que o Angular.

Se você ainda não o conhece, sugiro que leia seu guia e brinque um pouco com ele: é uma experiência muito interessante.  Na excelente documentação oficial há uma seção interessante na qual o comparam com outros frameworks, recomendo sua leitura, apesar de naturalmente se tratar de um texto tendencioso.

Creio que, apesar de ter preferindo o Vue, estudar Angular é essencial: tenho certeza de que boa parte da facilidade que tivemos em aprendê-lo (Vue) se deve aos conceitos que precisamos aprender em nosso estudo do Angular.

Se você gosta de vídeos, o Fabio Vedovelli tem uma série a respeito que vale muito à pena assistir (como tudo o que ele faz).