Successfully reported this slideshow.
Your SlideShare is downloading. ×

Single Page Applications - Desert Code Camp 2012

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 34 Ad

Single Page Applications - Desert Code Camp 2012

Download to read offline

Slides from my presentation on Single-Page Applications at Desert Code Camp 2012.

The event was held on November 17th, 2012 at Chandler-Gilbert Community College.

http://nov2012.desertcodecamp.com/session/565

Slides from my presentation on Single-Page Applications at Desert Code Camp 2012.

The event was held on November 17th, 2012 at Chandler-Gilbert Community College.

http://nov2012.desertcodecamp.com/session/565

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to Single Page Applications - Desert Code Camp 2012 (20)

Advertisement

Single Page Applications - Desert Code Camp 2012

  1. 1. SINGLE-PAGE APPLICATIONS Should you make the shift? Adam Mokan Desert Code Camp Nov 17, 2012
  2. 2. Adam Mokan Sr Application Architect Five9, Inc @adammokan
  3. 3. WHAT DEFINES A SINGLE-PAGE APPLICATION?
  4. 4. KEY CHARACTERISTICS • No reload or ‘refresh’ within the user interface • User experience similar to Flash and Java • Much more ‘state’ and logic on the client • Gmail is a good example
  5. 5. WHAT ARE THE GAINS? • Deployment ease • Feature-rich UI • No plugins • Cross-platform and device • Web browser as a runtime • HTML5, CSS3, Web Sockets*
  6. 6. GAINS OFTEN NOT CONSIDERED • REST API can be consumed by other clients and makes a great integration point. • Flexibility to shift your application/UI in directions not considered. • Many client distribution options. • Parallel development opportunities.
  7. 7. IT’S NOT FOR EVERYONE Yet
  8. 8. CONSIDERATIONS • How ready is your team? • Doyou have a JSON-based REST API? • How much JavaScript experience? Especially over the past couple years. • Do you have specific browsers or platforms to target?
  9. 9. FIRST STEP IDEAS • Dashboard interfaces • Portions of a larger application for use on mobile or tablets • A ‘todo’ list ( I am not being serious here ) If this idea is new to you and your team, start small.
  10. 10. WHICH FRAMEWORK???
  11. 11. WHICH FRAMEWORK??? • Backbone.js • Spine.js • Knockout.js • Ember.js • and hundreds more!
  12. 12. ‘Todo’ examples only go so fa r... http://todomvc.com But they are beneficial
  13. 13. WHAT ARE WE USING ? • Backbone.js (base lib) • Backbone.Marionette (application framework, composite views, and more) • Handlebars.js (view templating) • AMD/RequireJS (dependency management, module loading) • Rivets.js (UI binding/Observables)
  14. 14. WHAT ARE WE USING ? • Backbone.js (base lib) Backbone.js is like a toolbox • Backbone.Marionette with a few ba sic items in it (application framework, composite . views, and more) You will not b uild a skyscra without addit per • Handlebars.js (view templating) ional knowled specialty tool ge, s, and manpo • AMD/RequireJS (dependency wer. management, module loading) • Rivets.js (UI binding/Observables)
  15. 15. USE THE ‘LEGO’ APPROACH
  16. 16. THINGS TO PLAN FOR • Plan for shifts in client-side technology. • You will spend considerable time refactoring. • Ifin a Scrum environment, plan time for refactoring every other sprint or so. • Set proper expectations with stakeholders and management.
  17. 17. DEVELOP YOUR TEAM • Invest in learning and enable developers to do the same • Try to keep up, but don’t expect to follow everything. • Keep moving forward • Even if things are not perfect, because they will not be! • Extract what works and refactor. • Step back and look at your development workflow. • What can be improved?
  18. 18. TOOLING Optimize Your Workflow
  19. 19. TOOLING • Browser Dev Tools • JavaScript console • Debugging • Builds • File Concatenation • File Minification • JavaScript Transcompilers • CoffeeScript • TypeScript • Node.js • It’s not only useful for 4 line web servers
  20. 20. HOW WE HAVE HANDLED THE BUILD PROCESS • Custom CLI tool built upon Grunt.js • Evaluated Google’s Yeoman and many others • Focused on consistency across teams http://gruntjs.com/
  21. 21. EXAMPLE OF A FULL-FEATURE SYSTEM • Brunch http://brunch.io/ • Application ‘skeletons’ or boilerplate templates • JavaScript, CoffeeScript, and others • Multiple frameworks, but primarily Backbone.js • Combines project layout, builds, test runners, and dev server
  22. 22. But the re are others! • Backbone Boilerplate • Google Yeoman • Ember.js
  23. 23. MODULAR CODE Plan for disaster
  24. 24. THE OLD APPROACH • LargeJavaScript files crossing multiple concerns • Dependency chain managed manually
  25. 25. TODAY • DiscreteJavaScript files and structure based upon logical area of application • Dependency management managed by a module loader
  26. 26. AMD & REQUIREJS
  27. 27. WHAT AMD/REQUIREJS HELPED US WITH • Difficult and/or complex dependency issues • Created a code-base that is easier for new developers to pick up • Flexible build strategies
  28. 28. LOOSE COUPLING
  29. 29. MEDIATORS & EVENT AGGREGATORS Avoid direct communication between modules Look for bad patterns developing between view modules, in par ticular
  30. 30. TESTING • Jasmine for unit testing • Selenium Webdriver for integration testing • This has been neglected, but is getting better
  31. 31. RESOURCES MENTIONED A bit.ly bundle with links to frameworks and tools mentioned in addition to a couple fairly new books. http://bit.ly/dcc-single-page-app-resources
  32. 32. THANK YOU ! Adam Mokan @adammokan

Editor's Notes

  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

×