Backbone Implementation 2.0

[nicoburns]

So continuing on from #87, I thought it would be useful to have another master bug for the Backbone architecture and implementation in the client. One of the big issues in terms of features is the fact that the admin interface is not yet a single-page app. However, when considering how to fix this, I came across a number of things which I believe need to be addressed in order to implement this cleanly.

Really these should be separate issues. But as the solutions to each affect the solutions to the others, I thought it made more sense to discuss them together.

Issues with the current implementation

1. No memory management for views (views are never destroyed)
2. Views are doing transitions (animations) manually
3. Routing
   • Sub-sections (e.g. preview post in the mobile view) don't have their own backbone routes
   • Handling of links in the mobile view is handled in a global file for all views (mobile-interactions.js)
   • Views are changing the route manually ( e.g. https://github.com/TryGhost/Ghost/blob/master/core/client/views/settings.js#L62)

Proposed solutions

1. View memory management

EITHER use the backbone.layoutmanager plugin. Advantages: Established and stable. Adds a setView function to backbone views which will automatically cleanup replaced views. Disadvantages: Contains a lot of functionality we don't need.

OR Create a Ghost.Region view (extends from Ghost.View) with a setContentView function or similar, which will automatically cleanup the current "content view", and insert the new one. Advantages: minimal code. Disadvantages: We are duplicating the functionality of an established plugin.

Based on Ghost's current need for view management (fairly minor), I would probably suggest the second option, but the LayoutManager wouldn't be a bad option either and could be more future proof.

2. Views are doing transitions (animations) manually

Create a Ghost.RegionGroup view. i.e. an entity with a function which accepts a view, and will automatically render and animate that view, and cleanup the old view. Ghost.RegionGroup would depend on Ghost.Region.

Example that I currently use: https://gist.github.com/nicoburns/6772469. This is a complicated example which supports view caching and depends on renderloop (a simple requestAnimationFrame wrapper) in order to support JavaScript based animation. It could be simplified a lot if we only needed support for CSS transitions.

3. Routing: (Sub-sections don't have their own backbone routes, etc)

Use the Backbone.Activities plugin. Essentially this would mean adding controllers ("Activities") to our app. This plugin is designed specifically to deal with the issues that arise in responsive backbone apps which we are hitting up against (e.g. that routes need to map to different views for different mobile and desktop layouts). The latest version (0.8) hasn't been published (because the docs are currently outdated), but it is very stable (it's been tested on multiple apps with tens of thousands of users each), and I could get it released and documented as part of it's inclusion in Ghost.

Disclaimer: I didn't create this plugin, but I have made significant contributions to it. That said, I genuinely believe it is the best solution for responsive Backbone apps. I can write a quick proof of concept if you want to see what Ghost+Activities would look like.

Summary

Really there are two proposed changes here:

1. The addition of more advanced base views which handle memory management and animation.
2. The addition of controllers "activities" which allow us to abstract views from routes, clearly define separate code paths for the mobile and desktop views, and eliminate routing code from views.

I think these two changes would really help to clean up our Backbone architecture, and make it a lot easier to add new views in the future.

[ErisDS]

I haven't read this thoroughly, so am not responding to anything other than the opening of a useful discussion about Backbone, and I wanted to throw a couple of thoughts into the mix.

1. Do we actually want to stick with Backbone? I still think it's the most popular framework and therefore good for open source, but I'm not convinced it's the best. We're building a set of fancy forms and currently have no data binding tools - meaning messy code that's prone to bugs.
2. Is a full one-page app, with everything rendered on the client side, what we actually want to end up with?
   My opinion is a categorical "no". At the moment we're mitigating some of the problems of client side rendering by mixing it up, that's not the right solution either. What we want to do is have an app that is completely rendered server side first, and then taken over and enhanced on the client side. That means we need to come up with means to share templates and other code between the client and server side. We need to do something like https://github.com/airbnb/rendr

[JohnONolan]

This is absolutely a discussion for post-public-launch when we come to speccing out the 0.4 and 0.5 milestones - needs a meeting and discussion between quite a few people. GH is not the place for this as we're still at the "what should we do?" stage rather than "how should we do it?"

[nicoburns]

@JohnONolan I thought 0.4 was the first public release... I'll leave it to you to organise such a meeting? I'm thinking that we should look to produce a diagram like https://github.com/TryGhost/Ghost/wiki/Tech-architecture-vision which also includes details of the client's architecture.

@ErisDS

1. I think the biggest plus for Backbone is that it is fairly minimal, and doesn't force you to use new programming paradigms like Ember and Angular seem to. Also, Backbone has an awesome plugin ecosystem. Not doing lots of magic can be a good thing for performance too.
2. I think the ideal is probably that the first page load serves the base part of a single-page app (main libraries + page loading code) and the content for the first page, and then subsequent page loads only load the content. The base part could be a separate script so that it could be cached... Alternatively, we could keep the mobile website strictly server rendered, and offer a "single-page style" wrapped web app (using mostly the same codebase) as an alternative for mobile users.

For now the important thing is probably that as much of our code as possible will run on both the client and server, which should give us a lot of flexibility in terms of where we decide to run it, when we decide. IMO this is where having a formal module system on the client is really helpful, as it allows you require the same modules that are used on the server side on the client side.

Rendr look like they have the right idea, but as they admit themselves, their implementation is still looks a bit rough around the edges.

[jamesbloomer]

FWIW been using Angular for a while now and found it a pleasant experience: great databinding, easy to encapsulate UI components, can test everything easily. It's very reminiscent of MVVM with the controller arranging the data for the view and all the external logic encapsulated in services.

Although sharing code on server and client sounds like a great idea I'm personally sceptical of this. Each environment has their own requirements. The utopia of sharing code on client and server has been tried before over the years and I've never seen anything that really worked, although that doesn't stop the cycle repeating. Having said that I haven't actually tried something like Browserify yet so my scepticism could be unfounded. Does anyone have any real world experience of doing this?

[gotdibbs]

I definitely agree this whole topic should be something we discuss in greater detail in another forum. Good ideas all around but all very debatable.

[JohnONolan]

Let's get October 14 launch out of the way and then we can set a time and date to discuss properly amongst all :)

[ErisDS]

Closed in favour of #2144