A plataforma web percorreu um longo caminho desde que o HTML5 se tornou popular e as pessoas começaram a perceber JavaScript como uma linguagem que poderia ser utilizada para construir aplicações complexas. Muitas APIs surgiram e existe conteúdo abundante sobre como o navegador pode se aproveitar de todas elas.
Esta série de artigos específicos vai um passo além e se concentra em como estas poderosas tecnologias podem ser utilizadas na prática, não somente para construir demonstrações e protótipos interessantes mas também como os profissionais têm se utilizado delas em produção. Nesta série de artigos pós-HTML5, iremos além de modismos e obteremos uma visão prática de especialistas sobre o que realmente funcionou para eles. Também falaremos sobre tecnologias (como o AngularJS) que vão um pouco mais a frente, e definem o futuro de como os padrões e o desenvolvimento web vão evoluir.
Você pode se inscrever nas notificações de novos artigos desta série aqui.
Conforme mais e mais lógica acaba sendo executada no navegador, o código de front-end em JavaScript torna-se maior e mais difícil de manter. Como uma forma de resolver este problema, os desenvolvedores passaram a utilizar frameworks MVC que prometem entregar melhorias na produtividade e código de manutenção mais simples.
Em 2013, o InfoQ pediu à comunidade para classificar os frameworks MVC JavaScript, de acordo com os recursos que eles apresentavam e com sua maturidade:
Agora, o InfoQ perguntou a opinião de especialistas sobre como eles utilizam estes frameworks e quais são as melhores práticas que eles seguem para desenvolver aplicações JavaScript.
InfoQ: Qual é seu framework JavaScript MVC predileto, há quanto tempo você o utiliza e qual é o problema fundamental que ele lhe ajuda a resolver?
Matteo Pagliazzi: Angular é o framework do momento, e isso não é somente uma questão de estrelas (stars) no GitHub: ele tem o maior número de biblotecas, módulos e está sendo falado (e utilizado) por muitos desenvolvedores. É óbvio que nós (desenvolvedores) gostamos dele. Penso que isso acontece pela facilidade de começar a utilizá-lo: são necessários apenas 5 minutos para ter algo não trivial funcionando e ao mesmo tempo ele é muito poderoso. Assim, a curva de aprendizado começa a se tornar íngreme conforme você se move das coisas mais básicas para o núcleo do framework, quando você vai descobrir que ele é muito complexo.
Julien Knebel: Eu venho desenvolvendo com Ember.js há mais de 2 anos e em 5 aplicações em produção. Eu diria que ele me oferece flexibilidade, rapidez e confiança então posso me focar mais em definir toda a experiência do usuário ao invés de investir grandes quantidades de tempo em funcionalidades complexas como, por exemplo, um roteador assíncrono robusto.
Brad Dunbar: O meu favorito é o Backbone. Ele provê a simplicidade e a flexibilidade que os outros não oferecem. Além disso, e talvez mais importante, seu código é geralmente simples e legível.
John Munsch: O meu framework favorito é o AngularJS, que venho utilizando há um ano, e a lua-de-mel com ele ainda não acabou.
O problema fundamental cuja resolução eu busco em qualquer framework de front-end é a capacidade de me ajudar a construir uma interface de usuário complexa no front-end, não somente comparável, mas melhor do que aquelas que pudemos construir no passado com frameworks back-end como JSP, PHP, Rails, etc.
Julio Cesar Ody: Na maioria das vezes eu uso Backbone e venho utilizando cada vez mais o React.js como substituto as views do Backbone.
Todas as aplicações web que eu construo executam completamente em navegadores e se comunicam com um servidor utilizando uma API e/ou WebSockets. Isso significa que muita lógica acaba sendo escrita em JavaScript e o Backbone me ajuda a manter as coisas ordenadas e manuteníveis.
Thomas Davis: Minha primeira experiência com frameworks JavaScript MVC foi no final de 2010 e naquele tempo eu estava decidindo entre utilizar o Backbone.js ou o Sproutcore. Fiz um post comparativo que chegou a página principal do Hacker News e recebeu mais de 100.000 visualizações. Baseado no feedback que recebi naquela época, decidi utilizar o Backbone.js pois ele era compacto e não me impedia de implementar funcionalidades complexas sem estar preso às convenções de um framework maior. Conforme eu aprendia o Backbone.js, escrevi tutoriais que me deram um entendimento mais concreto do framework. Estes posts receberam e ainda recebem milhões de visualizações. Os arquivos atuais estão em backbonetutorials.com.
Atualmente, ao construir um produto, a experiência do usuário e o design são cruciais para a necessidade de manter o site relevante. Aplicações de uma única página (single page applications) lhe permitem implementar experiências que as páginas tradicionais não permitem devido à atualização da página. Por exemplo, imagine utilizar o Facebook e ter de atualizar a página a cada like e cada comentário.
InfoQ: Com tantas alternativas disponíveis, como comparar o framework que você usa com os outros?
Julien Knebel: Ele possui performance muito boa! Eu nunca imaginei que fosse me permitir codificar aplicações quase que inteiramente sozinha. O Angular é realmente muito bom, e gosto da forma rápida que você consegue começar a utilizá-lo, entretanto, acredito que ele tende a se tornar mais e mais tedioso conforme a sua base de código cresce. Por outro lado, tive mais dificuldade com o Ember no início, mas ele começou a se tornar mais simples conforme fui aprendendo mais sobre. Outro ponto importante (pelo menos para mim) é a componentização. Não gosto da forma que as diretivas do Angular lidam com isto e os componentes do Ember parecem realmente estar no caminho certo na forma de tratar componentização.
Brad Dunbar: Acho muito difícil uma biblioteca JavaScript preencher todas as necessidades da minha aplicação. Isso significa que frequentemente eu acabo escrevendo algum código no entorno delas. A funcionalidade do Backbone é pequena e ele provê utilitários que eu posso utilizar para composição, ao invés de utilizar grandes blocos que não são exatamente o que eu preciso.
John Munsch: Esta é uma pergunta difícil, minha experiência envolve apenas o Backbone.js (menos de dois anos de experiência) e o AngularJS (um ano). Mas entre estes dois, eu não acho que seja uma escolha difícil.
O Backbone.js estava funcionando bem, mas nós tivemos um grande projeto com mais de 6 pessoas trabalhando juntas e o problema que observamos foi com todas as grandes lacunas do Backbone.js (associação de duas vias -- two way binding, validação, templates, AMD, etc) que você tipicamente preenche com outros softwares. Se você não definir todas as soluções para estas lacunas antes de inciar o projeto, cada desenvolvedor vai procurar preenchê-las da sua maneira. Se você estiver com o cronograma apertado e escrevendo muito código rapidamente, pode ser muito difícil de capturar toda esta divergência e aplicar consistência.
Nós terminamos com um projeto funcionando e ele era muito mais rápido que a solução anterior, mas ele era uma Quimera: cada parte dele parecia ser um animal diferente. Com o AngularJS, muitas destas partes são do próprio framework e há menos espaço para este tipo de problema.
Julio Cesar Ody: Eu diria que o Backbone é o mais compacto, mas este não é um ponto particularmente útil para focarmos. De forma geral, o framework que mais lhe agradar vai ser também aquele que vai lhe tornar mais produtivo.
Então, entre Backbone, Angular e Ember não há como errar. Eu estou deixando o React.js de fora pois é somente uma biblioteca de componentes de interface, então ele não deve ser confundido com frameworks de aplicação.
Thomas Davis: Muita coisa mudou desde 2010 e, mesmo tentando constantemente quebrar meus velhos hábitos, eu ainda uso o Backbone.js atualmente. Ele continua compacto e não mudou nenhum de seus conceitos ou métodos centrais. Embora na minha opinião, ele esteja na eminência de ser substituído pelos seus competidores. Os esforços realizados em bibliotecas como o Angular para permitir aos desenvolvedores um controle mais intuitivo sobre o DOM fazem o Backbone.js parecer arcaico quando se trata de renderização. Com o novo movimento de JavaScript modular também podemos chamar o Backbone.js de monolítico no aspecto de tamanho. Não existem razões para os modelos (models), coleções (collections), roteadores (routers) e visões (views) serem empacotadas na mesma biblioteca. Alternativas como o Components.js estão escrevendo estas partes como módulos individuais. Isso não está completamente finalizado no momento e eu estou considerando utilizá-lo em um dos meus próximos projetos.
InfoQ: Construir rapidamente aplicações mais robustas de front-end é interessante, mas e a performance? Especialmente em mobile, qual é sua experiência?
Igor Minar: Eu acho que o mobile ainda é uma área mal servida para o desenvolvimento web. É necessário aplicar muito mais foco para esta área e o Angular está definitivamente se reposicionando para o mobile em sua versão 2.0.
Julien Knebel: O Ember é mais pesado que os demais, isto é um fato. Mesmo se você minificá-lo e comprimí-lo, então isto é algo importante a se considerar principalmente se você está planejando construir aplicações web para mobile. Ter de lidar com transações de 60 FPS (frames por segundo) de forma suave é difícil, seja implementando em Ember ou em qualquer outro framework. Eu diria que você tem de saber como lidar com os problemas comuns de performance na renderização, caso contrário você vai enfrentar problemas independente do framework que escolher.
Brad Dunbar: O Backbone possui alto desempenho e é compacto em relação aos demais. Eu não tenho encontrado problemas ao utilizá-lo para mobile, apesar de eu não construir aplicações para dispositivos com mais de uma geração de idade.
John Munsch: Nós ainda não estamos focados em mobile para o meu site atual, mas ja fizemos isto para o meu empregador anterior. Como eles queriam executar uma interface web adicional em leitores de códigos de barras em depósitos e hangares, nós criamos uma interface de usuário (IU) secundária, composta de paginas construídas exclusivamente para os leitores de código de barras. Eles usaram a mesma tecnologia usada na UI para navegadores de desktop e as páginas chamavam as mesmas APIs de back-end mas eram menores e mais simples para as pequenas telas sensíveis ao toque dos leitores de código de barras.
Naquele ambiente, essa pareceu uma solução melhor do que tentar fazer uma versão responsiva das páginas existentes onde nós teríamos que abandonar 80% da funcionalidade no mobile. Nós tivemos muita sorte de leitores de código de barras de boa qualidade com navegadores HTML5 estarem disponíveis antes do projeto entrar em produção. O trabalho em desenvolvimento foi realizado com leitores de código de barras que possuíam apenas o IE 5.5 disponível. * Arrepios *
Se eu tivesse de voltar ao projeto hoje, a primeira coisa que eu provavelmente faria seria adicionar o Grunt para concatenação, minificação e revisão do JavaScript para acelerar a performance no mobile e no desktop e também ativar a expiração dos cabeçalhos para que o cache do navegador pudesse ser ativado para um mês ou mais.
Julio Cesar Ody: O JavaScript é rápido e atualmente os navegadores são muito eficientes e continuam se aperfeiçoando. Seria necessário fazer uma grande bagunça para tornar as coisas realmente lentas.
O desempenho é muito importante quando tratamos de boa experiência de uso. Mas o JavaScript é apenas uma parte da história. Como você utiliza o CSS (transições e animações) e o quão boa e leve é sua marcação HTML (markup) também podem exercer um grande impacto sobre a performance. Você precisa ser cuidadoso com o todo.
Se você já programou qualquer micro controlador em C talvez você saiba o que significa escrever programas que executam em dispositivos limitados. Apesar de os celulares serem computadores poderosos, eles ainda são significativamente mais lentos que o laptop médio. Você não pode se dar ao luxo de cometer tantos erros e precisa levar em conta a regra que eu mencionei antes e ter cuidado redobrado.
Medir coisas que são problemáticas ajuda bastante. E nesse contexto, o Chrome DevTools me vem à mente.
Thomas Davis: Não existe bala de prata na escolha entre mobile e desktop para abordagem de desenvolvimento de front-end no momento. Às vezes aplicações nativas são melhores, as vezes aplicações JavaScript e outras vezes páginas geradas pelo servidor. Embora por questões de eficiência relacionada ao DOM em geral, eu provavelmente faria uma aposta segura no React. O React implementa um DOM virtual que difere do DOM dos navegadores e somente faz alterações quando necessário buscando alta performance de renderização. Pelo fato do DOM ser virtual, você também pode renderizar o DOM no servidor e acessá-lo programaticamente.
InfoQ: Qual é o seu fluxo de trabalho utilizando o framework escolhido? Quais ferramentas você usa para desenvolver e depurar?
Igor Minar: Webstorm, Karma e Chrome.
Julien Knebel: Eu uso Grunt como minha ferramenta de construção (build) para pré-processar, pré-compilar, pós-processar, concatenar, minificar, etc. O TextMate2 é meu editor (IDE) há anos. Eu também gasto bastante tempo depurando no Chrome DevTools com breakpoints. E claro, eu não viveria sem o Git.
Brad Dunbar: Eu costumo utilizar uma configuração minimalista incluindo uma interface de linha de comando (Command Line Interface - CLI) e vim/node/npm. Ultimamente, eu tenho gostado de utilizar o browserify para empacotamento. No fluxo de trabalho, eu uso o típico ciclo codificar, atualizar, depurar. Eu nunca fui um grande defensor de escrever os testes antes do código ou coisas desta natureza.
John Munsch: A maioria dos desenvolvedores no time de front-end usam WebStorm ou Sublime em computadores Mac, o projeto é construído e executado pelo Maven porquê o back-end é Java e, recentemente nós começamos a executar o Grunt de dentro das nossas construções Maven para conseguir otimizações do código de front-end. O Jenkins é utilizado para construção, execução de testes unitários e implantação para vários ambientes de testes e de produção.
Os desenvolvedores usam o Karma em suas máquinas para executar em segundo plano os testes unitários em AngularJS que temos atualmente (infelizmente, a cobertura de código atual é de apenas 30%).
Julio Cesar Ody: Eu faço o máximo possível de design (quando sou eu que estou fazendo isso) no início. Olhar como a página vai se apresentar me ajuda a fazer uma divisão mental dos componentes que eu preciso escrever.
Recentemente eu tenho usado muito o Hopla, que eu mesmo escreví, como um ferramenta de construção. Ele usa o Sprockets para traduzir CoffeeScript e SASS e compila a aplicação para HTML/CSS/JS estático. Isto é útil para implantações e até para a construção de aplicações Phonegap.
Então, eu usualmente começo um design implementando uma página HTML estática com estilos usando SCSS, revisando cada parte dela posteriormente e substituindo com componentes JavaScript.
Thomas Davis: Honestamente, eu sou muito indiferente sobre como as pessoas gostam de desenvolver e depurar, e minhas metodologias mudam projeto a projeto. O único conselho que eu dou aos desenvolvedores é que eles usem Asynchronous Module Definition (AMD). O Require.js oferece uma implementação robusta de AMD e na minha experiência, torna a depuração mais fácil em todas as linguagens e ambientes. Ele não só lhe ajuda a estruturar seu código de forma inteligente mas também reduz para níveis muito baixos a barreira de entrada para a sua base de código pois tudo precisa ser uma dependência referenciada apontando para um caminho de arquivo.
InfoQ: Conforme uma aplicação cresce, pode ser desafiador manter uma arquitetura robusta e uma grande base de código. Como o seu framework JavaScript favorito escala? Além disso, como ele escala quando um time de desenvolvimento cresce e diferentes pessoas precisam trabalhar em diferentes partes das funcionalidades?
Igor Minar: A reutilização de código, redução de código boilerplate e guias de estilos e convenções são importantes para reduzir a complexidade de grandes bases de código. Mas em nossa experiência no mundo real temos observado que conjuntos de testes de alta qualidade apresentam ainda mais impacto pois eles nos permitem refatorar enquanto mantemos o risco baixo. E refatoração é a chave para mantermos uma grande base de código limpa.
Matteo Pagliazzi: Além da complexidade (como a presença de Serviços, Factories e Providers, que são muito confusos), com simplicidade sendo um objetivo da versão 2 (http://blog.angularjs.org/2014/03/angular-20.html), o que eu pessoalmente não gosto é o mecanismo utilizado pelo Angular para verificar quais propriedades mudaram e atualizar a visualização (mas isto também vai acabar já que Object.observe é implementado nativamente, permitindo que as notificações sejam lançadas a cada alteração, ao invés de checar por alterações em cada uma das propriedades)
Para finalizar: O Angular é realmente muito bom, apoiado por uma comunidade incrível, um enorme número de bibliotecas externas que geralmente satisfazem cada necessidade e mesmo em casos que você não encontre o que procura, você sempre pode escrever sua própria diretiva. Mas ele também é cheio de conceitos complexos que levam tempo para entender.
Julien Knebel: O Ember lida muito bem com grandes bases de código por causa de sua "aplicação de boas práticas" e suas convenções fortes que permitem que você faça muita coisa com algumas simples linhas de código (também conhecido como convenção sobre configuração). Ele ajuda a cada membro do time a depurar o código dos demais de forma mais rápida. Eu vi alguns desenvolvedores irritados porque eles se sentiam limitados a codificar da forma que o Ember impõe, mas eu acho que a real frustração vem do fato de que você primeiro precisa entender/aprender o Ember antes de tentar fazer coisas legais com ele. E eu acredito que esse tempo de aprendizado adicional realmente se paga no longo prazo. Além disso, eu costumo confiar bastante no trabalho de Yehuda Katz e Tom Dale (mas eu acho que isso não é muito objetivo :) ).
Brad Dunbar: Eu acho que grandes bases de código JavaScript são desafiadoras independente do framework utilizado. Cabe ao time manter um conjunto de diretrizes e aderir à elas. O uso de módulos de algum tipo (eu mencionei que gosto do npm e do browserify) ajuda muito.
John Munsch: Até agora nossas experiências escalando aplicações tem sido boas. Código de Front-End JavaScript escala bem porque existem muitos arquivos estáticos passíveis de otimização, cache e até mesmo CDNs. Praticamente as únicas experiências ruins que tivemos foram tentando renderizar milhares de valores de dados nas páginas. Nós tentamos nos encorajar a utilizar paginação e outros ajustes deste tipo mas não conseguimos sempre chegar a um acordo sobre como utilizá-los e grandes quantidades de dados gerando milhares de elementos no DOM é uma receita para problemas em navegadores antigos.
Outros problemas desapareceram por completo. Por exemplo, o comportamento padrão do AngularJS de descartar as visões (views) e controllers quando alternamos entre visões mantém o uso de memória da outra visão sem impactar a visão atual. Esta é uma solução simples que ajuda os desenvolvedores a evitar diversos problemas conforme eles adicionam mais e mais funcionalidade para uma aplicação de página única (single page application).
Julio Cesar Ody: Eu não acho que nenhum dos frameworks populares tenha um caminho para escalabilidade definido. É o desenvolvedor que deve pensar em algo e executar esta ideia.
Eu sempre gostei do conceito de componentes/módulos. Ele me faz pensar em escrever programas da mesma forma que se constrói um relógio. Cada parte (ou componente) tem o seu propósito, e precisa funcionar de forma mais independente possível, expondo uma pequena área de superfície pela qual os outros componentes podem interagir.
Thomas Davis: Como eu disse anteriormente, desde que você use um framework JavaScript modular como o Require.js, escalar e manter a sua base de código é um passeio no parque e só vai depender das suas práticas de codificação. Embora o Backbone.js precise ser dividido em seus próprios módulos neste momento para que, ao invés de requerer o Backbone como dependência, você possa requerer apenas Backbone.Model, por exemplo.
InfoQ: Para as equipes que estão agora considerando adotar um framework JavaScript, quais seriam algumas das armadilhas mais comuns a serem evitadas?
Matteo Pagliazzi: Trabalhando em um grande projeto de código aberto que usa Angular como o framework de client-side eu descobri que é fácil para desenvolvedores sem muita experiência a incorrer em problemas com herança ou a começar a poluir o $scope e o $rootScope com muitos objetos que a partir de um certo ponto vão começar a deixar a aplicação mais lenta e aumentar o volume de memória RAM utilizada pelo navegador (nós facilmente usamos mais de 300 MB e isso pode chegar facilmente a 1GB mesmo com um pequeno vazamento de memória). O fato de ele tornar a associação de dados (data binding) tão "simples" é fantástico mas você deve entender que ele não vai sempre funcionar da forma que você espera só porquê ele é'"mágico".
Julien Knebel: Todos esse frameworks MV* fazem cálculos pesados no front-end, então, se sua aplicação precisar imprimir um grande volume de dados para o usuário você vai rapidamente atingir o seu limite de performance de renderização (eu estou falando do limite de 60 FPS). Você vai ter que lidar com paginação, rolagem de página inteligente, utilizar CSS de forma moderada e inteligente, sequenciamento sutil, alguns poucos lugares escolhidos para exibir spinners e fazer chamadas de rede que recuperam dados, etc. Tudo isso importa muito.
Brad Dunbar: Eu acho que os problemas mais comuns aparecem antes mesmo de você utilizar o framework. A parte cliente de sua aplicação vai precisar de testes, módulos, um gerenciador de pacotes e integração contínua, da mesma forma que o servidor. Se você conseguir se manter fiel à isto, provavelmente não vai ter problemas.
John Munsch: Eu mencionei os problemas que tivemos com o Backbone.js, mas existem alguns problemas comuns que sempre podem surgir. Por exemplo, SEO é um fator a ser considerado para páginas geradas inteiramente via JavaScript no front-end. Eu tenho a sorte de que a maioria do meu trabalho é com SaaS então SEO não tem sido algo com que nos importemos muito, mas se você está construindo algo para um público amplo na web você deve olhar para soluções como Prerender.io, BromBone, etc. para avaliar como você vai lidar com isso. O Google Analytics pode apresentar problemas similares. Nenhum destes problemas é insolúvel, mas é bom que você os conheça e saber que você talvez precise escolher uma solução.
Para nós, o IE8 tem sido sem dúvida um de nossos maiores problemas. É o último navegador com uma fatia significativa do mercado que não possui um compilador just-in-time para JavaScript. Como resultado, front-ends com muito código JavaScript podem ficar lentos às vezes, podem disparar erros do tipo "o script não está respondendo" quando apresentando muitos dados, etc. O quanto antes pudermos nos livrar do IE8, melhor para todos nós.
Julio Cesar Ody: A curva de aprendizado é definitivamente o maior problema que eu vejo. A maioria das pessoas vêm desenvolvendo aplicações web há anos, que consistem em um componente servidor recebendo requisições, processando-as e enviando HTML de volta ao navegador.
Esse é um paradigma completamente diferente que lembra muito o paradigma cliente/servidor e isso não é algo que muitos tenham feito antes. Ele possui muitos dos problemas que o paradigma cliente/servidor tinha, e ter alguma conhecimento sobre ele certamente vai ajudar.
Thomas Davis: A única grande armadilha a se preocupar é não ter conteúdo gerado pelo servidor disponibilizado na url. Isto obviamente vai fazer os motores de busca pararem de indexar o seu website e você também vai encontrar problemas para compartilhar sua página. Muitas redes sociais tentam agora analisar o seu webisite quando os usuários o compartilham para que elas possam buscar informações adicionais. Se você não tiver conteúdo gerado pelo servidor disponível no tempo adequado, estas tentativas vão falhar. Embora este problema tenha sido resolvido muitas vezes, e eu recomendo prerender.io como uma boa solução de código aberto, eu também tenho escrito bibliotecas SEO para mitigar este problema. Apesar das grandes empresas de motores de busca deverem renderizar sua aplicação para busca de conteúdo, algumas pessoas especulam que todo o projeto Chromium é uma tentativa da Google de ser capaz de carregar e executar todas as páginas para que eles possam amarrá-lo ao Google Bot e indexar todo o conteúdo apresentado pelo JavaScript.
InfoQ: Para alguém que quer começar a trabalhar com o framework, o que você acha que seria o caminho de aprendizado mais rápido e eficiente? Você gostaria de recomendar algum material?
Igor Mintar: Existem muitos livros bons sobre Angular, listas como a ng-newsletter.com e muitos podcasts ótimos no egghead.io.
Julien Knebel: Os guias oficiais do emberjs.com são ótimos, cada um deles foca em um recurso específico do framework. Eu escrevi uma introdução para iniciantes na Smashing Magazine (quando o Ember 1.0 foi lançado) que, na minha opinião, continua relevante.
Brad Dunbar: Talvez não seja a coisa mais legal a apontar, mas eu sempre recomendo a leitura do código fonte. É lá que a ação acontece e se ele for uma bagunça você vai saber. Você vai se tornar muito familiar com a sua escolha de framework MVC então se você não tiver estômago para encarar o código fonte talvez você deva considerar utilizar outro framework.
John Munsch: Se a pessoa em questão já for familiar com JavaScript eu recomendaria pegar um pequeno projeto (quatro ou menos visões (views) distintas formando uma aplicação web) e implementar o projeto inteiro usando o framework em questão. Construindo algo, mesmo algo muito simples, por todo o caminho até a conclusão e implantação é muito diferente de "brincar" com o framework. Você é forçado a resolver alguns problemas específicos e começar a realmente entender algumas coisas que de outra forma passariam despercebidas porque elas não são as partes divertidas de se aprender.
Julio Cesar Ody: Cometa quantos erros você puder em projetos experimentais, mas seja extraordinariamente consciente sobre eles. O que eu quero dizer é que é inútil tentar com unhas e dentes fazer tudo da melhor maneira possível logo de cara, e isso não vai fazer você aprender mais rapidamente.
Então, refatore seu código continuamente, mantendo em mente que o que você procura é um cenário onde você coloca um punhado de componentes para trabalhar em conjunto e formar uma aplicação completa, e você precisa os manter o mais independentes possível.
Eu escrevi um livro gratuito sobre este assunto, com ênfase em Backbone.js, que é claro que eu vou recomendar.
Thomas Davis: Depende do seu estilo de aprendizado. Eu geralmente prefiro simplesmente começar a tentar algo direto. Eu tenho recebido feedback fantástico sobre o meu vídeo tutorial para Backbone.js, que pode ser encontrado no Youtube.
InfoQ: Agora que os frameworks MVC tornaram-se mainstream, como você pensa que eles devem evoluir para melhor se adequar às necessidades dos desenvolvedores? Por exemplo, quais funcionalidades você acha que ainda faltam?
Igor Minar: Mobilidade e testabilidade.
Julien Knebel: Sincronização de dados entre o back-end e múltiplos clientes em tempo real seria o próximo passo lógico. O Meteor.js parece que vai seguir esse caminho então eu certamente vou experimentá-lo em breve.
Brad Dunbar: Eu não tenho certeza. Eu costumo submeter código para coisas que eu acredito que o Backbone precise e nem todas elas são boas :)
John Munsch: A resposta mais fácil é algo que os números do ngmodules.org apresentam sobre soluções que os desenvolvedores acabando procurando constantemente. Qualquer coisa que una frameworks de front-end à frameworks HTML/CSS (como o Bootstrap), upload de arquivos, internacionalização e localização, etc. Se centenas de desenvolvedores tiveram que procurar um recurso e gastaram tempo para marcar em um website que eles o utilizaram, você pode apostar que milhares de outros desenvolvedores também usaram o recurso as não se importaram em compartilhar o fato. Esta é a resposta fácil, mas eu gostaria de conectar duas coisas que eu não acho que recebem a atenção que merecem, validação e ausência de back-end.
Validação
Validação no cliente é algo geralmente necessário e que pode se tornar muito complexo para algumas páginas. Nós temos páginas em que várias datas precisam ser testadas entre si para garantir que elas ocorrem na sequência correta, e muitas outras variáveis tem várias regras também. Então, nós enviamos para o servidor via uma chamada de API, e ele tenta fazer as mesmas validações pois você nunca pode confiar na validação no cliente. Nosso back-end não é escrito em JavaScript então nós não podemos usar uma biblioteca de código em comum para fazer a validação e nós temos de construir dois conjuntos do mesmo código em linguagens diferentes e nos dar o dobro de probabilidade de cometer erros em algum caso extremo.
Por quê não me permitir descrever os dados em um esquema (schema) JSON e então tornar fácil para mim utilizá-lo para validação em ambos os lados (cliente e servidor) de uma chamada da API? Eu gostaria de ver isso poder ser feito de forma simples.
Ausência de Servidor
Houve alguns rumores sobre isso no último ano como o estado da arte (por exemplo, nobackend.org) mas isso está começando a morrer. Mas a ideia parece ainda estar forte com o Firebase, Hoodie, Backendless, etc. Eu acho que é uma boa maneira de desenvolvedores familiarizados apenas com o trabalho em front-end construírem uma aplicação completa sem precisar da ajuda de alguém para construir o back-end. Mesmo para aqueles como eu que podem construir o front-end e o back-end de uma aplicação de forma confortável, ela provê uma forma simples de prototipar uma ideia ou produzir um MVP.
Julio Cesar Ody: É difícil dizer. Eu acho que muitas ideias nasceram de equívocos sobre modularidade, e o pensamento de ter cada vez mais recursos é algo que eu venho historicamente lutando contra.
Mas eu acho que o React.js tem a ideia correta sobre isso, na medida que ele lhe oferece uma abordagem direcionada à componentes para construção de aplicações, e é difícil de você fazer algo terrivelmente errado se você simplesmente seguir os exemplos. Ele também abstrai alguns problemas complexos como a eficiência do DOM de graça para você.
Este é o tipo de problema que ninguém quer gastar tempo resolvendo no decorrer do desenvolvimento de uma aplicação, então, este é um passo na direção certa.
Thomas Davis: O ferramental e os frameworks MVC client-side estão fazendo progresso rápido na direção certa. Eu acredito que as APIs de servidores estão ficando pra trás neste ponto. Não há nenhuma convenção real que as pessoas estão seguindo para construir APIs RESTful, o que torna difícil para as coleções e modelos (models) client-side trazerem os dados de forma eficiente. O log de erros no client-side ainda precisa de melhorias mas tentativas como o trackjs.com estão fazendo progresso neste ponto. A forma como os eventos são tratados do lado cliente também precisa de melhorias.
Sobre os integrantes deste painel
Igor Minar é engenheiro de software no Google. Ele é o líder do AngularJS, praticante de test driven development, entusiasta de código aberto e hacker
Matteo Pagliazzi é apaixonado por desenvolvimento de software e contribui com projetos de código aberto.
Julien Knebel é uma designer de interface auto-didata e desenvolvedora front-end vivendo em Paris onde ela faz freelances para algumas das maiores empresas da França.
Brad Dunbar é programador JavaScript e um contribuidor frequente dos projetos Backbone e Underscore.
John Munsch é um desenvolvedor de software profissional com mais de 27 anos de experiência. Atualmente, lidera um time que está construindo front-end em AngularJS para aplicações web modernas, após passar alguns anos fazendo o mesmo tipo de trabalho com Backbone.js, Underscore.js e Handlebars.js.
Julio Cesar Ody é desenvolvedor de software, designer, palestrante e aspirante a escritor que vive em Sydney, Australia.
Ele trabalha muito com desenvolvimento para web em dispositivos móveis, e construiu um conjunto de ferramentas das quais ele se orgulha muito.
Thomas Davis é o fundador do backbonetutorials.com, co-fundador do cdnjs.com e desenvolvedor para o taskforce.js. Ele também contribui diariamente para vários projetos e código aberto que podem ser encontrados em github.com/thomasdavis.
A plataforma web percorreu um longo caminho desde que o HTML5 se tornou popular e as pessoas começaram a perceber JavaScript como uma linguagem que poderia ser utilizada para construir aplicações complexas. Muitas APIs surgiram e existe conteúdo abundante sobre como o browser pode se aproveitar de todas elas.
Esta série de artigos específicos vai um passo além e se concentra em como estas poderosas tecnologias podem ser utilizadas na prática, não somente para construir demos interessantes e protótipos, mas também como os profissionais têm se utilizado delas em produção. Nesta série de artigos pós-HTML5, nós vamos além de modismos e vamos obter uma visão prática de especialistas sobre o que realmente funcionou para eles. Também vamos falar sobre tecnologias (como o AngularJS) que vão um pouco mais a frente, e definem o futuro de como os padrões e desenvolvimento web irão evoluir.
Você pode se inscrever nas notificações sobre novos artigos da série aqui.
