Nós precisamos falar sobre o jQuery

Transcript

1. Nós precisamos falar sobre o jQuery @vimoding
2. Vinícius Almeida @vimoding
3. Consultor/Programador @vimoding
4. E fornecedor de mate @vimoding
5. A semelhança entre os títulos não é por acaso @vimoding
6. A principal definição para o filme é que ele é difícil @vimoding
7. Eu defino da mesma forma a resistência descabida à jQuery @vimoding
8. Isso não é sobre ficar na zona de conforto. É sobre ter uma visão pragmática em relação ao assunto. @vimoding
9. @vimoding
10. A idéia é propor uma visão menos passional dos assuntos vinculados ao frontend em geral. @vimoding
11. Vamos começar falando sobre alguns dos argumentos padrão @vimoding
12. 1: Eu preciso de uma SPA e a jQuery não foi feita pra isso. Logo, ela não vai me ajudar. @vimoding
13. Receber um HTML pronto do servidor e enviar dados utilizando formulários nunca será uma má idéia. — Jean Carlo Emer. @vimoding
14. A relação entre alguns devs frontend e as SPAs @vimoding
15. A necessidade de uma interface rica é muito mais comum do que uma SPA @vimoding
16. Alguns dos problemas que precisamos encarar nas SPAs estão muito bem resolvidos no backend @vimoding
17. Botar os pés no chão é difícil. Eu sei. Mas a falha de julgamento nessas situações são um prato cheio para over engineering @vimoding
18. 2: A jQuery é muito pesada. Principalmente por conta do suporte aos browsers antigos. @vimoding
19. Esse é o calcanhar de Aquiles da jQuery Mas a versão 2 da biblioteca já indica um movimento @vimoding
20. Mas será que a biblioteca é tão grande assim? @vimoding
21. Quais são as opções no contexto de uma interface rica? @vimoding
22. Ok, o approach para a sincronização com uma API precisa contar com terceiros @vimoding
23. Veja bem, em nenhuma das situações o approach com jQuery foi mais pesado do que os demais @vimoding
24. Ah, mas fora desse contexto a jQuery é enorme! @vimoding
25. Pois saiba que ainda temos alternativas Outras bibliotecas como a Zepto provêem uma API “largamente compatível” com a do jQuery pesando apenas 25K @vimoding
26. Pense nisso. Talvez o tamanho não seja um argumento tão forte assim. @vimoding
27. 3: Dá pra fazer em Vanilla @vimoding
28. @vimoding
29. A API de acesso ao DOM de fato melhorou muito tendo em vista um passado não muito distante @vimoding
30. Um desavisado depois de conhecer o querySelectorAll @vimoding
31. Nós precisamos entender como as abstrações são benéficas para o nosso código @vimoding
32. @vimoding
33. @vimoding
34. @vimoding
35. We want to have as much time as we can for the challenging tasks — Yehuda Katz @vimoding
36. Então, faz mesmo sentido investir tempo nisso? @vimoding
37. You need jQuery in many cases. Feel free to re- create it if you can. But please stop advertising to not use it — Anselm Hannemann @vimoding
38. GOING FORWARD @vimoding
39. A jQuery foi amplamente aplicada durante anos Segundo a Wikipédia, ela está presente em 77% dos 10 mil sites mais visitados do mundo @vimoding
40. O fato é que a forma de se escrever código com jQuery é muito sólida @vimoding
41. O processo de desenvolvimento é documentado e de fácil acesso @vimoding
42. E se mudássemos o nosso mind-set? plugin === component @vimoding
43. jQuery for Fun & Profit @vimoding
44. Mas cuidado com os gotchas O jQuery way pode não corresponder ao nível desejado para a sua aplicação @vimoding
45. Forma padrão de se inicializar um plugin/componente $(document).ready(function() { $('#any-selector').hypotheticPlugin({ firstProperty: foo, anotherProperty: bar }); }); Essa é a pior das convenções do jQuery way @vimoding
46. Por que ele é ruim? $(document).ready(function(){ $('.some-selector').ninjaMask({mask: '99-9999999'}); }); @vimoding
47. Por que ele é ruim? $(document).ready(function(){ $('.some-selector').ninjaMask({mask: '99-9999999'}); $('.another-selector').ninjaMask({mask: '99/99/99'}); }); @vimoding
48. Por que ele é ruim? $(document).ready(function(){ $('.some-selector').ninjaMask({mask: '99-9999999'}); $('.another-selector').ninjaMask({mask: '99/99/99'}); … … … }); Cadê o DRY magrão? @vimoding
49. Componentes auto detectáveis Sistema onde os componentes a serem inicializados são declarados no markup @vimoding
50. O markup Declarando tudo o que é necessário <div data-jquery-component="hypotheticComponent" data-first-property="foo" data-second-property="bar"> </div> @vimoding
51. O código JS Utilizando o .data() com maestria $('[data-jquery-component]').each(function(_i, el) { var $currentElement = $(el); var options = $currentElement.data(); $currentElement[options.jqueryComponent](options); }); @vimoding
52. Aplicação real <input data-jquery-component="ninjaMask" data-mask="99-9999999"> <input data-jquery-component="ninjaMask" data-mask="99/99/99"> Sem nenhuma linha de JS especializada ! @vimoding
53. Estender a API é fácil Isso é perfeitamente viável para um desenvolvedor de qualquer nível @vimoding
54. @vimoding
55. Mas ainda tem mais… @vimoding
56. Lazy init de componentes Componentes/plugins inicializados apenas quando eles de fato forem necessários na aplicação @vimoding
57. .one() e .is(':visible') ajudam nessa missão @vimoding
58. ! O jQuery é a melhor opção na ampla maioria dos casos ! Relembrando o disclaimer: Isso não tem a ver com ficar parado no tempo ou estagnado. É tudo uma questão de entendimento do contexto @vimoding
59. E é o contexto que deve motivar as decisões. E não as tendências. @vimoding
60. Obrigado! -> vinialm88@gmail.com -> viniciusalmeida.github.io -> speakerdeck.com/viniciusalmeida -> twitter.com/vimoding @vimoding