Javascript vai resolver tudo mesmo?

Fala galera, meu nome é Diogo. E como proposto pelo Jean, vou falar um pouco mais sobre mim neste primeiro post.

Fui graduando de Engenharia de Software na UFG, porém tranquei o curso em busca de me “autodidatizar” (discussão que quero trazer pra outro post). Desde então tenho estudado vários assuntos, até que me descobri apaixonado pelo Frontend.

Sou desenvolvedor Frontend na Meta Tecnologia. Fã de conhecimento holístico. E curto muito ler quando não estou programando. Além de ter idéias horríveis todos os dias.


A “nova era” do desenvolvimento web

Bom, eu já tinha um post semi-pronto sobre Web Storage. Porém, um podcast¹ que eu escutei hoje (13/08) me inspirou a escrever esse post. E me fez pensar bastante sobre o seguinte assunto: “Estamos mesmo usando Javascript da forma certa?”

Desde 2006-07 com a popularização de bibliotecas como jQuery e YUI, até hoje em dia com a evolução destas para os frameworks MV* (model-view-whatever) como Angular, Ember, Backbone, ExtJS, fora o uso de JS no servidor. Muitas das atividades, antes designadas ao backend, foram transferidas para o frontend. Por vários motivos, tais como: facilidade de desenvolvimento, performance, menor consumo de banda, entre outras.

No podcast, Nicholas C. Zakas (@slicknet) comenta sobre esse crescimento da “cultura do javascript” e levanta 2 pontos importantes:

  1. JS é a melhor solução para o meu problema?

  2. Qual o peso de usar uma ou várias bibliotecas javascript? E o que fazer para diminuí-lo?
     

Entender o problema é a melhor solução

 

No primeiro ponto abordado, é discutida a real necessidade do uso de bibliotecas/frameworks JS nas aplicações. O entrevistado fala da “jqueryzação” do desenvolvedor, citando a frase: “Bom, eu tenho esse problema. Como eu vou usar jQuery pra resolvê-lo?”. Ele critica o modo com muitos desenvolvedores não estendem os limites impostos pelas bibliotecas usadas, como criar plugins, forks, etc.

Outro argumento utilizado é o de que já existem tecnologias que fazem as mesmas coisas, no backend, por exemplo. E que podemos usar de Progressive Enhancement (melhoria progressiva) com Javascript para melhorar a experiência do usuário.

Eu divirjo um pouco dessa opinião. Pois penso que essa cultura de estender as bibliotecas tem crescido bastante. Muito pelo fato de que o GitHub (a.k.a: presença open-source) dos desenvolvedores tem se tornado uma espécie de currículo na visão de muitas empresas.

Porém, concordo com o fato de que JS deve ter uma abordagem de Progressive enhancement². O fato de se ter uma stack toda em Javascript é bastante atraente e resolve boa parte dos problemas. Mas nem todos eles exigem uma baita interface rica, ou uma ótima performance. Ou seja, conforme a necessidade surgir, a solução deve ser implementada.
 

Optei por Javascript, e agora?

 

Um dos principais problemas que surgem quando usamos javascript, principalmente no browser, é o excesso de alternativas.

Por exemplo, hoje eu preciso de uma lib para navegar na DOM, amanhã de widgets, depois de promises, autocomplete, etc. Além do meu próprio código, que faz o projeto realmente funcionar. Chegará um dia em que eu terei arquivos demais, consequentemente mais tempo de carregamento.

Para melhorar esse problema de carregamento, o Nicholas fala sobre os quatro tempos de carregamento no browser (os quais você pode se aprofundar mais nos slides³ da palestra que ele deu sobre o assunto).

Dentre eles, o que mais me chamou a atenção é o quarto: “On demand”. Neste tipo de abordagem, nós devemos pensar em como o cliente usará a aplicação.

Um bom exemplo citado no podcast, é de uma página de produto da Amazon.

 

amazon

 

  • Qual deve ser o primeiro passo do usuário logo após ter aberto a página? (assumindo que ele veio de uma pesquisa)

  1. Prioritariamente o botão “Add to Cart”, pois, se o usuário gostar do produto, essa será a primeira ação a ser tomada.

  2. Se o usuário não quiser o produto, provavelmente ele vai querer fazer outra pesquisa. Então, por exemplo, o autocomplete da pesquisa, não precisa estar carregado junto com a página. Podemos atrasar um pouco seu carregamento.

  3. O botão “Sell on Amazon”, por ser menos usado, pode ter sua funcionalidade carregada quando o mouse estiver a uma certa distância dele, por exemplo.

Só neste pequeno exemplo, nós economizamos o carregamento de 2 scripts. A partir daí, nós podemos viajar e pensar melhor em outras formas de trazer o mínimo viável de arquivos para o funcionamento da página. Tudo isso com base no comportamento do usuário. Achei isso muito foda e pretendo usar nos meus próximos projetos.
 

Conclusão

Apesar de causar xiismo e polêmica em muitos casos. Acho muito válidas as discussões sobre o uso ou não das tecnologias. Pois muita gente defende muito tecnologias em si, e não a solução para o problema.

Pra quem tiver um bom nível de inglês eu recomendo que escute o podcast, pois há outras discussões que eu não citei aqui. E espero que vocês tragam suas opiniões nos comentários, para que a gente possa discutir melhor sobre o assunto.

 

Referências

¹ Hanselminutes #383: Enough With The JavaScript Already! with Nicholas Zakas?
² Progressive enhancement is still important
³ Enough with the Javascript already!

 

Diogo César Beda

Desenvolvedor Frontend na Meta Tecnologia. Foi graduando de Engenharia de Software na UFG. Hoje dedica seus estudos a RIA e performance web, porém pretende adicionar Web Components nessa lista. Nas horas vagas, é viciado em livros e acredita que a educação ainda vai mudar o país.

Latest posts by Diogo César Beda (see all)

Comentários