O documento descreve uma apresentação sobre desenvolvimento client-side em 2016. Apresenta paradigmas de programação, APIs, frameworks e desafios como sincronia de dados, performance e desenvolvimento para múltiplos dispositivos. Recomenda escolher abordagens de acordo com os objetivos do projeto, usuários e tempo disponível.

1. 26 de Abril, 2016
R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com

2. Desenvolvimento
Client-Side 2016
Huge Brazil
26 de Abril, 2016

3. 1. Introdução
2. Paradigmas 3.APIs
4. Frameworks 5. Desafios
6. Conclusões
Agenda

4. Introdução.

23. CaioVaccaro
Technology Lead
cvaccaro@hugeinc.com

24. O que você quer?

25. Além de…

28. Huge Rio.

32. Sei lá…

34. I just wanna do some cool shit stuff.

35. Nosso trabalho é
muito difícil.
Não se culpe se você
não tem feito
coisas legais.

36. Tools.
Typescript.
Babel.
Framework.
HTML, CSS, JS.
Devices*.
Browser/V8.
Linguagem de prog.
Sist. Operacional
Kernel.
Ling. Máquina.
Hardware.
Computador.

37. Tools.
Typescript.
Babel.
Framework.
HTML, CSS, JS.
Devices*.
Browser/V8.
Linguagem de prog.
Sist. Operacional
Kernel.
Ling. Máquina.
Hardware.
Computador.

38. Tools.
Typescript.
Babel.
Framework.
HTML, CSS, JS.
Devices*.
Browser/V8.
Linguagem de prog.
Sist. Operacional
Kernel.
Ling. Máquina.
Hardware.
Computador.

39. Tools.
Typescript.
Babel.
Framework.
HTML, CSS, JS.
Devices*.
Browser/V8.
Linguagem de prog.
Sist. Operacional
Kernel.
Ling. Máquina.
Hardware.
Computador.

40. Tools.
Typescript.
Babel.
Framework.
HTML, CSS, JS.
Devices*.
Browser/V8.
Linguagem de prog.
Sist. Operacional
Kernel.
Ling. Máquina.
Hardware.
Computador.

43. Tools.
Typescript.
Babel.
Framework.
HTML, CSS, JS.
Devices*.
Browser/V8.
Linguagem de prog.
Sist. Operacional
Kernel.
Ling. Máquina.
Hardware.
Computador.

44. Tools.
Typescript.
Babel.
Framework.
HTML, CSS, JS.
Devices*.
Browser/V8.
Linguagem de prog.
Sist. Operacional
Kernel.
Ling. Máquina.
Hardware.
Computador.
Facilidade.
Desenvolvedores.
Mudanças.

45. Tools.
Typescript.
Babel.
Framework.
HTML, CSS, JS.
Devices*.
Browser/V8.
Linguagem de prog.
Sist. Operacional
Kernel.
Ling. Máquina.
Hardware.
Computador.
Facilidade.
Desenvolvedores.
Mudanças.

46. I just wanna do some cool shit stuff.

47. Inteligente.

48. Que faça a diferença.

49. … e que as pessoas
usem.

50. … e no final traga:

53. Huge Rio.

57. Eu quero desenvolver
aplicações sem me preocupar
demais em aprender algo
além da tecnologia,com
partes reutilizáveis,de fácil
manutenção e que traga uma
boa experiência para os
usuários.

58. Usuários.
Considere que existem dois tipos de usuário:
“regular” e “altamente interativo”. No contexto
desta palestra o foco é no interativo.

59. Tools.
Typescript.
Babel.
Framework.
HTML, CSS, JS.
Devices*.
Browser/V8.
Linguagem de prog.
Sist. Operacional
Kernel.
Ling. Máquina.
Hardware.
Computador.
Facilidade.
Desenvolvedores.
Mudanças.

65. Tools.
Typescript.
Babel.
Framework.
HTML, CSS, JS.
Facilidade.
Desenvolvedores.
Mudanças.

66. Tools.
Typescript.
Babel.
Framework.
HTML, CSS, JS.
Facilidade.
Desenvolvedores.
Mudanças.

68. Framework.
HTML, CSS, JS.
Facilidade.
Desenvolvedores.
Mudanças.

69. Framework.
HTML, CSS, JS.
Facilidade.
Desenvolvedores.
Mudanças.

70. Framework.
Formatos de API.
Paradig. de Programação.
HTML, CSS, JS.
Facilidade.
Desenvolvedores.
Mudanças.

71. Temos que escolher entre.
1. Frameworks de Front-End.
2. Paradig. de programação.
3. Formatos de API.
4. Tools.

72. Temos que escolher entre.
1. Frameworks Interface lógica.
2. Paradigmas Modelo mental.
3. API Dados, fatos.

73. O que combina melhor com
você,sua equipe,os desafios
do seu projeto e o seu
tempo de vida?

74. Paradigmas.

75. Buzz words 😪

76. react, redux, flux, flow, typescript,
babel, vue.js, om, meteor, aurelia,
angular, firebase, riot, bacon.js,
cycle.js, relay, immutable,
web assembly.

77. Você já leu por aí.
1. State.
2. Stateless.
3. Passivo.
4. Reativo.

78. Imperativo.

79. Funcional.

80. Imperativo.
1. Stateful.
2. Passivo.

81. Funcional.
1. Stateless.
2. Reativo.

82. Obs: Não são excludentes,
mas você pode pensar
dessa forma.

83. Imperativo.
Conceitos.

84. Esse é o estilo mandão.
Eu sei quem você é, eu quero
que você faça aquilo pra
mim. Eu mudo o seu estado e
eu sei disso.

86. Passivo.
Imperativo.

87. A mesma coisa, mas do
ponto de vista do pau
mandado.
Ele é passivo de receber
ordem e está exposto
aos outros.

89. State.
Imperativo.

90. Você está feliz agora,
esse é seu estado.
Estado é um snapshot da
memória de uma parte
do seu programa em
determinado momento.

91. Funcional.
Conceitos.

92. Esse é o estilo matemático.
Eu defino funções previsíveis,
que apenas alteram o estado
do seu escopo e nunca
causam efeitos colaterais
(nunca mudam estados fora
de si mesmas).

93. fn(x) => x * 2

96. Reativo.
Funcional.

97. O contrário do imperativo e
passivo, vai junto com
o funcional.
Ele diz explicitamente que
vai reagir quando acontecer
tal coisa nos outros.
Ninguém manda nele
diretamente, ele manda em
si mesmo e se controla.

100. Stateless.
Funcional.

101. Também vai junto com
o funcional.
Advoga que a melhor forma
de evitar efeitos colaterais é
não armazenar estado,
simplesmente transformar
e retornar.

103. reactivex.io/learnrx

104. Imperativo.
1. Stateful.
2. Passivo.

105. Funcional.
1. Stateless.
2. Reativo.

106. Bags time!

108. APIs.

109. APIs.
1. RPC.
2. REST.
3. GRAPH.

110. RPC.
APIs.

111. example.com/list?offset=0&size=5

112. Mais de um recurso
ou entidade por chamada.

113. RPC, Bad.
1. Ruim para cache/infra.
2. Acoplado.

114. RPC, Good.
1. Uma chamada por view.
2. Respostas pequenas.

115. REST.
APIs.

116. example.com/list/1234
example.com/user/3

117. Cada endpoint === uma
entidade.

118. REST, Bad.
1. Muitas chamadas por view.
2. Respostas grandes.

119. REST, Good.
1. Bom para cache.
2. Desacoplado.

120. Graph.
APIs.

125. Cara.. pensa em
JSON 360 graus.

126. Graph, Bad.
1. Query language complexa.
2. Pode haver débito técnico.

127. Graph, Good.
1. Bom para cache.
2. Rápido.
3. Respostas pequenas.
4. Desacoplado.

128. Olha depois aí.
1. Netflix Falcor.
2. Facebook Relay/GraphQL.

129. Frameworks.

135. Frameworks.
1. MV* (Angular, Ember...).
2. Components (React,Vue.js, Flux).
2.1. Web Components (Polymer…).
3. Functional/Reactive (Cycle…).

136. O que é uma aplicação?

137. No que consiste uma aplicação.
1.
2.
3.
4. Usuário.

138. No que consiste uma aplicação.
1.
2.
3. Interface.
4. Usuário.

139. No que consiste uma aplicação.
1.
2. Lógica.
3. Interface.
4. Usuário.

140. No que consiste uma aplicação.
1. Dados persistentes.
2. Lógica.
3. Interface.
4. Usuário.

141. No que consiste uma aplicação.
1. Dados persistentes.
2. Lógica.
3. Interface.
4. Usuário.

142. No que consiste uma aplicação.
1. Dados persistentes. Model.
2. Lógica. Controller.
3. Interface.View.

143. No que consiste uma aplicação.
1. Dados persistentes. Store.
2. Lógica. Reducer.
3. Interface. Components.

144. No que consiste uma aplicação.
1. Dados persistentes. Stream, State.
2. Lógica. Pure Functions.
3. Interface. Components.

145. Desafios.

146. Premissas.
Desafios.

147. Não ter que aprender algo
demasiadamente específico.

148. Partes reutilizáveis e
modulares.

149. Sem muita necessidade
de refatoração.

150. Boa experiência para o
usuário (rápido, transições,
feedback, fácil de usar).

151. Premisas.
1. Fácil de aprender.
2. Reutilizável e modular.
3. Intuitivo de manter.
4. Bom de usar.

152. Tempo.
Premisas.

153. Não só quanto tempo
você tem para fazer,
mas quanto tempo
sua aplicação
vai viver.

154. Tempo.
1. Curto prazo.
2. Longo prazo.

155. Desafios de 2016*.
Premisas.

156. Wait…

157. One more bag.

158. Desafios de 2016*.
Premisas.

159. Sincronia de dados entre
servidor e cliente/cache.

160. Performance.

161. Fácil de desenvolver
e dar manutenção.

162. Concorrência e Paralelismo.

163. Offline.

164. Desafios.
1. Sincronia servidor/cliente/cache.
2. Performance.
3. Fácil de desenvolver/manter.
4. Concorrência e Paralelismo.
5. Offline.

165. Conclusões.

166. O que eu faço?

167. Se você é bom em
seguir “passo a passo”,
você está bem perto…

168. De ser normal.

170. Toda empresa chega
em um “padrão” para
evoluir — frameworks
são isso.

171. É bom estudar, saber e
fazer uso deles.

172. Mas em grandes
projetos na vida real,
o “passo a passo” não é
suficiente.

173. Você precisa saber
como as coisas
funcionam,
e porque elas
funcionam
daquela forma.

174. Saiba responder:

175. O que você quer fazer?

176. O que você quer fazer?
Em/por quanto tempo?

177. O que você quer fazer?
Em/por quanto tempo?
Para qual usuário?

178. O que você quer fazer?
Em/por quanto tempo?
Para qual usuário?
Qual seu principal desafio?

179. O que você quer fazer?
Em/por quanto tempo?
Para qual usuário?
Qual seu principal desafio?
Como o BE/dados estão
estruturados?

180. O que você quer fazer?
Em/por quanto tempo?
Para qual usuário?
Qual seu principal desafio?
Como o BE/dados estão
estruturados?
Qual modelo mental da
equipe?

181. O que você quer fazer?
Em/por quanto tempo?
Para qual usuário?
Qual seu principal desafio?
Como o BE/dados estão
estruturados?
Qual modelo mental da
equipe?
Vocês tem tempo para
aprender?

183. Zhou-yi.
Conclusões.

188. github.com/caiovaccaro/zhou-yi

189. Nossa aplicação pode ser
independente de frameworks?

190. Lunar.
Conclusões.

192. Separar framework-code
de application-code.

193. Deixar sua lógica de negócio
ser independente de
ferramentas.

195. github.com/hugeinc/lunar

196. Você pode ajudar.
Conclusões.

197. Você pode ajudar.
1. Soluções para paralelismo.
2. Propor como trabalhar offline.
3. Como transitar entre frameworks.
4. Melhorar data models no cliente.

199. Nós não temos o “luxo”
de só escolher uma
fórmula da prateleira.

200. Isso é uma
oportunidade.

201. Faça as
perguntas
certas.

203. caiovaccaro.com

204. We are hiring, talk to us.

205. And we have more bags,
come get them.

206. 26 de Abril, 2016.
R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com