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.

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.

8. Client-side === SPA.

9. Or UniversalJS.

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…

13. Technology x Tool.

14. Technology Tool
Javascript Angular
Node.JS Express
PHP Symphony
Python Flask

16. medium.com/@caiovaccaro

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

29. Challenges of 2016*.
Premises.

30. Data synchronization between
server and client/cache.

31. Performance.

32. Easy to develop/maintain.

33. Concurrency and Parallelism.

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.

45. Imperative.
1. Stateful.
2. Passive.

46. Functional.
1. Stateless.
2. 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.

49. Imperative.
Concepts.

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.

52. Passive.
Concepts.

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.

56. Reactive.
Concepts.

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.

60. Functional.
Concepts.

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

64. Stateless.
Concepts.

65. Also goes with functional.
Says that the best way to avoid
side effects is to not hold state,
only transform and return.

67. reactivex.io/learnrx

68. Imperative.
1. Stateful.
2. Passive.

69. Functional.
1. Stateless.
2. Reactive.

70. Comparisons.
Concepts.

74. APIs.

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

76. RPC.
APIs.

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

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.

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

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.

91. Comparisons.
APIs.

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

102. medium.com/@caiovaccaro

107. Conclusions.

109. zhou-yi.herokuapp.com

114. github.com/caiovaccaro/zhou-yi

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.

124. Separate framework-code
from application-code.

125. Leave your business logic
independent of tools.

126. github.com/hugeinc/lunar

127. We do need abstraction
layers, but we always need
to know where technology
is and the role of each tool.

128. You can help.
Conclusions.

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