extracting Backbone.Wreqr and Backbone.EventBinder in to separate releases

[Derick Bailey]

Hi all,

I had some time to work on some things this week while traveling and sitting in my hotel room. Some of what I worked on was to begin extracting Marionette in to a few smaller pieces that can be used on any Backbone application, and not just Marionette apps. This includes extracting the EventBinder object and the EventAggregator. 

For the EventBinder, I've created this repository in the MarionetteJS github org: https://github.com/marionettejs/backbone.eventbinder

For the EventAggregator, I've created a repository called https://github.com/marionettejs/backbone.wreqr which contains the EventAggregator and also a very basic Command pattern and Request/Response pattern implementation. These three patterns are the core patterns that I've used for many years in building scalable, stateful applications in WinForms, mobile apps, JavaScript, etc. I've been wanting to add the Command and Req/Res to Marionette for a while and I'm already using them in my BBCloneMail sample app.

So now some questions…

Right now the Backbone.Marionette repo hasn't changed at all. I want to try and get Marionette updated to depend on both of these libraries soon, so that we don't have to maintain duplicate code between Marionette and these repos. The real question is what should those dependencies look like? 

I would like to say "these are the dependencies. be sure to include them in your project" the way Backbone does with Underscore, etc. This makes it easier for the Marionette build process, makes it abundantly clear what the dependencies are, and lets the release cycles for each of these libraries vary instead of requiring a new Marionette release with every release of either of these.

What do you all think? Is that a good direction to head? Or would you rather see Marionette's builds have EventBinder and Wreqr stuffed in to the single .js file for you? And if you do, what reasons can you provide for wanting this other than the convenience of not having to grab 3 separate files? I'm especially interested in hearing from others that are building Marionette add-ons, packages (like the rubygem for rails), etc. 

  - Derick

--

Derick Bailey
- @derickbailey 
- http://derickbailey.lostechies.com

- http://watchmecode.net 

Muted Solutions, LLC
- @mutedsolutions
- http://mutedsolutions.com 

- http://backbonetraining.net

[Jarrod Overson]

I'm all for extraction and promoting dependencies, but I think it's going to be important to still have a pre-built Marionette library for ease of adoption and the most common use.

I only say that because it's very unlikely that people will use those components outside of Marionette right now, because they just were separated. If the common use case is people using Marionette which then depends on these components, then the additional downloads and source management are just extra hurdles that don't benefit primary users.

It could easily be part of the current build step, pulling in repos with bower and building them into the distributed lib. That way you could also tie down versions so the other libraries don't need to overly consider the risk of breaking Marionette in future development.

--

Jarrod Overson

--
You received this message because you are subscribed to the Google Groups "Backbone.Marionette" group.
To post to this group, send email to backbone-...@googlegroups.com.
To unsubscribe from this group, send email to backbone-marion...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jason Strimpel]

+1

Visit this group at http://groups.google.com/group/backbone-marionette?hl=en.

[Ruben Vreeken]

+1 to everything Jarrod said.

[Derick Bailey]

I have more questions than answers :P

Is there a way we can get the best of both worlds?

I agree the convenience for the common use is good. but i don't want marionette releases to look like "vX.Y.Z - updated Backbone.EventBinder reference". That inverts the relationship between Marionette and EventBinder, which has a high potential for causing a lot of releases for Marionette when only a dependency has changed. Maybe that's not a bad thing since a bug fix in a dependency can fix bugs in the main library. 

Also - package management systems make that easy to fix. We specify Marionette depends on whatever version of EventBinder, giving it one of the patterns that doesn't tie to exactly a specific release number, but a general version that can be updated. There's two problems here, though:

1) what if the user doesn't use a package management system for front-end JS libraries?

2) what package system do we tie Marionette to, and is that at the exclusion of others?

#1 is still common. I still don't use a package manager for front end JS. If this is the case, do we still need to provide a pre-built package with all the dependencies in place as a single link from the website?

#2 is frustrating because there are too many options. Bower seems to be the smart choice and likely the one that will win… but does that mean we officially support Bower at the exclusion of others?

Lastly - can the convenience problem be solved by more manual means? Maybe a list of downloads as links to the actual downloads instead of just to the website for the project?

I'm probably over-thinking this. I really just want something simple that won't burden us in a release process, or burden the end users trying to get up and running.

  -derick

Visit this group at http://groups.google.com/group/backbone-marionette?hl=en.

[Tony Abou-Assaleh]

jQuery UI depends on jQuery. Apparently they found a process that's acceptable by millions around the world. Can we just follow suit?

Disclaimer: I don't know what their process is, I just download the latest version of both once in a while.

TAA

[Jarrod Overson]

They're good questions and questions that should have good answers for the sake of future JS development.

I don't think a current build would need to be versioned, it would just need a last build date and a list of its components and versions (one of those would be Marionette proper). It would be more convenience than anything.

For people who need finer grain control, they should already be comfortable dealing with higher levels of configuration.

There could even be build options that include jQuery, Backbone, and underscore, too. They're already included in the source for unit tests, this would be just pre-bundling them.

I don't know if that's even appropriate, it just wouldn't be difficult. Travelling across the wasteland for your dependencies is never fun, this would be a one-stop shop for people who just want to get started quickly.

--

Jarrod Overson

[Ruben Vreeken]

Maybe I'm oversimplifying by trying too hard not to over-think this, but would it be an idea to make a stable bundled build version that only really updates if one of its references introduces a change that's big enough to warrant an update (like a breaking change, or a significant new feature you really want to include) and let the small nitpicky updates slide. This bundle could then be like the 'stable/officially supported' version.

Then, a 2nd 'no-guarantees made here' release could be supplied that does not include any of the required external components, and lets you add the latest&greatest versions of those components yourself, at your own risk.

All these great developments in the JS-world sure do make things complicated sometimes... still, these are exciting times! I'm looking forward to absorb whatever knowledge the ninja's have to offer.

--

Ruben

[Robert Levy]

One of the things I find most frustrating about web development is figuring out which versions of which libraries will play nicely together (you can’t even safely assume things like “latest version of jQuery is surely compatible with the latest version of jQuery Mobile”).  It would be nice to not have this problem with Marionette, especially as it gets split up.

 

For daily/test/pre-release/whatever builds, it’s fine to keep things separate if that’s easier for you.  Folks using those builds should be comfortable tracking down and dealing with the dependencies.

 

For ‘release builds’ (however you choose to define that), I’d like to see a single .zip file download that contains Marionette and everything Marionette depends on (including whatever version of backbone and underscore that version of Marionette was tested against).  I understand the extra works this puts on you but think that’s mitigated somewhat by having flexibility in when you choose to do one of these builds.

--

[Derick Bailey]

thanks for the feedback on this, everyone. i really appreciate it and I think i have a good idea of where to head with this based on the feedback.

• I really like Jarrod's idea of having a pre-packaged release with a date stamped on it, which would list the version numbers of each file that it includes
• the suggestion of including all of those files as a single .js file to download might work ok for the files that we control (marionette, wreqr, eventbinder). this could be built as part of the website project, and not part of marionette's build directly.
• maybe having a .zip file of the full stack: json2, underscore, backbone, marionette, wreqr, eventbinder. i would purposely exclude jquery from this, but reference the jquery version # that it was tested with. this could also be part of the website build.
• let the package management maintainers decide what files should be included in their package vs set up as separate packages with dependencies
• always provide raw download links to the individual files for those that wish to go this way

does that sound like a good plan? i think it answers all of the concerns that have been expressed, and can be automated well enough to not be a burden to the marionette team.

  -derick

[Jason Strimpel]

+1

--
You received this message because you are subscribed to the Google Groups "Backbone.Marionette" group.
To post to this group, send email to backbone-...@googlegroups.com.
To unsubscribe from this group, send email to backbone-marion...@googlegroups.com.

Visit this group at http://groups.google.com/group/backbone-marionette?hl=en.

[Tony Abou-Assaleh]

+1