Your SlideShare is downloading. ×
  • Like
Testable client side_mvc_apps_in_javascript
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Testable client side_mvc_apps_in_javascript


Overview of some technologies I've been looking at in the past few weeks

Overview of some technologies I've been looking at in the past few weeks

Published in Technology , Design
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • Serverside technology and jobs Serverside technology and vendor lock-in Serverside technology and legacy Possible issues with browser environments becoming outdated quickly Probably a good thing though
  • Your database operations should be abstracted anyway Persistence &  Caching     if the client has already downloaded that data why do they need to download it again Client-side prediction - quake Client should do anything it can do easily.
  • in a quick bit of research, looks like less than 5%, more IE5.5 users
  • Doesn't need to be complicated don't let it scare you away from making an awesome app  There's always a way to fall back nicely Regressive Enhancement
  • One of the best things about javascript is how fast it moves. Since beginning this 2 months ago, the hardest part has been selecting the right tools.  Modernizer is a HTML5 shim and a feature detector HTML5 Boilerplate is a shim and a CSS reset also includes a bunch of css stubs. it's a little bloated and to get started you may want to go for something a little more lightweight
  • Variables Mixins Cross-browser Templates
  • CSS not included
  • No Tests,  Bugs around every corner No guarantee that the app actually works Rigorous manual testing means testing doens't happen Unprofessional Documentation The original developer(s) only person who can fix bugs without inducing homicidal rage Documentation gets out of sync if it's too heavy only when totally necessary "Refactoring? Just write it well the first time" Code gets worse with time Urge to rewrite each piece of software every 6 months Knee-jerk Methodology Always in crisis mode Impossible to keep deadlines Overworked staff Minimal technology options Sticking with what you know Don't fix it if it ain't broke  When all you have is a hammer everything looks like a nail
  • There are others but these ones are most general. Allows you to identify 'code smells' in any language Surprising how many people don't read this kind of material These books make it easier to communicate ideas and me not sound like a madman with strange ideas designed to ruin projects


  • 1. Testable, client-side MVC apps in Javascript Demo using Spine, Jasmine, & node.JS
  • 2. Motivation
      • Browser environment is becoming increasingly powerful
        • 'Serverside for everything' exists because there was no other choice
        • Flash platform no longer required/ideal for rich interaction 
      • Server infrastructure is expensive
        • Push as much work onto the client as possible
        • Less importance on what server-side tech you select
        • Unnecessary to talk to server for every action
      • More responsive interaction
        • Smoother UX -> better customers*
      • Web applications not web sites
        • Web browser is (mostly) cross-platform
    • *
  • 3. Thin-Server Architecture
    • Server Responsibilities
      • Persistence
        • Storage & retrieval of unformatted data
        • Sessions
      • Validation
        • Sanity
        • Security
      • Resource serving
        • Modules
        • Images
        • DRY HTML
        • CSS
      • Handling/reporting state
      • SEO/Accessibility
    • Client Responsibilities
      • Behaviour
        • Navigation
        • User Prompt
      • Layout
        • Visual Hierarchy
        • Theme
      • Data Presentation
        • Data (e.g. JSON)  ->  HTML via templates
      • Pseudo Persistence
        • Caching
        • Processing (eg filtering)
      • Validation
      • The eye candy is the application is the eye candy
  • 4. Accessibility?
      • Premature optimisation.
      • Make something cool first.
      • Simple to achieve later, IF you need it
  • 5. Graceful Degredation?
      • Premature optimisation. 
      • Make something cool first. 
  • 6. Give your code a fighting chance
    • Polyfills
        •   "A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will."
    • HTML5 + Shim/Shiv
    • CSS Reset
  • 7. Add some structure
    • MVC
        • Backbone
        • Spine
    • Tests
        • jasmine
          • jasmine-node
        • expresso
        • vows
  • 8. Visuals should be easy and fun
    • A language that compiles to CSS
        • stylus
        • sass
    • A language that compiles
    •   to HTML
        • jade
        • haml
    • Language that cross-browserizes your css & adds cool stuff
        • nib
        • Compass
    • Templating system for lists
  • 9. Optimise your resources
    • Image Reduction
        • via YSlow
    • JS Reduction
        • Google Closure Compiler
        • UglifyJS
    •     CSS Reduction
        • YUICompressor
  • 10. Familiar?
      • Out of date tests, or none at all
      • Out of date documentation, or none at all
      • "Refactoring? Just write it well the first time"
      • Knee-jerk Methodology
      • Minimal technology options, from 5+ years ago
  • 11. Self Improvement
  • 12. CommonJS
      • Community Driven
      • The W3C of Javascript
      • Define specs for
        • console
        • modules
        • assert
        • packages
      • Module spec 
  • 13. Loading Modules
      • Load modules with the CommonJS require() function
      • RequireJS = async require()
      • Compare with HeadJS
      • Transparent, client-side require: Stitch/Browserify, – dependency on nodeJS though
      • In-browser support not ideal, but manageable - workarounds available
    • //commonjs synchronous require
    • var module = require( 'moduleName' )
    • //requirejs asynchronous require
    • var module;
    • require( 'moduleName' , function (loadedModule) {
    •      module = loadedModule;
    • })
    • // headjs has no concept of commonjs modules
    • head.js( "moduleName.js" , "myOtherModule.js" , function () {
    •      // module loaded
    • });
    • <head>
    • <script src= &quot;/mymodule.js&quot; ></script>
    • <script src= &quot;/myOtherModule.js&quot; ></script>
    • <script src= &quot;/YAM.js&quot; ></script>
    • <script src= &quot;/ilovemodules.js&quot; ></script>
    • <script>
    •        // ewww. Polluting the global namespace?!
    •        myModule.use()
    • </script>
    • </head>
  • 14. CommonJS Modules
      • Avoid naming collisions
      • Wraps module in a closure, keeping the module's internals private
      • Encourages Good Practice
      • Exposes properties through the special module.exports object
    // define my module var Me = {       name : &quot;Tim&quot;      ,doDishes : function () {          return false      } } //export module module.exports = Me;
  • 15. Resources
    • nodeJS Patterns
    • Mastering Node
    • Javascript Templating
  • 16. Resources
    • Polyfills