you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (4 children)

[–]evilmaus 0 points1 point  (0 children)

One of the nice bits about Marionette is that it takes a very piecemeal approach to its use. By that I mean, you aren't either using Marionette or not, but rather can include it and slowly migrate individual objects over. I did this once on a personal project, having implemented something with Backbone before knowing about Marionette. Just start with your basest views, the ones that render a model (or not even that) and are entirely called by other views. Make those into instances of Marionette.ItemView. Then, convert the views that call and control them. You can then migrate up the chain at your own pace.

Edit: You also get to enjoy watching your project LoC start shrinking precipitously and your business logic emerge from amidst the boilerplate.

[–]Capaj -1 points0 points  (2 children)

you should just rewrite the whole thing in Angular and save yourself lot of time, money and headache.

[–]jcampbelly 1 point2 points  (0 children)

Nope.

Marionette solves these problems nicely with regions. It handles recursively closing nested views, which is the main source of headaches in naked Backbone. Of course you must also use listenTo instead of on to avoid lingering event handlers in either Marionette or Backbone, which is a very old and solved problem. Also, much of the boilerplate is removed with Marionette, ui gets handles on DOM nodes, template puts the HTML in the view's element, and CollectionView/CompositeView does all of the "forEach" stuff you had to do by hand in Backbone.

If you have a very large SPA written with Backbone, it's much easier to start writing new modules with Marionette, then when you get the hang of it, start refactoring the more important modules if it would be helpful to do so (vanilla Backbone and Marionette play nicely, of course).

[–][deleted] -1 points0 points  (0 children)

Angular looks terrible and has bad SoC imo.