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
58
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
CSC509 Lecture 01
javiergs
PRO
1
430
After go func(): Goroutines Through a Beginner’s Eye
97vaibhav
0
220
Чего вы не знали о строках в Python – Василий Рябов, PythoNN
sobolevn
0
150
Breaking Up with Big ViewModels — Without Breaking Your Architecture (droidcon Berlin 2025)
steliosf
PRO
1
290
ИИ-Агенты в каждый дом – Алексей Порядин, PythoNN
sobolevn
0
150
大規模アプリのDIフレームワーク刷新戦略 ~過去最大規模の並行開発を止めずにアプリ全体に導入するまで~
mot_techtalk
0
370
CSC305 Lecture 02
javiergs
PRO
1
260
Model Pollution
hschwentner
1
180
GraphQL×Railsアプリのデータベース負荷分散 - 月間3,000万人利用サービスを無停止で
koxya
1
1k
Let's Write a Train Tracking Algorithm
twocentstudios
0
220
XP, Testing and ninja testing ZOZ5
m_seki
2
250
NetworkXとGNNで学ぶグラフデータ分析入門〜複雑な関係性を解き明かすPythonの力〜
mhrtech
3
970
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
49
14k
A better future with KSS
kneath
239
17k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
Embracing the Ebb and Flow
colly
88
4.8k
The World Runs on Bad Software
bkeepers
PRO
71
11k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6.1k
Rails Girls Zürich Keynote
gr2m
95
14k
A Tale of Four Properties
chriscoyier
160
23k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
The Pragmatic Product Professional
lauravandoore
36
6.9k
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