Yes, we can definitely do a better job at explaining the concept and how templates work in conjunction with product data. The mechanism is pretty standard for this type of service - all the data that you introduce through the admin is available as template variables. Adding products, categories, vendors, checkout options is simply done through a UI interface. We will add some screenshots of the admin pages to showcase what is available.

Actually the target audience does not need to know any python. Jinja2 is a template engine written in python, however you do not need to write any python code to make the templates work. HTML, CSS and some understanding of how to use the Jinja2 templates to output variables is enough. We should definitely communicate this better!

Web based editing is something that is on the roadmap. FTP and Web Based uploading is available in a lot of competitor’s products and we really wanted to do something different here. Git allows you to have multiple branches, you can work on a new version of the website and showcase that to clients while still not modifying production and have it all integrated in the version control system.

On the pricing - noted! We’ll think of a more compact way of presenting the info.

Thanks a lot for taking the time to review our product! The info is really valuable to us! If you are interested in trying out the full version, send us an email and we will give you the first 3 months free of charge.

What do you think are the best use cases for Backbone Marionette?

I think that it may be simpler to learn than both angular and ember.

Unfortunately, given the fact that it's missing 2 way data binding and it's not declarative, you end up with lots of boilerplate code and in the end you invest more time in writing your backbone application than in learning angular and writing the application in it.

To be honest, I'd only start a new project in angular or ember because they are extremely productive frameworks. Backbone was great more than 2 years ago.

I politely disagree with ending up with more boilerplate code with marionette... you're ending up with _less_ boilerplate code when using marionette with backbone, and even when including marionette, your "boilerplate" code is necessary configuration... binding dom elements, events, template handling, rendering, data serialization... even more so if you're doing it in CoffeeScript.

behold... a view in 3 lines of code.

  class Views.AlbumTracks extends Marionette.CompositeView
    className: 'album-tracks'
    template: 'album-tracks'

In angular you'd never need the line with className, so you'd end up with even less code, because of its declarative style.

A good reading when thinking that's necessary to bind dom elements, events, etc is here: http://stackoverflow.com/questions/14994391/how-do-i-think-i...