Javascript spaghetti stirtrek_5_17


Published on

Published in: Technology
1 Comment
  • I attended this presentation at Stir Trek. It was an awesome presentation and I appreciated Jared's time and attention to sharing important information with a presentation that obviously took a lot of work to put together. Joe Kunk, Microsoft MVP Visual Basic
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Javascript spaghetti stirtrek_5_17

  1. 1. Building Rich User ExperienceswithoutJavaScript Spaghettiby Jared
  2. 2. About me
  3. 3. Traditional Web DevelopmentWeb assets are created last to glue together things.Stakeholders, architects and developers define the“real” application.The application is built model first (from the DB up).
  4. 4. Traditional Web DevelopmentThe design is focused on making the CRUD pretty, notusableThe design of the UI/UX happens in Photoshop... if ithappens at all.Most of the application is just CRUD.
  5. 5. We have a widgetstableWe need awidgetsscreen!
  6. 6. Traditional Web Development“Advanced” web developers write lots of unorganizedbits of jQuery.Most user interactions result in lots of POSTS backto the server.JavaScripts are something someone download
  7. 7. We have a widgetstableWe need awidgetsscreen!Make sure youadd a date pickerAnd a lighbox!
  8. 8. JavaScript: Not a “Real” LanguagePatternless design.Built as a glue to bind pieces together, not as a corecomponent of the application.Not thought through like server-side code.
  9. 9. Not Real? Why?A lot of development tools traditionally hid the JS behindconfigurable controls.Libraries like jQuery make it really easy to pile on lots oflittle events.JS used to be a tool for doing image rollovers.
  10. 10. Is That A Problem?In a workflow-based application it falls apart.For form-based apps that was mostly fine.Customized, reusable controls and a modularapplication design needs something more.
  11. 11. Questions So Far?
  12. 12. A Typical Product LifecycleSomewhat dramatized...
  13. 13. Designer Developer
  14. 14. We need thisfeature
  15. 15. I got this
  16. 16. ?
  17. 17. Tweaking time...
  18. 18. I got anothergreat idea
  19. 19. Now you tellme
  20. 20. The developer bolts on some more code
  21. 21. And anotherthing...
  22. 22. grrr
  23. 23. We don’t‘really’need this
  24. 24. Uh, yeah wedo
  25. 25. The developer bolts on some more code
  26. 26. Some time passes‘Some time’ is defined as:Just long enough that the developer doesn’t rememberexactly how his original code works.
  27. 27. I’ve got a newfeature
  28. 28. Angry developerscan really do this.IT managers bewarned.
  29. 29. Protective Beret
  30. 30. More messy code
  31. 31. The last bugOh wait, one more
  32. 32. Finally(14 tests ought to be enough for anybody)
  33. 33. The next day...
  34. 34. Two weeks pass.
  35. 35. I’ve got a newfeatureGahh!
  36. 36. No developers were harmed in the makingof this dramatic reenactment.
  37. 37. Poor design patterns+ crappy code= JavaScript spaghetti
  38. 38. Why does this happen?
  39. 39. Some Reasons• JavaScript isn’t real code• We don’t treat client side things as real features• We can’t easily test it• We don’t like writing it• It behaves differently in different browsers** Or at least it used to
  40. 40. This really all boils down to one thing.We developers suck.
  41. 41. Three JavaScript PrinciplesPush events, not stateWrite small, discrete bits of codeDecouple everything
  42. 42. Decouple EverythingApply your OO best practices here too.Remove dependencies between objects.Start thinking about UI pieces as individual JS objects.
  43. 43. Small Chunks Of CodeEven if you don’t test everything, learning how towrite testable code means learninghow to write better codePut the rest of the stuff in classes that you can test.Separate DOM dependent stuff into a single layer.
  44. 44. Push Events, Not StateInform other controls that “X happened to Y”,not “Y is in X state”Let controls worry about their own state.Know about the Law of Demeter.
  45. 45. Writing Better JavaScriptFind the tools that make your life easier.Use the design patterns you already know.Leverage language features whether JS has them or not.
  46. 46. Language FeaturesKeep state inside of the objects and expose methods.Objects have state and behavior.JavaScript loves its objects. Create them to representpage elements.
  47. 47. Language “Features”Consider using namespaces.
  48. 48. JavaScript Namespacing
  49. 49. Language “Features”Use inheritance or faux subclassing.Consider using namespaces.
  50. 50. JavaScript Prototyping
  51. 51. Coffeescript Classes
  52. 52. Language “Features”Pass JSON around asynchronously.Use inheritance or faux subclassing.Consider using namespaces.
  53. 53. Design Patterns
  54. 54. Mediator Pattern“The essence of the Mediator Pattern is to ‘Define anobject that encapsulates how a set of objects interact.Mediator promotes loose coupling by keeping objectsfrom referring to each other explicitly, and it lets youvary their interaction independently.’”-Design Patterns: Elements of Reusable Object-Oriented Software
  55. 55. NavControlMediatoritemSelected()Events from someother objectunselectAll()
  56. 56. Observer Pattern"Define a one-to-many dependency between objects sothat when one object changes state, all its dependentsare notified and updated automatically."-Design Patterns: Elements of Reusable Object-Oriented SoftwareThink jQuery $(‘.something’).click()
  57. 57. NavControlMediatoritemSelected()Events from someother objectunselectAll()viewModel
  58. 58. Tools & Frameworks
  59. 59. KnockoutMagic.Setup a template with some markup binding it.Setup a JavaScript object with some KO code.
  60. 60. A KO WarningIt’s really easy to go overboard with KO events.I prefer to use KO for the VM binding (observables andcomputeds) but rely on jQuery for events.jQuery’s .on() binding and a good understanding of‘this’ makes for much cleaner events.
  61. 61. BackboneViews help you control the visual rendering.Routers help you organize page flow.While KO is Model < > View magic, Backbone is structure.Models help you keep track of state.
  62. 62. Backbone Use Case
  63. 63. What about all the otherframeworks?
  64. 64. Pub/Sub + Fairy Dust = Service BusPub/Sub is great to make sure events propagate.It starts to get brittle with lots of different controls.
  65. 65. Way Too Much Pubbing and Subbing
  66. 66. Service BusYour controls are then only coupled to a single thing.Controls that want to communicate speak through it.A service bus is another layer that sits outside controls.
  67. 67. Postal.js
  68. 68. Service Bus + Mediator• Controls no longer need to know about others.• We can remove/replace controls individually.• We can add controls that listen to the same eventswithout modifying the publisher.• We can re-use pieces more easily because they workin a standard way.
  69. 69. NavControlMediatoritemSelected()Events from someother objectunselectAll()viewModelReportMediatoritemChanged()unselectAll()viewModelService Bus
  70. 70. NavControlMediatoritemSelected()Events from someother objectunselectAll()viewModelReportMediatoritemChanged()unselectAll()viewModelService BusHistoryControl
  71. 71. Service BusTeamControlGets team changedmessage, makes AJAXcall for this team’s data,rewrites team with templateNo view model
  72. 72. Service Bus
  73. 73. TestingTry to have layers of your application’s JS that don’ttouch any HTML elements.Store data in models inside individual controls and testthat published messages change the state of thosemodels correctly.
  74. 74. Underscore
  75. 75. Underscore
  76. 76. Underscore w/ Coffeescript
  77. 77. What Else?I don’t have a third bullet point hereBrowser DebuggersTemplates
  78. 78. A Typical Product LifecycleRound Two
  79. 79. We need thisfeature
  80. 80. I got a fewquestions
  81. 81. ?
  82. 82. Tweaking time...
  83. 83. I got anothergreat idea
  84. 84. Ok, Cool
  85. 85. And anotherthing...
  86. 86. Done.
  87. 87. Two weeks pass...
  88. 88. I’ve got a newfeature
  89. 89. No worries.
  90. 90. Wha? Ohhhk.
  91. 91. A short time later...
  92. 92. Examples
  93. 93. Questions?
  94. 94. Special thanks toHe did the frame artBlame me foreverything else
  95. 95. My Stuff@jaredthenerdjfaris@gmail.com