Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Nós precisamos falar sobre o jQuery
Search
Vinícius Almeida
September 19, 2015
Programming
0
96
Nós precisamos falar sobre o jQuery
Vinícius Almeida
September 19, 2015
Tweet
Share
More Decks by Vinícius Almeida
See All by Vinícius Almeida
Don't blame yoy tools
viniciusalmeida
0
57
ember-cli - A ambiciosidade migrando para o workflow
viniciusalmeida
1
84
Por que o Rails detona
viniciusalmeida
1
170
Pragmatismo no JavaScript
viniciusalmeida
0
81
Repensando o uso do jQuery
viniciusalmeida
2
560
Uma breve introdução do GruntJS
viniciusalmeida
1
70
Other Decks in Programming
See All in Programming
知っているようで知らない"rails new"の世界 / The World of "rails new" You Think You Know but Don't
luccafort
PRO
1
150
ファインディ株式会社におけるMCP活用とサービス開発
starfish719
0
1.1k
AI Coding Agentのセキュリティリスク:PRの自己承認とメルカリの対策
s3h
0
220
Ruby×iOSアプリ開発 ~共に歩んだエコシステムの物語~
temoki
0
310
Processing Gem ベースの、2D レトロゲームエンジンの開発
tokujiros
2
130
私の後悔をAWS DMSで解決した話
hiramax
4
210
Rancher と Terraform
fufuhu
2
400
MCPでVibe Working。そして、結局はContext Eng(略)/ Working with Vibe on MCP And Context Eng
rkaga
5
2.3k
FindyにおけるTakumi活用と脆弱性管理のこれから
rvirus0817
0
510
速いWebフレームワークを作る
yusukebe
5
1.7k
プロポーザル駆動学習 / Proposal-Driven Learning
mackey0225
2
1.3k
@Environment(\.keyPath)那么好我不允许你们不知道! / atEnvironment keyPath is so good and you should know it!
lovee
0
120
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Docker and Python
trallard
45
3.6k
Embracing the Ebb and Flow
colly
87
4.8k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Designing for humans not robots
tammielis
253
25k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
GraphQLとの向き合い方2022年版
quramy
49
14k
Transcript
Nós precisamos falar sobre o jQuery @vimoding
Vinícius Almeida @vimoding
Consultor/Programador @vimoding
E fornecedor de mate @vimoding
A semelhança entre os títulos não é por acaso @vimoding
A principal definição para o filme é que ele é
difícil @vimoding
Eu defino da mesma forma a resistência descabida à jQuery
@vimoding
Isso não é sobre ficar na zona de conforto. É
sobre ter uma visão pragmática em relação ao assunto. @vimoding
@vimoding
A idéia é propor uma visão menos passional dos assuntos
vinculados ao frontend em geral. @vimoding
Vamos começar falando sobre alguns dos argumentos padrão @vimoding
1: Eu preciso de uma SPA e a jQuery não
foi feita pra isso. Logo, ela não vai me ajudar. @vimoding
Receber um HTML pronto do servidor e enviar dados utilizando
formulários nunca será uma má idéia. — Jean Carlo Emer. @vimoding
A relação entre alguns devs frontend e as SPAs @vimoding
A necessidade de uma interface rica é muito mais comum
do que uma SPA @vimoding
Alguns dos problemas que precisamos encarar nas SPAs estão muito
bem resolvidos no backend @vimoding
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
2: A jQuery é muito pesada. Principalmente por conta do
suporte aos browsers antigos. @vimoding
Esse é o calcanhar de Aquiles da jQuery Mas a
versão 2 da biblioteca já indica um movimento @vimoding
Mas será que a biblioteca é tão grande assim? @vimoding
Quais são as opções no contexto de uma interface rica?
@vimoding
Ok, o approach para a sincronização com uma API precisa
contar com terceiros @vimoding
Veja bem, em nenhuma das situações o approach com jQuery
foi mais pesado do que os demais @vimoding
Ah, mas fora desse contexto a jQuery é enorme! @vimoding
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
Pense nisso. Talvez o tamanho não seja um argumento tão
forte assim. @vimoding
3: Dá pra fazer em Vanilla @vimoding
@vimoding
A API de acesso ao DOM de fato melhorou muito
tendo em vista um passado não muito distante @vimoding
Um desavisado depois de conhecer o querySelectorAll @vimoding
Nós precisamos entender como as abstrações são benéficas para o
nosso código @vimoding
@vimoding
@vimoding
@vimoding
We want to have as much time as we can
for the challenging tasks — Yehuda Katz @vimoding
Então, faz mesmo sentido investir tempo nisso? @vimoding
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
GOING FORWARD @vimoding
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
O fato é que a forma de se escrever código
com jQuery é muito sólida @vimoding
O processo de desenvolvimento é documentado e de fácil acesso
@vimoding
E se mudássemos o nosso mind-set? plugin === component @vimoding
jQuery for Fun & Profit @vimoding
Mas cuidado com os gotchas O jQuery way pode não
corresponder ao nível desejado para a sua aplicação @vimoding
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
Por que ele é ruim? $(document).ready(function(){ $('.some-selector').ninjaMask({mask: '99-9999999'}); }); @vimoding
Por que ele é ruim? $(document).ready(function(){ $('.some-selector').ninjaMask({mask: '99-9999999'}); $('.another-selector').ninjaMask({mask: '99/99/99'});
}); @vimoding
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
Componentes auto detectáveis Sistema onde os componentes a serem inicializados
são declarados no markup @vimoding
O markup Declarando tudo o que é necessário <div data-jquery-component="hypotheticComponent"
data-first-property="foo" data-second-property="bar"> </div> @vimoding
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
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
Estender a API é fácil Isso é perfeitamente viável para
um desenvolvedor de qualquer nível @vimoding
@vimoding
Mas ainda tem mais… @vimoding
Lazy init de componentes Componentes/plugins inicializados apenas quando eles de
fato forem necessários na aplicação @vimoding
.one() e .is(':visible') ajudam nessa missão @vimoding
! 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
E é o contexto que deve motivar as decisões. E
não as tendências. @vimoding
Obrigado! ->
[email protected]
-> viniciusalmeida.github.io -> speakerdeck.com/viniciusalmeida -> twitter.com/vimoding @vimoding