Marionette as a framework

[cobbweb]

Intentionally, Marionette v1 has been quite barebones much like Backbone. It is a library and not a framework. Alongside the v2.0.0 core, I was hoping that we might look at building a framework on top of Marionette.

We could re-use existing Backbone plugins like Backbone.Mutators and other libraries like RivetsJS. Then we'd write an integration layer on top of the core and maintain an official yeoman generator to tie everything together.

The generator would optionally support different technologies like RequireJS, CoffeeScript and various template languages like Underscore, Handlebars and Dust.

We can use best practices from books like Marionette Gentle Introduction, @derickbailey's + community recommendations and learnings from other frameworks like AngularJS to prescribe a recommended way to use Marionette.

The result would be Marionette Framework, but underneath all this is the v2 core which can still be used as a standalone library like v1 is currently; all it would depend on is Backbone, Underscore and jQuery.

Obviously the above plugins, libraries, languages, etc I've mentioned above are open for discussion, I've just plucked some popular examples.

[jamesplease]

I'm not sure if either of these are things that would be good candidates for inclusion in a Marionette framework, but I've been working on two enhancements to include in my Marionette applications: a more robust messaging system and a more generalized finite state machine.

The basics of the messaging system have been flushed out as WreqrChannel, which allows you to group messaging systems into groups called (you guessed it), channels. I realized after-the-fact that it shares some similarities to postal.js if you're familiar with that framework. Marionette touches on this idea by automatically attaching a vent instance to the application. I think that instead of just giving it a vent, that thing should have its own channel. And modules (components) should also have their own channel.

My desire to include a FSM is that Marionette implicitly gives its things two states: open and closed, or started and stopped. At the least, apps, regions, and modules have these two states. I've found myself wanting to give my things more states than that, so I've looked to machina.js.

Again, I'm not sure if either of these things make sense to include in the Marionette core but I thought I'd share the ideas nonetheless.

[cobbweb]

Yea I wasn't sure about Backbone.Mutators, I've used it in the past and it's worked ok. I'm just thinking of features from other frameworks I've liked to make our own. Ember has computed properties, which is why I suggested Backbone.Mutators.

View binding like what Angular has is a nice feature and has been requested here before. Rivets.js is something I've seen before but haven't tried.

I was also thinking Mixins might be a nice feature, like cocktail or Marionette.Behaviour.

WreqrChannel looks cool, is it a more explicit way of creating namespaces for events? (as opposed to appVent.trigger('myModule:someEvent'))

I'm hoping that as a community we can decide if want to go down that path of maintaining a framework too, and what features like these it should have.

[jamesplease]

:+1: for computed values & mixins. Those both seem immensely useful.

And yeah, that's essentially all that WreqrChannel is; more explicit namespacing.

[cobbweb]

Another feature we might add for this is loading views. Not sure what the implementation is like.

[rhubarbselleven]

Being a library and not a framework is a feature and also desirable in itself.

What'd be really nice is a Marionette.ui repo which not only defines common ui views like lists and tables, but also more fun views with databinding (for example).

[Anachron]

Actually imho if you check what Marionette currently represents is a mix of framework and library. Moving towards a framework is not a bad choice, as long as the code is not coupled and good for small projects.

[StevenLangbroek]

I'm just gonna throw in my 50 cents here, all very subjective of course. What drew me into Marionette over something like Angular or Ember (not looking to stir up a flamewar here, just explaining where I came from), is that it does provide the tools necessary to build, let's say, a house, but doesn't prescribe to you what that house should look like, or what type of wood to use, so to speak. I like building houses very much, and I wouldn't want my tools to come with a set of rules that my house is required to follow.

That being said: I love the tools very much, and I would trust the judgement of the company / person to make recommendations about the brand of kitchen to get and what-not. All this leads me to think that there's space in the Backbone ecosystem for a UI-library, which could be (as @rhubarbselleven mentioned MarionetteUI for example) related to Marionette, but not integrated into it. This could contain for example the loadingView that's being discussed, a form-controller, an authentication-controller, a grid-view with inline-editing... pretty much things that are too opinionated for MarionetteJS core.

So sign me up for that :).

On Thu, Jan 23, 2014 at 12:14 PM, Anachron notifications@github.com wrote:

Actually imho if you check what Marionette currently represents is a mix of framework and library. Moving towards a framework is not a bad choice, as long as the code is not coupled and good for small projects.

— Reply to this email directly or view it on GitHubhttps://github.com/marionettejs/backbone.marionette/issues/876#issuecomment-33115342 .

[samccone]

Hey @StevenLangbroek thanks for the input, I agree 100%

So as to Marionette.UI .. something like that is actually coming! see https://github.com/marionettejs/backbone.marionette/issues/869

[darky]

Framework must solve problem of lifecycle application. Here https://github.com/marionettejs/backbone.marionette/issues/840 considered attempt to resolve problem with module managment logic based on route transition.

[diasjorge]

I like the idea of having a "framework-flavored" marionette, since I think you end up implementing something like that on your own apps when they start growing a lot, curating your own plugin selection, reusable classes, etc. I think it should be a different project that uses marionette as it's core and then adds on top.

[samccone]

@diasjorge yes I agree 100%, it will sit on top of marionette and again just be a more opinionated set of conventions upon which to build.

[lukesargeant]

I think having a mission statement or set of goals for the framework would be good. A danger would be to simply add some extra wrapping to Marionette. Perhaps start with a well known popular and powerful framework like Angular and state how it will differ and what it will offer in comparison, and how it will utilise Marionette's library of objects.

[Anachron]

@samccone how's it going here? I would love to see functionality like Epoxy. Few tests were good so far and I like the approach. Could you give it a try?

[samccone]

@Anachron the road to 2 is still a bit out, this issue is going to be open for a while.

[Anachron]

@samccone fine with me, however, did any of you (core developers) take a look at the already existing data bindings? I would love to help, but I think a PR is just overkill, since there is not even a discussion about which library to pull in, if any.

Would it help you if I make a list of possible data binding libs?

[samccone]

I am thinking of making a repo that sits on top of marionette, basically a yeoman generator with general setup, opinions, data binding, and more out of the box.

I still do not think this behavior belongs in "core" but for people that want it we should have an approved way to do it.

[Anachron]

Before deciding for yeoman, get a look at https://github.com/dbashford/mimosa please. I think the framework should be buildtool unspecific.

[samccone]

@Anachron yeoman would be used for a generator primarily

[eth0lo]

I would love the idea of a framework on top of marionette

[cobbweb]

I think having a mission statement or set of goals for the framework would be good. A danger would be to simply add some extra wrapping to Marionette.

Yes this is a great idea/advice @lukesargeant.

I think we've got enough support here to show a framework would be useful, I'm thinking the next step is to decide what features we want in it and how many different setups/workflows we want to support. I'll be taking a good look at other popular frameworks over the next few weeks as part of the investigation.

Just to re-iterate, any framework we come up with will be a separate project from the core library. It will be totally opt-in and provide a means to get people off the ground with Marionette easier with extra goodies and good practices.

@Anachron The framework will probably use Yeoman + Grunt.js, this is pretty common really. I don't see why we'd want it to be build-tool agnostic.

[Anachron]

@cobbweb & @samccone: So this framework will have a generator by Yeoman but won't require Yeoman to be implemented, right?

Here is a list of alternatives that I was checking before Marionette:

• http://angularjs.org
• http://www.trintejs.com/
• http://kmalakoff.github.io/knockback/
• http://emberjs.com
• http://sailsjs.org/‎
• http://koajs.com/
• http://geddyjs.org/
• http://locomotivejs.org/
• http://flatironjs.org/

Maybe this helps when collection for which features would be great in the Marionette Framework. We could name it Strings, as link to control Marionette.

Edit: One more framework.

• https://www.meteor.com/

[cobbweb]

@Anachron Yeoman (or more precisely yo) will be used to generate/scaffold an app using the framework.

Many of those frameworks you've listed are server frameworks. The main ones I'll be looking at are Angular, Ember and Knockout. I've got a rough idea how each works and have glanced over their docs numerous times over the past 2 years but never built anything with them. So my plan is to re-build the same app with each of those and raw Marionette (a bit like TodoMVC but something a bit with sorting, filtering and multiple routes).

[Anachron]

@cobbweb

About yo: Okay, makes sense. Thanks for clarifying.

I'm aware many of these have server-parts, like meteor, but still have client-code as well.

[monzou]

:+1:

The main core competence of Marionette is its modularity. Marionette is the MV* library, not a framework like Chaplin. So I beleve it will be better to keep Marionette-core as an extension of Backbone.

However, as a one of the Marionette user, I wish there would be real world best practices which uses Backbone.mutators, Backbone.stickit and others ... Marionette Gentle Introduction is good, but this is too simple to use Backbone on the real world.

If there are some architecture / framework / best-practices which uses Marionette and other Backbone plugins, it will make Marionette users more happy ! :smiley:

[Anachron]

I just bought the greatest bundle possible on leanpub, 3 books of marionette for 55$!

[samccone]

@Anachron off topic

[Anachron]

@samccone actually it was thought to be a reply to @monzou who said it would be nice to get some best-pratices for Marionette.

But I agree that I shouldn't reply to an offtopic post in the first place.

Ontopic: What's about the suggestion in #885 now? Will we see some of this love in Marionette?

[samccone]

Oh ha looked spammy :) no worries

[cobbweb]

gulp.js has popped up on my radar, looks like a better alternative to Grunt.js. I'm trialling this along with the demo app I'm building in each framework.

[darky]

:+1: gulp

[bgaillard]

Is their any reflections about the new Web Components W3C specifications ?

Perhaps "integrating" the Web Components "Way of thinking" / design into Marionette v2 is too early.

But as Web Components is considered to be "the futur of UI Web Development" if architecture / design decisions have to be taken perhaps it would be judicious to think about Marionette & Web Components working together ?

PS: If this comment is out of scope for Marionette v2 (I suppose it is because Web Components is not supported well in all browsers for now) and polutes a little short term decisions for the v2 do not hesitate to remove this comment. Perhaps the Web Components subject would be a good candidate into an other discussion on Marionette github pages ...

[billychan]

It's easy to get fat and hard to be skinny. I hope you the maintainers to resist the temptation to add fancy features. Let plugins and practice guides to do most of them.

[jamesplease]

@billychan:

samccone commented 12 days ago @diasjorge yes I agree 100%, it will sit on top of marionette and again just be a more opinionated set of conventions upon which to build.

This stuff won't even be in the core.

[billychan]

Great! :+1:

[Anachron]

Anyone interested in making a little diagram about the framework idea?

[ahumphreys87]

Hi guys,

Really like the framework suggestion. Me and the guys in the team I work on have created something like what you are suggesting.

We use libraries like backbone.stickit for data bindings, cocktail for mixins and have locale support. Also have a yeoman generator for it.

Not sure whether we could open source it (not my decision to make) though. I'd love to get involved in this and v2 development. Do you guys have a list of what's planned for v2?

[Anachron]

Poke @samccone @jmeas,- would like to see some progress here. Especially in combination with https://github.com/marionettejs/backbone.marionette/issues/885

[jamesplease]

I like the idea of a Marionette framework, but I know I won't have any time to invest in it for a long time.

[stephanebachelier]

You can count me in to help. But I 100% agree with @StevenLangbroek and @monzou. One of the main advantage of Marionette over Chaplin is its modularity.

[samccone]

@Anachron had my head down for the last few weeks working on the 2.x release. After that is done a bunch of the core people will become available to work on problems like this!

[masterspambot]

If you consider extendeing framework please have in mind aura that integration might be huge step forward as an aspect of including components to Marionette. http://aurajs.com/

[Anachron]

@samccone how is it going here? v2 is out, I would love to get some framework mind maps. :+1:

[jamesplease]

Thinking more on it I'm :-1: to the Marionette framework.

I'd rather see a solid core and then a curated list of plugins you can pick and choose from.

[cmaher]

+1 for a curated plugin list. Maybe plugin creation guidelines or a skeleton plugin project could help?

[jasonLaster]

@cmaher - nice ideas. Skeletons are really helpful

[cobbweb]

My idea for this was always some plugins glued together with a Yeoman generator, on top of the solid core.

[darky]

About theme of framework want to say, that at least needed guide or scheme to use, how to properly link components of Marionette core together and create robust, extendable app. Similary http://docs.chaplinjs.org/

[masterspambot]

+1 for plugin combination - more elastic solution and potentialy more people involved

[monzou]

How about sample app collection using marionette like TodoMVC ?

I made a sample app with marionette (1.x) with some plugins.

[jasonLaster]

Cool app @monzou - I love the idea of having a list of apps that follow good practices. I'd even like to try to use the apps for testing and api improvements... I think if we had a couple apps tha we could all talk about and work on to try out ideas that could be a huge benifit.