Desenvolvimento Client-Side 2016

501 visualizações

Publicada em

Quais são nossos desafios atuais, como Front-Enders? Temos um número de questões para resolver, que se encararmos como nossa responsabilidade, conseguiremos evoluir. O tema dessa palestra inclui: comparações de modelos de API; grupos de frameworks; conceitos/paradigmas de programação.

Links:
English version: http://www.slideshare.net/Hugeinc/clientside-development-2016
Zhou-yi comparison tool: http://zhou-yi.herokuapp.com
Lunar, framework abstraction: https://github.com/hugeinc/lunar

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
501
No SlideShare
0
A partir de incorporações
0
Número de incorporações
13
Ações
Compartilhamentos
0
Downloads
4
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Desenvolvimento Client-Side 2016

  1. 1. 23 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 23 de Abril, 2016
  3. 3. 1. Background 2. Uma sentença 3. Premissas
 4. Conceitos 5.APIs 6. Frameworks
 7. Conclusões Agenda
  4. 4. Background.
  5. 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. 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.
  7. 7. Client-side === SPA.
  8. 8. Ou UniversalJS.
  9. 9. Se você não precisa de alguma combinação de: AJAX, Binding, 
 Interatividade e Input/Output.
 
 Você não precisa de SPA.
  10. 10. Não ser SPA também é Front-End,
 e tem seus desafios como arquitetura de pastas/arquivos, organização de CSS, templates inteligentes, etc.
  11. 11. Voltando ao
 Single Page Application…
  12. 12. Tecnologia x Ferramenta.
  13. 13. Tecnologia Ferramenta Javascript Angular Node.JS Express PHP Symphony Python Flask
  14. 14. medium.com/@caiovaccaro
  15. 15. Uma sentença.
  16. 16. 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.
  17. 17. Premisas.
  18. 18. Não ter que aprender algo demasiadamente específico.
  19. 19. Partes reutilizáveis e modulares.
  20. 20. Sem muita necessidade de refatoração.
  21. 21. Boa experiência para o usuário (rápido, transições, feedback, fácil de usar).
  22. 22. 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).
  23. 23. Desafios de 2016*. Premisas.
  24. 24. Sincronia de dados entre
 servidor e cliente/cache.
  25. 25. Performance.
  26. 26. Fácil de desenvolver e dar manutenção.
  27. 27. Concorrência e Paralelismo.
  28. 28. Offline.
  29. 29. 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.
  30. 30. Tempo. Premisas.
  31. 31. Tempo.
 1. Curto prazo.
 2. Longo prazo.
  32. 32. 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
  33. 33. 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
  34. 34. 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.
  35. 35. Temos que escolher entre.
 1. Conceitos de programação.
 2. Formatos de API.
 3. Frameworks de Front-End.
  36. 36. Conceitos.
  37. 37. Você já leu por aí.
 1. State.
 2. Stateless.
 3. Imperativo.
 4. Funcional.
 5. Passivo.
 6. Reativo.
  38. 38. Imperativo.
 1. Stateful.
 2. Passivo.
  39. 39. Funcional.
 1. Stateless.
 2. Reativo.
  40. 40. State. Conceitos.
  41. 41. Você está feliz agora,
 esse é seu estado.
 
 Estado é um snapshot da memória de uma parte do seu programa
 em determinado momento.
  42. 42. Imperativo. Conceitos.
  43. 43. 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.
  44. 44. Passivo. Conceitos.
  45. 45. A mesma coisa, mas do ponto
 de vista do pau mandado.
 
 Ele é passivo de receber ordem
 e está exposto aos outros.
  46. 46. Reativo. Conceitos.
  47. 47. 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.
  48. 48. Funcional. Conceitos.
  49. 49. 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).
  50. 50. Stateless. Conceitos.
  51. 51. Também vai junto com o funcional. 
 
 Advoga que a melhor forma de evitar efeitos colaterais é não armazenar estado, simplesmente transformar e retornar.
  52. 52. reactivex.io/learnrx
  53. 53. Imperativo.
 1. Stateful.
 2. Passivo.
  54. 54. Funcional.
 1. Stateless.
 2. Reativo.
  55. 55. Comparações. Conceitos.
  56. 56. APIs.
  57. 57. APIs.
 1. RPC.
 2. REST.
 3. GRAPH.
  58. 58. RPC. APIs.
  59. 59. example.com/list/?rowOffset=0&rowSize=5
  60. 60. Mais de um recurso
 ou entidade por chamada.
  61. 61. RPC.
 1. Ruim para cache.
 2. Acoplado.
 3. Uma chamada por view. 4. Respostas pequenas.
  62. 62. REST. APIs.
  63. 63. example.com/list/1234 example.com/user/3
  64. 64. Cada endpoint === uma entidade.
  65. 65. REST.
 1. Bom para cache.
 2. Desacoplado.
 3. Muitas chamadas por view. 4. Respostas grandes.
  66. 66. GRAPH. APIs.
  67. 67. Cara.. pensa em JSON 360 graus.
  68. 68. Olha depois aí.
 1. Netflix Falcor.
 2. Facebook Relay/GraphQL.
  69. 69. Comparações. APIs.
  70. 70. E o REST?
  71. 71. Frameworks.
  72. 72. Frameworks.
 1. MV* (Angular 1.x, Ember...).
 2. Flux + Components (React,Vue.js…).
 3. Web Components (Polymer...).
 4. Functional/Reactive (Cycle, Bacon…).
  73. 73. medium.com/@caiovaccaro
  74. 74. Conclusões.
  75. 75. zhou-yi.herokuapp.com
  76. 76. github.com/caiovaccaro/zhou-yi
  77. 77. Fácil de desenvolver + Curto prazo + Não ter que aprender algo muito específico.
  78. 78. Imperativo + RPC + Flux/Components.
  79. 79. Sincronia de dados + Performance +
 Longo prazo + Partes reutilizáveis.
  80. 80. Funcional + GRAPH +
 Flux/Components ou Functional/Reactive.
  81. 81. Ah legal.. tenho que
 saber escolher disso tudo então.
  82. 82. Nossa aplicação pode ser independente de frameworks?
  83. 83. Lunar. Conclusões.
  84. 84. Separar framework-code de application-code.
  85. 85. Deixar sua lógica de negócio ser independente de ferramentas.
  86. 86. github.com/hugeinc/lunar
  87. 87. 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.
  88. 88. Você pode ajudar. Conclusões.
  89. 89. 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.
  90. 90. Perguntas?
  91. 91. 23 de Abril, 2016. R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com

×