1. O documento discute conceitos e tecnologias para desenvolvimento front-end como estado, APIs, frameworks e conclusões. 2. É apresentada uma comparação entre estilos imperativo e funcional e entre APIs do tipo RPC, REST e GRAPH. 3. Frameworks como Angular, React e Polymer são discutidos e a conclusão é que é importante separar a lógica da aplicação dos frameworks.

1. 23 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
23 de Abril, 2016

3. 1. Background
2. Uma sentença 3. Premissas
4. Conceitos 5.APIs 6. Frameworks
7. Conclusões
Agenda

4. Background.

5. Computadores existem para
satisfazer as nossas necessidades e
automatizar tarefas. A forma como
nós humanos interagirmos com
qualquer sistema que automatize
tarefas (não só computadores,
pense em carros, por exemplo) é
através de uma interface.

6. Antes da internet ser como
conhecemos hoje, essa interface era
feita através de softwares instalados
no sistema operacional. Com a
evolução da web e a praticidade da
mesma, muitos têm tentado trazer
todo o poder do computador para
sistemas na web, através de
interfaces no navegador.

8. Client-side === SPA.

9. Ou UniversalJS.

10. Se você não precisa de alguma
combinação de:
AJAX, Binding,
Interatividade e Input/Output.
Você não precisa de SPA.

11. Não ser SPA também é Front-End,
e tem seus desafios como
arquitetura de pastas/arquivos,
organização de CSS, templates
inteligentes, etc.

12. Voltando ao
Single Page Application…

13. Tecnologia x Ferramenta.

14. Tecnologia Ferramenta
Javascript Angular
Node.JS Express
PHP Symphony
Python Flask

16. medium.com/@caiovaccaro

17. Uma sentença.

22. 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.

23. Premisas.

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

25. Partes reutilizáveis e modulares.

26. Sem muita necessidade
de refatoração.

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

28. Premisas.
1. Não ter que aprender algo
demasiadamente específico.
2. Partes reutilizáveis e modulares.
3. Sem muita necessidade de refatoração.
4. Boa experiência para o usuário (rápido,
transições, feedback, fácil de usar).

29. Desafios de 2016*.
Premisas.

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

31. Performance.

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

33. Concorrência e Paralelismo.

34. Offline.

35. Desafios.
1. Sincronia de dados entre servidor e
cliente/cache.
2. Performance.
3. Fácil de desenvolver/dar manutenção.
4. Concorrência e Paralelismo.
5. Offline.

36. Tempo.
Premisas.

37. Tempo.
1. Curto prazo.
2. Longo prazo.

38. Não ter que
aprender algo
demasiadamente
específico
Partes reutilizáveis
e modulares
Sem muita
necessidade de
refatoração
Boa experiência
para o usuário
(rápido, transições,
feedback, fácil de
usar)
Fácil de desenvolver/
dar manutenção
Fácil de desenvolver/
dar manutenção
Sincronia de dados
entre servidor e
cliente
Offline
Fácil de desenvolver/
dar manutenção
Concorrência e
Paralelismo
Performance
Sincronia de dados
entre servidor e
cliente/cache

39. Curto prazo Longo prazo
Boa experiência para o usuário
(rápido, transições, feedback, fácil de
usar)
Boa experiência para o usuário
(rápido, transições, feedback, fácil de
usar)
Não ter que aprender algo
demasiadamente específico
Sem muita necessidade de
refatoração
Partes reutilizáveis e modulares

40. 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.

42. Temos que escolher entre.
1. Conceitos de programação.
2. Formatos de API.
3. Frameworks de Front-End.

43. Conceitos.

44. Você já leu por aí.
1. State.
2. Stateless.
3. Imperativo.
4. Funcional.
5. Passivo.
6. Reativo.

45. Imperativo.
1. Stateful.
2. Passivo.

46. Funcional.
1. Stateless.
2. Reativo.

47. State.
Conceitos.

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

49. Imperativo.
Conceitos.

50. 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.

52. Passivo.
Conceitos.

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

56. Reativo.
Conceitos.

57. 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.

60. Funcional.
Conceitos.

61. 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).

64. Stateless.
Conceitos.

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

67. reactivex.io/learnrx

68. Imperativo.
1. Stateful.
2. Passivo.

69. Funcional.
1. Stateless.
2. Reativo.

70. Comparações.
Conceitos.

74. APIs.

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

76. RPC.
APIs.

77. example.com/list/?rowOffset=0&rowSize=5

78. Mais de um recurso
ou entidade por chamada.

79. RPC.
1. Ruim para cache.
2. Acoplado.
3. Uma chamada por view.
4. Respostas pequenas.

80. REST.
APIs.

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

82. Cada endpoint === uma entidade.

83. REST.
1. Bom para cache.
2. Desacoplado.
3. Muitas chamadas por view.
4. Respostas grandes.

84. GRAPH.
APIs.

89. Cara.. pensa em JSON 360 graus.

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

91. Comparações.
APIs.

95. E o REST?

96. Frameworks.

101. Frameworks.
1. MV* (Angular 1.x, Ember...).
2. Flux + Components (React,Vue.js…).
3. Web Components (Polymer...).
4. Functional/Reactive (Cycle, Bacon…).

102. medium.com/@caiovaccaro

107. Conclusões.

109. zhou-yi.herokuapp.com

113. github.com/caiovaccaro/zhou-yi

114. Fácil de desenvolver + Curto prazo +
Não ter que aprender algo muito específico.

115. Imperativo + RPC + Flux/Components.

116. Sincronia de dados + Performance +
Longo prazo + Partes reutilizáveis.

117. Funcional + GRAPH +
Flux/Components ou Functional/Reactive.

118. Ah legal.. tenho que
saber escolher disso tudo então.

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

121. Lunar.
Conclusões.

123. Separar framework-code
de application-code.

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

125. github.com/hugeinc/lunar

126. Temos que ter camadas de
abstração sim, mas
sempre teremos que saber
em que pé anda a
tecnologia e o papel de
cada ferramenta.

127. Você pode ajudar.
Conclusões.

128. Você pode ajudar.
1. Soluções para paralelismo.
2. Propor formas de trabalhar offline.
3. Como transitar entre frameworks.
4. Facilitar o modelo de dados no cliente.

129. Perguntas?

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