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.

Using Ember to Make a Bazillion Dollars

829 views

Published on

This talk outlines why I believe that Ember solves many of the problems that we face as browser developers today. We aim to build rich dynamic applications, and some of the time we fail. Ember helps reduce friction by providing the right features at the right time. In particular, the router.

Published in: Technology
  • Be the first to comment

Using Ember to Make a Bazillion Dollars

  1. 1. Programming is easy
  2. 2. Programming is hard really fucking^
  3. 3. Browser programming is hard rendering engines are broken
  4. 4. Browser programming is hard
  5. 5. we must use Javascript inconsistent implementations
  6. 6. Everyone runs their own show we must use Javascript
  7. 7. Using to Make a Bazillion Dollars
  8. 8. @mikepack @zombidev Mike Pack
  9. 9. a little history
  10. 10. Simple Document rendering turned into dynamic applications
  11. 11. document.getElementById('id')!
  12. 12. document.getElementsByClassName('yo')!
  13. 13. spec implementations varied
  14. 14. so we built higher abstractions
  15. 15. $('#id')
  16. 16. $('.yo')
  17. 17. but higher abstractions didn’t help us organize code speak a common language manage datA
  18. 18. so what did we do?
  19. 19. we built higher abstractions
  20. 20. event/dom management Data organization basic routing
  21. 21. but higher abstractions didn’t help us understand architecture scale teams wrangle dependencies
  22. 22. so what did we do?
  23. 23. we built plugin abstractions backbone-relational.js
  24. 24. but plugin abstractions didn’t help with consistency stability community momentum
  25. 25. so what did we do?
  26. 26. we consolidated abstractions
  27. 27. my favorite features ! ! object model computed properties two-way data binding router
  28. 28. object model
  29. 29. we started with basic objects
  30. 30. {! firstName: 'Mike',! lastName: 'Pack'! }
  31. 31. but basic objects didn’t give us events shared behavior taxonomy
  32. 32. Person = Ember.Object.extend! firstName: 'Mike'! lastName: 'Pack'! fullName: ->! [! @get('firstName')! @get('lastName')! ].join(' ')
  33. 33. person = Person.create()! ! person.fullName() #=> Mike Pack
  34. 34. You can be notified when things change
  35. 35. Person = Ember.Object.extend! firstName: 'Mike'! lastName: 'Pack'! firstNameChanged: (->! alert('OK, got it!')! ).observes('firstName')
  36. 36. You can be notified of object lifecycle events
  37. 37. Ember.Object.extend! doSomethingSpecial: (->! alert('Object is ready!')! ).on('init')
  38. 38. You can override properties
  39. 39. You can monkey patch
  40. 40. You can use mixins
  41. 41. turtles all the way down
  42. 42. @bcardarella
  43. 43. savings ! events mixins convention ! 100 hours/year
  44. 44. computed properties
  45. 45. person = Person.create()! ! person.get('fullName') #=> Mike Pack! person.set('lastName', ‘Katz')! ! person.get('fullName') #=> Mike Katz
  46. 46. You could write computed properties like…
  47. 47. Person = Ember.Object.extend! ...! fullName: -> ...! setLastName: (value) ->! @set('lastName', value)! @set('fullName', @fullName())
  48. 48. person = Person.create()! ! person.get('fullName') #=> Mike Pack! person.setLastName('Katz')! ! person.get('fullName') #=> Mike Katz
  49. 49. but this doesn’t scale. Consider thousands of these properties
  50. 50. Person = Ember.Object.extend! ...! fullName: (->! [! @get('firstName')! @get('lastName')! ].join(' ')! ).property('firstName', 'lastName')
  51. 51. You can create a dependency tree
  52. 52. Person = Ember.Object.extend! fullName: (->! ...! ).property('firstName', 'lastName')! ! address: (->! ...! ).property('fullName') depends on fullName^
  53. 53. You can do this as many times as you’d like
  54. 54. will sync all your changes using the run loop
  55. 55. savings ! data manipulation dependency management run loop ! 200 hours/year
  56. 56. two-way data binding
  57. 57. we started by rendering server side
  58. 58. SERVER browser screen state as HTML render html action eg: click post/put/patch/delete stateless HTTP state
  59. 59. this is called statelessness
  60. 60. it’s predictable, but slow
  61. 61. stateful programming is hard!
  62. 62. you must present state to the user respond to user input manage internal events update urls sync with the server
  63. 63. SERVER browser screen state as JSON render html action eg: click post/put/patch/delete statefulness ember ember data persistencehydration into memory state state state
  64. 64. person = Person.create() in the route
  65. 65. person = Person.create() in the route in the template <h1>Wassup, {{fullName}}?</h1>
  66. 66. person = Person.create() in the route in the template <h1>Wassup, {{fullName}}?</h1> rendered to the browser <h1>Wassup, Mike Pack?</h1>
  67. 67. the view stays in sync with whatever’s in memory
  68. 68. inversely, objects in memory stay in sync with the view
  69. 69. {{input value=lastName}} in the template
  70. 70. {{input value=lastName}} in the template rendered to the browser Pack Katz last name last name
  71. 71. {{input value=lastName}} in the template in memory person.get('fullName') #=> Mike Katz rendered to the browser Pack Katz last name last name
  72. 72. think about user interactions, not wiring things up
  73. 73. savings ! view updates in-memory updates handlebars ! 100 hours/year
  74. 74. router
  75. 75. the web is just rectangles nested inside rectangles
  76. 76. the web is just rectangles nested inside rectangles
  77. 77. the web is just rectangles nested inside rectangles
  78. 78. html is tags nested inside tags <article>! <header>! <h1>Ember!</h1>! </header>! <p>! Sweet Embers!! </p>! </article>
  79. 79. CSS is styles nesting inside styles article {! header {! h1 {! font-size: 18px;! }! }! p {! padding: 10px;! }! }
  80. 80. we started replacing nested rectangles
  81. 81. we started replacing nested rectangles
  82. 82. scoping DOM manipulations is hard
  83. 83. scoping DOM manipulations is hard so we rerender at a lower fidelity, causing flicker
  84. 84. wrangling events attached to Dom nodes is hard
  85. 85. wrangling events attached to Dom nodes is hard so we delegate to higher nodes, slowing interactions
  86. 86. persisting page state to the url is hard so we settled for poor urls, degrading user experience
  87. 87. what if you could have amazing view management and awesome urls…
  88. 88. just use this one weird trick
  89. 89. url nesting often corresponds to view nesting
  90. 90. /
  91. 91. /people
  92. 92. /people/mike
  93. 93. /people/mike/posts
  94. 94. examples
  95. 95. /mikepack/nerdbox
  96. 96. /mikepack/nerdbox/issues
  97. 97. /mikepack/nerdbox/issues/new
  98. 98. /mikepack/nerdbox
  99. 99. /mikepack/nerdbox/issues
  100. 100. /mikepack/nerdbox/issues/new
  101. 101. /home
  102. 102. /../appid
  103. 103. /../appid
  104. 104. /../appid/date…date
  105. 105. /../appid/date…date/nthweek
  106. 106. /../
  107. 107. /../appid
  108. 108. /../appid/date…date
  109. 109. /../appid/date…date/nthweek
  110. 110. the key is to think like a nested… url rectangle node style
  111. 111. nesting has context
  112. 112. /people /people/mike /people/mike/posts /people/mike/likes
  113. 113. Router.map ->! @resource 'people', ->! @resource 'person', path: '/:person_id', ->! @route 'posts'! @route 'likes'
  114. 114. /people /people/mike /people/mike/posts /people/mike/likes
  115. 115. /people /people/mike /people/mike/posts /people/mike/likes
  116. 116. /people /people/mike /people/mike/posts /people/mike/likes
  117. 117. /people /people/mike /people/mike/posts /people/mike/likes
  118. 118. this is extremely powerful think about page structure, not dom manipulations
  119. 119. this is extremely powerful forget about cleaning up event handlers
  120. 120. get url support for free this is extremely powerful
  121. 121. focus on building awesome apps quickly this is extremely powerful
  122. 122. savings acute dom manipulations event binding/unbinding url management state management ! 250 hours/year
  123. 123. object model = 100 computed properties = 150 two-way data binding = 100 router = 250 total = 600 hours/year
  124. 124. Your financial plan ! ! ! !
  125. 125. Your financial plan ! 600 hours/year savings ! !
  126. 126. Your financial plan ! 600 hours/year savings 600 x $200/hour = $120k !
  127. 127. Your financial plan ! 600 hours/year savings 600 x $200/hour = $120k $120k x 2 devs (pair) = $240k
  128. 128. Your financial plan because your startup is the next big thing… ! ! ! ! !
  129. 129. Your financial plan because your startup is the next big thing… ! $240k x 50 pairs = $12M ! ! !
  130. 130. Your financial plan because your startup is the next big thing… ! $240k x 50 pairs = $12M $12M x 3 years = $36M ! !
  131. 131. Your financial plan because your startup is the next big thing… ! $240k x 50 pairs = $12M $12M x 3 years = $36M ! because you’re first to market, thanks to ember…
  132. 132. Your financial plan because your startup is the next big thing… ! $240k x 50 pairs = $12M $12M x 3 years = $36M ! because you’re first to market, thanks to ember… You spend your $36M to buy all competition
  133. 133. BOOM!
  134. 134. BAZILLION DOLLARS
  135. 135. @mikepack @zombidev thanks!

×