#chaplin.js

With the advent of javascript Model-View-Controller like frameworks and libraries, the future of web and mobile application development has become explicitly apparent. Unfortunately, the flaws and limitations of these libraries has also become apparent exposing both positive and negative side effects. For example, limitations in javascript are more evident than ever before as the community actively engages in using it for more than just a simple scripting language or DOM parser -- this is most certainly a positive side effect and has been instrumental in pushing the ES6 standard closer to release. Furthermore, using javascript in this context has given way to the creation of an amazing set of tools, libraries, and higher level abstractions e.g. Node.js, polyfills, enhanced unit testing and debugging, and languages like coffeescript, typescript, and livescript. Conversely, many of the frameworks themselves aren't robust enough to allow for large javascript single-page-apps or make many decisions for you. I've spent a great deal of time with backbone.js during the last 9 months and after reading every comparison of every JS MV* framework out there, I have come to some conclusions of my own. It is my belief that these conclusions are vital to building an extensible, highly reusable, and easily scalable javascript MVC-like framework. These conclusions and thoughts, whilst studying other frameworks like ember.js, knockout.js, and knockback.js, were sprung after reviewing the Backbone.js extensions Backbone.marionette and Chaplin.js in depth. I love the patterns and concepts that Marionette brings forth as add-ons for Backbone but it was the documentation for Chaplin.js that laid way for inevitable epiphany! Most of my conclusions are simply ideas that have been used extensively in the server side frameworks Django and Rails. The ticket is the manner in which we can apply these concepts to the brave new world of thick-client web applications. For brevity, a brief summary of these conclusions and how they are relative have been listed below:

--Must haves for future javascript based web apps. Guidelines are based on using Backbone with something like Chaplin and extending it to take advantage of these concepts:

Decoupled components Chaplins separation of the Backbone.router into a routes file is brilliant and is exactly like Rails. But I much prefer Django's urls.py - they're easy to decouple into plugin/section specific modules. Since i just lost a page of writing due to the shitty ass program i'm going to summarize my idea even more --- make the web app system work like django apps with decoupled routes.js, models.js, controllers.js, list-view.js, detail-view.js. This allows us to simply drag and drop the blog folder into a new backbone application structure, register the controller, and add 1 line to the root routes.js to delegate all urls for accessing blog posts to the blog module's routes.js e.g. in root routes.js -> match 'blog/*params', 'blog#routes' instead of declaring all the routes for the posts, etc... in the root routes.js (urls.py equivalent)

The real power comes from the reusability of this setup. For instance, we still have just one root templates folder, but since our reusable blog plugin will likely already have at least 2 basic templates for displaying posts why not simply set up the templates directory to check for an apps/plugins templates in a nested folder with the same name as the plugin.

Convention vs configuration?? What happened to balance... I want to find some middle ground here: instead of making it painful to setup like Django or hiding all the implementation behind "magic" / implicit methods like Rails, I am going to stick to the initial explicit nature of backone. Some of the more complex low-level details should be "convention" based and implicit so as not to confuse while the rest of the framework should be based on excellent documentation (like django - not backbone) and configuration. -- Should it use common.js or require.js? is AMD important if the entire application is minified, compressed, and bundled into one javascript file? How can lazy loading modules be of any importance when the entire app has already been bootstrapped -- merits investigation! How easy would it be to make that a user choice? Also could really use a yeoman generator package for easy project setup.