I've seen the future

Talk I gave for JS group in Jönsköping, Sweden. May 7, 2014

Transcript

1. I’ve seen the future @HenrikJoreteg
2. JAVASCRIPT APPLICATIONS
3. WAIT?!
4. SERVER? COMMAND LINE? BROWSER?
5. WEB APPLICATIONS
6. WAIT?!
7. WHAT IS A WEB APP REALLY?
8. THE WEB HAS AN
9. RAILS/.NET/DJANGO
11. 1. REQUEST
12. 1. REQUEST 2. PROXY/MIDDLEWARE
13. 1. REQUEST 2. PROXY/MIDDLEWARE 3. HANDLER
14. 1. REQUEST 2. PROXY/MIDDLEWARE 3. HANDLER •DATABASE CALL
15. 1. REQUEST 2. PROXY/MIDDLEWARE 3. HANDLER •DATABASE CALL •TEMPLATING
16. 1. REQUEST 2. PROXY/MIDDLEWARE 3. HANDLER •DATABASE CALL •TEMPLATING •RETURN HTML
17. THAT’S A WEB APP!
18. WAIT?!
20. GMAIL?
21. GMAIL? FACEBOOK?
22. GMAIL? FACEBOOK? EVERNOTE?
23. GMAIL? FACEBOOK? EVERNOTE? DROPBOX?
24. GMAIL? FACEBOOK? EVERNOTE? DROPBOX? TALKY.IO?
25. THE WEB HAS CHANGED
26. "But, I’m not building Facebook"
28. 1. HTML INTERFACE
29. 1. HTML INTERFACE 2. API
30. 1. HTML INTERFACE 2. API 3. iOS APP
31. 1. HTML INTERFACE 2. API 3. iOS APP 4. ANDROID APP
32. AS SOON AS THERE IS MORE THAN A SINGLE WEB INTERFACE?
33. SOMETHING GREATER THAN A WEB APP
34. SO WHAT?
35. IT CHANGES YOUR ARCHITECTURE
36. LET’S TALK SCIENCE!
37. COMPUTER SCIENCE
38. #1 SEPARATION OF CONCERNS
39. #2 ENCAPSULATION
40. SO HOW DID WE DO?
41. 1. REQUEST 2. PROXY/MIDDLEWARE 3. HANDLER •DATABASE CALL •TEMPLATING •RETURN HTML
42. MAYBE NOT PERFECT…
43. …BUT IT GETS BETTER
44. …BY WHICH I MEAN WORSE
45. WE SEND JAVASCRIPT!
47. 1. CODE WITH OUR CONTENT
48. 1. CODE WITH OUR CONTENT 2. AJAX TO FETCH MORE DATA
49. 1. CODE WITH OUR CONTENT 2. AJAX TO FETCH MORE DATA 3. WE DO TEMPLATING AGAIN!
51. 4. JSON API
52. 4. JSON API 5. DASHBOARD APP
53. 4. JSON API 5. DASHBOARD APP 6. SUPPORT TOOL APP
54. 4. JSON API 5. DASHBOARD APP 6. SUPPORT TOOL APP 7. MOBILE WEB APP
56. WHAT IS THE ALTERNATIVE?
57. HOW DO WE SEPARATE CONCERNS?
58. API SERVERS SPEAK DATA
59. CLIENTS DO PRESENTATION
60. MOST CAPABLE UBIQUITOUS RUNTIME ON THE PLANET
61. WE SHOULD STOP TREATING IT LIKE A DUMB DOCUMENT RENDERER…
62. WEB APP iOS APP Mobile Web App HTML RSS JSON MAIN HTML INTERFACE JSON HTML PUBLIC API JSON FEED READERS 3RD PARTIES JSON ADMIN INTERFACE HTML
63. iOS CLIENT DASHBOARD JS CLIENT MAIN JS CLIENT 3RD PARTY CLIENT SERVICE INTEGRATION JSON SESSION API SERVICE API(s) REDIS RIAK SOLR SERVICE API(s) SERVICE API(s) SERVICE APIs
64. WHAT DO WE GAIN?
65. EASIER TO DISTRIBUTE WORK TO A TEAM
66. EASILY BUILD CLIENTS FOR NEW PLATFORMS
67. ISOLATE PERFORMANCE ISSUES
68. WAY EASIER TO: TEST
69. WAY EASIER TO: MAINTAIN
70. WAY EASIER TO: SCALE
71. WAY EASIER TO: SECURE
72. SOLVE SCALING ISSUES AT THE EXACT BOTTLENECK
73. EASILY BUILD VARIATIONS OF YOUR CLIENTS
74. A/B TESTING ANYONE?
75. SERVE CLIENT APPLICATION FROM STATIC SERVERS
76. WORK ON A CLIENT LOCALLY AGAINST PRODUCTION API
77. "That’s a nice theory, but how?"
78. SEND THE APP ITSELF TO THE BROWSER INSTEAD OF THE RESULT OF RUNNING IT
79. "You have to send the browser HTML!"
80. THE ENTIRE HTML FOR AND BANG: GET https://andbang.com/*
81. SO HOW DO WE BUILD THIS WAY?
82. {{ DO A DEMO, HENRIK! }}
83. HOT NEW JAVASCRIPT FRAMEWORK OF THE WEEK!
84. HOW DO YOU PICK?
85. WHERE DO YOU START?
86. andyet.com
87. ~27 DEVELOPERS GOBS OF JS APPS REALTIME APPS
88. HOW WE DECIDED WHAT TO USE:
89. GOALS
90. 1. BUILD GREAT APPS GOALS
91. 1. BUILD GREAT APPS 2. QUICKLY GOALS
92. 1. BUILD GREAT APPS 2. QUICKLY 3. WRITE JAVASCRIPT GOALS
93. 1. BUILD GREAT APPS 2. QUICKLY 3. WRITE JAVASCRIPT 4. HIGH LEVEL OF CONTROL GOALS
94. 1. BUILD GREAT APPS 2. QUICKLY 3. WRITE JAVASCRIPT 4. HIGH LEVEL OF CONTROL 5. INSANELY MODULAR/FLEXIBLE GOALS
95. 1. BUILD GREAT APPS 2. QUICKLY 3. WRITE JAVASCRIPT 4. HIGH LEVEL OF CONTROL 5. INSANELY MODULAR/FLEXIBLE 6. NOT TOO ABSTRACT GOALS
96. FOUR BIG PROBLEMS TO SOLVE:
97. 1. FETCHING/STORING STATE
98. 2. RENDERING HTML
99. 3. BINDING STATE TO DOM
100. 4. CLIENTSIDE ROUTING
101. A FEW SPECIFIC FRAMEWORKS:
102. AngularJS
103. 1. easy to start AngularJS
104. 1. easy to start 2. logic mixed into HTML AngularJS
105. 1. easy to start 2. logic mixed into HTML 3. you’re learning Angular, not JS AngularJS
106. 1. easy to start 2. logic mixed into HTML 3. you’re learning Angular, not JS 4. highly abstracted AngularJS
107. Ember
108. 1. Lots of decisions made for you Ember
109. 1. Lots of decisions made for you 2. Everything is "ember" as a base Ember
110. 1. Lots of decisions made for you 2. Everything is "ember" as a base 3. Lack of flexibility Ember
112. Backbone
113. 1. Basic building blocks Backbone
114. 1. Basic building blocks 2. Extremely flexible Backbone
115. 1. Basic building blocks 2. Extremely flexible 3. You have to solve more problems Backbone
116. We made HumanJS:
117. 1. Backbone as a base We made HumanJS:
118. 1. Backbone as a base 2. Stricter Models We made HumanJS:
119. 1. Backbone as a base 2. Stricter Models 3. Conventions for binding to views We made HumanJS:
120. HumanJavascript.com
121. What’s next?
122. Shh…
123. AMPERSAND.js
125. 1. Un-frameworky non-framework
126. 1. Un-frameworky non-framework 2. Backbone ripped apart
127. 1. Un-frameworky non-framework 2. Backbone ripped apart 3. Individual npm modules
128. 1. Un-frameworky non-framework 2. Backbone ripped apart 3. Individual npm modules 4. Insanely flexible
130. 5. Clear starting point
131. 5. Clear starting point 6. CommonJS + Browserify
132. 5. Clear starting point 6. CommonJS + Browserify 7. Directory of "sanctioned" modules
133. 5. Clear starting point 6. CommonJS + Browserify 7. Directory of "sanctioned" modules 8. IE9+ only
134. WE’RE BUILDING APPS WITH IT ALREADY
135. ampersandjs.com
136. QUESTIONS?
137. THANKS! @HenrikJoreteg