Client-side Development 2016
6 likes2,679 views
The document discusses client-side development concepts for 2016. It covers background on how user interfaces have evolved to the web. Key concepts discussed include state, imperative vs functional programming, and reactive programming. API styles like RPC, REST, and GraphQL are compared. Popular frontend frameworks like Angular, React, and Vue are also mentioned. The document concludes that choices should consider whether the project requires learning something new or not, reusability, and handling data synchronization and performance over the short and long term. It suggests that separating application code from framework code can help ensure independence.
Client-side Development 2016
- 1. April 23th, 2016 R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com
- 2. Client-side Development 2016 Huge Brazil April 23th, 2016
- 3. 1. Background 2. One sentence 3. Premises 4. Concepts 5.APIs 6. Frameworks 7. Conclusions Agenda
- 4. Background.
- 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. 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.
- 10. If you don’t need any combination of: AJAX, Binding, Interactivity and Input/Output. You don’t need a SPA.
- 11. To not be a SPA is also Front-End, with its own challenges such as files/folders architecture, CSS organization, smart templates, etc.
- 12. Going back to Single Page Applications…
- 14. Technology Tool Javascript Angular Node.JS Express PHP Symphony Python Flask
- 17. One sentence.
- 22. 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.
- 23. Premises.
- 24. Not necessary to learn something too complex or specific.
- 25. Reusable and modular parts.
- 26. Without too much need of refactoring.
- 27. Brings a good user experience (fast, transitions, feedback, easy to use).
- 28. 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).
- 30. Data synchronization between server and client/cache.
- 31. Performance.
- 34. Offline.
- 35. Challenges. 1. Synchronize data between client and server/cache. 2. Performance. 3. Easy to develop/maintain. 4. Concurrency and Parallelism. 5. Offline.
- 36. Time. Premises.
- 37. Time. 1. Short term. 2. Long term.
- 38. 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.
- 39. 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.
- 40. 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.
- 42. We have to choose between. 1. Programming concepts. 2. API formats. 3. Front-End Frameworks.
- 43. Concepts.
- 44. You have seen around. 1. State. 2. Stateless. 3. Imperative. 4. Functional. 5. Passive. 6. Reactive.
- 47. State. Concepts.
- 48. You are happy now, this is your state. State is a memory snapshot of a program’s part, at some point in time.
- 50. 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.
- 53. 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.
- 57. 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.
- 61. 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).
- 65. Also goes with functional. Says that the best way to avoid side effects is to not hold state, only transform and return.
- 74. APIs.
- 75. APIs. 1. RPC. 2. REST. 3. GRAPH.
- 76. RPC. APIs.
- 78. Allows more than one resource or entity per call.
- 79. RPC. 1. Bad for caching. 2. Coupled. 3. One call per view. 4. Small responses.
- 80. REST. APIs.
- 82. Each endpoint === one entity.
- 83. REST. 1. Good for cache. 2. Decoupled. 3. Lots of calls per view. 4. Big responses.
- 84. GRAPH. APIs.
- 89. Dude.. just think about a 360 degree’s JSON.
- 90. Take a look afterwards. 1. Netflix Falcor. 2. Facebook Relay/GraphQL.
- 95. What about 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…).
- 107. Conclusions.
- 115. Easy to develop + Short term + Not having to learn something too specific?
- 116. Imperative + RPC + Flux/Components.
- 117. Data synchronization + Performance + Long term + Reusable parts?
- 118. Functional + GRAPH + Flux/Components or Functional/Reactive.
- 119. Ok cool.. so I need to know how to choose between all those stuff then.
- 121. Can our application be framework independent?
- 122. Lunar. Conclusions.
- 125. Leave your business logic independent of tools.
- 127. We do need abstraction layers, but we always need to know where technology is and the role of each tool.
- 129. 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.
- 130. Questions?
- 131. April 23th, 2016. R. Jardim Botânico 518 2º andar Rio de Janeiro/ 55 21 35540 3540 / hugeinc.com