Backbone Custom Builds #1598

Closed
gfranko opened this Issue Aug 29, 2012 · 16 comments

8 participants

@gfranko

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.

@dnemoga

It would be great.

@gfranko

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/

@asciidisco

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.

@gfranko

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

@asciidisco

@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 :(

@gfranko

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

@caseywebdev
Collaborator

👍 for modularizing the codebase

@braddunbar
Collaborator

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.

@gfranko

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?

@braddunbar
Collaborator

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. :)

@gfranko

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.

@jashkenas
Owner

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.

@jashkenas jashkenas closed this Sep 28, 2012
@jdalton

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

@asciidisco

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.

@jdalton

@asciidisco Thank you, you rock!

@DylanPiercey

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment