I hadn't seen simpla.io before - the demo seems very nice though and the concept pretty cool, their mechanism for managing the logic behind editable regions seems really clean.

To clarify - ContentTools is not a CMS - it's a front-end tool that provides a more natural editing environment for HTML pages than traditional rich text boxes. You still need a CMS behind it. What I've presented in the Saving Strategies tutorial is really intended to help those looking to integrate ContentTools into their CMS understand how the output of the editor can be stored. The example code in the tutorial could I suppose serve as a basis for someone looking to build there own CMS but I suspect in most cases it's far too simplistic for that purpose.

So coming back to your original question I guess the main difference is that simpla.io provides both the editing environment as well as an API for storage to different platforms (such as dropbox which they mention on the demo page). ContentTools only provides the editing environment - the storage of content and other CMS responsibilities are out of it's scope.

For storage simpla.io provides a remote API which you either need to sign up to use, or which you need to host yourself (you can host there API locally). The simpla.io front-end library sends updates to this API which is then responsible for storing the content somewhere.

Reading the questions at the end of the simpla.io KickStarter page it appears you still potentially need a CMS, e.g to manage the creation of new pages, access control, etc.

So really only the two editing environments are comparable and the best way to establish the difference between them is to try the demo pages on both sites (which I'm sure you have).

Thanks for your question, I hope my answer helps better define ContentTools' role.

Thanks Peter I appreciate your feedback - that's great to hear.

I'm actually in the process of writing a short guide on the subject of integrating ContentTools into your CMS because this question has come up a number of times since the library was released last week.

We currently use the library on a number of client sites (including the getcontenttools website which promotes the library itself). The role the editor plays is determined by the balance of content. On the getcontenttools website new pages are added by creating a new template file in a relevant directory (e.g /tutorials/adding-content-tools-to-your-cms.html) at which point I can navigate to the page and use the editor to populate it with content (IMO it's preferable to writing markup or HTML) - so in this instance ContentTools is pretty much the entire CMS interface (there's a fairly detailed description of how this is done in the Saving strategies tutorial).

However clearly in many cases content is better edited through traditional forms (no one wants to try to build/parse a product discount matrix written using a WYSIWYG editor). So typically in these scenarios ContentTools is used to enhance the functionality of an existing CMS not replace it. For example on an eCommerce site users might add a blog/page/product using a traditional form but when they wish to edit the item's content the CMS would switch to a front-end preview of the item and allow the user only to update the relevant content (e.g the content of a blog article or page, the description for a product).

ContentTools does not attempt to replace the CRUD facilities of a CMS (it's beyond the libraries scope) but rather to provide users with a more natural editing environment.

Hopefully that helps answer your question, if you keep an eye out next week for the tutorial on integrating the library into a CMS I'm hoping top provide some screencasts showing how we've achieved this on different sites.