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.

Client-side Development 2016

Our biggest challenges as Front-Enders. We have a number of questions to solve, we can evolve if we face them as our responsibility. This deck includes: comparisons of API models; framework's groups; programming concepts/paradigms.

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

  • Login to see the comments

Client-side Development 2016

  1. 1. April 23th, 2016 R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com
  2. 2. Client-side Development 2016 Huge Brazil April 23th, 2016
  3. 3. 1. Background 2. One sentence 3. Premises
 4. Concepts 5.APIs 6. Frameworks
 7. Conclusions Agenda
  4. 4. Background.
  5. 5. Computers are there to satisfy
 our needs and automate tasks.
 The way we humans interact
 with any system that automates tasks (not just computers, think of cars, for example) happens
 through an interface.
  6. 6. Before the internet became how
 we know it, this interface was stablished by a software installed
 on your operating system.
 With the evolution of the web
 and the practicality of it, many have tried to bring all the power of computer systems to the web, through interfaces in the browser.
  7. 7. Client-side === SPA.
  8. 8. Or UniversalJS.
  9. 9. If you don’t need any
 combination of: AJAX, Binding, 
 Interactivity and Input/Output.
 
 You don’t need a SPA.
  10. 10. To not be a SPA is also Front-End,
 with its own challenges such as
 files/folders architecture, CSS organization, smart templates, etc.
  11. 11. Going back to
 Single Page Applications…
  12. 12. Technology x Tool.
  13. 13. Technology Tool Javascript Angular Node.JS Express PHP Symphony Python Flask
  14. 14. medium.com/@caiovaccaro
  15. 15. One sentence.
  16. 16. I want do develop applications without worrying too much about learning something beyond technology,with reusable parts, that is easy to maintain and
 brings a good user experience.
  17. 17. Premises.
  18. 18. Not necessary to learn
 something too complex or specific.
  19. 19. Reusable and modular parts.
  20. 20. Without too much
 need of refactoring.
  21. 21. Brings a good user experience (fast, transitions, feedback, easy to use).
  22. 22. Premises.
 1. Not necessary to learn something
 too complex or specific.
 2. Reusable and modular parts.
 3. Without too much need of refactoring.
 4. Brings a good user experience
 (fast, transitions, feedback, easy to use).
  23. 23. Challenges of 2016*. Premises.
  24. 24. Data synchronization between server and client/cache.
  25. 25. Performance.
  26. 26. Easy to develop/maintain.
  27. 27. Concurrency and Parallelism.
  28. 28. Offline.
  29. 29. Challenges.
 1. Synchronize data between client and server/cache.
 2. Performance.
 3. Easy to develop/maintain.
 4. Concurrency and Parallelism.
 5. Offline.
  30. 30. Time. Premises.
  31. 31. Time.
 1. Short term.
 2. Long term.
  32. 32. Not necessary to learn something too complex Modular and reusable parts Without too much need of refactoring Good user experience (fast, transitions, feedback, easy to use) Easy to develop/ maintain. Easy to develop/ maintain. Synchronize data between client and server/cache. Offline. Easy to develop/ maintain. Concurrency and Parallelism. Performance. Synchronize data between client and server/cache.
  33. 33. Short term Long term Good user experience (fast, transitions, feedback, easy to use). Good user experience (fast, transitions, feedback, easy to use). Not necessary to learn something
 too complex. Without too much need of refactoring. Modular and reusable parts.
  34. 34. I want do develop applications without worrying too much about learning something beyond technology,with reusable parts, that is easy to maintain and
 brings a good user experience.
  35. 35. We have to choose between.
 1. Programming concepts.
 2. API formats.
 3. Front-End Frameworks.
  36. 36. Concepts.
  37. 37. You have seen around.
 1. State.
 2. Stateless.
 3. Imperative.
 4. Functional.
 5. Passive.
 6. Reactive.
  38. 38. Imperative.
 1. Stateful.
 2. Passive.
  39. 39. Functional.
 1. Stateless.
 2. Reactive.
  40. 40. State. Concepts.
  41. 41. You are happy now, this is your state.
 
 State is a memory snapshot
 of a program’s part, at some
 point in time.
  42. 42. Imperative. Concepts.
  43. 43. This is the bossy style.
 
 I know who you are, I want you
 to do something for me. I change your state and I know that.
  44. 44. Passive. Concepts.
  45. 45. The same thing, but from the point of view of who receive orders.
 He is passive of receiving orders and it is exposed to others.
  46. 46. Reactive. Concepts.
  47. 47. The opposite of imperative and passive, goes together
 with functional. He explicitly says that it will react when something
 happens on others. No one gives him direct orders, he owns and controls himself.
  48. 48. Functional. Concepts.
  49. 49. The mathematic style.
 
 I define predictable functions,
 that just changes state from their own scope and never cause side effects (never change state out of themselves).
  50. 50. Stateless. Concepts.
  51. 51. Also goes with functional. 
 
 Says that the best way to avoid side effects is to not hold state,
 only transform and return.
  52. 52. reactivex.io/learnrx
  53. 53. Imperative.
 1. Stateful.
 2. Passive.
  54. 54. Functional.
 1. Stateless.
 2. Reactive.
  55. 55. Comparisons. Concepts.
  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. Allows more than one
 resource or entity per call.
  61. 61. RPC.
 1. Bad for caching.
 2. Coupled.
 3. One call per view. 4. Small responses.
  62. 62. REST. APIs.
  63. 63. example.com/list/1234 example.com/user/3
  64. 64. Each endpoint === one entity.
  65. 65. REST.
 1. Good for cache.
 2. Decoupled.
 3. Lots of calls per view. 4. Big responses.
  66. 66. GRAPH. APIs.
  67. 67. Dude.. just think
 about a 360 degree’s JSON.
  68. 68. Take a look afterwards.
 1. Netflix Falcor.
 2. Facebook Relay/GraphQL.
  69. 69. Comparisons. APIs.
  70. 70. What about 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. Conclusions.
  75. 75. zhou-yi.herokuapp.com
  76. 76. github.com/caiovaccaro/zhou-yi
  77. 77. Easy to develop + Short term + Not having to learn something too specific?
  78. 78. Imperative + RPC + Flux/Components.
  79. 79. Data synchronization + Performance +
 Long term + Reusable parts?
  80. 80. Functional + GRAPH +
 Flux/Components or Functional/Reactive.
  81. 81. Ok cool.. so I need to know how to choose between all those stuff then.
  82. 82. Can our application be
 framework independent?
  83. 83. Lunar. Conclusions.
  84. 84. Separate framework-code from application-code.
  85. 85. Leave your business logic independent of tools.
  86. 86. github.com/hugeinc/lunar
  87. 87. We do need abstraction layers, but we always need to know where technology is and the role of each tool.
  88. 88. You can help. Conclusions.
  89. 89. You can help.
 1. Parallelism solutions.
 2. Propose ways of offline working.
 3. How to change between frameworks.
 4. Make client data model easier.
 5. Find a better way to use APIs and SPAs.
  90. 90. Questions?
  91. 91. April 23th, 2016. R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com

×