Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Desenvolvimento Client-Side 2016 (BrazilJS)

Quais são nossos principais desafios como Front-Enders? Essa apresentação faz um resumo do cenário tecnológico deste ano e traz uma abordagem de como escolher ferramentas.

  • Login to see the comments

Desenvolvimento Client-Side 2016 (BrazilJS)

  1. 1. 26 de Abril, 2016 R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com
  2. 2. Desenvolvimento Client-Side 2016 Huge Brazil 26 de Abril, 2016
  3. 3. 1. Introdução 2. Paradigmas 3.APIs
 4. Frameworks 5. Desafios
 6. Conclusões Agenda
  4. 4. Introdução.
  5. 5. CaioVaccaro Technology Lead cvaccaro@hugeinc.com
  6. 6. O que você quer?
  7. 7. Além de…
  8. 8. Huge Rio.
  9. 9. Sei lá…
  10. 10. I just wanna do some cool shit stuff.
  11. 11. Nosso trabalho é muito difícil.
 Não se culpe se você não tem feito coisas legais.
  12. 12. Tools. Typescript. Babel. Framework. HTML, CSS, JS. Devices*. Browser/V8. Linguagem de prog. Sist. Operacional Kernel. Ling. Máquina. Hardware. Computador.
  13. 13. Tools. Typescript. Babel. Framework. HTML, CSS, JS. Devices*. Browser/V8. Linguagem de prog. Sist. Operacional Kernel. Ling. Máquina. Hardware. Computador.
  14. 14. Tools. Typescript. Babel. Framework. HTML, CSS, JS. Devices*. Browser/V8. Linguagem de prog. Sist. Operacional Kernel. Ling. Máquina. Hardware. Computador.
  15. 15. Tools. Typescript. Babel. Framework. HTML, CSS, JS. Devices*. Browser/V8. Linguagem de prog. Sist. Operacional Kernel. Ling. Máquina. Hardware. Computador.
  16. 16. Tools. Typescript. Babel. Framework. HTML, CSS, JS. Devices*. Browser/V8. Linguagem de prog. Sist. Operacional Kernel. Ling. Máquina. Hardware. Computador.
  17. 17. Tools. Typescript. Babel. Framework. HTML, CSS, JS. Devices*. Browser/V8. Linguagem de prog. Sist. Operacional Kernel. Ling. Máquina. Hardware. Computador.
  18. 18. 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.
  19. 19. 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.
  20. 20. I just wanna do some cool shit stuff.
  21. 21. Inteligente.
  22. 22. Que faça a diferença.
  23. 23. … e que as pessoas usem.
  24. 24. … e no final traga:
  25. 25. Huge Rio.
  26. 26. 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.
  27. 27. Usuários. Considere que existem dois tipos de usuário: “regular” e “altamente interativo”. No contexto desta palestra o foco é no interativo.
  28. 28. 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.
  29. 29. Tools. Typescript. Babel. Framework. HTML, CSS, JS. Facilidade. Desenvolvedores. Mudanças.
  30. 30. Tools. Typescript. Babel. Framework. HTML, CSS, JS. Facilidade. Desenvolvedores. Mudanças.
  31. 31. Framework. HTML, CSS, JS. Facilidade. Desenvolvedores. Mudanças.
  32. 32. Framework. HTML, CSS, JS. Facilidade. Desenvolvedores. Mudanças.
  33. 33. Framework. Formatos de API. Paradig. de Programação. HTML, CSS, JS. Facilidade. Desenvolvedores. Mudanças.
  34. 34. Temos que escolher entre.
 1. Frameworks de Front-End.
 2. Paradig. de programação. 3. Formatos de API. 4. Tools.
  35. 35. Temos que escolher entre.
 1. Frameworks Interface lógica.
 2. Paradigmas Modelo mental.
 3. API Dados, fatos.
  36. 36. O que combina melhor com você,sua equipe,os desafios do seu projeto e o seu
 tempo de vida?
  37. 37. Paradigmas.
  38. 38. Buzz words 😪
  39. 39. react, redux, flux, flow, typescript, babel, vue.js, om, meteor, aurelia, angular, firebase, riot, bacon.js, cycle.js, relay, immutable,
 web assembly.
  40. 40. Você já leu por aí.
 1. State.
 2. Stateless.
 3. Passivo.
 4. Reativo.
  41. 41. Imperativo.
  42. 42. Funcional.
  43. 43. Imperativo.
 1. Stateful.
 2. Passivo.
  44. 44. Funcional.
 1. Stateless.
 2. Reativo.
  45. 45. Obs: Não são excludentes, mas você pode pensar dessa forma.
  46. 46. Imperativo. Conceitos.
  47. 47. 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.
  48. 48. Passivo. Imperativo.
  49. 49. A mesma coisa, mas do ponto de vista do pau mandado.
 
 Ele é passivo de receber ordem e está exposto
 aos outros.
  50. 50. State. Imperativo.
  51. 51. Você está feliz agora,
 esse é seu estado.
 
 Estado é um snapshot da memória de uma parte
 do seu programa em determinado momento.
  52. 52. Funcional. Conceitos.
  53. 53. 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).
  54. 54. fn(x) => x * 2
  55. 55. Reativo. Funcional.
  56. 56. 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.
  57. 57. Stateless. Funcional.
  58. 58. Também vai junto com
 o funcional. 
 
 Advoga que a melhor forma de evitar efeitos colaterais é não armazenar estado, simplesmente transformar
 e retornar.
  59. 59. reactivex.io/learnrx
  60. 60. Imperativo.
 1. Stateful.
 2. Passivo.
  61. 61. Funcional.
 1. Stateless.
 2. Reativo.
  62. 62. Bags time!
  63. 63. APIs.
  64. 64. APIs.
 1. RPC.
 2. REST.
 3. GRAPH.
  65. 65. RPC. APIs.
  66. 66. example.com/list?offset=0&size=5
  67. 67. Mais de um recurso
 ou entidade por chamada.
  68. 68. RPC, Bad.
 1. Ruim para cache/infra.
 2. Acoplado.
  69. 69. RPC, Good.
 1. Uma chamada por view. 2. Respostas pequenas.
  70. 70. REST. APIs.
  71. 71. example.com/list/1234 example.com/user/3
  72. 72. Cada endpoint === uma entidade.
  73. 73. REST, Bad.
 1. Muitas chamadas por view. 2. Respostas grandes.
  74. 74. REST, Good.
 1. Bom para cache.
 2. Desacoplado.
  75. 75. Graph. APIs.
  76. 76. Cara.. pensa em
 JSON 360 graus.
  77. 77. Graph, Bad.
 1. Query language complexa. 2. Pode haver débito técnico.
  78. 78. Graph, Good.
 1. Bom para cache. 2. Rápido. 3. Respostas pequenas. 4. Desacoplado.
  79. 79. Olha depois aí.
 1. Netflix Falcor.
 2. Facebook Relay/GraphQL.
  80. 80. Frameworks.
  81. 81. Frameworks.
 1. MV* (Angular, Ember...).
 2. Components (React,Vue.js, Flux).
 2.1. Web Components (Polymer…).
 3. Functional/Reactive (Cycle…).
  82. 82. O que é uma aplicação?
  83. 83. No que consiste uma aplicação.
 1. 2. 3. 4. Usuário.
  84. 84. No que consiste uma aplicação.
 1. 2. 3. Interface. 4. Usuário.
  85. 85. No que consiste uma aplicação.
 1. 2. Lógica. 3. Interface. 4. Usuário.
  86. 86. No que consiste uma aplicação.
 1. Dados persistentes. 2. Lógica. 3. Interface. 4. Usuário.
  87. 87. No que consiste uma aplicação.
 1. Dados persistentes. 2. Lógica. 3. Interface. 4. Usuário.
  88. 88. No que consiste uma aplicação.
 1. Dados persistentes. Model. 2. Lógica. Controller. 3. Interface.View.
  89. 89. No que consiste uma aplicação.
 1. Dados persistentes. Store. 2. Lógica. Reducer. 3. Interface. Components.
  90. 90. No que consiste uma aplicação.
 1. Dados persistentes. Stream, State. 2. Lógica. Pure Functions. 3. Interface. Components.
  91. 91. Desafios.
  92. 92. Premissas. Desafios.
  93. 93. Não ter que aprender algo demasiadamente específico.
  94. 94. Partes reutilizáveis e modulares.
  95. 95. Sem muita necessidade de refatoração.
  96. 96. Boa experiência para o usuário (rápido, transições, feedback, fácil de usar).
  97. 97. Premisas.
 1. Fácil de aprender.
 2. Reutilizável e modular.
 3. Intuitivo de manter.
 4. Bom de usar.
  98. 98. Tempo. Premisas.
  99. 99. Não só quanto tempo você tem para fazer, mas quanto tempo sua aplicação
 vai viver.
  100. 100. Tempo.
 1. Curto prazo.
 2. Longo prazo.
  101. 101. Desafios de 2016*. Premisas.
  102. 102. Wait…
  103. 103. One more bag.
  104. 104. Desafios de 2016*. Premisas.
  105. 105. Sincronia de dados entre
 servidor e cliente/cache.
  106. 106. Performance.
  107. 107. Fácil de desenvolver e dar manutenção.
  108. 108. Concorrência e Paralelismo.
  109. 109. Offline.
  110. 110. Desafios.
 1. Sincronia servidor/cliente/cache.
 2. Performance.
 3. Fácil de desenvolver/manter.
 4. Concorrência e Paralelismo.
 5. Offline.
  111. 111. Conclusões.
  112. 112. O que eu faço?
  113. 113. Se você é bom em seguir “passo a passo”, você está bem perto…
  114. 114. De ser normal.
  115. 115. Toda empresa chega em um “padrão” para evoluir — frameworks são isso.
  116. 116. É bom estudar, saber e fazer uso deles.
  117. 117. Mas em grandes projetos na vida real, o “passo a passo” não é suficiente.
  118. 118. Você precisa saber como as coisas funcionam,
 e porque elas funcionam daquela forma.
  119. 119. Saiba responder:
  120. 120. O que você quer fazer?
  121. 121. O que você quer fazer?
 Em/por quanto tempo?
  122. 122. O que você quer fazer?
 Em/por quanto tempo?
 Para qual usuário?
  123. 123. O que você quer fazer?
 Em/por quanto tempo?
 Para qual usuário?
 Qual seu principal desafio?
  124. 124. O que você quer fazer?
 Em/por quanto tempo?
 Para qual usuário?
 Qual seu principal desafio?
 Como o BE/dados estão estruturados?
  125. 125. 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?
  126. 126. 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?
  127. 127. Zhou-yi. Conclusões.
  128. 128. github.com/caiovaccaro/zhou-yi
  129. 129. Nossa aplicação pode ser independente de frameworks?
  130. 130. Lunar. Conclusões.
  131. 131. Separar framework-code de application-code.
  132. 132. Deixar sua lógica de negócio ser independente de ferramentas.
  133. 133. github.com/hugeinc/lunar
  134. 134. Você pode ajudar. Conclusões.
  135. 135. Você pode ajudar.
 1. Soluções para paralelismo.
 2. Propor como trabalhar offline.
 3. Como transitar entre frameworks.
 4. Melhorar data models no cliente.
  136. 136. Nós não temos o “luxo” de só escolher uma fórmula da prateleira.
  137. 137. Isso é uma oportunidade.
  138. 138. Faça as perguntas certas.
  139. 139. caiovaccaro.com
  140. 140. We are hiring, talk to us.
  141. 141. And we have more bags, come get them.
  142. 142. 26 de Abril, 2016. R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com

×