Backbone: Backbone Custom Builds

Created on 29 Aug 2012  路  18Comments  路  Source: jashkenas/backbone

I thought a great upgrade for a Backbone 1.0 release would be to split all Backbone Modules (Events, Model, View, Collection, Router, Sync) into separate files and provide users with the ability to make custom builds with a build tool such as Grunt and/or DownloadBuilder.js. What do you think? If you are interested, I would do some work and issue a pull request.

change wontfix

All 18 comments

It would be great.

If you are interested in how I modularized the Backbone.js codebase, check out the customBuild folder inside of my backbone fork. Keep in mind that all of the Backbone unit tests still pass successfully.
https://github.com/gfranko/backbone/tree/modularBuilds

Also, here is an example of how a custom build UI would work:
http://gregfranko.com/backbone/customBuild/

Finally, here is a blog post I wrote to discuss potentially using only some parts of Backbone:
http://gregfranko.com/blog/backbone-dot-js-convincing-the-boss-guide/

I really appreciate the Idea, especially the part where the ruby dependencies are gone & grunt comes into play.

Alos there are situations where I don麓t need Backbone.Router (Cause i don麓t have smth. to route but still like to use Backbone to organize my JavaScript).

Plus, this goes really well with LoDash (uh, hopefully no one feels pissed off) custom builds.

@asciidisco I haven't done the work to integrate custom builds with Grunt yet. Do you have an idea how you would approach that?

@gfranko Would like to see a jQuery like implementation (since 1.8 they have custom builds too),
maybe I fork your project & give it a spin this weekend, but I麓am not entirely sure if I have enough time :(

@asciidisco Don't worry about it. I will look at the jQuery grunt file this weekend to see how they are doing it.

:+1: for modularizing the codebase

While multiple files are often useful, I don't think Backbone would benefit from splitting up the source. The library is rather small, so custom builds will only save a few kilobytes at best while the added complexity would be significant.

For what it's worth, this was discussed at least once previously in #65.

What about use cases, for example, when a user is using jQuery Mobile with Backbone.js, and does not want to include Backbone Routes?

I agree that the default Backbone source should stay as one file, but I was suggesting that splitting up the source into multiple files (I realize this is more work to maintain) could also be added in case a user did not want a particular feature.

Also, I suggested in my blog post that allowing users to not include every feature of Backbone would make Backbone even easier to use in a corporate environment.

And just curious, what would be the added complexity?

What about use cases, for example, when a user is using jQuery Mobile with Backbone.js, and does not want to include Backbone Routes?

Just delete it from the source. It's rather clearly labeled and quite easy to do.

And just curious, what would be the added complexity?

I'm referring to complexity for new and existing contributors. Writing code for a new project is always daunting, and we want to encourage it as much as possible. Currently, Backbone requires only a browser that will serve up local files and a text editor. Requiring a build system/tool is a big step up.

That said, I'm not opposed to custom builds in general and I rather like the tool you introduce in your blog post. :)

You're right, each Backbone class object is clearly labeled (which is why it was so easy for me to split up the codebase). That being said, I don't think most developers want to touch the source of a library they are using.

Look at Require.js and non-AMD compatible scripts as an example. It is easy enough to wrap a lib inside of a define method, but who wants to do that?

But yes, I do hear what you are saying about not trying to introduce too many dependencies/complexities. Guess I will just keep this as a separate project and keep the code up to date with the backbone source.

Yep -- I think it's a really neat project ... but Backbone benefits from being a simple, single script. If you have Backbone installed, you've got it, period, and you can rely on everything that it provides being available.

braddunbar: Just delete it from the source. It's rather clearly labeled and quite easy to do.

Gah, it's a trap! Having an official build system to ensure quality, compatibility, and functionality is better.

jashkenas: Yep -- I think it's a really neat project ... but Backbone benefits from being a simple, single script.

Ya, I dig single files too which is why Lo-Dash is a single file but still supports custom builds (though jQuery makes it work with individual files in its repo).

Custom builds are great and give devs more control. With Lo-Dash and jQuery supporting custom builds the only thing missing is Backbone ;D

Hey,
if any of you guys is interested, I made a grunt plugin to have custom Backbone builds generated out of
the "normal" backbone source files: https://github.com/asciidisco/grunt-backbonebuilder

Not really tested by now (although I run a backbone version with all the router & history stuff left out), which works
well. Feedback welcome.

@asciidisco Thank you, you rock!

It would be nice if we were to switch to browserify or webpack, that way we would have the best of both worlds (multiple files and a single file) easily.

It's would be nice to have Events as separate module. Quite useful when builds custom modules with optional Models and Collections dependencies.

I'm using the Backbone Model and Collection in my Angular and AngularJS projects. I only need the model and the collection because the concept the concept is awesome. I'm using is as the data access layer. Angular is providing the ui layer.

I recently wrote an article about how you can benefit from using BackboneJS in an Angular app: https://docs.google.com/document/d/1ptYmQzjq8EWLKyqFENqyXwzz67VNWzh_-clhy4W5R40

It would be really nice to split BackboneJS into several components to you can include only the stuff that you need.

@jashkenas What about splitting the src files into multiple files and let a build task concat them into one file so you have both:

  • a simple single file
  • and split up source files
    ?
Was this page helpful?
0 / 5 - 0 ratings