1. Clientside MVC: A Journey
Tom Cully
@TomDionysus

2. What is Clientside MVC? MVC – Model / View / Controller
MVC is a software architecture pattern used in producing user interfaces
Models, Views and Controllers provide separation of concerns
In use since the 70's in UIs and GUIs, from terminals to WIMP systems
Model
View
Controller

3. Advantages of MVC Separation of concerns Maintainability
Cleaner Architecture
Variants exist MVC / MVVM / MV* / MV-whatever

4. Differences with Serverside MVC
Serverside MVC for the web processes all data on the server, using the browser as a thin client.
The browser does very little processing, if any.
server process
Model
browser
View
Controller

5. Differences with Serverside MVC
Clientside MVC moves the MVC stack wholly or partially into the browser.
The server does either very little, or no, rendering.
CDN, Host Server, APIs
Browser
Model
View
Controller

6. Why use it?

7. Clientside MVC Advantages
Scalability
Rendering and presentation logic happens on client meaning massively reduced server load
Asynchronous UI means apps are a lot less 'chatty', calling server APIs only when necessary
Clientside apps exist mostly as static assets (HTML, CSS, JavaScript) allowing greater use of CDN tech.

8. and... Responsiveness and User Experience
Usually written to look and behave like a native desktop application. Users don't have to wait for page reloads to see changes.
Can be written to cope with erratic network connectivity
Can more easily provide a rich user experience

9. and....... Code separation and simplicity
Serverside code can be reduced to a set of clean, maintainable APIs
Use of a class-based clientside framework can radically simplify UI design and improve maintainability

10. Who's using Clientside?

11. Awesome!

12. Well, Almost.

13. So, What's the Catch? Browser Compatibility
Some frameworks go a long way to addressing this, however design and operation may still differ even between modern browsers
Can be especially problematic in corporate environments where older browsers may be mandated (IE6)

14. and... Large datasets Browsers limit memory available to scripts
LocalStorage etc. differs in capability / capacity / speed between browsers, platforms and devices
APIs often need to implement paging, partial retrieval and similar, which makes them more complex.

15. and......
The SEO Problem
If all content is rendered clientside, what about webcrawlers and other automated clients that don't run JavaScript?
Implementing graceful degradation increases architecture and application complexity.
Only early solutions exist (e.g. Mozart Concerto)

16. AND......... Developer Resistance
'I don't trust the browser/JavaScript.'
'But PHP just works. Why would I bother with that?'
'But Ruby/Rails just works.'
'We've been doing these things with X since the 90s. Why should we change now?'

18. The Bigcommerce Clientside MVC Journey

19. Bigcommerce circa 2009
BC pivots from Interspire Shopping Cart, a downloadable PHP hosted app as a product, to a SaaS platform
The PHP application becomes the core of all hosted Bigcommerce stores
JavaScript in only very minor use, the platform is all serverside PHP

20. Bigcommerce 2013: Beginnings
Existing code uses Backbone, jQuery and JavaScript to render parts of control panel pages
BC launches the Onboarding Wizard project, Operation Slick
Architecture and code begins the move to a dynamic, scalable set of services providing an API, for use with multiple client technologies

21. Migration Plans Start slow, test for response and uptake as we go
Introduce clientside views and controls one at a time
Overlay wizards and the like on top of the existing PHP rendered pages.
Improve and extend our existing APIs to communicate with the clientside app

22. Bigcommerce Mobile App
HTML5/CSS/JS/Backbone - PhoneGap for Android/iOS

23. Operation Slick
An 'Onboarding Wizard' to allow store owners to get setup quickly
Use of a clientside MVC technology
CDN asset deployment

24. Some Existing Framework Choices
And many, many, many more...

25. Frameworks are not created equal
Ember has cool templating (Handlebars) and data binding, but uses a runloop – at the time, performance was less than stellar with a large number of views.
Backbone was fast and simple, but required tons of boilerplate.
Angular.js extended HTML in ways which made some of our engineers uncomfortable.
CoffeeScript can be used with any JS framework, but we really wanted something that worked with its class system natively.
Several breaking changes as frameworks evolved and improved meant we had to throw away code.

26. not a happy time.

27. So we wrote our own. 100% CoffeeScript
Uses standard jQuery, Handlebars, Underscore libraries
Bidirectional data bindings with no runloop
Fast rendering
Boilerplate-free DOM binding
Pub/Sub Event system

28. Operation Slick Demo
Mozart
CDN Assets
Control Panel Overlay

29. And then we open sourced Mozart.
github.com/bigcommerce/mozart
@mozartio
Stack Overflow: mozart-mvc

30. Mozart Demos http://todomvc.com
Source:

31. The Road Ahead
Complete the migration to clientside for our dashboard and control panel
Further improve our APIs to support 3rd party developers
Make it as easy as possible for all developers to work with our platform in line with the 'Operating System of E- Commerce' vision

32. “How do I do all the cool things?”

33. How to choose a framework

34. How did all this become possible?
HTML5/CSS/JavaScript
JS as the new 'assembly language of the web' – Brendan Eich
CSS3 transitions and HTML5 canvas with hardware acceleration make complex 2D and 3D graphics possible

35. Whats Current? WebSockets and real time communication (Meteor)
WebGL and 3D (e.g. HTML5 Unreal Engine)

36. Thank you for listening
Demo Sources:
Tom Cully